Help Constrain two rods into each other

[Qriva0]

I would like to constrain rod by another one and align them to each other.
The way how I want this to work could be compared to putting one rod into another one, like into pipe.

   

I managed to write some script that maps particles from first rod to target position on another second rod (based on displacement), but this method fails to create stable alignment.
That script uses end of simulation to run constraint for both rods on each other. Position is casted and delta is based on nearest particle weights, but I guess because I don't mix orientations it fails to keep shape properly or it's caused by the fact it runs after simulation, but I hope I am wrong. Current result is some kind of broke, because outside of constraint particles "break" into their prefered direction, it's more like teleportation of common part, than physical constraint.

   

My question is - what things I need to take into account to make it work (even if not perfect), and is it actually possible at all without modification of Obi itself?
I also tried to pin particles of inner rod by setting invMass to 0, it kind of works better, but the problem is that it's one sided and first rod does not influence second one.
I wish there was way to kind of "blend" shapes of both rods into each other and make forces to work properly.

[josemendez]

I would like to constrain rod by another one and align them to each other.
The way how I want this to work could be compared to putting one rod into another one, like into pipe.



I managed to write some script that maps particles from first rod to target position on another second rod (based on displacement), but this method fails to create stable alignment.
That script uses end of simulation to run constraint for both rods on each other. Position is casted and delta is based on nearest particle weights, but I guess because I don't mix orientations it fails to keep shape properly or it's caused by the fact it runs after simulation, but I hope I am wrong.

Hi,

You can't do this by simply moving particles to their desired position once the simulation ends. This completely ignores velocity-level constraints, and will yield wrong results. I guess this is what you're describing as "more like teleportation that physical constraint". Same applies to orientations in the case of rods.

The only way to do this properly is to implement an entirely new constraint type in Obi's internal solver, that gets solved at the position level together with all other constraints. Once all constraints have been enforced, Obi will calculate a new velocity value that meets all constraints simultaneously.

My question is - what things I need to take into account to make it work (even if not perfect), and is it actually possible at all without modification of Obi itself?

I'm afraid it requires modifying Obi quite heavily, adding a new constraint type to the engine. Each simulation substep follows the basic PBD scheme:

Code:

#1) for each particle:
Use linear/angular velocity to calculate inertial position/orientation

#2)
for each iteration:
for each constraint affecting particle:
Adjust inertial position/orientation

#3) for each particle:
Use adjusted inertial position/orientation and previous position/orientation to calculate new linear/angular velocities.

For positional constraints to have any physical meaning, they must be enforced during step 2, so that proper velocities can be calculated during step 3. These steps aren't exposed as callbacks since doing so would be extremely expensive: in the Burst backend it would mean a sync point with the main thread, and in the Compute backend it would require synchronously reading data back from the GPU which is even worse.

I wish there was way to kind of "blend" shapes of both rods into each other and make forces to work properly.

Unfortunately not. This is a very specific kind of constraint that hasn't been requested before, so it's simply not been considered yet.

Your best bet is to implement this at the velocity level using impulses. That is, calculate the linear and angular impulses needed to drive each particle to the desired position/orientation and inject these as external forces into the simulation, just like you'd do in a regular rigidbody engine (like Unity). Note this won't be unconditionally stable as a fully position-based approach would be, overshooting may take place (like in Unity, too)

kind regards,

[Qriva0]

You can't do this by simply moving particles to their desired position once the simulation ends. This completely ignores velocity-level constraints, and will yield wrong results.

What if I fake integrated velocity? I mean based on constraint delta I would add velocity in the same direction, or even take previous position and current position to get that velocity like you did.

For positional constraints to have any physical meaning, they must be enforced during step 2, so that proper velocities can be calculated during step 3. These steps aren't exposed as callbacks since doing so would be extremely expensive: in the Burst backend it would mean a sync point with the main thread, and in the Compute backend it would require synchronously reading data back from the GPU which is even worse.

Assuming burst backend, why would that be a problem to expose callback? I guess you meant callback where you modify data on main thread, but I don't mean that but callback to attach my own jobs to queue to do stuff during substep. Actually I tried to do that in very dirty way and I attached my own jobs. The end result worked way more physically correct, but there is small shaking for some reason and when I change difference parameter, the one that moves one rod "inside" the other one, it does very strange stuff, so I guess I coded something in a wrong way or velocities from that movement makes the whole thing move like crazy.

Unfortunately not. This is a very specific kind of constraint that hasn't been requested before, so it's simply not been considered yet.

Oh, that was more general, just wondering, I know it's very specific and I don't even expect you to implement this.
When we talk about this, what would be nice to have is some kind of API to have ability to add custom constraint or other stuff to simulation, but I guess that would be a lot of work and probably most of people don't even need that.