Hey, been working on a lot of things all at once so I couldn't manage to get a stable build yet, so today I'll do a short preview of thing to come. Did not have time to investigate the Meteor engine this weekend, but I do have my monitor back and working.
First, I optimized a little the rendering pipeline. There is now one less CPU matrix multiplication per object and shaders are starting to get optimized for pre-shaders. Considering that for single render target shadow mapping you are rendering things at lest two times, that can mean two CPU matrix multiplications per object. I also optimized the shadow mapping part of the rendering pipeline and it uses even less multiplications than normally are needed for rendering.
What I forgot to mention last time is that there is now support for fine tuned control of render targets. You can render normally, into a new render target, into multiple, etc.
I also optimized the load order of the texture streaming system to first load all diffuse maps, the all bump maps, the all specular maps. This way even if the load time is exactly the same, loading seems faster because the more important maps are brought in with less delay.
Then I started working on model import/export. As said, loading 7 models with a total size of a few hundred KiBs takes 3.2 seconds. Unacceptable! By my calculations, a busy scene might take over 20 seconds just to load the meshes. I really did not want to resort to a custom binary format for storing meshes, but in the end I had to. I wrote a fairly lengthy mesh importer/export specially for static meshes (no bones/no animations). In the future I might add support for bone animations to the format. Here I had the opportunity to get rid of another bone multiplication. See, the exported mesh is exported weirdly and you need to take into account the first bone transformation, and also the standard loading process that I want to bypass computes normals and tangents, but again based on this bone information and... I have no idea what I'm doing! So the bone information is stored into my custom format (but animations are not) and still used because I couldn't convert the normal and tangent information into something that makes the rendered output look the same.
Anyway, loading time is now 10 milliseconds. Let's compare the two values: before it was 3200 milliseconds, now it is 10. 320 times faster. Even if I load 10 times as many meshes, it will still take only 100 ms, so I think we're done here.
And now the great advantage of my system becomes apparent. You can modify a mesh/texture and by pressing a hot key in game the assets are reloaded on the fly, without having to exit the game or reload the level. Currently everything is reloaded, but adding support for the file modification time-stamp is trivial so I won't bother with it :).
I also further enhanced the procedural building generator, but it is still at least a week away from its first underwhelming version.
Then I tried to do something about the horrible back sides of objects that are facing away the light. I think some form of global illumination is needed, but that exceeds my current level of knowledge, so I hacked together a shader that is not particularly convincing, but still looks better and performs OK. There is just one particular graphics bug with it and currently I am not sure if the technique is flawed or it has to do something with my custom mesh import. Once I figure it out and decide if the technique is good or not, I'll list all the advantages and disadvantages.
Finally, I tried integrating XNA Procedural LTrees.
But enough word-thingies. Let's bring out the screen! First, we have a normal scene with traditional one directional light = sun lighting:
The backsides are too dark and you can't see the bump mapping. Now the after shot, with the new shader:
Better, but still not great. I need to investigate that visual bug and decide if this method is a keeper or not.
Finally, let me show you a closeup of the procedural tree:
It uses the same technique to keep the backsides from going dark, but it is not normal mapped (yet). Also, the leaves are billboards, so going close to the tree and spinning the camera around causes the typical billboard display bug.
The system comes with a few tree species out of the box but currently only one can be loaded at a time. On the other hand, every single tree is unique. It is not the same mesh repeated over and over and... I made a few tests, and generating 400 trees (not pictured) takes a few minutes and eats up over 600 MiBs of RAM, so clearly each tree can't be unique, not even on small maps.
No comments:
Post a Comment