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.

CEGUI Ugliness And UML Diagrams

Yes, I looked at the Taharez and Windows skins before settling for the "Vanilla" skin. Lesser of three evils no? Integrating CEGUI (Crazy Eddies Graphical User Interface) was somewhat painless but there are some definite quirks with the code and the layout generator tool that I ran into:

• When you deactivate a window in CEGUI your subsequent calls to getActiveChild() will still return the deactivated window.


• The layout generator tool undo system does not seem to work and the copy and paste functionality is also finicky.


• The use of a data directory for the layout tool is not intuitive to me. It should just use its' own program install directory and save the .layout files where you indicate via the save file dialog - isn't that the main purpose of the tool? Why confuse your average n00b by asking them where they want their data directory to be when they install? It's not like you can easily change the data directory if you select the wrong location as I found out.


• CEGUI window skins seem to stretch by default so I will eventually have to figure out how to make them pixel perfect and resolution dependent where needed.

The reason I needed a GUI was that setting the 8 different blend properties for the 16 different layers was going to be a pain to do (and slow) by keyboard alone. I also wanted to see how easy it would be to work in what seems to be the "go to" Ogre GUI (it gets used in several demos). The GUI allows me to move the sliders that adjust the values in the look up table (or I can type the values in by using the edit boxes and pressing 'Enter'). When values are adjusted the terrain texture is automatically updated and the screen refreshes to show the new texture. I use the mouse right click to toggle between GUI mode (when the mouse cursor is revealed) and fly mode (when the cursor is hidden and the mouse controls where you look).

After integrating the GUI I realized how complicated this little tool had become and that in order to un-complicate it and make it easier to integrate into the planet engine that I would need to break out the UML tools (I used OmniGraffle Pro) in order to get a good look at the architecture.



As you can (or cannot) see, it's a tad complicated for what looks so basic by the screenshot and I'm not even including all the getter/setter functions. To integrate this with the planet engine I think I will make the render to texture a singleton helper and if I bring the GUI over then I'll probably make a GUI class that receives input from the InputHandler and then translates the GUI actions into application actions. The InputHandler will be responsible for non-GUI actions like movement, screenshots, quiting the program etc.

Sorry this isn't a very exciting post, but it was necessary. I'm going to try and get the quadtree test program running on Vista and then try to integrate the new terrain texture process. See how I said that in one sentence? It will probably take me weeks to get running right.

Oh and I should say I'm excited to see that Steve Streeting (the main dev behind Ogre 3D) appears to be working on some terrain improvements to Ogre which I plan on dissecting. You can follow his tweets at http://twitter.com/sinbad_ogre. Mine are at http://twitter.com/petrocket.