D3D provides the convenient computation of either a bounding sphere or a bounding box (don't know whether it is AABB or OOBB), as far as I know. So other volumes, like a cylinder possibly good for arms and legs, may be left to be computed by yourself. (However, implementing a collision test between too many possible shapes of volumes could become problematic.)

Normally you don't need to be very exact in collision detection, so it could be sufficient to build up a hierarchical bounding just by primitives: At the lower level e.g. a sphere for the head, a box for the body, boxes (or even cylinders) for the arms and legs. Smaller intersections or gaps are normally neglectible. However, you should deal with _aligned_ boxes to be exact enough.

If you want a really exact testing, you have to use ray - mesh intersection, but that would be very costly, of course.

Quote:Original post by DarkScript
what i need to do is:
1-create every subset as a mesh
2-make every child object move or rotate with its parent(riging)
3-test with every subset

The thing you've described above is the usual forward kinematics. I suggest you to do so if (and I assume so) you are using animations.

Quote:Original post by DarkScript
wat are the AABB OOBB???

BB is the abbreviation for Bounding Box in general.

AABB means Axis Aligned BB. If all BB's are AABB's (with, to be precise, all aligned to the _same_ axes), then it is very easy to test them, since the test reduces to at most 6 1-dimensional tests. However, they normally produce too big volumes if used in a body hierarchy as you are about to do.

OOBB means Object Oriented BB (sometimes named shortly OBB). Here the boxes are aligned to the _local_ co-ordinate frame, and hence rotate with the local objects. In other words, OOBB are BB's that participate also on the forward kinematics as the particular meshes do. So they are closer to the mesh, but need also more effort in collision detection.

Sorry, I don't have any such suggestion. I could only give some topical hints. However, I assume the inet is full of such stuff?!

Whether you actually need skeletons depends on the animation system you are about to realize. Looking at an object hierarchy, you have related co-ordinate frames given. With this you could already drive forward kinematics. A skeleton could be understood to add constraints to such a system, e.g. "the origin of upper arm is fixed" or "the ellbow could rotate about local x-axis only in-bewteen 0 and160 degrees". You need a skeleton in this sense especially for _inverse kinematics_, where you need to automatically adapt the ellbow and shoulder if you position the hand.

Looking at games, you can see that some of them uses predefined animations, importing just a defined series of posings and playing them back. Such a system does not necessarily need to have skeletons; for them forward kinematics is sufficient w.r.t. the bounding volumes (in fact the animation itself does not need forward kinematics itself).

You could also make a "free" animation system with forward kinematics alone, e.g. by defining the angles of all hinges. However, this way normally yields in unnatural looking movements if not spending several of hours on making them smooth.

A quick google has shown these as possible introduction points:
http://home.planet.nl/~monstrous/tutskel.htm
http://www.okino.com/conv/skinning.htm