Hi,
I’ve started work on a free game engine and I have a couple of questions, mainly regarding renderer design and performance. You see, I’d like to make my renderer to take full advantage of OpenGL 2.1. The problem is that even though there are many tutorials that present how to use VBOs, FBOs, GLSL etc., they do not explain how to do it efficiently.
Some background on my engine: I’d like it to be a large, realistic outdoor environment engine, ARMA: Armed Assault being the closest of inspirations, with a target geometry throughput of about 1M triangles per frame. Model polycounts are to be at levels similar to ARMA as well.
So, here’s my questions:
1. How do I organise the scene’s geometry into VBOs to ensure optimal performance? Which parts of the world do I put in which kind of a VBO? How many VBOs should I create?
Here’s my sloppy go at the issue: I was thinking of creating a number of static VBOs and uploading all the world geometry to it.
[ul][li]Terrain VBO: I’d have a fixed pool of vertices for use with the terrain; they’d be put into their positions using a vertex shader VTF-ing the heightmap. A single terrain patch would consist of a fixed amount of vertices/triangles, but would cover a varying amount of space, depending on the LOD.[*]Map objects VBO: all the map objects (i.e. buildings, trees, all kinds of static props) stuffed into one VBO, one instance of each. Have a stream IBO assembled each frame and rendered.[/ul][/li]I have yet to think of what to do with entities (players, vehicles, all the moving parts of the world). Dynamic or stream VBOs?
Do these ideas sound reasonable? Or is there a better way?
2. What’s more expensive, texture binding or program switching? Should I sort surfaces by textures or programs to minimise the number of state changes?
I’ve introduced the concept of materials in my engine. A material object consists of a texture object (an encapsulation of one or more texture names/IDs) and a GPU program ID (all compiled and linked, ready to be glUseProgram’d). I know that binding textures and switching programs are both expensive operations, so I’m going to introduce surface sorting. I’m guessing that in a scene there are bound to be less program than texture changes, so I could sort first by the program, then by the texture objects. How does that sound?
3. Is GPU-based skeletal animation (skinning) worth a try? Say, having the bone motion data dumped into a floating point texture VTF-ed in the vertex shader? Is it widely used or is it still done by the CPU in today’s engines?
Thanks a lot in advance!
IneQuation