Sticky collision... bug?
by Tom Spilman · in Torque Game Builder · 07/24/2006 (5:14 pm) · 36 replies
So this is what is happening...
(click for larger version)
1. In the first frame you can see that the player is away from the wall... no collision.
2. The second frame i'm running into the wall... my velocity is low, but the player collision poly is clearly penetrating the wall.
3. When i release the control stick the player is pushed out of the wall... but it seems not completely. If i set a breakpoint in t2dPhysics::resolveForwardCollision() it hits... so i'm still penetrating the wall even with zero velocity. I would have expected to be fully pushed out.
4. So when i decide to run away from the wall... no matter how long i hold down the run left button i stick to the wall. I suspect this is because i'm still penetrating the wall.
My collision settings on the player are:
And the collision settings on the wall are:
So is this a bug or something i'm doing wrong? It seems like you should never get penetration in the collision and especially not at low speeds.
(click for larger version)
1. In the first frame you can see that the player is away from the wall... no collision.
2. The second frame i'm running into the wall... my velocity is low, but the player collision poly is clearly penetrating the wall.
3. When i release the control stick the player is pushed out of the wall... but it seems not completely. If i set a breakpoint in t2dPhysics::resolveForwardCollision() it hits... so i'm still penetrating the wall even with zero velocity. I would have expected to be fully pushed out.
4. So when i decide to run away from the wall... no matter how long i hold down the run left button i stick to the wall. I suspect this is because i'm still penetrating the wall.
My collision settings on the player are:
%player.setCollisionPolyCustom( 4, "-0.4 0.2", "0 -0.1", "0.4 0.2", "0 0.5" ); %player.setCollisionActive( true, true ); %player.setCollisionPhysics( true, true ); %player.setCollisionResponse( CLAMP ); %player.setCollisionCallback( true ); %player.setCollisionMaxIterations( 3 );
And the collision settings on the wall are:
new t2dStaticSprite() {
imageMap = "stonewalls_map";
position = "241.865 357.879";
size = "4.690 20.500";
Layer = "10";
CollisionActiveSend = "1";
CollisionPhysicsSend = "0";
CollisionPhysicsReceive = "0";
CollisionPolyList = "0.988 -0.245 0.915 0.989 -0.952 0.994 -1.000 -0.245";
mountID = "4";
};So is this a bug or something i'm doing wrong? It seems like you should never get penetration in the collision and especially not at low speeds.
About the author
Tom is a programmer and co-owner of Sickhead Games, LLC.
#22
When the rectangle runs straight into the circle, it all works perfectly. I can collide it into it and it stops (and goes around if it's near the edge) but if I'm close and then turn into it - they warp all over each other and go crazy.
NOTE: If you change the collision area to a custom poly, it works fine (for me). Try that out.
09/07/2006 (2:31 pm)
Same problem here with CLAMP collisions (rectangle to circle) and setAngularVelocityWhen the rectangle runs straight into the circle, it all works perfectly. I can collide it into it and it stops (and goes around if it's near the edge) but if I'm close and then turn into it - they warp all over each other and go crazy.
NOTE: If you change the collision area to a custom poly, it works fine (for me). Try that out.
#23
09/11/2006 (12:53 pm)
For me, if I cahnge the collision area to a custom poly (mini platformer tutorial), it makes things much worse, not better. Now certain stair-case-like situations, where blocks increase in height by 1 blocks each time you move over a tile, result in a sort of "staircase" that he climbs automatically, without jumping, as a result of the custom poly. And other weird things. 
#24
The changes made in the next release seem to have resolved this issue although time will tell. One of the major contributors to this issue is a fix that I can post here as it's a pretty minor change as follow...
In the following function in "t2dPhysics.cc"....
Let me know how this works for you. As I say, the other updates are too complex easily post here.
- Melv.
09/27/2006 (4:49 am)
There seem to have been a number of reasons why this has been occurring, not limited to the collision-response modes themselves but also the overlap resolver.The changes made in the next release seem to have resolved this issue although time will tell. One of the major contributors to this issue is a fix that I can post here as it's a pretty minor change as follow...
In the following function in "t2dPhysics.cc"....
void t2dPhysics::resolveOverlapPair( cCollisionStatus* pCollisionStatus, const U32 contactIndex )... remove the following block of code...
// Is the Contact Direction Null?
if ( contactDirection.isLenZero() )
{
// Yes, so ignore.
return;
}Let me know how this works for you. As I say, the other updates are too complex easily post here.
- Melv.
#25
There's a duff line in "t2dUtility.h"...
... who knows why the 0.5f go added but I'll admit it was probably me during some debugging session a while ago.
Also, there's inverted logic for the overlap solver. In "t2dPhysics.cc"...
You need to be careful on the last one as there are subtle issues related to rigid-body that you may encounter. In most cases though you should be able to safely change it.
- Melv.
09/27/2006 (5:24 am)
Also...There's a duff line in "t2dUtility.h"...
#define T2D_CONST_COLLISION_UPSCALE (1.0001f * 0.5f)... which should be...
#define T2D_CONST_COLLISION_UPSCALE (1.0001f)
... who knows why the 0.5f go added but I'll admit it was probably me during some debugging session a while ago.
Also, there's inverted logic for the overlap solver. In "t2dPhysics.cc"...
void t2dPhysics::solveCollision( cCollisionStatus* pCollisionStatus )... change the section...
// Have we definately got a forward-time collision?
if ( pCollisionStatus->mOverlapped )
{
// Yes, so move to collision point before we calculate the response.
moveToCollisionPoint( pCollisionStatus );
}... to be ...// Have we definately got a forward-time collision?
if ( !pCollisionStatus->mOverlapped )
{
// Yes, so move to collision point before we calculate the response.
moveToCollisionPoint( pCollisionStatus );
}... e.g. add a "!" before the "pCollisionStatus.....".You need to be careful on the last one as there are subtle issues related to rigid-body that you may encounter. In most cases though you should be able to safely change it.
- Melv.
#26
09/28/2006 (7:06 am)
Good to hear that you resolved the issue. Is this fix coming in the next version of TGB (non-pro) ?
#27
09/28/2006 (3:29 pm)
Just curious.. is this fixed in 112?
#28
- Melv.
09/29/2006 (3:59 am)
Some of the fixes made it in but a few didn't. Unfortunatley, they were found after v1.1.2 was packaged for distribution. Some of the main ones are in v1.1.2 though.- Melv.
#30
09/30/2006 (8:17 am)
Er... the fix make more bugs than the initials one, now the character on my plateformer change his velocity every time when he runs on a surface, he speeds up unaturally and speeds down at any moment without logic.
#31
Which fixes exactly? The v1.1.2 release or the changes outlined above? Could you send me some simple code that shows your problem?
- Melv.
10/01/2006 (3:00 am)
Benjamin,Which fixes exactly? The v1.1.2 release or the changes outlined above? Could you send me some simple code that shows your problem?
- Melv.
#32
With the v1.1.2, The character change his runs speed occasionnaly when he runs, without logic (either in CLAMP or BOUNCE). Something was changed here, has if the linear velocity x is not so linear when I collide with the ground (plus, the character still get stuck when trying to jump in slopes in CLAMP mode).
It's not so dramatic, for now I can stay with the 1.1.1 wich I made it working just fine.
But it's a little annoying to be unable to use the next version because of this.
10/01/2006 (6:57 am)
It's all about Clamp collisions, in the v1.1.1, in a slope (on my platformer) sometimes the character get stuck if I try to jump. The problem was simply fixed by changing CLAMP to BOUNCE, and it runs just fine (with some tweaks and workarround for each collisions so that the character do not bounce everywhere).With the v1.1.2, The character change his runs speed occasionnaly when he runs, without logic (either in CLAMP or BOUNCE). Something was changed here, has if the linear velocity x is not so linear when I collide with the ground (plus, the character still get stuck when trying to jump in slopes in CLAMP mode).
It's not so dramatic, for now I can stay with the 1.1.1 wich I made it working just fine.
But it's a little annoying to be unable to use the next version because of this.
#33
There are many contributors to the issue you're experiencing, some of which made it into the recent release and some minor ones that didn't. There's also some major changes that were only going to be in the next version that'll really stabilise stuff.
The above fixes won't work 100% of the time for 100% people. When we've finished the suite of changes, we'll hope to hit exactly that figure, time will tell. ;)
In the meantime, in case you didn't add it, I'd definately make the "T2D_CONST_COLLISION_UPSCALE" change that didn't get in v1.1.2 as it may help solve your issue. This one causes the overlap to be solved over two integrations and with high constant forces, you may never get out of the overlap.
- Melv.
10/01/2006 (7:22 am)
As I said above, only a few changes made it in. In either case, the issue isn't that the fixes cause more bugs, it's a case of the "fix" you're using is not actually solving the root of the problem, simply working around it. It'll more than likely be unstable so that when the assumptions made by the fix change, it stops working.There are many contributors to the issue you're experiencing, some of which made it into the recent release and some minor ones that didn't. There's also some major changes that were only going to be in the next version that'll really stabilise stuff.
The above fixes won't work 100% of the time for 100% people. When we've finished the suite of changes, we'll hope to hit exactly that figure, time will tell. ;)
In the meantime, in case you didn't add it, I'd definately make the "T2D_CONST_COLLISION_UPSCALE" change that didn't get in v1.1.2 as it may help solve your issue. This one causes the overlap to be solved over two integrations and with high constant forces, you may never get out of the overlap.
- Melv.
#34
10/01/2006 (7:30 am)
Thanks Melv, I'm running on a non-pro version, so I'll just stay with the 1.1.1 until the next patch.
#35
- Melv.
10/02/2006 (3:57 am)
Not a problem. There's definately a focus now to sort out these annoying issues so it'll get sorted sooner rather than later!- Melv.
#36
I understand that collisions issues as a TGB bug... if that's the case, would there be an upgrade/fix to the engine in the near future? I really don't want to spend my time trying to learn something that's beyond my scope, and less if the nature of the problem is a bug.
Thanks
-Isaac
10/24/2006 (11:24 am)
Hello Melvin:I understand that collisions issues as a TGB bug... if that's the case, would there be an upgrade/fix to the engine in the near future? I really don't want to spend my time trying to learn something that's beyond my scope, and less if the nature of the problem is a bug.
Thanks
-Isaac
Torque Owner DragonSix