Bounds scaling

#1 The bounds defines the world of the object in the DTS shape. Anything within the box is what is exported and the pivot point for the bounds shape defines the transform information for the DTS shape and the place to start or grow player collision box data (generated in code) at.

To adjust your bounds shape collapse to an editable mesh and then edit it from there.

#2 Is there some way to automatically size the bounds box to the size of my model?

#3 @brad: No... you could probably write a script to do it though. (If I get a few moments free later tonight I'll do it for you. No promises though =).

#4 That'd be awesome!

#5 Okay, done.

www.witentertainment.com/GenerateBounds.zip (i'll try to post it as a resource later, I've been having problems posting resources lately though).

#6 Hmmm...it doesn't look like it's working. I made a box, selected it, went to the MaxScript utility and chose Run Script. I chose the WIT-GenerateBounds.mcr in \UI\MacroScripts. Am I missing something? Thanks.

#7 @Brad: yep. you missed something. =)
Read the readme. The way the script is set up right now you have to assign it to either a keyboard key, a toolbar button or a quad menu.

I prefer to use a quad menu so I'll explain how to do that here: (any of the others are similar though so you'll figure it out).

Go into The Customize->Customize User Interface menu, select "Quads".
Select the lower right quad if it's not selected already.
Change "Category" to "WIT" and drag the "GenerateBounds" action to the list of actions in the quad menu. Now you can access the script by right clicking in a viewport and selecting it.


If you want to run the script with the "Run script" command you have to open the file and remove everything BUT the stuff between the ( and the ) (remove the two lines with those characters too). Save it as GenerateBounds.ms (not .mcr! and not in the \UI\ folder, put it somewhere else like \your_max_folder\scripts).

#8 Ah ha! I thought the read me was suggesting places that the script could from but I didn't get that it had to be set up that way. now it works like a dream. thanks for all of your help!

on another note...I checked out your site. great work.

#9 No problem. The script fixed a problem I didn't even know I had anyway. I had to redo the bounds for 50+ models last night too. =)

#10 Doesn't the bounding box need to encompass the character and all of its animations and not just the character?

#11 @Todd: No idea really, probably. so yes, this won't work particulary well for animated objects. Perfect when I had to export 50 different static objects last night though.

For a character it's not that much of a problem to set up the bounds by hand though as you generally only have to do it once. It doesn't get annoying until you have to do it on a bunch of tiny little objects. =)

#12 Could you select the 'largest' frame of animation and run the script there?

#13 Todd-

Quote:
The bounding box does NOT need to fully enclose the model. It can be ultra-tiny if you want it to be. The main thing to think about with your player models is that the bounding box is also your collision mesh. So if your bounds box is big enough to enclose all your animations, you will most likely collide with stuff that is an arm's reach away, even if your arms are at your sides. Also, when on a hill, you will be resting on the bottom corner of the box, resulting in the character looking like he's floating. I have found a happy medium in making my player's bounding box as tall as the character, but skinny in the other two dimensions, basically only enclosing the player's main body (I learned this from the Jill pack).

It's also worth noting that the bounds box can be scaled from script (server/scripts/player.cs - search for bounding box), so you don't always necessarily have to go back to max to alter the box's dimensions.

Edit: I quoted what I wrote originally, and now I'm writing what I found out, which makes the above wrong. The bounding box does NOT in fact control the collision box. The collision box is controlled by the boundingBox parameter, found in the player.cs, and is completely separate from the bounds box that comes from the exporter. The only relation is that the boundingBox (collision box) is "rooted" at the pivot of the bounds box.







For non-player models, the only thing I have found that the bounds box affects is object culling... meaning, if the bounds box is smaller than the object, sometimes the bb will be comletely outside the view frustrum, while some of the model should still be visible, but it will disappear as you walk by because of this discrepency. I'm not sure if that makes sense, but you can try it by making a tiny bb and then putting the object in game and walk by it.

Edit: The bounding box also defines the local coordinate system and pivot point for the entire DTS shape.

PS. Thanks for another useful script, Magnus!

#14 Thanks Jeff. I had read in a couple of other posts that the bounding box needed to encompass all the animations. This is good to know as it was causing the bounding boxes to be unneccessarily big on some of our character models.

#15 Very informative post Jeff... I'm finally getting to character exporting from Max so that was very helpfull

#16

Quote:
Thanks Jeff. I had read in a couple of other posts that the bounding box needed to encompass all the animations. This is good to know as it was causing the bounding boxes to be unneccessarily big on some of our character models.

Jeff is correct, but keep in mind your exact scenario, and how it may play out visually:

--You have an animation that "extends" the weapon outside of the models' bounding box.
--the player is positioned so that they are just about to collide with a wall.
--the animation that extends the weapon forward is played.

In this scenario, the weapon itself will push into the wall, which looks visually unappealing (depending of course on your weapon!).

So while Jeff is correct in that the bounding box doesn't have to enclose all of the animations' extents, you can run into unusual situations where it might be better to keep your animations "tight" within the box itself.

#17 @Brad: technically yes. You could run through each of the frames and collect the "max bounding box" that way, right now I have no need for such a script though and I'm a bit short on time so this probably won't come from me any time soon.

@Jeff: Thank you for the rundown there, actually I'm a bit confused myself as to the use of the bounding box but what you say makes sense. This should mean that the script would be perfect for static objects as it doesn't include "too much" and it won't leave anything out. It makes the bounding box exactly as big as it needs to be. For characters and other animated objects the script probably isn't that useful, but as you said you generally want to hand tweak the bounding box for those sort of models anyway.
For my characters I haven't been that particularly exact with the bounding box either, as you said I make the height pretty exact but then I haven't bothered too much more. Making it have the same dimensions in the width and length is probably a good idea though if it's used for collision.

#18 @Stephen: Yes. I see what you mean, but you usually have to control things like that in the animation rather than changing the size of the bounding box. Having a too large collision box will make things rather annoying too as you won't be able to walk up close to that wall at all.

#19 @Stephen

Thats exactly what I was just thinking, I was just under the impression that it MUST enclose the animation. Knowing that it does not helps a ton.

#20 Stephen is exactly right. The other side of the coin is that if you make the width and depth of your box small, as I suggest, your character's extremities will go through the wall when you're right up against it. Basically it's a decision that needs to be made based on your specific situation. For example, in and RTS game, having the big bb would probably be more useful, so all the characters stay an arm's length from each other and from buildings, etc. But for a 3d platformer or FPS, the smaller bb might be what you want, since you'll be playing at a faster pace, and it cam be annoying to "run into" a wall when you're still a foot away.

It seems like the optimal solution would be to have your bb scale dynamically along with your animations, but unfortunately in Torque you cannot animate a collision mesh. I'm not a programmer, so there might be reasons why you can't... like it would kill performance.