bounding volumes
I'm about to implement bounding volumes into my engine but I'm not sure of the best way to go about it. The volumes I want to use for collision tests are: box, sphere, cylinder, and mesh. My question is, should the engine automatically create all 4 of these volumes for every object created or should I set it up that one particular type of volume is used for each object, which would be specified upon creation.
[edited by - TheJakub on August 9, 2003 12:46:42 PM]
It depends on how many collision detection routines you want. If you give each object only one volume, and want all objects to be able to collide with all others, you will have to write a separate collision detection routine for each pair of volume types, including pairs of the same volume.
Mesh to Mesh collision testing is _very_ difficult.
It depends upon what you are writing, but I would suggest giving each object only one simple volume (eg box, cylinder). If it wants a mesh, give it that also.
I would always check the basic volume collides first, and only if it does, check mesh collision if required.
The way I would do it, I would implement box-box, box-sphere, box-cylinder, sphere-sphere, sphere-cylinder, cylinder-cylinder and mesh-box, mesh-sphere and mesh-cylinder. Avoid mesh-mesh unless you really need it. The non-mesh ones are fairly easy.
Expect the mesh collision routines to be slow. But the simpler the mesh, the faster the routine will go.
Mesh to Mesh collision testing is _very_ difficult.
It depends upon what you are writing, but I would suggest giving each object only one simple volume (eg box, cylinder). If it wants a mesh, give it that also.
I would always check the basic volume collides first, and only if it does, check mesh collision if required.
The way I would do it, I would implement box-box, box-sphere, box-cylinder, sphere-sphere, sphere-cylinder, cylinder-cylinder and mesh-box, mesh-sphere and mesh-cylinder. Avoid mesh-mesh unless you really need it. The non-mesh ones are fairly easy.
Expect the mesh collision routines to be slow. But the simpler the mesh, the faster the routine will go.
I see what your''e saying. As for the mesh volumes, what I was thinking was a simplified convex mesh primitive that would encapsulate the original game model. I was originally only going to go with box, spehere and cylinder but someone I know showed me that a simple mesh surrounding an object would work better in some cases than a box or sphere would. I think a good example would be a triangle. A seperate bounding mesh could be constructed in a 3d modeling package to be used instead of the traditional primitives. I guess my problem is I want to be sure that my collision detection runs accurately enough in the games I decide to make.
Hm..
Well what I''m doing is making Boxes, but then representing my meshes with a lot of smaller boxes (OBB tree). What this does is you still get the speed of boxes, but, assuming your representation of the mesh with the boxes is good enough, you still get a very accurate collision model.
Walt
Well what I''m doing is making Boxes, but then representing my meshes with a lot of smaller boxes (OBB tree). What this does is you still get the speed of boxes, but, assuming your representation of the mesh with the boxes is good enough, you still get a very accurate collision model.
Walt
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement