Red box : yellow box :: collision box : ??
by Rubes · in Torque Game Engine · 07/11/2006 (9:45 pm) · 6 replies
Hoping for a little basic help here...
In the World Editor, objects are highlighted by bounding boxes. These boxes can be red, yellow, green, or blue. I'm not really interested in blue or green boxes right now.
Once an object is selected in the World Editor, it displays a red box and a yellow box. The red box is an "object-aligned" box that essentially shows the object's collision box. Then there is a yellow box. The yellow box is a "world-aligned" box that shows "which objects are selected as a group" (per the online docs). In the image below, from the docs, two characters are selected, the two with surrounding red boxes. The yellow box surrounds both of those characters to show they are both selected:
The yellow box does more than that, though. In the image below, Kork is standing near a door object. The door's red and yellow boxes overlap, since it's the only object currently selected:
Now, if I rotate the door 90 degrees, the red box (which is object-aligned) rotates with the door, but the yellow box (which is world-aligned) stays put, and actually expands to encompass the rotating red box:
After this rotation, the player (Kork) can run around and collide with the door the way you would expect (dictated by the red collision box). But in this rotated position, what space does the yellow box now define? The bounding box?
In the last picture, the yellow box intersects the green Kork collision box. This intersection causes the engine to call the Armor::onCollision() routine, signifying a collision with the door object even though Kork is not really near the red collision box. But even though Armor::onCollision() is called, Kork can still walk right up to the door's red collision box before bumping up against it.
So I'm just a little confused at the difference between a collision triggered by contact with the yellow box vs. a physical collision dictated by the red box.
After reading through Matt Fairfax's collision tutorial (which is a bit above my head), I'm guessing that the onCollision() routine is called because of the overlap in bounding boxes that is detected through the Convex::updateWorkingList() method. But I would guess that the finer details of actual collision are handled later. Is that close?
In the World Editor, objects are highlighted by bounding boxes. These boxes can be red, yellow, green, or blue. I'm not really interested in blue or green boxes right now.
Once an object is selected in the World Editor, it displays a red box and a yellow box. The red box is an "object-aligned" box that essentially shows the object's collision box. Then there is a yellow box. The yellow box is a "world-aligned" box that shows "which objects are selected as a group" (per the online docs). In the image below, from the docs, two characters are selected, the two with surrounding red boxes. The yellow box surrounds both of those characters to show they are both selected:
The yellow box does more than that, though. In the image below, Kork is standing near a door object. The door's red and yellow boxes overlap, since it's the only object currently selected:
Now, if I rotate the door 90 degrees, the red box (which is object-aligned) rotates with the door, but the yellow box (which is world-aligned) stays put, and actually expands to encompass the rotating red box:
After this rotation, the player (Kork) can run around and collide with the door the way you would expect (dictated by the red collision box). But in this rotated position, what space does the yellow box now define? The bounding box?
In the last picture, the yellow box intersects the green Kork collision box. This intersection causes the engine to call the Armor::onCollision() routine, signifying a collision with the door object even though Kork is not really near the red collision box. But even though Armor::onCollision() is called, Kork can still walk right up to the door's red collision box before bumping up against it.
So I'm just a little confused at the difference between a collision triggered by contact with the yellow box vs. a physical collision dictated by the red box.
After reading through Matt Fairfax's collision tutorial (which is a bit above my head), I'm guessing that the onCollision() routine is called because of the overlap in bounding boxes that is detected through the Convex::updateWorkingList() method. But I would guess that the finer details of actual collision are handled later. Is that close?
#2
07/12/2006 (6:35 am)
Not that I know of either, but if I continuously rotate the door with a function that adjusts its Z rotation using setTransform, you can see that Armor::onCollision is called whenever the yellow box (and not the red box) intersects Kork's green box.
#3
In this image, Kork's box and the object's yellow box intersect, but there is no intersection with the object's red box. Nevertheless, my scripts show that in this situation the Armor::onCollision() routine is being triggered with that object as the collider.
07/12/2006 (11:06 am)
Here's an example:In this image, Kork's box and the object's yellow box intersect, but there is no intersection with the object's red box. Nevertheless, my scripts show that in this situation the Armor::onCollision() routine is being triggered with that object as the collider.
#4
When collision checks are performed, there is typically a check against the axis aligned box performed first, before more precise(and costly in speed) checks are performed.
When more than one object is selected, the editor adds in the extent of the axis aligned boxes of the other objects, to create an axis aligned box that encompasses all of the selected objects.
So your initial approximation is more or less accurate. Although i'm not sure why onCollision is being called specifically for the yellow box (when your object is rotated)... must be the way that particular object has implemented collision checks perhaps?
07/12/2006 (11:45 am)
The yellow box the representation of the axis aligned box that encompasses the whole of the object (in a shape, this would be determined by the bounds in the dts file and the scale of the object).When collision checks are performed, there is typically a check against the axis aligned box performed first, before more precise(and costly in speed) checks are performed.
When more than one object is selected, the editor adds in the extent of the axis aligned boxes of the other objects, to create an axis aligned box that encompasses all of the selected objects.
So your initial approximation is more or less accurate. Although i'm not sure why onCollision is being called specifically for the yellow box (when your object is rotated)... must be the way that particular object has implemented collision checks perhaps?
#5
In the image above, the object (objAlmsBox) is an Item object, while the player (objPlayer) is your basic Player object from starter.fps. I think it's something unusual about the Item class and the way it handles collisions. I suppose Items were originally designed to exist as things like powerups or ammo that rotate, and thus it may have been simpler to use the axis-aligned box (which encompasses the rotation) to determine when the player collided with an Item for pickup so it would disappear.
When I changed the object above to a StaticShape, it no longer calls the onCollision routine when contacting the yellow box, but it does when contacting the red box.
07/12/2006 (11:56 am)
Thanks, James, that sounds like what I understood from Matt Fairfax's tutorial. You're right, though, I'm not sure why onCollision is being called there.In the image above, the object (objAlmsBox) is an Item object, while the player (objPlayer) is your basic Player object from starter.fps. I think it's something unusual about the Item class and the way it handles collisions. I suppose Items were originally designed to exist as things like powerups or ammo that rotate, and thus it may have been simpler to use the axis-aligned box (which encompasses the rotation) to determine when the player collided with an Item for pickup so it would disappear.
When I changed the object above to a StaticShape, it no longer calls the onCollision routine when contacting the yellow box, but it does when contacting the red box.
Torque 3D Owner Peter Simard
Default Studio Name