Quote:Original post by taz0010
You're best off using different structures to handle different tasks. Octrees work well with view frustum culling and intersections between moving objects and the static scene. This is because you can generate the octree to be a near optimal fit with the geometry by increasing the node depth in more detailed areas.
For intersecting pairs of moving objects, it's not efficient to just rebuild the octree to handle dynamic changes in spatial locality. Instead you can use a sparse grid combined with bounding volume hierarchies. This method assumes that the density of intersecting objects is very low. If you had dozens or hundreds of objects bounding against each other, then resizing the octree on a per frame basis would be faster.
I agree with taz0010, this is a good approach. You could have bounding volume hierarchies for all moving and static objects, and for objects that are animated (for example a character), you can bound the convex hull as another skin to the same skeleton, so the collision geometry will always be synchronized with the rendered geometry.
@Sappharos
Here is a bit of pseudocode about how I see the collision response code:
class SceneObj{ virtual void Collide (SceneObj * obj);}class Character : public SceneObj{ void Collide (SceneObj *obj) { //handle this object's response, not obj's response switch(o->type) { case CHARACTER: handle character against character collision case LEAF: handle character against leaf collision case TREE: handle character against tree collision } }}class Leaf : public SceneObj{ void Collide (SceneObj *obj) { //handle this object's response, not obj's response switch(o->type) { case CHARACTER: handle leaf against character collision case LEAF: handle leaf against leaf collision case TREE: handle leaf against tree collision } }}class Tree : public SceneObj{ void Collide (SceneObj *obj) { //do nothing as trees dont react to leaves and characters }}
