Jump to content
  • Advertisement
Sign in to follow this  
DarkScript

Collision detection and maths...i need help

This topic is 4759 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This thread is clear from the subject....im using d3d9 and i use bounding collision...the idea i want to implement is if they collide...i make a more advanced test...its faster than making the advanced test everytime....any help??

Share this post


Link to post
Share on other sites
Advertisement
Do you mean you want a more sophisticated way of collision detection than just a bounding box?

Try bounding boxes for each subset of the mesh - that way it is a lot more accurate

Share this post


Link to post
Share on other sites
greate idea for some of the objects....but when it comes to an FPS ur game needs a more accurate detection methode....and in d3d u can't make a bounding box except for a mesh

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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
one more question....wat are the AABB OOBB???

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
A quick google has shown these as possible introduction points:
http://home.planet.nl/~monstrous/tutskel.htm
http://www.okino.com/conv/skinning.htm

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!