[fixed]BoundingBox problem

Started by
3 comments, last by repka3 14 years ago
Hi all, first of all let me show you the problems: Here is collision detect/block path from one side of Arc 1) c1 And here the same thing but in other side of Arc. 2) c2 And now my steps for accomplish the block path: 1)Compute boundingbox with D3DXComputeBoundingBox only at initialization of each entitis. 2)Everyframe I trasform the Max and Min point to world space with: //================================= //Bounding box coordinate in world space D3DXVec3TransformCoord( &mBBoxWorld.maxPt, &mBBox.maxPt, &mWorldMat ); D3DXVec3TransformCoord( &mBBoxWorld.minPt, &mBBox.minPt, &mWorldMat ); 3)Everyframe check aabb collision, if any: 3.1) D3DXVec3TransformCoord( &RayPos, &RayPos, &worldInvTrans ); D3DXVec3TransformNormal( &RayDir, dir, &worldInvTrans ); HR(D3DXIntersect((*it)->getMesh(),&RayPos,&RayDir,&hit,&FaceIndex, &u, &v, &Dist,&allhits,&numHits)); If hit and if dist<Min_distance I block the movement. Now the first question: 1)Is this the right way ? The things go quite good except for collision show in figure 2. 2)The computed boundingbox is computed( :) ) when mesh is not animated, so like you can see in figure 1 the aabb is smaller then model. (The black cross is just a little mesh positioned in mBBoxWorld.maxPt) 3)And for figure 2 what do you think is the problem? Why bounding box ar so small for arc ? Bye and thanks for you time;) [Edited by - repka3 on April 3, 2010 7:52:22 PM]
My dev blog: gameluna.blogspot.com
Advertisement
uhm.... transform points with world matrix can rotate AABB which can become OBB.. right? the standard AABB test may fault..

so ? which is the best way to translate aabb in model space (computed with D3DXComputeBoundingBox) in world space without recompute everyframe ? (i think computing this every frame is a problem for performance right?)

thx..
My dev blog: gameluna.blogspot.com
wrong model for character representation? Or just use an OBB. You appear to be running at >600FPS so performance doesn't currently seem to be even remotely an issue for you.

Usually one uses capsules for humanoid bi-pedal entities because it's a relatively cheap check and there's no recompute for rotation. For coarse grain CD a lot of games ignore limbs that protrude through the collision bounds (why in a lot of games you see toes/arms penetrate nearby geometry.

Or just forget about it and integrate PhysX and let their library worry about it [smile]

-me
Thx! Do you know where can I find some examples for capsule bounding volume and aabb/capsule collision? I googled a little but nothing appear :)

And yes i know performance is not a problem but i like learn the right things cause this is the reason for this project.. Learn :)
My dev blog: gameluna.blogspot.com
anyway Fixed :)
c3

computing aabb only at initialization, then everyframe:

1)compute the 8 corners of aabb in modelspace
2)transform the 8 corners into world space (OBB)
3)get aabb from this 8 corner

work quite well, if i will find something for capsule bounding volume i will try to implement it.

Thx to all :)
My dev blog: gameluna.blogspot.com

This topic is closed to new replies.

Advertisement