If you group your triangles by proximity to one another then you can quickly filter out a bunch of them at a time if you know they are not in your view.

Otherwise, your best bet is to use binary tree to organize everything.

Your triangle count may be reasonably low, but if you just blast them out in any old order it's likely going to punish you on fillrate. Frustum culling 10,000 individual triangles is not going to be very CPU-friendly either, and you need to consider leaving headroom for particle effects, models, etc. So even with such low triangle counts there still remains a lot to be said for doing it the old-fashioned Right Way rather than being lazy (and expecting your customer to pick up your slack for you by buying faster 3D hardware).

Some form of space partitioning will certainly help here. There are well known and well understood solutions for this such as BSPs, Quadtrees and Octrees, which you've already mentioned. You want to be able to reject large groups of triangles quickly before they even get to your GPU, as well as order your scene geometry from front to back (so far as is possible) so as to make best use of your Z-buffer.

Batching your geometry so as to minimise state changes and enable you to submit large groups of triangles with a single draw call is also critical.

I don't recommend use of hardware occlusion queries for this. There is a certain overhead with issuing queries and you need to blaance things finely so that not drawing objects that fail them gains you more than you lose from that overhead. Even worse, reading back the results can stall the pipeline, so you'll need to either accept that or else accept up to a few frames of latency in the results by reading them back those few frames later (which would not be acceptable for your main scene geometry).

The best thing to do is to look at some real-world examples that are known to work, such as the Quake engines, and take inspiration from them.

Quote:Original post by Simon_Roth
10000 tris is nothing on modern hardware! Forget about space partitioning. Dump them in a VBO. Use frustum culling if you must.

Seconded. I've used 20K+ triangles per mesh before without barely taxing the GPU. Mind you I didn't have too many meshes on the go at once, but still- 10K is nothing.

The only optimisation I'd recommend you to do beforehand is to sort the triangles by texture so that you can render all triangles of the same texture in one batch. State changes in the graphics driver can be very expensive.

Other than that, unless this starts becoming a performance problem I'd suggest not to bother optimising at all. That goes for everything else too.

'Premature optimisation is the root of all evil...' [wink]

The trouble is that this isn't a mesh. It's all of the scene geometry. Walls, floors and ceilings. Triangle counts are not the relevant item here, it's fillrate and overdraw, and we are deep in overdraw city.