Monday, May 26, 2008

Terrain shaping up

The last couple of days I've been toying with a new terrain. I'm thinking of an island with some far away mountains and some harbours. I've put up some preliminary screen shots here. With the new terrain editing features it's really easy to quickly create some nice looking terrain. I should really record some movies of it...
When working on that I found a couple of problems in Ember though. The first was that it used massive amounts of memory. A prime source for this seemed to be the fact that it created a lot of both bitmaps and textures for all of the terrain, which it then never really used, but had lying around anyway. That prompted a refactoring of how the terrain worked which removed most of these instances. While doing that I also realized that we're quite wasteful in how we use full 8 bit bitmaps for all of the layers in the terrain, even if one layer might be the snow, where the 256 steps allowed by 8 bits never are used. To improve this we should combine many layers into one bitmap, where perhaps the grass layer is allocated 64 values, while the snow only is allocated 8 values, and so on. This would only work with shaders though.
After refactoring the terrain texture system I found that it still gobbled up memory, but I haven't run any good benchmark yet. I'm however guessing that it's the Mercator system which is initialized in full when the world is loaded, and then never has it's data removed. Preferrably, we should only load the Mercator segments on demand, and we should only keep those most used around and unload the others (perhaps by keeping a time stamped cache). It should work very much like the Ogre PagingLandscape system works.

I also quite alarmingly found that Ember currently is leaking memory. Just by starting it up and having it running without connecting to any server makes it allocate 2-6Kb/s. Something is seriously wrong here. I need to hunt that down and fix it.

When searching for the cause of these things I did some alterations to the logging system, making it not shut it down so early in the shutdown process. I also cleaned up the headers and moved some classes to separate headers. The logging service is included in pretty much every other file in Ember, so making it slim is good for compilation performance. Unfortunately the changes I did to it will force an almost full recompile after updating...

I also ran into a really strange problem with mouse picking in the terrain when testing out my new island. The picking is simply off. It's however working as it should the Mason world, which makes me think that it's either something to do with the fact the the island world is much larger, or that it's in a non-square form. I'll have to investigate it further.

This week also marks the start of the coding period for the students, which is really exciting. I'm looking forward to see how they'll evolve as they more and more into the WF system.


roger said...

When will be possible to create the world from Ember side and store it in the server?

Erik Hjortsberg said...

Al is working on adding better support to cyphesis for persistence, but I cannot say when that will be done.

Apart from that, one of the Summer of Code projects is about creating a much more powerful entity creator which will allow you to store "entity recipies" on the client, and then use these to quickly populate the world.

There's already an "export" function though, which will let you export any arbitrary entity to an atlas xml representation. There's however now way currently to easily load the xml again.