foreach (Myobject in my scene that are inside the Frustum and are visible)
{
// unproject the clicked point to 3D position using the current object ObjectSpace-->WorldSpace Matrix transformation
_RayStart = Vector3.Unproject(_RayStart, DeviceManager.NoaDevice.Viewport, CameraManager.Projection, CameraManager.View, Myobject .World);
_RayEnd = Vector3.Unproject(_RayEnd, DeviceManager.NoaDevice.Viewport, CameraManager.Projection, CameraManager.View, Myobject.World);
_RayDir = _RayEnd - _RayStart;
_RayDir.Normalize();
if (Geometry.BoxBoundProbe(Myobject .BoundingObj.minBorder, Myobject.BoundingObj.maxBorder, _RayStart, _RayDir))
{
// Object Clicked !
}
}
Simple mouse Picking question/remark.
Hello,
After a lot of reading around, I choosed to use a mouse picking method using AABB (axis aligned bounding box) around my various objects.
Everything is working correctly !
So, You could ask why I'm here ?
A couple of questions arised while doing the dev. of this part of my engine :
1) Why do we call AABB "Bounding Box", for my its more a bounding Square, as the resulted geometry from an AABB computation is a flat geometry (rectangle most of the time) ?
2) I read a lot concerning this probleme : If your AABB boxed geometry does rotate,move or scale then you must recompute a new AABB box. That's the most "strange" things for me.
In my engine, the object vertex in the object space are never changing, if an object need to move its local World matrix will be changed that's all !
Here are the steps I'm using, to see if an object has been clicked or not :
This way, no matters what's the position/size/scale of the Object and the world space, the picking mechanism is always working.
Am I doing something wrong ? What is the drawback of this method compared to the others (Recompute the Bounding box everytime the world matrix of a geometry is changing) ???
AABB is an acronym for Axis Aligned Bounding Box and, as the name implies, the box is aligned to the world axes. So, Box A is OK, Box B isn't:
This makes determining if two boxes a really easy task.
Now imagine that your game objects have an AABB each and that one object is long and thing (a daschund). Assuming it is initially pointing +X and yu've got an AABB like Box A above, what happens when the object turns to face another direction? It's geometry will stick out from the AABB and so collision detection won't work. So the object looks like Box B above, but that's not an AABB so a new AABB is made to fit the rotated object. This is a slow step as the geoemetry has to be evaluated in collision space to get the new extents. Just finding the AABB for Box B won't work as the box's size would grow continuously.
Skizz
y| ------ | |A | | ------ /` | /B/ |__________`/______ X
This makes determining if two boxes a really easy task.
Now imagine that your game objects have an AABB each and that one object is long and thing (a daschund). Assuming it is initially pointing +X and yu've got an AABB like Box A above, what happens when the object turns to face another direction? It's geometry will stick out from the AABB and so collision detection won't work. So the object looks like Box B above, but that's not an AABB so a new AABB is made to fit the rotated object. This is a slow step as the geoemetry has to be evaluated in collision space to get the new extents. Just finding the AABB for Box B won't work as the box's size would grow continuously.
Skizz
Hello,
I'm alright with you. You are computing your bounding box in the world space.
But that's not what i'm doing.
I will add that I'm only doing this for mouse picking, not between object collision.
I compute the Bounding Box around an object in the Object Space, in my engine, the object in this space will never change (The X,Y and Z value from the object vertices will never change).
It means that the computed bounding box around this object will always be good ! (As the object cannot move/rotate/... in the object space).
Now, sure, my object can turn/rotate, ... but this is done in the World space.
in this case all my object does have a local World matrix with the corresponding translation/rotation/scaling to apply at the object in the object space.
The "trick", I'm using at the testing for collision between the mouse Ray and the BoundBox is that I have to Unproject the mouse ray to the Object space using the object local World Matrix (not the general scene World) !
Until now, its working really fine and it's really quick, but I'm maybe missnig something ...
I'm alright with you. You are computing your bounding box in the world space.
But that's not what i'm doing.
I will add that I'm only doing this for mouse picking, not between object collision.
I compute the Bounding Box around an object in the Object Space, in my engine, the object in this space will never change (The X,Y and Z value from the object vertices will never change).
It means that the computed bounding box around this object will always be good ! (As the object cannot move/rotate/... in the object space).
Now, sure, my object can turn/rotate, ... but this is done in the World space.
in this case all my object does have a local World matrix with the corresponding translation/rotation/scaling to apply at the object in the object space.
The "trick", I'm using at the testing for collision between the mouse Ray and the BoundBox is that I have to Unproject the mouse ray to the Object space using the object local World Matrix (not the general scene World) !
Until now, its working really fine and it's really quick, but I'm maybe missnig something ...
There's nothing wrong with what you're doing. I was just describing the idea behind AABB, which is not the method you're doing, you're just doing BB. This is fine. However, you may get erroneous results when objects overlap visually (one behind the other) and the ray test hits the bounding box but misses the geometry of the object inside the box, if you see what I mean. There are various options available to solve this.
Skizz
Skizz
Heps,
Sure, I known that the bounding box doesn't fit at the perfection the object.
Different possibility here : If the bounding box test succed, I could those more finest testing like base triangles one.
But nomatters, the first thing I would like to do is draw 3D cards, and create a game like "Magic The Gathering" in 3d. So the bounding box is the ideal and perfect solution for this :p
just one question : Why the Bounding box I'm using is not a AABB ? I'm only using 2 vector3 variables to store it. So If we look at the object space, the box is AABB.
The only thing is that instead of making the Bounding Box change when the object is moving, I'm applying the invert of every changes done at the object in the world to the computed Mouse ray !
Sure, I known that the bounding box doesn't fit at the perfection the object.
Different possibility here : If the bounding box test succed, I could those more finest testing like base triangles one.
But nomatters, the first thing I would like to do is draw 3D cards, and create a game like "Magic The Gathering" in 3d. So the bounding box is the ideal and perfect solution for this :p
just one question : Why the Bounding box I'm using is not a AABB ? I'm only using 2 vector3 variables to store it. So If we look at the object space, the box is AABB.
The only thing is that instead of making the Bounding Box change when the object is moving, I'm applying the invert of every changes done at the object in the world to the computed Mouse ray !
The AA in AABB generally refers to world axes, that is, no transformation is required to test the AABB's of two objects to determine if they intersect. Object space BB's have to be translated into world space in order to do an intersection (or one translated into the object space of the other). AABB is generally used for object-object collision detection as opposed to ray-box (e.g. mouse picking), the latter tends to use bounding spheres instead.
Skizz
Skizz
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement