Bounds scaling

#21 I have no idea about the programming specifics, but I can see other problems with animating the collision box. Say you're standing close to a wall with a small collision box. What would happen if you performed some action that would quickly enlargen it? Either you'd "bounce" off the wall, or you get stuck.

In either case, an animated bounding box is probably a bad idea (other than in the case of ground transforms, but that's a special situation so I won't go into that).

#22 Hmm ... I thought I had bounding boxes worked out but after reading the thread I am not sure now.

I had read that the exporter bounds was used to basically say - 'export everything inside me'.

Then, Torque automatically made a bounding box just big enough to excompass the objects geometry regardless of the box used in the modelling tool (set the box size to whatever you want and then look in showtool).

To get the actual in game box, for players, you set the bounding box size in the playerbody datablock

...
   boundingBox = "0.8 0.8 2.4";
...

and for other objects you needed to use a collision mesh bigger than the object if you want a bigger bounding box than the one that just fits geometry.

Or is this not correct?

#23 That bounding box size that you just defined there in the server side player.cs controls the collision data. This box is grown from the pivot position defined by the bounds.

#24

Quote:I had read that the exporter bounds was used to basically say - 'export everything inside me'.

Then, Torque automatically made a bounding box just big enough to excompass the objects geometry regardless of the box used in the modelling tool (set the box size to whatever you want and then look in showtool).

This is incorrect. The bounds is really used to basically say "use my local coordinate system and pivot point as the local coordinate system and pivot point for the whole DTS shape". There are other functions as well, as I mentioned in my above posts.

The bounding box in the ShowToolPro, as far as I can tell, is misleading and not useful. It is basically an "extents box", that I'm guessing gets created by the showtool itself, and is never used in the engine. Am I right?



Logan-

My impression was that that "boundingBox = " statement is a scaling effect, on top of the dimensions of the bounds box you supply in the original model, and not an absolute size. Is that not correct?

#25 I have yet to see this otherwise but to my knowledge the bounding box variable in the server side player.cs does indeed define the collision test that the game engine will use. The engine "grows" this box from the position of the DTS bounds pivot, which is why it is super important to ensure that the pivot is positioned right on your object, if it isn't you can get some pretty funny collision and clipping issues happening (hence why I have a big issue with scripts that autobuild the "Bounds" shape).

Logan

Edit: Just as a follow-up to the bounds question. You guys are both sort of right with the bounds node. It does indeed define the local world for the object, with the pivot acting as the DTS shapes local coordinate information for collision shapes and position in the game engines world. With the export process though you do need to ensure that everything not just what you want to export (with the exception of sequence helpers) falls inside of the bounds for a successful export, the export dislikes it when stuff flys outside of the bounds (like in an animation).

#26 @Logan

Quote:With the export process though you do need to ensure that everything not just what you want to export (with the exception of sequence helpers) falls inside of the bounds for a successful export, the export dislikes it when stuff flys outside of the bounds (like in an animation).

That's what I had thought but then when Jeff had stated that this was not the case I went back and resized the BB of one of my models so that the BB did NOT encompass the model throughout its entire range of animations and it exported fine and played the animations correctly.

#27 I just did a test. And you're right, Logan. I was wrong about that. The boundingBox variable in the player.cs is indeed the absolute size of the collision box, and is completely separate from the bounding box exported with the shape.

IMHO that variable should be renamed to what it really is... collisionBox. :(

#28 When you say it is the absolute size of the collision box do you mean that the bounding box parameters affect the size of collision box.

Bascially, saying boundingBox = "1 1 1" would result in a collision box that is exactly the same size as the bounding box and boundingBox = "2 2 2" would be a collision box twice the size of the bounding box?

#29 No, I mean the exact opposite. That's the way I thought it worked, but I was wrong. I meant it when I wrote that they're completely separate. The bounds box exported from MAX (or whatever) controls the local coordinate system, the offscreen culling, etc, and the boundingBox in the script controls the size of the collision box. So, saying

boundingBox = "1 1 1" means the collision box will be exactly 1 world torque unit wide, long and tall.
boundingBox = "2 2 2" means the collision box will be 2 world units in all dimensions.

The bounds box has no effect on and no relation to the boundingBox, and vice versa. (edit: except that, as Logan says, the boundingBox "grows" from the pivot of the bounds box).

#30 Ah, I see, I will have to go into my scripts and clean that up so the collision boxes are more accurate.

Do you know which box you are viewing when you select a character in the world editor, the collision or the bounding box?

#31 This only applies to Player objects. The rest of the objects in the Torque use the Bounds that you generate in your modelling program for bounding box checks (like view frustrum occlusion) and use their collision meshes for collision so it is important to make sure their bounds are "correct".