Hello, we always wrestling with this issue in our game.    when in rag doll mode, on falling or during violent movements, hands can cross neck parts , foot through the other leg, , etc and then get  stuck there.  Parts are all convex, and bullet and all in the same collision category.

in Farseer, Is there a way to set the collision response to have a higher "priority" to the solver than any AngleJoint or RevoluteJoint?   I am guessing the iterative solver allows the joints to push something through in some cases.  And after this, its stuck with parts crossed, and needs to be "unstuck" .

in ODE a collision constraint was treated like a temporary distance joint.   so you could maybe specify this particular constraint  as "non-negotiable"  and let the other joint or joints take the error if needed..

so without this feature , or resorting to IK solvers,  we have to make all sorts of limit functions and such tricks to prevent the sticking or do the unsticking...

Hi,

I've had similar problem. It happens a lot with highly articulated bodies (such as ragdolls). But consider my situation with an articulated body with more than 200 links - it's a nightmare! But since having such an object is fundamental to my simulation (robots) I had to bite the bullet and figure out some workarounds.

First I'd like to say that I don't see the issue as a joint problem but as an interpenetration problem. Basically the polygons have no notion of direction of motion so sometimes the easiest computational way is to separate them after a collision with a lot of overlap is in the "cis" geometrical configuration (on the same side of the immaginary axis) than in the normal "trans" configuration. It's quite visible with EdgeShapes that are infinitely thin. Then next step the regular collision response won't allow them to come back to the normal state because now the "back" faces collide . Immediately a possible workaround is obvious that could work for ragdolls - make the limbs have "one way collision":

http://www.iforce2d.net/b2dtut/one-way-walls

I haven't explored this much because it wont' work for me. I've found that running at smaller timesteps helps. For example if the budget in a frame update is 10ms it's better to take two steps of 5 ms (not clearing forces between them). This of course has a limit on the CPU as it assumes physics can actually run in less than the "substep". E.g. if the physics step takes 7 ms to simulate two steps of 5 ms (total 10) it would take 14 ms of CPU time to simulate 10 ms of real time and therefore the physics simulation will lag. Same with increasing Velocity and Position iterations - sometime it helps sometime it doesn't always at the cost of CPU.

In the end for me the biggest problem is that sometimes joints need huge correcting forces to go back to their normal state which they cannot develop. Or the direction of the force is flipped 90 or 180 degrees. For an articulated body the stress on a joint is not so easy to correct because it would require corrections to many other joints and the the stress can offload at points that are not useful (non-linearity of the solution). One way to deal with this is some Inverse Kinematics but the way I've gone with is have a sanity check for the whole object and recover manually if the constraints diverge too much. At the end of the day it's a trick but so is simulated physics. I suppose if I wanted to simulate some mission critical object I would resolve to offline engineering tools and not use a real time a game engine :)

The idea of having constraint "priority" is interesting. I would definitely help me too. I don't know if can be implemented but more importantly in "normal" games there is little need for such complexity. Basically only ragdolls and rope/chains would benefit and for ragdolls I suppose workarounds are easier. For a ragdoll system you can check Erin Catto's presentation on the one used in Diablo 3 and it has many ideas and solutions to the problems (especially the bone tree and the unstucking on spawn algorithm):

https://code.google.com/p/box2d/downloads/list

This is particularly due to to the iterative solver of the joints, and there are many ways to make them less soft.

Smaller timesteps or higher velocity and position iterations helps. Adding more than one joint will also make the constraint less soft. That is how Toy Stunt Bike did it if I remember correctly. There are also some very creative solutions such as turning up the iterations when the error is getting higher. It is just a matter of experimenting as there are no real solution to this behavior, it is inherently a part of the engine.

Thanks, after considering all these ideas, i decided i'll probably have to do the "sanity check"  on the system.

I like that  Erin Catto's  paper , i wish i read it before I learned much of it the hard way.

One-way collision might work unless its doing extreme yogic posing..  but it might still tunnel and then i'd have to push it out.

Or I might try to make the part restitution (bouncy)  for a frame..  probably no one will notice that trick.

I think i want to make the joints -more- soft,  meaning collision response is more important to be accurate than the joint.. but when i mess with the solvers such as changing the time steps or iterations,  it adversely affects the other tuned parts of the simulation  that aren't stuck.

Hey Jerry is the game with the 200-part robot publicly viewable yet , i'm curious to see it .   curious if it is a snake or dragon or a machine.  

 Another wish i have is  if I could set a weld to be an absolute priority constraint, meaning not  bouncy or "non-negotiable" .. I see it was another user's recent issue with hanging from a ledge.    if i change the two parts to one body and combine fixtures  ..it would be  a pain.   i'd have to reattach the Joint-connected bodies to the new body, set all the position and velocities to match ( like a backwards breakable body) , and then hope it looks seamless..  but if it worked,  it would be generally useful.

I'm not sure making joints softer will improve collision response. The joints are the solution to regaining consistent state, not the problem, which is tunneling. You could check out some threads I have archived for ideas:

http://www.box2d.org/forum/viewtopic.php?f=4&t=4357

http://www.box2d.org/forum/viewtopic.php?f=2&t=154

http://www.box2d.org/forum/viewtopic.php?f=3&t=1784

As for increasing the iterations and taking smaller steps I would like to point out that it's not worthless to explore in general because it has a lot of similar issues to multithreading the solver.

http://www.box2d.org/forum/viewtopic.php?f=4&t=1450

For example here's an idea I've been toying with - the solver groups bodies into "islands" (bodies in contact or connected with each other) and solves them sequentially. Now what would stop us from creating a system where bodies of particular interest would have their islands solved at a higher sensitivity (more iterations, taking smaller time substeps etc)? I suppose there could be issues synchronizing the islands between themselves and that's where my knowledge of the internals stops. But intuitively it seems pretty obvious that if the solver needs to solve 10 islands but only one of them is important we would gain significant speed solving only that one at a higher iteration rate than applying more iterations to the whole simulation. If the interesting island is small the increase in speed could be phenomenal. Assuming linear time per island you could solve it at a 10 fold sensitivity at the same CPU cost. Also if it were not for sync issues the code change would be fairly trivial (it's all in Island.cs:Solve/SolveTOI). I'm sure there is already facility to deal with the sync issues if they should come up - I would presume calling FindNewContacts will be enough reconfiguring the islands midstep...

damian999 wrote:

Hey Jerry is the game with the 200-part robot publicly viewable yet , i'm curious to see it .   curious if it is a snake or dragon or a machine.  

It's more a SnakeWorm thingie :) Actually it's not game yet because I'm still figuring out the non-serious gaming element but I'll get there :) Officially it's an interactive simulation of a robotically steered catheter for endovascular interventions in the treatment of abdominal aortic aneurysms. The latter is definitely a mouthful but it's pretty cool what Farseer can do. When I fire up the current version I am absolutely amazed at the fidelity of the simulation and the possibilities it opens up both in training and actual treatment planning. We definitely live in interesting times and I can't stop thanking Genbox and the other devs for making such stuff possible, although I'm sure he never planned for his engine to be used in such scenarios.

I appreciate it. Let us know when you are done with your game. We love looking at the cool games created with Farseer Physics.