Horde3D

In my current project, my artists have started to become very ambitious with the level geometry. It is clear to me that the manual optimizations that are possible with the engine will no longer suffice. I was thinking of a flight sim where the player flies over mountaintops obscured by clouds, they're thinking massive canyons and caverns, which sounds tons more fun than my idea.

So I was thinking of ways to automate the optimization process, and one thing I thought of was to actually build it into the collada converter. When writing out the mesh nodes for a model, it could be possible to apply an optimization technique to the mesh such as a Quad or Octree instead of breaking the mesh up soley by materials as it currently does. However, after looking at the code I am still rather confused as to where I would drop an algorithm. Not to mention my knowledge of algorithms in this field are not my strong point (and quite frankly, never have been )

Has anyone else explored this possibility and can offer some advice?

Are you sure you really want an octree? If you have a flight simulator, you will always see a huge part of the world from above, so a standard octree over small meshes might not bring much. Traversing trees can even be a lot slower these days than just looping over linear but memory-coherent lists.

An easy alternative could be that you split your world into a grid where each cell is a single model/collada file. You could switch between different models depending on the distance to get some efficient LOD. It would also be a lot easier to stream in new cells if required.

This is actually a pretty good point. But what about larger mobile models? It is not a traditional flight simulator so much as it is fantasy/fiction (steam-punk, not cyber-punk), so objects can range in size to the small single person fighter to gargantuan floating cities. In the latter instance, I think an optimization structure would serve a better purpose, especially if it is being combined with bullet's bounding volume optimized convex meshes.

I will bring up the fixed grid idea to them, but I am fairly certain they would want some sort of automated solution regardless of how the world is optimized. I know I would prefer this as well.

Hi Orm,

Would hardware occlusion queries help here at all? Geometry already has AABB's which get tested by the frustum, and the occ query would cull things based off the zbuffer from the previous frame (delay might not be good for you in those situations where you do many camera changes). Following Marciano's idea of gridding up the world might be good, the low lod representations if far enough away could even just be a texture with all the stuff baked in to bring down draw call budgets.

I'd like to try my hand at making a software occlusion query implementation with very low res geo and small zbuffer (hell, even sneak in a tile determination buffer for sparse virtual textures maybe) but I have a lot on my plate at the moment (like that GL ES 2.0 port when I get time).

_________________
-Alex
Website

Interestingly enough there was a bigger problem with the optimized geometry than just one big chunk of geometry. The level designer I am working with took a heightmap and exported it out to a single mesh, and the single mesh rendered significantly faster than the heightmap loaded in with the Terrain extension. So I think that in this case, breaking up the world into the grid would be the best course of action. That and me getting out of the artist's way might help as well.