Good days progress.

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 polys	VBOs	Fixed Function
18,872	24ms	33ms
112,680	24ms	110ms

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.