Player BoundingBox Settings
by Michael Hall · in Torque 3D Professional · 06/05/2009 (10:22 pm) · 8 replies
Quoted from Matt Fairfax from another thread, just didn't want to hi-jack that one with a side discussion:
And the fix is good, I've been using "0.8 0.8 1.9" for Gideon. It definitely seems to make things more fun when chasing bots or getting shot at :D However there are still a couple of unwanted side effects.
Just how tight do we want these bounding boxes to be? The only two negative side effects that I've noticed so far is that (1)you can get that much closer to a wall, which means you can sometimes see through a wall, and (2) getting closer to a wall means that even more of your weapon penetrates said wall (another classic problem), allowing you to shoot something on the other side. For these two reasons it may be necessary to widen the box a little more. I believe that it's possible to avoid the second issue, just never had a weapon setup for it to experiment with, if the weapon image retractNode/retractionNode works the way I seem to think it would.
What do you all think, where do we find that balance between a better tighter bounding box and undesired consequences?
These are the settings I'm currently using and have committed, would anyone care to test and offer any feedback so I can make further changes before the next beta release?
Current boundingBox settings, 08 JUN 09:
Boombot = "1.1 1.2 2.5" ForgeSoldier = "1.1 1.0 2.4" Gideon = "0.8 0.8 1.9" Spacesuit = "0.8 0.8 2.2"
Quote:
Before Torque 3D Beta 2, Torque had a problem where if your eye node moved so that the Player's bounding box then it would stop rendering the Player and more noticeable its weapon. So the easiest "fix" was to increase the size of the bounding box to make sure that the eye node stayed inside. Unfortunately, this meant that the Player's collision was really different from his visible mesh in a lot of cases (like with Joe's case or with the classic "floating" Player on sloped surfaces).
Now that we no longer have that issue, we are planning to tune all of the Players' bounding boxes to better fit their visible geometry. If anyone would like to lend us a hand, it would be much appreciated (we need new bounding box settings for Gideon, ForgeSoldier, BoomBot, and Spacesuit)!
And the fix is good, I've been using "0.8 0.8 1.9" for Gideon. It definitely seems to make things more fun when chasing bots or getting shot at :D However there are still a couple of unwanted side effects.
Just how tight do we want these bounding boxes to be? The only two negative side effects that I've noticed so far is that (1)you can get that much closer to a wall, which means you can sometimes see through a wall, and (2) getting closer to a wall means that even more of your weapon penetrates said wall (another classic problem), allowing you to shoot something on the other side. For these two reasons it may be necessary to widen the box a little more. I believe that it's possible to avoid the second issue, just never had a weapon setup for it to experiment with, if the weapon image retractNode/retractionNode works the way I seem to think it would.
What do you all think, where do we find that balance between a better tighter bounding box and undesired consequences?
These are the settings I'm currently using and have committed, would anyone care to test and offer any feedback so I can make further changes before the next beta release?
Current boundingBox settings, 08 JUN 09:
About the author
Been dabbling with game-programming since the age of 10 when I got my first computer, a Commodore. Got serious about game-development after modding Tribes for several years. Doesn't sleep much. Drinks rum. Teaches guitar. Plays cello.
#2
But if that's not an option, I'd definitely go with preventing undesired consequences.
A hybrid approach would probably be more realistic. Maybe an "inner bounding box" (better would be per-limb boxes) for hit-detection... and an "outer bounding box" which could be used for collision detection for movement (as well as potentially culling out unnecessary hit detection on the "inner bounding boxes per limb").
Best of both worlds?
06/06/2009 (1:16 am)
+1 on deepscratch's suggestion.But if that's not an option, I'd definitely go with preventing undesired consequences.
A hybrid approach would probably be more realistic. Maybe an "inner bounding box" (better would be per-limb boxes) for hit-detection... and an "outer bounding box" which could be used for collision detection for movement (as well as potentially culling out unnecessary hit detection on the "inner bounding boxes per limb").
Best of both worlds?
#3
take a look at the gideon model in ShowTool, it has multiple bounding boxes,
kinda like what you are talking about.
06/06/2009 (2:11 am)
@Chris,take a look at the gideon model in ShowTool, it has multiple bounding boxes,
kinda like what you are talking about.
#4
After all, you can stand in front of a wall, but you can't point out a weapon when you do that.
06/06/2009 (3:05 am)
Another possible solution would be to make the player lower is weapon if he is too near to a wall (or another tall object) on his front side.After all, you can stand in front of a wall, but you can't point out a weapon when you do that.
#5
If we use a BoxConvex and do the right corrections - the problem is fixed.
06/06/2009 (11:23 am)
The floating player on sloped surfaces is actually caused by the the axis aligned OrthoBoxConvex.If we use a BoxConvex and do the right corrections - the problem is fixed.
#6
But I really like the idea of making the player lower his weapon when running into a wall. Now that would be nifty!
Edited original post with current boundingBox settings if anyone wants to try them out and offer alternative settings. I've got them rather "tight" as it is now.
06/08/2009 (4:11 pm)
Honestly I don't think that hit boxes per limb is generically useful enough for it to be a stock feature. One could definitely make a case for such a system to be added to a FPS genre kit, or to have it integrated with a melee feature though.But I really like the idea of making the player lower his weapon when running into a wall. Now that would be nifty!
Edited original post with current boundingBox settings if anyone wants to try them out and offer alternative settings. I've got them rather "tight" as it is now.
#7
So there's a trade-off to think about these things. Swings and roundabouts and all that.
However, a tiny box is especially useful when used with seperate AI player settings as it makes them much easier to fit through doors without banging off the sides as they run through.
edit: On the "hitbox" idea, wouldn't it be generally better to have a "hit-mesh"? Projectile strikes object, gets meshname, does something funky in script with damage application). Obviously you'd have to have a model made of seperate meshes for all the different parts you wanted to utilize, but at it's basic a seperate mesh for headshots would suffice.
I've no idea how feasible any of this is though.
double-edit: Also having the "align player to ground" resource from TGE/A incorporated into the code might nice.
06/08/2009 (4:36 pm)
You can making the settings very tight to the player model however this does make it easier for the eyenode to penetrate a wall and see beyond, which doesn't look so nice during play.So there's a trade-off to think about these things. Swings and roundabouts and all that.
However, a tiny box is especially useful when used with seperate AI player settings as it makes them much easier to fit through doors without banging off the sides as they run through.
edit: On the "hitbox" idea, wouldn't it be generally better to have a "hit-mesh"? Projectile strikes object, gets meshname, does something funky in script with damage application). Obviously you'd have to have a model made of seperate meshes for all the different parts you wanted to utilize, but at it's basic a seperate mesh for headshots would suffice.
I've no idea how feasible any of this is though.
double-edit: Also having the "align player to ground" resource from TGE/A incorporated into the code might nice.
#8
06/09/2009 (3:38 am)
The lowering weapon idea, is a brilliant option. I think a flagship engine like T3D really cant afford to have an Age old bug like that in it. 
Torque Owner deepscratch
DeepScratchStudios
thats the ultimate solution.