Sign in to follow this  
DarkScript

Collision detection and maths...i need help

Recommended Posts

DarkScript    127
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
Xpyder    120
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
DarkScript    127
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
haegarr    7372
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
DarkScript    127
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
haegarr    7372
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
haegarr    7372
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
DarkScript    127
i would like to check if this idea has problems...
question is:how do games create all these meshes and collide with each one with a different way?...e.g.when the player hits a door it opens(his health doesn't get affected),when he hits an enemy while that enemy is attacking..his health changes

im thinking of making that:
std::vector<D3DXMESH9> Enviroment(0);
std::vector<D3DXMESH9> Enemies(0);

and create a bounding shpere 3 or 4 times as large as the players original bounding sphere and if any of those meshes in any array of the two is in that bounding sphere....i put in the test we talked about later(a test for each subset) and if i collide with an enviroment...if its a door and closed..open it...if its opened....close it,if its an enemy and idle....do stealth attack...if its attacking..and im not evading...health goes down...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this