Bounding Box Dx11

Started by
2 comments, last by e3d_ALiVE 13 years, 3 months ago
hy.
I'm creating a scengraph.
I'm searching for documentation to create a bounding boxes,
waht are the difference between alligned and not alligned?
1)Is possible to use parallel reduce with tbb for calculate it?
2)is better recalculate all the bounding box in the scenegraph or simply bind the location and orientation to the node or mesh that have it?
thanks
Advertisement
An Axis-Aligned Bounding Box (AABB) is as its name implies, the box is aligned to the standard XYZ axes. So say you have a model that is longer than it is wide, if you rotate the model, the AABB will not rotate with it but expand (or shrink) to fully encapsulate the model. Because the bounding box isn't aligned to the model, if the model rotates you can get large gaps (and hence false positives when you do intersection tests). E.g take this image for an example.

An Oriented Bounding Box (OBB) on the other hand would keep its shape and be oriented with the model. Consequently these are more computationally expensive than an AABB. This can result in a very tight bounding, but at a lot of cost.

Of course there's the third common volume which is a sphere, that is the simplest since all it needs to know is a radius and a center location. But a large sphere may not represent the model very well (again, large gaps).


Since you're working on a scene graph, you'd probably want a bounding volume hierarchy right? That is, each node of your tree has a world bounding volume that encapsulates all the subtrees that are children of the node. You can quickly cull large sections of the scene by testing a few large bounding volumes - if your scene is well organized that is. I would also bind the bounding volumes to their respective nodes/meshes, and have them take care of updating them. That way, you can minimize the number of times you recompute bounding volumes. Static scenes would only ever have to calculate their bounds once, and whenever a node or mesh's spatial transform changes, then you can make the necessary bounding volume computation. Then the parents of the node or mesh get notified, recompute their bounds, and so on until you get to the root.

An Axis-Aligned Bounding Box (AABB) is as its name implies, the box is aligned to the standard XYZ axes. So say you have a model that is longer than it is wide, if you rotate the model, the AABB will not rotate with it but expand (or shrink) to fully encapsulate the model. Because the bounding box isn't aligned to the model, if the model rotates you can get large gaps (and hence false positives when you do intersection tests). E.g take this image for an example.

An Oriented Bounding Box (OBB) on the other hand would keep its shape and be oriented with the model. Consequently these are more computationally expensive than an AABB. This can result in a very tight bounding, but at a lot of cost.

Of course there's the third common volume which is a sphere, that is the simplest since all it needs to know is a radius and a center location. But a large sphere may not represent the model very well (again, large gaps).


Since you're working on a scene graph, you'd probably want a bounding volume hierarchy right? That is, each node of your tree has a world bounding volume that encapsulates all the subtrees that are children of the node. You can quickly cull large sections of the scene by testing a few large bounding volumes - if your scene is well organized that is. I would also bind the bounding volumes to their respective nodes/meshes, and have them take care of updating them. That way, you can minimize the number of times you recompute bounding volumes. Static scenes would only ever have to calculate their bounds once, and whenever a node or mesh's spatial transform changes, then you can make the necessary bounding volume computation. Then the parents of the node or mesh get notified, recompute their bounds, and so on until you get to the root.


thank Starnick ,very detailed and exaustive .
My problem now is to find the algorithm that does this operation.
in particular the oriented OBB.
The dx 11 have a function that do it?
You know a book or an article ?
for not reinventing the wheel
xna math in dx11 has lots of functions to work with OBB and AABB
check the collision sample in dxsdk
Crazy dude smoking D3D11, AngelScript, PhysX, 3D Sound, Network, DB, FBX, and some other weird things, doing that on Visual Studio 2010 + Visual Assist X on Overclocked CPU

This topic is closed to new replies.

Advertisement