Platforming Collision Detection
by Univ.of Central Florida (UCF_003 · in Torque Game Engine · 09/20/2006 (1:33 pm) · 4 replies
Hello. We are having problems with our collision detection for platforming. First we checked out the bounding box of the player created upon export and it encompases the model as we would expect. But when we look at the box in the world editor, the box is much bigger.
The main problem is that the player's large in game box is what the platforming is using for determining if a model is standing on a model. So because the box encompases him, he can almost completely stand beside the model and still not fall off of it.
In addition, we attempted to add a small collision box around the model's feet hoping that the engine would recognize this when standing on a model in the world. This was an unsuccessful attempt.
Has anyone else encountered this problem? Any feedback would be greatly appreciated.
The main problem is that the player's large in game box is what the platforming is using for determining if a model is standing on a model. So because the box encompases him, he can almost completely stand beside the model and still not fall off of it.
In addition, we attempted to add a small collision box around the model's feet hoping that the engine would recognize this when standing on a model in the world. This was an unsuccessful attempt.
Has anyone else encountered this problem? Any feedback would be greatly appreciated.
About the author
#2
eg: boundingBox = "whatever";
09/20/2006 (2:25 pm)
Isn't the player's bounding box set by script in Player.cs as part of the PlayerData datablock ?eg: boundingBox = "whatever";
#3
EDIT: Here'a a link to Matt Fairfax's Simple Collision Tutorial which may be helpful.
09/20/2006 (2:38 pm)
Yes, but as far as I am aware, the bounding box is the basis for determining collision specifications, and I've seen rendered collision boxes (it's a debugging flag) where if your object has "unusual" dimensions, such as a very long x/y dimension, the box can get severely out of whack when collisions are being checked.EDIT: Here'a a link to Matt Fairfax's Simple Collision Tutorial which may be helpful.
#4
09/20/2006 (3:30 pm)
The debug rendering only shows the object bounding box, which you will not see grow. 
Torque 3D Owner Stephen Zepp
The player is going to be moving so much that the collision needs to be optimized as much as possible, even forgoing perfect collision detection (false positives being treated as true positive collisions).
The basic way it does this is that for the Player class, a bounding box collision equates to a "real" collision--there is no third layer of collision detection at the poly to poly level, like there is for other objects, and even the Vehicle class.
The second thing it does is that we expand the collision box so that it is guaranteed to stay polygonal/convex no matter the Z-axis (up/down) rotation of the player. This also causes some false positive responses, in that even a decently sized bounding box (reasonably accurate) is going to expand in certain cases to be "over-reaching".
Torque does try to compensate for these heavy handed optimizations by allowing for "collisionRetry", in that if a collision is detected, it will "fuzzify" the position of the Player class a fractional amount, and retry the collision. IIRC, the sMoveRetryCount is the static variable in Player.cc that controls this behavior.
A couple of solutions people have used:
--instead of bounding box based collision, implement a bounding cylinder. The box collision algorithm is faster, but this can be optimized as well.
--using Vehicle as a model, put back in poly to poly collision for your Player class, or alternatively derive your operating class from Vehicle instead of Player. This can take some work as the Player and Vehicle classes deviate in much more than just collision.