Moving across a straight object.

Topics: Developer Forum, User Forum
Jun 17, 2010 at 6:59 PM

This is a wonderful physics engine but I am having a significant problem moving my character across a flat edge. The object he is running across is static and simply a x by x rectangle. The character running across it is a rectangle that has an infinite MOI (so it cannot rotate).

The problem is the character when moving (by applying force) will seem to "trip up" on the flat edge even though it is completely flat. I have looked into the collision detection and it seems that collisions always seem to happen about around .5-1 of where the actual collision happens (by looking at the y coordinates of the two objects). So it seems I am not getting pixel perfect collision which is understandable I am just wondering if there is anyway to solve this problem without turning the character into having the invisible wheel setup (which I will probably eventually do) so I can understand why this is happening?

Or is this something that always happens with physics engines? This is my first time using one.

In short, the body of the character seems to trip up and almost "hop" sometimes over the other flat body. Or even completely stop sometimes (guessing the collision detection was too late?).

Otherwise it's been fantastic using it and I hope to solve this issue, this engine opens up alot of ideas.

Jun 17, 2010 at 8:23 PM
What version of the engine are you using? It is a common problem with engines build on the iterative solver that Box2D has. Even tho you have a flat surface comprised of more than a single geometry, then your character will trip when it hits the seems. One way to solve it is to use a wheel setup like you mentioned, another is to detect when collisions happen in seems and ignore them. This problem should be significantly reduced in FPE 3.0 and it should be completely gone in FPE 3.1 once I start working on it.
Jun 18, 2010 at 12:59 AM

I am currently using FPE 2.13 (latest stable 2.0). I see that is a problem with the engine then. I guess I will do the wheel setup like I was planning to. How would I go about ignoring collisions in seems?

Jun 18, 2010 at 4:30 PM

It is not easy, but you would save link data between the geometries and if you detect a normal of a contactpoint to be other than (0,1), you ignore it. That would reduce the problem, but not remove it completely.

Jun 18, 2010 at 11:37 PM
Edited Jun 19, 2010 at 12:42 AM

I had this issue early on, but I fixed it by adjusting the physics properties..

Basically, first make sure you are updating the PhysicsSimulator.Update() function at a proper speed, I use GameTime.ElapsedGameTime.Milliseconds * 0.001f..

Getting that value setup right ensures that the engine is checking for collisions at a fast enough rate to avoid things like your character\objects falling through floors, etc,.

If you have this setup right, then try adjusting the FrictionCoefficient to like 0.5f(I usually set my floor to 1.2f, and my character to 0.5f)., and make sure to set the players RestitutionCoefficient to 0.0f, which eliminates bouncing(like a basketball does on collision with the ground..)... (If the friction seems too little for your needs, adjust your mass instead, too much friction is the main cause, and Restitution makes it worse, so disabling it on the player is recommended unless he is supposed to bounce on impact..)

Other than that, play with the spacing a bit, or do what I do, just design the level with that in mind, look at the original mario, they had pipes pop up every so often, it serves as a way to break up flooring sections, or hide seams under stuff, like the block stairs seen in Mario, put the seem under there where the player can't get on it....

(I have a Mario character, and a small level setup, it runs just like the real Mario, minus a few issues I still need to work out.. )

PS: Never mess with the BiasFactor on anything, it usually causes issues.. If all else fails, try changing your properties around, like mass, gravity,  I ended up using a pretty high gravity, enough that things fall realistically, and adjusting the rest of my engine to match that, it's been really stable and fast since.


Btw, thanks for the awesome physics engine, it's implementation is very nice, it fit with no issues with my existing code, and I've had very few problems using it..

The only thing I really get, is the occassional float Not-A-Number crash, when a joint\spring goes wonky..

Is there an easy fix I could put into the existing code till the new version is ready? I just want to avoid the crashing.. I'm guessing it involves putting a check on a float somewhere to avoid it going out of bounds(NAN) or something like that,. but it's a lot of code, so a pointer in the right direction would be great..

Jun 19, 2010 at 7:36 PM

Seem issues plague physics engines. In version 3.0 we will have a solution as soon as Erin Catto finishes his edge loop shape.


Jun 20, 2010 at 12:00 AM

Sounds good, looking forward to playing with the newer versions.

Btw, about my solution above, it really works best at(half\full) running speeds, my character is capped at 650 on LinearVelocity.X, and has an acceleration impulse of 150..(He weighs 8.0f)

It's not perfect, but it does work, just not always, you can still catch, it's just not as often(like 20% chance assuming your at least moving at half speed or more, anything slower and the catch starts to become obvious..).

At any rate I can make 1-2 pixel gaps without issues for the most part, anyways, I just wanted to clear up my wording, I should have said it's a workaround, rather than implying it was a pefect solution..