Collision "hitch" at tile seam
by Phil Shenk · in Torque Game Builder · 03/01/2005 (11:44 pm) · 15 replies
I noticed that when sliding along a row of collision tiles, and the player is angled into the wall slightly (so there is part of the force pushing into the wall), that the player collision "catches" where two tiles butt up against each other, causing a collision hitch. In other words the player doesn't just slide along the wall nicely, it catches and spins away when it hits that seam.
THe player collision in this instance is a wedge. It's the front point that catches. I tried blunting the point a bit, but it still catches. I'm using setConstantForcePolar to apply the force to the player.
THe player collision in this instance is a wedge. It's the front point that catches. I tried blunting the point a bit, but it still catches. I'm using setConstantForcePolar to apply the force to the player.
About the author
#2
I won't bore you with all the details but it is partly a precision issue and partly related to the fact that each tile has a discreet and discontinuous collision-polygon. Applying a continuous force that causes the object to collide with the layers on angles, produces this issue.
You can start to get around this issue by balancing the mass/forces involved as well as reducing the dynamic friction coef of the surfaces. You can also clamp angular momentum at zero.
Thankfully, there are different (transparent) ways to resolve this problem though in the engine. This is one of the "bigger" issues that I'll be focusing my efforts on soon.
Sorry for any inconvienience this may cause.
- Melv.
03/02/2005 (1:21 am)
@Phil: I'm aware of this issue. Damn you Phil, you're just too good and finding problems. ;)I won't bore you with all the details but it is partly a precision issue and partly related to the fact that each tile has a discreet and discontinuous collision-polygon. Applying a continuous force that causes the object to collide with the layers on angles, produces this issue.
You can start to get around this issue by balancing the mass/forces involved as well as reducing the dynamic friction coef of the surfaces. You can also clamp angular momentum at zero.
Thankfully, there are different (transparent) ways to resolve this problem though in the engine. This is one of the "bigger" issues that I'll be focusing my efforts on soon.
Sorry for any inconvienience this may cause.
- Melv.
#3
It appears to be a problem that occurs when an external constant force causes continuous overlaps between the object and tiles. Tangental movement to the tile-surface therefore causes a collision with neighbour tiles as there is a fractional overlap. This could also be caused by hitting the tile-surface at high velocity with a tangental component velocity.
This problem can be trivially removed (although I'm working on a much nicer solution this evening) by doing a physics update both before and after the collision detection in "subUpdateScene".
Sorry for the problem. Hopefully it'll be in the next update.
- Melv.
03/21/2005 (8:34 am)
Just an update to let you know that I have now isolated this problem.It appears to be a problem that occurs when an external constant force causes continuous overlaps between the object and tiles. Tangental movement to the tile-surface therefore causes a collision with neighbour tiles as there is a fractional overlap. This could also be caused by hitting the tile-surface at high velocity with a tangental component velocity.
This problem can be trivially removed (although I'm working on a much nicer solution this evening) by doing a physics update both before and after the collision detection in "subUpdateScene".
Sorry for the problem. Hopefully it'll be in the next update.
- Melv.
#4
Seriously though, I thought it was being caused by another problem (most likely in my script code) I haven't had the time to unravel yet.
@Melv: I don't eat cream scones, but does bagel consumption count towards the next update countdown? ;^)
03/21/2005 (8:44 am)
And here I thought it was just me. I've seen this (with a wedge shape collision poly). I figured the quirky behavior just made for more interesting collisions ;^)Seriously though, I thought it was being caused by another problem (most likely in my script code) I haven't had the time to unravel yet.
@Melv: I don't eat cream scones, but does bagel consumption count towards the next update countdown? ;^)
#5
- Melv.
03/21/2005 (8:57 am)
Absolutely not, only cream scones will do. Bagels could be used but without a drink!- Melv.
#6
http://www.garagegames.com/mg/forums/result.thread.php?qt=32967
08/03/2005 (1:06 pm)
I have a fix for this issue that I just came up with. I don't think its the most correct way to fix it, but it worked with my game.http://www.garagegames.com/mg/forums/result.thread.php?qt=32967
#7
09/28/2005 (6:00 am)
I've been struggling with this tile hitching issue for the past few days and its really grinding my project down to a halt. Ive found the 'subUpdateScene' function mentioned, but im not sure what I need to add and where. Can anyone shed some light on Melv's suggestion?
#8
09/28/2005 (8:03 am)
Try the code in the link above. It worked for my limited senerio (a run and jump style platformer game), so it might work for what you are doing. If it doesn't work, at least you know around where the issue is occuring, and you can created some type of hack / fix to work around the tile hitching.
#9
I actually read through the code in subUpdateScene for a while (a feat for me, all this c++ stuff is skeery), and made an educated guess on where the physics update needed to be performed again. Lo and behold, it worked! I was tearful with joy. Ok, maybe not tearful, but very happy. As soon as I get home, i'll post the relevant code snippet in case anyone else wants to give it a whirl.
09/28/2005 (9:17 am)
Thanks for the tip, Ray. I tried your fix but it didn't seem to make any difference (though I was getting an odd crash upon exiting, possible its unrelated). I actually read through the code in subUpdateScene for a while (a feat for me, all this c++ stuff is skeery), and made an educated guess on where the physics update needed to be performed again. Lo and behold, it worked! I was tearful with joy. Ok, maybe not tearful, but very happy. As soon as I get home, i'll post the relevant code snippet in case anyone else wants to give it a whirl.
#10
09/28/2005 (10:31 am)
Sweet...It sounds cool to me, I will check it out once you post it. My "fix" was special cased to only fix the issue I had. I basically just tried things until something work, using educated guesses. Can you explain how the issue was occuring in your game? I am just curious what your exact problem was, because tile hitching could mean a lot of things i think.
#11
In my project, I have a very simple tiled 'ground' that stretches across the screen. The tile layer has collisions enabled, and each tile is using the default square collision poly. Then there is a static sprite that the player is able to control, which has a constant force applied ot it to simulate gravity, and which also uses the default rectangular collision poly which spans the entirety of the sprite. Im using setLinearVelocityX to move the player left and right. Once you press and hold either direction, the player begins to move properly, but everytime the end of one tile and the beggining of another (the seam), is encountered, the movement of the sprite is slowed, seemingly by about 30%. If you continue moving in this fashion, the speed continues to diminish after every tile seam. Moving backwards, curiously enough, would cause some 'skipping' along the surface at each of the seams, as well as the slowdown. Its as though the player sprite, which has 0 friction set on it and has its angular velocity clamped at 0, is colliding once with the ground, and again against the side edge of the next tile, even though it is a straight and level plane.
In any case, copy & pasting the physics update inside subUpdateScene has done the trick. I'm not sure if its in the optimal spot or not, and I haven't thoroughly tested it, but it appears to have done the trick. Perhaps someone who knows what they're doing will be able to verify. :)
09/28/2005 (10:50 am)
I think you're right on that; this seems like the kind of issue that could cause a range of odd issues.In my project, I have a very simple tiled 'ground' that stretches across the screen. The tile layer has collisions enabled, and each tile is using the default square collision poly. Then there is a static sprite that the player is able to control, which has a constant force applied ot it to simulate gravity, and which also uses the default rectangular collision poly which spans the entirety of the sprite. Im using setLinearVelocityX to move the player left and right. Once you press and hold either direction, the player begins to move properly, but everytime the end of one tile and the beggining of another (the seam), is encountered, the movement of the sprite is slowed, seemingly by about 30%. If you continue moving in this fashion, the speed continues to diminish after every tile seam. Moving backwards, curiously enough, would cause some 'skipping' along the surface at each of the seams, as well as the slowdown. Its as though the player sprite, which has 0 friction set on it and has its angular velocity clamped at 0, is colliding once with the ground, and again against the side edge of the next tile, even though it is a straight and level plane.
In any case, copy & pasting the physics update inside subUpdateScene has done the trick. I'm not sure if its in the optimal spot or not, and I haven't thoroughly tested it, but it appears to have done the trick. Perhaps someone who knows what they're doing will be able to verify. :)
#12
Ok, at the bottom of the subUpdateScene function, in fxSceneGraph2d.cc, near line 2091:
I'm not sure if the addition physics update should be occuring before or after setInitialUpdate(), but in its current state before it, it's working fine.
09/28/2005 (11:07 am)
Ahh, gotta love GoToMyPc.Ok, at the bottom of the subUpdateScene function, in fxSceneGraph2d.cc, near line 2091:
// Custom Integrate Object. pSceneObject2D->integrateObject( mSceneTime, elapsedTime, pDebugStats ); // Calculate Object Spatials (again). pSceneObject2D->calculateSpatials(); // Calculate Forces and Update Physics Simulation. // ADD THE FOLLOWING LINE *********************** pSceneObject2D->getParentPhysicsModel().update( elapsedTime ); // Flag Initial Update. pSceneObject2D->setInitialUpdate();
I'm not sure if the addition physics update should be occuring before or after setInitialUpdate(), but in its current state before it, it's working fine.
#13
The tiles (all sub-objects) should be sorted and the first one (in time) processed.
- Melv.
09/29/2005 (12:00 am)
There were lots of interelated problems in v1.0.2 that have now been fixed (and hopefully no others introduced) with regards to collision processing. One of the biggest related issues for the "hitching" was the fact that when the object (the player) does a trivial check and decides that it potentially collides with the ground (the tile-layer), the player-object asks the tile-layer for a list of potential tiles. These tiles were being processed correctly (at least for v1.0.2) but the main issue was that the returned objects (the tiles) were processed in no particular order. This can be potentially disasterous for the col-det.The tiles (all sub-objects) should be sorted and the first one (in time) processed.
- Melv.
#14
10/10/2005 (4:00 pm)
Hi @Corey irst of all thanxs for share your work. Well, I've applied your fix, something I noticed was my player now moves more fast and jumps higher but the slowdown moving backwards still remains (but diminished). Have you been able to get this working?
#15
10/10/2005 (9:14 pm)
I still get slight hitches when moving backwards, and i'm not particularly sure why. It is, however, greatly diminished for me. 
Torque Owner Harold "LabRat" Brown