How to deal with Rigid and softbody interaction

[bone]

No, sorry, I didn't mean at the same time, those are all separate functions of the constraint. I'm using something like you have recommended in the past for a symplectic euler loop:

// symplectic euler velocity integration step
for all bodies:
..body->IntegrateVelocity()

// solve velocity constraints
for all constraints:
..constraint->PrepJacobian()
for numVelocityIterations:
..for all constraints:
....constraint->SolveVelocities()

// symplectic euler position integration step
for all bodies:
..body->IntegratePosition()

// position correction
for numPositionIterations:
..for all constraints:
....constraint->SolvePositions()

[fishboy82]

// symplectic euler velocity integration step
for all bodies:
..body->IntegrateVelocity()

// solve velocity constraints
for all constraints:
..constraint->PrepJacobian()
for numVelocityIterations:
..for all constraints:
....constraint->SolveVelocities()

// symplectic euler position integration step
for all bodies:
..body->IntegratePosition()

// position correction
for numPositionIterations:
..for all constraints:
....constraint->SolvePositions()

Hi Bone : It seems the above procedure is just like the ordinary solve procedure plus a position correction procedure. So what's your meanning of "generic constraints ",as you said "My constraints are aware of more than just the Jacobian " So what's that meanning? Is that meanning you constraint can easily process constraint which has more than 2 objects involved?
By the way Dirk,Bone,raigan , I am considering if we use position correction step why we need velocity level solver any more? Could we do like this:

for all bodies:
..body->IntegrateVelocity()
..body->IntegratePositionAndOrientation()
// Use New Position to Detect collision
TestCollision();
// position correction (Project Position to their correct Position)
for numPositionIterations:
..for all constraints (contact and Joint):
....constraint->SolvePositions()
//Use the difference of the corrected new position and the last position to calculate linear speed and angular speed
CalculateSpeed();
It is just like the Position based solver .So am wondering if we use the step of position correction ,why we not directly use the Position based solver,and use position difference to get bodies speed.

[raigan2]

So am wondering if we use the step of position correction ,why we not directly use the Position based solver,and use position difference to get bodies speed.

Our solver *is* position based; there are benefits but also a lot of disadvantages -- collision detection needs to happen in the inner solving loop, TOI/swept simulation isn't possible (at least, I haven't been able to figure out how to get this working sensibly), etc.

I think both position and velocity solving might be the best idea; this way, constraints which are velocity-only are more naturally formulated at only the velocity level, while position constraints will involve both position- and velocity-level solving.

[bone]

Hi Bone : It seems the above procedure is just like the ordinary solve procedure plus a position correction procedure. So what's your meanning of "generic constraints ",as you said "My constraints are aware of more than just the Jacobian " So what's that meanning? Is that meanning you constraint can easily process constraint which has more than 2 objects involved?

By generic, I just meant they could work with either point masses or rigid bodies. My constraints have access to the bodies, so they can apply sequential impulses or position corrections. I was replying to raigan2's post that said their constraints were only aware of the Jacobian. In contrast, my constraints build the K matrix and all that.

By the way Dirk,Bone,raigan , I am considering if we use position correction step why we need velocity level solver any more?

My opinion is that truly velocity-based actions like friction and restitution can't easily be done with position-level solvers. Obviously raigan2's opinion on the matter has a lot more weight, though.

[fishboy82]

Thanks Bone and Raigan:
I think I finally got what your meaning ,so their is only one remain question

constraints which are velocity-only are more naturally formulated at only the velocity level, while position constraints will involve both position- and velocity-level solving

So what the "velocity-only constraint" and "position constraints"meaning, in my mind all constraints should be satisfied in all 3 level(velocit ,position ,acceleration)?

[bone]

So what the "velocity-only constraint" and "position constraints"meaning, in my mind all constraints should be satisfied in all 3 level(velocit ,position ,acceleration)?

For many constraints, you're basically right, I think, because those 3 levels are related to each other - velocity is the derivative of position, and acceleration is the derivative of velocity. So that's why a normal ball joint, for example, can be 'solved' at any of the levels. If you guarantee that the acceleration at the ball joint is zero, then the velocity and the position should also stay at zero (assuming they started at zero). Of course numerical errors and integration mess up this perfect scenario.

But other constraints are not so "easy". I think that nonholonomic constraints are one example, although I'd be treading out of my comfort zone if I tried to explain what that meant. I can say, though, that dynamic friction is not easily described in terms of position.

[raigan2]

My opinion is that truly velocity-based actions like friction and restitution can't easily be done with position-level solvers. Obviously raigan2's opinion on the matter has a lot more weight, though.

I don't know if the way I'm approaching things is generally applicable -- velocity-level constraints can be modeled trivially using position-level constraints if you use a scheme like Jakobsen's where position and velocity are coupled, because then there is no "position" or "velocity", only a combined "position/velocity", and changing one changes the other. Of course the tradeoff is that you can't change one without changing the other, which causes problems of its own (i.e any unresolved penetration becomes outward velocity next step).

If you don't couple position and velocity like this then I'm not sure what you can do.

We've avoided restitution entirely (i.e nothing bounces) since as far as we could tell there are very few scenarios where you actually need/want bouncing objects. Typically they're special-case small objects which aren't involved in any constraints aside from collision (grenades, balls, etc), we're hoping that we can achieve bouncing for such objects through a logic-based approach (i.e on collision callback, modify velocity directly).


A different way to look at Jakobsen's method that just occurred to me recently (possibly someone on this list has already mentioned this) is that it's just a normal impulse-based velocity-level solver, but it minimizes error measured at the predicted future state rather than the current state.

So, to solve a constraint you do prediction-correction:
-predict: integrate positions using current velocities to get predicted state
-correct: calculate constraint error at predicted state, apply corrections to current velocities

Rather than all the work of explicitly applying impulses to change the current velocity, and then re-integrating to get a revised predicted state, current velocity and predicted position are cleverly encoded in such a way that we get the corrected state immediately without having to manually re-predict.


Actually if you look at how Guendelman's "Non-Convex Rigid Bodies with Stacking" solver works, it's very similar -- use future positions to generate constraints and then correct the current velocity such that the future position error is removed.