Another Fine Day

Not only is it shining outside, but it's shining inside too thanks to some cooperate static batching code I wrote not too long ago.  With some other minor lightmapping task tweaks out the way I plumbed on to get common local static objects to group together before the lightmapping step. Worked out much better than I had hoped, and the upshot is that draw call count has been reduced.  You will notice in the following screenshots that although the draw call count went down, so did the FPS score. This is due to the slightly more expensive static shader I am using to lightmap the objects, and the addition of the shadows on the terrain which comprise of four terrain shaped objects.  Once I have optimized the static shader a bit more, I should be able to gain this back and of course over a larger scene with more common static objects I can glue together the benefit increases exponentially over the pretty flat cost of adding the terrain shadow geometry.

You will notice this scene has no shadows and each of those small plants is a separate entity thus a separate draw call.

After the lightmapping process, we have batched some objects together and now we have saved 72 draw calls (really 76 but we added four terrain shadow objects for the shadow casting over the floor).  Almost halved the draw call count, and for scenes which use lots of very small and similar entities, this saving will become quickly apparent.

Of course it's all for naught without a noticeable increase in frame rate, and my mission Friday will be to apply this new batching technique to The Escape level, which is a real game level with real challenges when it comes to what renders are important and which ones are redundant.

There are still some artifacts to deal with such as the brush trig plants casting a rectangular shadow and the glass terrain technique showing a faint edge where the non-shadow area is not completely white (1.0), but I am happy to leave these smaller issues until the larger issues have been tackled.

My next primary targets for performance improvement are inside the occluder and the render order systems.  They are somewhat related and so I am tackling them together, and providing VTune agrees with me, these will yield plenty more FPS points by the end of Friday with a little luck. Some minor tasks also remain if I get the above finished such as reducing the memory footprint of font images and going through the engine to make very small improvements based don notes I have made as I tackled neighboring areas but put to one side to avoid the distraction.

One last bit of news before I sign off and start my usual 4PM team call.  I discovered that I have not been handling my normal maps perfectly thus far. This article really describes the issue:

http://www.codeproject.com/Articles/10897/NormalMapCompressor-A-tool-to-automatically-compre

The problem is that the normal map formats used so far both internally and externally are all over the place, using uncompressed, DXT1 and DXT5.  Do I change all my normal maps (AND SHADERS) to use this new R->A swizzle to get a better normal map. If I do, does that means everyone in the store needs to change their normal map files, or do we have two sets of files, and two sets of shaders, choices choices!  I personally want the best visuals, and this technique will provide it, but it also means upsetting the status quo and potentially a LOT of re-exporting of normal maps on our official assets and the thousand plus entities already on the store.  Interesting times!