Paths

Jayr have been adding more and more excellent media as well as overhauled the media repository layout. He's been moving source files into an "art" directory, so that the "3d_objects" and "3d_skeletons" directories only contains exported formats. This is great since it means that client developers that only want to get access to the used media, without being burdened with having to download a lot of high res source media only need to check out the two latter directories.

With the new media in Ember it becomes more and more apparent that I really need to spruce up the terrain rendering code. As can be seen in this screenshot the terrain really looks awful in the distance when the LOD kicks in.
This is because it's using vertex shading, where the lightning is set by interpolating the normals of the surrounding vertices. As the number of vertices change with the LOD the lightning becomes messed up. All from the beginning the idea has been that this is a purely temporal solution and it should be replaced with a more robust lightning solution. I've just never had time to implement a better model and thus it's been this way for some time. But with jayr's great looking media it becomes more and more jarring.
I've thus started looking into how to better this. There are a couple of different techniques that can be used, with shaders, normal maps and all. Currently I'm experimenting with just creating a one channel shadow texture from the terrain normals I can get from Mercator (compared to the direction of the sun). This won't take into account occlusion though since no ray checking is done, but hopefully it would look good enough (it would actually look pretty much like normal vertex lightning). We want to update the shadow dynamically as the sun moves over the sky, so we can't use too computing intensive techniques.
With some upscaling and perhaps some gaussian blur I think the result will be good enough.

Another pet peeve of mine that's been bugging me for some time was a bug with the foliage code where it didn't take into account "negative" ares, such as the path and the sty, where there should be no foliage. The result was that foliage was added everywhere, even in places where there should be no grass growing. I've been trying to fix it for a while but couldn't find what was wrong. I finally tracked down the problem to a en error in what lookup container for terrain surfaces was used. So now we finally have clear paths! This together with the work I'm doing on nicer terrain shadows should allow for some much nicer visuals in the near future.

Normalize!

The last couple of weeks Jayr have been providing really great new textures. The biggest improvement is that he's created both diffuse, normal and specular versions. This together with a some nice shaders allows us to get some really nice visuals in Ember. There's already other media in Ember that uses normal mapping, such as the trees, but we now have a much wider variety of textures, as well as a better naming system. This together with improvements to Ogre's material framework, chief amongst them inheritance, allows us to much easier implement and handle the normal mapping.
Here are some example screenshots:


These show the new fern model (the colour is a bit off against the ground, that will be adjusted) as well as the new normal mapped texture for the tinderbox.

Getting the fern out in the world highlights the problem with the ugly lightning on the terrain. The problem is that I'm currently using vertex lightning. This has some disadvantages in that it won't work with the level of detail system, since far away terrain have fewer vertices, thus screwing up the lightning. There also seems to be a problem with the normals, such as terrain that shouldn't be in shadow is in shadow and so on. All and all it's not a good way of doing terrain lighting. The reason however that I haven't switched to a better model (such as baked texture lightmaps) is that I first need to refactor the terrain generation framework. The current framework works, but it's hard to do things like add different materials depending on whether you have shader support or not. We need a better framework. I've created a blueprint for this. Once this is done we can start working on some much better terrain. I'm pondering whether to actually put this on top of my things to do, since getting a nicer terrain will make the visuals tremendously better (since the major part of the screen is covered in terrain).

You will also see the new status widget in the upper right. He's actually also provided normal maps, though I'm not sure how to use them yet. :)

Missing files

I had some people try to build and run the Ember source by themselves. It turned out that apart from some missing media files (such as the whole gui texture file) some of the xml files for CEGUI wasn't conforming to the schema specification. The reason I haven't noticed this before is that CEGUI can use many different backends for parsing xml. It can use either expat, libxml, xerces or tinymxl. Very nice component design there and all. But I had always compiled it with tinyxml, which as the name implies is very tiny and don't have any validation support. All incorrect tags are just read as they are. However, if CEGUI was compiled with Xerces instead, which is quite large and has schema validation, the loading would fail since Xerces would throw an exception when encountering invalid xml. And this is precisely what happened when other people tried building Ember, since they had CEGUI compiled with Xerces support. I've now fixed the issue and committed. I have to do a 0.5.1rc2 release soon though, since the modeldef format has changed, disallowing the use of the 0.5.0 media with cvs ember.

On the icon front I've gotten even further with the drag-n-drop functionality. There are some small usability bugs still left, but overall I think it's quite usable. I've been starting to think of how to improve the entity context menu. Currently it's just a regular menu that pops up, but I'm thinking of having a radial menu with icons instead.