Optimisation Fail

This is a maintenance/progress blog post so nothing exciting really. I just try to post a few times a month as any developer keeping a journal should.

I got rid of the vertex buffer and texture resource pools and created a mesh pool and each mesh has its' own vertex buffer and textures so the same thing is accomplished and the mesh resource manager is now way simpler. I used to have std::maps with pointers to the meshes in each list depending on what stage the mesh was in (needs building, built, and visible, cached and cache build) - now I have 3 std::vectors for 3 lists: needs building, built and visible.

The lists are stored in an array like this:

std::vector mMeshLists[3];

The built and visible lists are in index 0 and 1 and I swap them periodically like this:

mVisibleListIndex = (mBuiltListIndex + 1) % 2;

And the build list is always index 2.

Unfortunately, the app is still too jerky. Creating the textures on the graphics card is taking too long, generating the heightmaps is taking too long and it's not smooth even though I'm using threads for all the non-opengl stuff. Most of the time spikes are now happening in Ogre so I will probably have to add some profiling there to figure out what's going on.

Also, I switch over to DirectX 9 so that I can use NVidia's Perfhud tool to help me analyze how the graphics card and cpu are being utilized. That's been fun.

The only major bug I have at the moment is that the Render To Texture code that generates the terrain texture for each patch isn't working in DirectX right. My dynamic heightmap texture is not being created correctly and I don't know why yet. I have been experimenting with different pixel formats to no avail yet.

I'm almost thinking of doing another simpler version of the quad tree planet that uses geomippmapping and the planet size is restricted to 1025x1025 vertices per side - or maybe 2049x2049. This terrain is taking too much of my time to code that should be spent on other important game things!

Debug Mode Really??

Minor amendment to the previous post - I was running in debug mode hence the poor fps, and when I switched to release the framerates jumped up to OSX levels (300 in space and about 80 at surface). I expect the framerates to be lower at the surface with all the texturing going on so I'm OK with it for now

Also, I've been viewing my profiling stats with Open Office and I have to say their charting tool is faster than Numbers, which I had been using on OSX. Not suprisingly, I'm seeing spikes when the terrain textures are created. To help with this I think I will implement a resource pool for the textures and try any other optimizations I can think of.

Lastly, I fixed the yellow/black stripe texture bug. Ogre displays that yellow/black texture when there is some kind of error with the texture you tell it to display. In my case I was asking Ogre to use a texture that I had destroyed when a mesh was cached and had not recreated when that mesh was reclaimed from the cache. In the future I should make sure to cache everything a mesh needs along with the mesh to optimize the speed of reclaiming from the cache - of course there is a speed/memory usage issue as always.

Diffuse Texture Applied to Planet and Performance Issues

I finally modified the quadtree planet test program to use textures that are generated on the GPU for each mesh. It's a lot more intensive then I had hoped - each mesh uses its own height map, slope map, texture map etc. Basically I took the simplest approach and ran with it and the results showed that texturing is possible, but the performance is now a major issue. On OSX I was getting 300+ FPS near the surface and more when out in space, but in Windows Vista I've been getting 90 FPS in space and as bad as 4FPS at the surface. Not to mention the time it takes to update the meshes with the added strain of the texture generation is way too slow.


This screenshot near the surface shows the poor FPS and also how at the surface the textures are too blurred. I can increase them but performance is bad at the surface already.

I haven't started debugging the performance bottle necks because I just wanted to get it working first, but now I think I've arrived at a point where the performance is so bad that I can't continue without fixing it.

One thing I ran into that is Ogre related is that it is a bad idea to call manualRender() from within the _updateRenderQueue() function (possible recursion issues?) So I took all the mesh building functionality that had to happen in the main thread and moved them out of the _udpateRenderQueue() function and into the application update() function.

The only obvious remaining graphical bug I have yet to figure out is the yellow/black striped textures I'm getting when pulling away from the planet when cached meshes are being drawn (I'm probably releasing a texture and not re-creating it).



*sigh* I miss having a good looking planet so bad. Can't wait to get it pretty again.