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,
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:
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.
