Position Based Dynamics and friction

[raigan2]

Hi,
I've been working on a solver based on Muller's "Position Based Dynamics", and I'm currently tackling friction. So far, it sucks.

The main problem is that, as far as I can tell, the paper's proposed method doesn't actually work -- it can't achieve sticking friction. The constraint-solving phase generates a set of new positions and velocities, and velocities are then adjusted to model friction: basically, viscous damping of velocity along the tangent direction.. which leads to objects always slipping down even near-horizontal inclines.

Looking through box2d, which is the only solver I have access to that seems to really nail friction, it's clear that the reason that friction works is that (a) it is taken into account/solved along with all of the other constraints, instead of tacked onto the end of the simulation update, and (b) positions are updated using the solved/corrected velocities.

I've successfully managed to formulate velocity constraints in my PBD-based sim, however they're applied after positions are updated, and thus won't ever be able to provide proper sticking friction. I'm trying to figure out how to formulate friction as a position constraint (so that it can be solved along with the rest of the constraints), however this isnj't clear to me as friction seems inherently "velocity-only".


Has anyone managed to get friction working in this sort of "position projection"-based solver? Jakobsen's particle/verlet sim had the same problems: because of how collisions were solved, objects on slopes would always slide regardless of the strength of friction.

thanks,
raigan

[Antonio Martini]

Has anyone managed to get friction working in this sort of "position projection"-based solver? Jakobsen's particle/verlet sim had the same problems: because of how collisions were solved, objects on slopes would always slide regardless of the strength of friction.

thanks,
raigan

a solution for friction that seemed to work very well in my tests was based on the same friction concepts used in some rigid body solvers: breakable equality constraints. So friction constraints are set before entering the solver, they work only if there is penetration and they break if a maximum elongation is exceeded. So breakable distance constraints
along the tangential direction that try to keep vertices in place with zero rest length. Such constraints are evalutated in the constraint solve loop together will all the other constraints.

cheers,
Antonio

[Dirk Gregorius]

Friction is actually handled on the velocity level (non-holonom constraints) so I think this is the reason why the position based approaches have so much problems with it. So a velocity level only solver like Erin's sequentiel impulses will give nice friction results. The same is true for restitution. All other constraints like joints are holonom and can be solved for the position error. Here the position based approaches like Jacobsen (or Muller) have an advantage over the velocity only solvers, because the try to solve the system of non-linear equation using some kind of "Gauss-Seideled" Newton iteration (s. Erin SuperSplit). With Erin' SI you linearize the position constraints in the Baumgarte term and this can lead to a lot of problems. The reason is that even if you find a perfect solution to your velocity constraints you can still have huge position errors (e.g. because of high angular velocities). These errors break your (Baumgarte) linearization and lead to instabilities.

So all you can is try some hacks, but this will most propably will not give satisfying results. If you want a best of both worlds look at the work of J. Bender. He iteratively solves for the position and velocity constraints. Maybe his approach could be made a little bit more performant. Currently I am thinking of something like this:

x(t+dt) = x(t) + v(t)*dt + 0.5*a(t)*dt^2
v(t+dt) = v(t) + a(t)*dt

CollisionDetection();
SatisfyPositionConstraints(); // Jacobsen
SatisfyVelocityConstraints(); // Sequentiel impulse (no stabilization)

I like the idea of fixing penetrations in the current frame, so this could avoid visual artifacts. Also for the position constraints we now finally try to solve what it we actually a must - a system of non-linear equations. Given the experiences we have with the Jacobsen method and according to Erin's result that Newton quickly converges at least to a local minimum (even for big errors) this could give reasonable results.

On the downside this should be slower then a velocity level only solver, but maybe we can warms-start the SI as we are used to and the Jacobsen stuff usually needs only very few iterations, so it could be reasonable fast and you could use it where you need higher quality.

Please note that nothing of this is tested. Just something that is going around my head...

[Antonio Martini]

Friction is actually handled on the velocity level (non-holonom constraints) so I think this is the reason why the position based approaches have so much problems with it.

Penalty methods "solve" for static friction at position level by attaching springs.

my problem was the following: assume you have a deformable box lying on the floor, volume conservation is enforced while you apply a slow uniform force on the top side in the direction of gravity. At some point the box will stop deforming. If there is no friction the opposite faces will still be parallel and they will have the same area. with maximum friction i am expecting to see the lower face in contact having the original area before the force was applied, the sides bent etc... so depending on the friction values im expecting the lower face to have different resulting area at the end of the process.

Now how do we do this with velocities if the constraint solver is shifting positions all around during the process? The solver can move all the vertices in contact even if i set the velocity to zero everytime, thats why i formulated friction using the penalty concept and like i said it seemed to work well. Then the fact that there is one method that works doesn't mean that there aren't others:)

cheers,
Antonio

[Dirk Gregorius]

Of course you can use a penalty method and I have no doubt that you can get good results this way, so it might be a nice option to use a penalty method with position constraints for the joints. Did you try this?

On the other hand if I see the very good results I get with SI for contact I will never throw this away easily. Personally all I would like to improve is the stabilization and less stretchy joints. In my opinion you can't achieve this with a velocity level solver.

Edit: Not to forget joint coordinates (Featherstone) in this context...

Cheers,
-Dirk

[Antonio Martini]

Of course you can use a penalty method and I have no doubt that you can get good results this way, so it might be a nice option to use a penalty method with position constraints for the joints. Did you try this?

i tried the friction approach i mentioned. I dont fully understand what you mean in regard to joints, the context is deformable bodies by using the position based approach, so if you have point to point constraints you can create all the joints you like. I said that i used a penalty concept, in the same way as conceptually resizing an edge is similar to having a spring of infinite stiffness. So some ideas transfer from one method to the other.

cheers,
Antonio

[Antonio Martini]

Edit: Not to forget joint coordinates (Featherstone) in this context...

Cheers,
-Dirk

it may well be that i have misunderstood, i thought that the problem is to deal with friction in the position based approach. The box2d example was mentioned as source of inspiration but the context is still PBD where bodies aren't necessarily rigid, here it looks like that a reference is becoming the context. i might have read the posts too quickly.

cheers,
Antonio

[raigan2]

Antonio: the breakable tangent constraint is a great idea! I had though of using tangent constraints but had no idea how to model the variable-response produced by friction.

Dirk: a potential problem with your proposed sim is that you're updating positions before velocities -- this is the problem that PBD has with friction. Unless you update/correct velocities first, and use the corrected velocities to update position, then positions will always be able to drift: friction constraints _will_ keep tangent velocity at 0, but since position-solving iteratively adjusts the position of objects, positions will still drift down slopes due to gravity+collision. This is why a position-level constraint may be necessary for friction.. But I agree that combining the velocity-level solving of box2d and the position-level solving of PBD sounds promising.


To everyone, I've been working on a PBD-based solver for rigid bodies (totally rigid, not "really stiff deformable") which is based on Jakobsen's idea of: use a simple particle+stick dynamics model, and "embed" it in constraint geometry. You can then use this geometry to generate constraints -- you just need to transform things into the particle+stick space (i.e you need to transform a given desired change in geometry state to the corresponding change in particle state).

In 2D this is quite simple: using 2 particles and a stick, I use the vector between particles and it's perp to describe a space, and it's easy to transform values in this "parametric segspace" to/from worldspace. Using this, you can quite easily determine the correct displacement to apply to the stick particles in order to create a given worldspace movement for an arbitrary point embedded in segspace.

The only tradeoff so far is that you have to give up the ability to model arbitrary moments of inertia -- you can only adjust the mass distribution along the stick's axis, instead of in full 2D.

Anyway, at some point there will be tutorials and source, but that's a long way off -- there are still many kinks to work out. Thanks for the help.

[raigan2]

FYI, Antonio's tangent-position-constraint method is working quite well in initial tests, it certainly solves the drifting problem.

One issue is of how to best calculate friction-related values (such as target/initial tangent position, or normal force): the data at each iteration can change wildly.

The only thing i can think of is using the previous frame's final state.. which would mean friction was 1 frame late. I'm pretty sure this is something that someone has mentioned here before, but my searches aren't finding anything.

[Antonio Martini]

One issue is of how to best calculate friction-related values (such as target/initial tangent position, or normal force): the data at each iteration can change wildly.

in my test the target tangential position was always the same at every iteration and it was the projected position(along the plane normal) of the penetrating node before entering the solver. At every iteration i checked if a node was penetrating and i applied the tangential constraint only in such case. However it was a quick test, surely there can be a few variants.

cheers,
Antonio