SUCCESS!

So, it turns out that VBO's are very fast indeed. Keeping arrays of vertices on the GPU side means very little increase in rendering time with a raw increase in polygons. Here is a table of results,



Num polysVBOsFixed Function



18,87224ms33ms



112,68024ms110ms



The first mesh, with 18k polys, is a hill made using subdivision modelling. The second is the same mesh, after being subdivided to another level, thus multiplying the number of tris by nearly 6.

It's pretty clear that using VBO's cuts the cpu -> gpu bandwidth considerably, and I didnt notice much of an overhead from building the array. This is an awsome success, but it is early days for serious benchmarking because,

• it is only with a few textures, and large blocks of the file using the same texture. More sorting of VBO's by texture will be required to keep these speeds.
  
  
• There are still some overheads in the code caused by some of my braindead STL container choices.
  
  
• No use of shaders. Every triangle is being rendered with a single texture and a diffuse colour of (0.7,0.7,0.7)
  
  
• As yet no culling is being done, the entire file is being renderered. This means I still have long render list gathering times. The sight distance is far further than what would be practical ingame, as the mesh is 4,000 x 500 x 4000 meters in dimensions, and I plan to use fogging and a close far plane to give the player a view of no further than 800 meters in any direction.
  

I expect that the final render times will be more affected by the shaders and other tricks I use than by polygon counts.

Issues to be resolved

Thanks to the use of VBO's I no longer need to construct octrees in order to cull the internals of one chunk. A chunk will have several things in it:



Object type:
How loaded:
How culled:
Notes:



Unique Geometry
Stored in file as list of vertices
Single chunk of approx 128^3 culled
Stores several VBO's, one per texture.



Brush Geometry
Stored as {Matrix,Octree }
OCtree compared to frustum
Also stores lights, which will be culled as per lights in unique geometry



Entities
Loaded from database
entities which are loaded will have their own triggers for when to work.




Dynamic objects
Same as brush geometry, but with a seperate table of physics only meshes
Bounding Sphere
Stored in database rather than in the actual file format. Placed in in-game editor



Creatures
Not sure, probably stored in database with resource files loaded in one big gulp
Bounding Volume Heirachy





Task for tomorrow:
Design file header for first prototype of file format. This should have a list of all the chunks and where each one starts in the file.