I've got to the stage of my game where I have hundreds of small meshes in a scene, so I wrote a batching class to reduce the draw calls.

For each frame this class takes any mesh below a certain size in the current camera frustum, transforms the vertex data and joins them all together into one big mesh. The algorithm has to run each frame, because the camera frustum is changing each frame and stuff is moving around as well.

Reducing draw calls decreases the amount of work that the CPU has to do, increasing frame rate, but on the other hand transforming the vertex data each frame increases CPU load. So, there is an optimal level, which I found to be around 100 vertices fro mesh size. In other words, I only batch meshes that have less than 100 vertices and that gives optimal performance.

Is anyone doing something similiar to this? Any tips would be appreciated.

Unfortunately I have to use OpenGL ES 2.0. I know there's probably some cool function in 3.1 that makes this a lot easier, but I don't have access to that.

It's normal to use a zone manager for this, so only when a player enters the zone do you check the LODs and batches. Maybe look into Unity's batching and see how it works. There is a lot about Unity that I don't like but it does have one of the best batch managers that I have ever seen.

It's normal to use a zone manager for this, so only when a player enters the zone do you check the LODs and batches. Maybe look into Unity's batching and see how it works. There is a lot about Unity that I don't like but it does have one of the best batch managers that I have ever seen.

Yeah, what I have implemented seems to be the same as Unity's "dynamic batching". I'm not sure what Unity "static batching" is though.

Well, that's good to know anyway. Thanks for the answer.

I'm not sure what Unity "static batching" is though.

Static batching is an offline (or load time) process that transforms the vertices of 3d object instances into world space and stores all vertices into a single vertex and index buffer, so you can draw multiple objects at different places with only one draw call. Of course that only makes sense if the objects can't move at all and can be drawn with the same material. It's pretty much as if you do instancing on the CPU and store all resulting vertex positions in a new vertex buffer. This can easily explode memory requirements though, because a single mesh instanced 100 times in a static batch takes 100 times the memory.

You don't have to regenerate your vertex data as the camera moves around; only the index data has to dynamically respond to the culling results.

That's a very clever idea. Thanks, Hodgman!