AlignPosition's RigidityEnabled property does not work as intended

Issue Type: Other
Impact: Moderate
Frequency: Very Rare
Date First Experienced: 2021-04-05 21:04:00 (-04:00)
Date Last Experienced:

Reproduction Steps:

  1. Create an assembly with WeldContraints
  2. Attach all parts to the PrimaryPart of the model
  3. Create AlignPosition & AlignOrientation objects and parent them to the PrimaryPart
  4. Create an attachment & parent it to the PrimaryPart
  5. Set the RigidityEnabled property of AlignPosition to true
  6. Create a Goal part & attachment
  7. Set the Attachment0 & Attachment1 properties (Attachment0 = PrimaryPart attachment, Attachment1 = Goal part attachment)
  8. Move the Goal Part
  9. Click ‘Run’ in studio

Expected Behavior:
I expect the assembly to move as quickly as possible to the goal position when RigidityEnabled is set to true.

Actual Behavior:
When using AlignPosition on an assembly (in conjunction with an AlignOrientation), I enabled the RigidityEnabled property, but the assembly moves slowly to the goal attachment. When instead using a large MaxForce value with a Responsiveness of 200, the assembly moves very quickly, as expected.

Included are videos describing the behaviour, and privately attached is a repro file with the assembly.

With RigidityEnabled

Without RigidityEnabled (Responsiveness workaround)

Kind of? Setting the Responsiveness to 200, setting the MaxVelocity to a reasonable value, and setting the MaxForce to a very large value works almost as I expect RigidityEnabled to.

Did you try making all the Parts in the ship Massless?

This is understandably confusing, but actually working as intended.

One implementation detail about constraints that’s sometimes impossible to hide is that they work in two very different ways at the same time: by changing velocities and positional correction.

Generally the velocity correction works to maintain alignment assuming things are already aligned, and position correction is used to correct alignment when they are not aligned. The velocity correction actually does most of the work, and is generally the most important part of constraints. Ideally we wouldn’t need positional correction at all, but it’s necessary to correct drift due to mathematical imprecision and non-linear behavior (like rotation) that the linear solver can’t perfectly account for. Because it’s meant for only minor corrections and does artificially add or drain energy from the world by changing potential energy it has very low limits set for it.

So AlignPosition and Rigidity…

Without rigidity, the constraint is entirely acting on the velocities of the two bodies. It has a force controller applying forces to accelerate up to some velocity and slow it before it overshoots. The max relative velocity it can reach is quite high, but it is using velocity.

With rigidity the constraint is not applying interesting forces between the two attachments, only working to match their velocities so that they stay rigidly aligned. If they are not already aligned the correction is done entirely by positional correction, which has a low absolute limit meant only to fix drift that creeps in from limitations of the velocity correction math.

In other words rigidity will rigidly KEEP things aligned super rigidly, but only if they’re moving with velocities. If they’re not already aligned or you’re CFraming things you’ll be leaning entirely on slow positional correction.

Another Example: Collisions

Collisions are another example where the difference between velocity correction and positional correction is interesting. Collisions are constraints internally too!

If you position two parts with one inside of the other, it’s actually the positional correction that pushes them apart. No force involved, we just pop them apart. If forces were working correctly this never should have happened. We either caught the collision too late, or the developer moved them outside of physics. It’s a positional error, positional correction fixes it.

After that initial correction the velocity part of the collision constraint will reflect or negate the relative velocity of the objects to make them bounce if Restitution > 0 or to keep them resting together without overlapping by applying equal and opposite forces on both parts. Positional correction isn’t really doing anything here after the initial impact.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.