Friday Performance Work

The Return Of Instance Stamps

As part of my batching code, I returned to a batching system I did a while ago for the old segments called Instance Stamps. The idea that instances are converted to reference data within a large grid, and the geometry is only created and rendered on a need to know basis.  

I had to heavily adapt it to the dimensions and unique style of the Reloaded level size and preferred ranges, and took all day, but the end result was a prototype that positively eats polygons for breakfast.  My last demo had 7800 combat buildings added all across the world, with HIGH and LOW LOD buildings being rendered in batches only where I was standing at the time. The draw calls where less than 50 and my frame rate was well over 500 fps. yes it included the actual entity shader, but did not include all the other gump required to run a games engine. The real teller was the impact of the dynamic creation as you moved through the world which kept a smooth motion even at 500 fps. One fear of course is that there is so much new geometry being dynamically created that it slows down and jitters the smooth running of the engine. So far, so good.

Next Steps

The two next steps are QUAD buffers for the far distance and OCCLUSION volumes for the stuff immediately around me, drawn front to back starting with the HIGH lod, then LOW lod, then QUADS, and all through the filter of a camera frustum. All these together should allow me to render only a handful of polygons for the view you are current watching, and disregard much of the rest of the level. It should also present very little performance hit as the stuff is created and managed, especially as the front to back sorting is done on a permanent visible object list so only needs to tax the processor when a change is required (which happens in small bursts as you move around and the order changes).

Signing Off

I am happy with the weeks work. Even though my two hour read-up on spacial databases has not contributed directly to the speed up work being undertaken it has given me a sense of clarity on how to approach a situation to gain speed in simple ways. It also means when the time comes to do quick searches based on spacial items in the world, I have this knowledge to fall back on. I even discovered a cool query you can do with spacial databases which is to project a line through 2D collection of boxes and it will instantly report which of those boxes where involved in the intersect test. Much better than a for next loop through every object in range of the bullet ray(s) and can quickly detect when it hits something solid and only check for dynamic entities within that reduced range!  It's the little things that will give us that super smooth performance, and even if I cannot afford the distraction of coding these ideas, making a small note in the source code will ensure I can come back to these little pearls.

I will be attending an Intel Game Fest this Saturday morning for 1 hour to help out would-be Android developers understand the wonderful world of AGK. If you know me, you know I can talk for an hour on practically any subject, but it is usually a rant or a long verbal waffle. Being center stage for an hour and not repeat myself too many times will be a challenge.  Should be a nice end of week distraction to kick-start my weekend.  It's about 1:30AM now and my Hangout is at 5AM, so I am going to prepare some AGK material for half an hour and then spend the rest of the time adding a QUAD buffer idea I just had to my instance stamp engine prototype.  Sorry there is no video or shot, but when I grabbed it, the quality was to 'programmer art' I dare not inflict it on you.  I think the next substantial shot will be a new view of my 'run to the river' demo with a substantially better FPS score :)