Constraints that should hold things in place doesn't

[albinaask]

I would expect that Constraints that are set with absolute limits are withheld for high forces without causing springy movement. For example I would expect that a fixed constraint would keep two bodies from changing their distance between each other with basically any force applied. This is however not the case, which I would argue results in instability of the simulation since a physics based game relies on these constraints to be upheld in order to ensure the intended behaviours.

The attached video shows a stack of blocks connected via 6DOF constraints without any spring, any motor or anything like that. In my head, this should place a constraint to keep the objects in place in relationship to each other, just like a fixed constraint would. The lowest cube is joined to the "base plate" which is a static body. The lowest rectangular piece is then connected to the first cube etc al the way up to the top. The expected behaviour is that these should induce no movement in any part since they are supposedly pinned together in a static fashion through the constraints. (Edit, the examples behaves better with a higher "Contact bias" up to equal 1, but it's still not nearly good enough. Would this be a Godot Jolt problem because they set it too low? and it can go above 1?).

All the objects have a mass of one, except for the very top one, which has three different masses, shown as subtitles in the video ranging from 1 to 100kg.

I can't really test the static constraint since it's not exported to Godot, but I'm sure you can test it in your build environment

BlockStack.mp4

Another test is if we apply a force to a cube to make it accelerate against a wall, held in place with a similar constraint. It fares well until we bump the force and mass of the cube up to 100kg, beyond which it starts to move disconcertingly.

Force.On.Constraint.mp4

The final test I've made is that the following red and blue bodies are connected via a sliding constraint whilst the red cuboid is frozen and the green cube is pushing on them with considerable force about 1kN at 1000 kg. This causes the constrained blue body to not be constrained in this given direction, even though the constraint would indicate it to be locked.

Slider.mp4

[jrouwe]

The answer to this is the same as #1390: You cannot have heavy objects attached to light objects as the solver cannot generate enough force in the number of iterations it has to hold the objects in place. If you want to have a stable simulation, make sure the masses decrease with every 'link' from the static world to the top block.

In general, a 'fixed constraint' can never be 100% rigid because of the way the solver works. If you want a 100% rigid connection you would group the collision hulls under the same physics body instead of connecting them via constraints.

[albinaask]

Hmmmm, I see. I know that a lot of physics libraries have this problem. I really do. The issue I'm having with this is that I want users to be able to combine blocks in arbitrary ways, of course blocks that aren't able to move independently share the same body, but I want to implement things like pistons that can manipulate the bodies' positional relationships. Since the bodies will be of different sizes, the masses would reasonably vary quite a bit. Could there be an option to make the solver artificially reset the axis that are 'locked' by the constraints to the location by the heavier body in the end of a simulation step or something like that? Or could there be an option to generate bigger compensatory forces? How does the contact bias fit into all this?

[jrouwe]

Could there be an option to make the solver artificially reset the axis that are 'locked' by the constraints to the location by the heavier body in the end of a simulation step or something like that?

Fixing the constraints between 2 bodies after the step may make it penetrate or violate a constraint with a 3rd body, so is not recommended. The best way really is to tweak masses so that they don't differ more than say a factor of 10. If you do this, most of the time people don't really notice.

For contact constraints, Jolt offers a way of overriding masses in its ContactListener class. This can be used to limit the mass difference for one contact, but this property is not exposed to godot at the moment. In any case, it would not help with the constraints, only with the contacts.

There is another solver approach ('small steps') which does much better with high mass ratios. This is something I looked at briefly and is something I will one day implement, but it requires a massive rewrite.

How does the contact bias fit into all this?

If you're talking about SPACE_PARAM_CONTACT_DEFAULT_BIAS then it doesn't. Jolt doesn't use that value. Jolt uses the 'Baumgarte Stabilization Factor' in combination with the 'Position Steps' attribute to control how fast constraint violations are resolved.

[albinaask]

So what you're saying is that overriding masses in contacts would for example affect the contact between the blue and green parts in the last clip so that the lateral movement would be reduced? But the green cube would still need 1kN to accelerate at 1m/s^2 if the body's mass is set to 1000kg, but act in the contact as if it only had a mass of 10kg?

Is the parameter set in the contact listener something you can do globally, or something you have to change for each collision point? If so, I gather that it's rather expensive if the algorithm has to jump from just doing collisions to some entire other part of the code base?

[jrouwe]

So what you're saying is that overriding masses in contacts would for example affect the contact between the blue and green parts in the last clip so that the lateral movement would be reduced? But the green cube would still need 1kN to accelerate at 1m/s^2 if the body's mass is set to 1000kg, but act in the contact as if it only had a mass of 10kg?

Correct.

Is the parameter set in the contact listener something you can do globally, or something you have to change for each collision point? If so, I gather that it's rather expensive if the algorithm has to jump from just doing collisions to some entire other part of the code base?

The current implementation already overrides the body masses, just not in this particular way. Adding extra logic there should not make things much more expensive.

[albinaask]

How very nice of you to answer all my questions.

Would it be as easy as to add a line before the last if-statement that just clamps body2:s inv mass and tensor between 0.1the mass of body 1 and 10 the mass of body 1or does this mean that the implementation would have to go the following way:

1. Add an either global or per body boolean parameter to the Jolt API to hold this value. (I think from a usability perspective it would be cumbersome to have a script to add this attribute to every encountered collision). Or would I assume wrong?
2. Check for this option, and if true, set both inverse masses and tensors for both objects in the contact settings to 0.
3. Expose this object to Godot Jolt

Or have I interpreted you entirely wrong here?

[jrouwe]

In the code above, we're talking about inverse mass scales, the function receives 1's as input and can modify the scale on output. You'd need to look at the actual mass of the bodies to decide what scale you want.

Add an either global or per body boolean parameter to the Jolt API to hold this value. (I think from a usability perspective it would be cumbersome to have a script to add this attribute to every encountered collision). Or would I assume wrong?

If you mean the Godot Jolt API then yes, you would need to somehow add a property to a RigidBody3D to indicate you want this behavior and modify the callback mentioned above. If you mean the Jolt API, then no, I'm not going to add a property to bodies for this purpose, it is too specific.

Check for this option, and if true, set both inverse masses and tensors for both objects in the contact settings to 0.

If you set both inverse mass scales to 0 then you're indicating to Jolt that both bodies are kinematic and they will pass through each other unaffected. Instead if A is 100 kg and B is 10 kg then you would set the inverse mass scale of A to 10 to make A and B equally heavy for the simulation.