Quote:Original post by paic
Google for "occlusion culling"

Not wanting to be picky, but did you mean Occlusion Querys?

Occlusion culling can cover software and hardware algorithms.

There are many differeing ways, however the "simplist" to start you off I guess are....

a) if the scene is small enough, use a regular grid accross it. Linear time lookups, trivial to implement, but obviously not adaptive to the number of items in the grid.

b) As mentioned bounding sphere around each asteroid. Be aware you might not see much performance increase if you're not geometry limited and the asteroids are simple. Of course instead of sphere you could use a bounding box or anything else you have a fast and easy Object in View Frustum test for.

c) Occlusion Querys though I doubt they'll save you much if anything on a per asteroid bases.

As mentioned there are many many more options out there, but to start I'd have a go with option b) and see if it makes any difference. If it does then look into more efficient methods (or post back here and we'll pull up something a bit more orientated to your problem)

Hope this helps,

GOCP

I'd recommend something like a loose dynamic aabb tree, I'm very happy with the performance of my implementation (even though it's not optiomized at all).
You can get some more info and demos in this thread.

zedzeek: Those figures doesn't say much, since there's no info on how many spheres where visible by average.

I agree that if you ONLY need to do culling once per frame AND most of the objects are visible say 50% or more, then brute force is the winner.
If you have a smaller number of objects visible every frame < 10% OR you need to do several frustum checks OR collision queries, then a hierarchial data structure is the winner.
In the samples I provided in the thread referred to above, I did three frustum tests of 10000 moving boxes in 0.5 ms (Intel P4 @ 2.4 GHz), granted the number of visible boxes is probably only around 1%. Furthermore it's slower to update the position in a more advanced data structure (than an array of transforms).
I still thinks it's an invaluable tool to have a dynamic spatial data structure that can be used for different queries when creating real games.
It provides for very fast overlap tests (used for collision detection), raycasts, frustum culling, occlusion culling etc.
I've worked on games were we wanted to have dynamically updating envmaps for the player car, but since we didn't have a fast enough way of determining which objects are visible in each of the faces frustums we had to abandon the idea (the rendering was actually fast enough, though simplified).

Just my 2c