Summertime is coding time

Worldforge has been accepted to the Google Summer of Code, which is really excellent in many different ways. Not only will we now get a student working on the code while being paid by Google, we will also get some nice publicity. I've already seen a sharp increase in visits to our sites after Google announces the projects that were approved two days ago. More information about this can be found in the wiki. We've also set up a new forum dedicated to the program.
For prospective students it's worth noting that the project ideas put forth in the wiki page are just suggestions. As such we really encourage the students to either expand on the suggested projects or to submit new projects. The forums are perfectly suited for such discussions.

Other developments lately have been that Sean Ryan has checked in his first code contribution. He's been working on adding logging of in game chat messages to text files in the user's ember home directory, something which might be handy for seeing what's transpired in the world. His code was solid and functional which always is good to see. Getting into the code can be quite daunting since there's so many different sub components used, but he's managed to navigate it all, with a little help.

We've also now completed the conversion from cvs to git. While the cvs repo will remain for some time, all new development now happens through git. Kai has done all the heavy lifting with setting up the server and all. A very nice web interface of it all can be found here.
In order to get the latest development version you should first do

git clone git://git.worldforge.org/ember.git ember

which will checkout the latest code to a new "ember" directory. To keep in sync with the latest changes you would then do

git fetch

More information here.

All over the place

The last couple of weeks I've been all over the code base, working on different things each day it seems. I've upgraded Caelum to a newer version, fresh from svn. It gets better and better. New in this one is nicer sunsets and sunrises, but the same code which make that so nice also produces a little to large halo during the day. But overall it looks nicer and nicer.
I fixed some long standing but rare bugs, such as a crash when you had deleted an entity with the entity editor and wanted to look at another. I also fixed a very spurious problem where sometimes chat messages wouldn't appear in the console. Turned out that the lua garbage collector sometimes destroyed the connection object which binds chat messages to the console output. Garbage collected languages can be very nice, but when there's a problem like this it's really hard to track down due to the nature of the unpredictability of the destruction.

I also spent some days restructuring how media is handled. This is mainly a problem for other people wanting to help with the development. Since it's only been me for quite a while it's been quite easy: my box contains the latest dev media. But as more people get interested we need a better way of distributing the development media. In contrast to the release media this is very much in flux and is often updated. The new solution is to use a rsync service at amber which always will contain the latest media. By using the new make target "devmedia" it's possible for other developers to get the latest media by simply typing

make devmedia

and rsync will take care of it all. Furthermore I've removed the configure variable MEDIA_VERSION in favour of getting that information from ember.conf instead. This makes it much easier to configure and won't require a total recompile every time the media version changes. This is just one move towards a better media system. I've already added some blueprints on how I would see the media system getting even more dynamic.

The icon rendering works nice and all when there's FBO support on your GPU, but when there's not there are a couple of issues. The current way of solving these is to delay the copying of the render information one frame and then blitting it to system memory and then to the icon atlas texture. However, the Ogre::Viewport class has the ability to render into just a smaller section of a larger texture. This would be perfect for the icons, since then we could render directly into the icon atlas. So I implemented that, only to find out that there's either a bug with how it works, or that I've totally misunderstood it. The problem is that every time a full frame render occurs, this seems to mess up the whole icon atlas texture, and renders junk data into all sections that don't have a viewport assigned to them. It seems the problem is that it either gets repainted by mistake, or that it's intended behaviour. I need to research it more closely, but for now that functionality is deactivated in favour of the old way of rendering icons.

It seems that I with regular intervals goes through the code looking for places where I can refactor it to better fit with updated behaviour, or simplify structures and methods that works like a cludge. Just basic cleanup. I spent one day doing that too, adding some nifty methods and classes to the configuration service as well as adding a new time service which can be used to both get local and server time. Should come in handy.

I've also evaluated both git and monotone. They both seems to have pretty much the same functionality, but I just like the feel of git better, so I'm gonna migrate all of Ember into that. We'll still keep the old cvs as read only, but all new development will happen in git.

Currently I'm working on adding an overhead map. It's good progress, but there are some different approaches to it. I can use CEGUI and do pretty much all of it with CEGUI elements. Or I can use Ogre overlays. Or use the Ogre compositor system. There's pros and cons with all of these, so currently I'm just getting a feel for it. There should be a working version in some days though.

Oh, and today is the day that Google announces the projects that it has accepted for the Summer of Code. This year we applied, so hopefully we've gotten a slot. But you never know.

Reeds

With the new terrain foliage system it's now very easy to add new layers of foliate by just altering the .terrain xml file. Yesterday I set out to try this by adding some reeds to the world. We've had textures for reeds for a while, done by zzorn, but since there hasn't been a good system for adding them to the world they've been unused so far. Adding them now was however trivial. We want the reeds to grow by the water, and only there. They are also very much like grass, so they should use the same rendering technique as the normal grass. Adding them to the world was thus as simple as editing the moraf.terrain file so that the sand layer definitions looks like this:

<layer shadername="sand" diffusetexture="3d_objects/environment/ground/textures/sand/sand_AD.png" normalmaptexture="3d_objects/environment/ground/textures/sand/sand_AN.png" tilesize="8">
<foliage planttype="grass" populationtechnique="cluster" rendertechnique="grass">
<param key="minClusterRadius">2</param>
<param key="maxClusterRadius">10</param>
<param key="clusterDistance">25</param>
<param key="density">2</param>
<param key="falloff">0.6</param>
<param key="material">/global/plants/grass/ducktail/single</param>
<param key="minHeight">2.0</param>
<param key="maxHeight">2.5</param>
<param key="minWidth">1.0</param>
<param key="maxWidth">1.5</param>
<param key="swayLength">0.25</param>
<param key="renderTech">quad</param>
</foliage>
</layer>

This tells the terrain system to add foliage to the sand layer, and the sand layer only. It also tells it to use the "cluster" population technique for placement, and the "grass" technique for rendering, using the "ducktail" material. The other parameters should be pretty self-explanatory. The end result can be seen here:


Not too bad. The main point here though is how easy it is to alter and add new foliage layers. Worth noting also is that we used the built in cluster populating technique, but this would be a prime candidate for using Mercator Areas. By using areas, the world designers would have much greater control of where to put the reeds, and it could also be possible for players to affect them in the world, for example by using a scythe to cut them down.

Yesterday I also committed some performance improvements to the foliage engine, mainly by using batch stores for the sub areas, thus avoiding having to iterate through all plants for each geometry page.
I stumbled upon a bug in the entity editor which caused a crash when deleting entities in the world. It was however an easy fix (don't hold on to deleted entities...) which I will commit later today.

New skies opening up

I've spent the last couple of days updating the version of the sky system Caelum that Ember uses. We've been using an almost two year old version, and there's been some nice recent improvements to it. It turned out to be fairly easy to do, some classes and interfaces had changed, but all in all it was a straight forward update process. The end result is a better looking world, if I might say so myself. The sky model has been refined, and support for clouds and sky transitions is more smooth and robust. One interesting addition is that it now uses an astronomically correct earth model, where both earth position and absolute day must be specified. This opens up some nice possibilities for virtual worlds, since it then is possible to specify where on the earth sphere your world should be placed, and get a different lighting model. A world placed at the north pole would have a very different day-night cycle than one placed at the equator. Alternatively, the server shouldn't assume that we're on an earth sphere and could instead just specify direct values for night and day cycle, as well as the sun's trajectory over the sky. That would require us to create our own solar system model classes to be used by caelum, but it's certainly doable. But there's a certain simplicity to just letting the server specify the longitude and latitude that's quite alluring.
Another issue is how to present the world during night. In the current caelum implementation it just gets darker, until you can't pretty much see anything. This isn't very nice for players, and would probably force them to always manually set the time to noon to be able to see something. Instead we want to provide a world that's as clear during the night as it is during the day. WoW does this splendidly, and we need to adapt something similiar. But until then we'll use the current hack, where the time of day on the client always is adjusted so it's sometime around noon, even when it's in the middle of the night on the server.

Another thing that's I've committed is some updates to the PagedGeometry system where it now uses classes specifically tailored for Ember, which renders near objects as entities while switching to imposter rendering for far away ones. Previously we had to use the DummyPage class and use the Entity::renderDistance functionality for hiding far away entities, but now that's all smoothly taken care of by classes which work directly with the PagedGeometry engine. There are still some issues with both performance and updates that needs to be taken care of, but it works much better now.

On the Worldforge front, there's two new exciting developements which has unfolded the last couple of weeks. One is that we now have a new Ember developer, Sean Ryan, who's just starting out getting a feel of the Ember code base. He's already taken upon himself to implement event logging as an initial task which is an excellent way to start.
The other development is that we're applying for the Google Summer of Code this year. We've already set up a wiki page for this purpose and will gladly accept any applicants or project ideas. If you think this is something for you, or if you know someone that might be suited, please get in touch with us, preferrably by using the mailing lists.