What I did for Bouncy Hunters was just to build an octree for the whole level. Then collision detection was a matter of testing all octants the moving object crossed through for each particular movement. Then within each octant, the collision detection was bounding sphere vs the triangles in the octant.

If you don't want to use the same tree structure for your visibility culling as for your collision detection it might make sense to keep two copies of the world: one subdivided for collision detection and one subdivided for visibility testing. It'll use up more memory but most players will make the tradeoff between loading times and in game speed.

Quote:Original post by flery
My question is how to check for collision with the ground. Test every triangle for intersection ? Split the ground into many single objects and then test ? How to exclude "irrelevant" triangles from testing ?

Collision detection can be divided into two phases: a broad phase and a narrow phase.

During the broad phase you determine which objects or part of are close enough to each other that they may be in collision with each other (and discards from collision those who are not). The narrow phase then takes the objects or parts which may be in collision and performs more detailed collision on these, such as triangle vs. triangle tests.

Your question is on the broad phase part. For that the basic idea is to use some sort of spatial partitioning scheme to group together objects that are "nearby" (for some definition of nearby) and to be able to exclude objects that are too far away to be able to collide with your query object.

For example, consider overlaying the world with a uniform grid and associate your ground geometry with the grid cells the ground geometry comes in contact with. Now, to test an object against the ground you check to see which grid cells your object overlaps, then you pass the contents of those cells to the narrow phase. No other ground geometry needs to be collision tested.

There are many different spatial partitioning schemes: grids (both hierarchical and nonhierarchical), trees (octrees, quadtrees, BSP, k-d, etc). You can also divide your ground geometry up into pieces and then form a bounding volume hierarchy around it and then recursively perform tests against this hierarchy (visiting only the parts of the tree that your query object overlaps). And more.

I would suggest starting with something simple, like a uniform grid. Then you can try other methods to see if they perform any better on your particular problem (which isn't necessarily the case).

If you want more detailed advice, you would have to provide much more detailed information about what your ground looks like, how it is represented, what type of collision queries you want to perform against it, how the colliding objects are represented, etc. Basically, there are tons of things that affect what is an appropriate method so, well, don't worry and just pick one.