[fixed]BoundingBox problem
Hi all,
first of all let me show you the problems:
Here is collision detect/block path from one side of Arc
1)
And here the same thing but in other side of Arc.
2)
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]
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..
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..
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
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 :)
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 :)
anyway Fixed :)
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 :)
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 :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement