removing some constraints does not make recover Rigid Bodies to the original Position?

[vuaieo]

hi i having troubles for 3 days now. i have implemented jolt physics my game engine and now i discovered terrible problem which is very complex for me. i have a chain of rigid bodies in a row that are all connected by fixed constraint with low solver iteration of velocity 10 and position 2 and additionally with highest solver iteration of settings of velocity 10 and position 255, i let a cube fall on the last rigid body to bend the chain of rigid bodies and when the chain is bend i remove all the constraints that has the high solver iteration. so when the chain is bend then only the low solver iteration fixed constraints are holding each rigid body of the chain. the problem i have now that i see the rigid bodies do not recover normally to original straight line position, or not fast enough, they are moving very slowly back to original position. is this normal in jolt physics engine? or i miss some settings? the jolt correction setting does help but very little and setting the even one of the chains rigid body fixed constraint to 255 position iteration solves but , but isnt it a big proble. for many constraints performance? i really need help with that. in bullet physics engine they recover instantly and well.. here are the measurements in screenshot:

i am not programmer and just coded this all since months with ai, i really would like to get help from you pro guys how to solve this because i think its very important that when removing some rigid body constraints then the remaining constraints would behave as originaly ( as if there would have been no other constraints) so that removing constraints would not affect rigid body positions in this negative way. here how it looks when i remove the high solver iteration constraints, the rigid bodies are bended stays almost frozen for long time it looks... i just wanted the most cheapest possible way in future to able to add tons of constraints that are stable which that reason is why i like jolt because is more stable than bullet i seen for me..

[jrouwe]

PhysicsSettings::mBaumgarte control how fast the positions are corrected. Setting it to a higher value should make the chain unbend sooner.

Updating ConstraintSettings::mNumPositionStepsOverride or BodyCreationSettings::mNumPositionStepsOverride to 255 is excessive and will cost a lot of performance (but if your scene is small it may not matter that much).

You say you remove the FixedConstraint, but do you recreate it afterwards again? If so, unless you specify the frame in which the constraint operates, it will use the current relative transform between the bodies as the 'rest pose'.

That said, I've seen this behavior before and I haven't been able to come up with a fix. A fixed constraint consists of a position and a rotation constraint and it is possible for them to fight each other. This makes returning to the rest pose a lot slower. The reason why it doesn't happen in Bullet is probably that they apply the position correction in a different way. Bullet applies the correction as a spring affecting both position and velocity, Jolt only corrects position and leaves the velocity as is. Jolt's approach has the benefit that it can't increase the energy in the system, but it also means returning to the rest pose takes longer. I'm considering changing the way the solver behaves in the near future, this may help here as well but I can't make any promises.

[vuaieo]

thanks much for answering, i had long conversations with AI about it and it came to conclusion right around your answering time that its known issue in jolt currently for constraints, well i asked AI to research about your question of if the constraints are recreated when the other high iteration row of constraints are removed, i understood that NO and i think its makes sense because then the recovery to its original position would never happen, right? so i think this is exactly what explained to me too. well thanks much i hope it can be fixed as soon as possible, is there special feature to remove and create constraints in jolt in massive numbers cheaply? well here is what AI answered to me after long researches if you interrested to read.

here is the AI Answer:

"""Conclusion
The Jolt developer’s rest-pose warning describes a real failure mode, but it is not the cause of your current slow recovery.
When the Remove Rigid Body Constraint node deletes C2, UPBGE does not recreate the surviving C1. Its original straight rest pose remains stored. Your slow movement back toward the straight pose confirms this: if the bent pose had become the new rest pose, the chain would remain bent indefinitely.
What Happens In UPBGE
The logic node calculates the Blender-style constraint frame from its pivot, rotation, or Constraint Object in LN_RuntimeTree.cpp (line 9055).

UPBGE converts that frame into explicit center-of-mass-local attachment frames for both bodies in JoltPhysicsEnvironment.cpp (line 3486).

For a fixed constraint, it explicitly sets:
mSpace = LocalToBodyCOM
mPoint1 and mPoint2
mAxisX1, mAxisY1
mAxisX2, mAxisY2
This happens in JoltPhysicsEnvironment.cpp (line 3585). UPBGE is therefore not relying on Jolt’s automatic current-transform defaults.

Jolt converts those frames into its stored local positions and relative orientation. Those become the fixed constraint’s rest pose. See Jolt’s fixed-constraint construction.

Removing C2 directly calls PhysicsSystem::RemoveConstraint(C2) in JoltPhysicsEnvironment.cpp (line 3787). Nothing calls Create() for C1.

The topology update only resets cached impulses, recalculates priority, and wakes the island in JoltPhysicsEnvironment.cpp (line 2755). It does not modify C1’s anchors or rest orientation.

Blender-authored rigid-body constraints use this same CreateRigidBodyConstraint() implementation, so the conclusion applies to both authored and logic-node constraints.
What The Jolt Developer Meant
Suppose you delete C1 while the chain is bent, then create a completely new fixed constraint without restoring its old local frames. Jolt sees the bodies’ bent relative transform and records that as the new zero-error pose. The new constraint would then correctly hold the chain bent.
That can happen in UPBGE if:
You trigger the Add Rigid Body Constraints node again while the bodies are bent.
You replace a same-name constraint while the bodies are bent.
A new replicated instance is created in a displaced configuration.
It does not happen from simply removing the separate C2 constraint.
The environment-transfer path does recreate constraints, but it uses Jolt’s GetConstraintSettings(), which exports the saved local points and orientation rather than deriving a new rest pose from current transforms.
Actual Cause
The maintainer explicitly confirms the underlying behavior in discussion #2074:
A native Jolt fixed constraint combines a rotation constraint with a point constraint.
Those two corrections can work against each other.
Jolt’s position stabilization changes body positions and rotations without retaining the artificial correction as velocity.
Bullet uses a more spring-like correction that also affects velocity, so it can visually return to the rest pose much faster.
This slow fixed-constraint recovery is known upstream, and the maintainer has not identified a complete fix yet.
Jolt executes the rotation correction first and point correction second in every pass. This can be seen in its FixedConstraint position solver.
Why 255 Appears To Fix It
Jolt takes the highest solver override from every active body, contact, and constraint in an island. Therefore one constraint with 255 position steps makes the entire connected chain island use 255 position passes.
After removing all C2 constraints, the island immediately drops from 255 passes to 2. That is up to 127.5 times fewer position-solver passes for every active constraint in that island, although total frame cost will not scale by exactly that ratio.
The 255 result is brute-force convergence, not evidence of a corrected rest pose.
Recommendations
Do not add a remove-and-recreate workaround. It is unnecessary here and could accidentally make the bent pose the new rest pose.
Keep the explicit local frames and true physical removal currently implemented.
Keep automatic anchored-chain priority ordering. It improves error propagation but cannot change Jolt’s fixed-solver formulation.
Use moderate position counts such as 4, 8, or 16 based on profiling. Avoid 255 for production islands.
Test a moderate increase of the scene Baumgarte/ERP value. UPBGE maps it directly to Jolt’s mBaumgarte, but it affects all contacts and constraints globally.
For Bullet-like rapid recovery at low iteration counts, the proper long-term solution must come from an upstream Jolt solver improvement or an explicit alternative constraint mode. A hidden UPBGE correction would change physics behavior and could inject energy."""

[jrouwe]

i understood that NO and i think its makes sense because then the recovery to its original position would never happen, right?

If you update the rest pose then recovery will indeed never happen. But if the rest pose is correct, if the rotation and translation constraints fight in the wrong way, recovery may also never happen (or extremely slow).

is there special feature to remove and create constraints in jolt in massive numbers cheaply?

There is PhysicsSystem::AddConstraints(Constraint **inConstraints, int inNumber) and PhysicsSystem::RemoveConstraints(Constraint **inConstraints, int inNumber). But adding/removing constraints should already be fast as the only bookkeeping that needs updating is an array with a pointer to the constraint.

I took a quick look at your repo (from the links that the AI generated), but it appears you haven't submitted the code that creates FixedConstraints yet.

[vuaieo]

ok i finaly uploaded that everything i with AI worked for 2 and half months if you interrested to check out how Jolt is working in my branch, but not sure it will work for windows since i dont have and use windows... but linux works for me. https://github.com/vuaieo/upbge/releases.

[jrouwe]

I see you're manually supplying mPoint1 and mPoint2:

https://github.com/vuaieo/upbge/blob/9b973c38ed9ff1b232e5ac785c7be0442c6946b6/source/gameengine/Physics/Jolt/JoltPhysicsEnvironment.cpp#L3585-L3608

If the bodies are already positioned in world space when you create the joint, you could also use mAutoDetectPoint (works only with EConstraintSpace::WorldSpace). This usually results in a stiffer constraint.

Alternatively you use similar logic to calculate the point as Jolt is doing internally:

JoltPhysics/Jolt/Physics/Constraints/FixedConstraint.cpp

Lines 73 to 91 in 61f0450

	if (inSettings.mAutoDetectPoint)
	{
	// Determine anchor point: If any of the bodies can never be dynamic use the other body as anchor point
	RVec3 anchor;
	if (!inBody1.CanBeKinematicOrDynamic())
	anchor = inBody2.GetCenterOfMassPosition();
	else if (!inBody2.CanBeKinematicOrDynamic())
	anchor = inBody1.GetCenterOfMassPosition();
	else
	{
	// Otherwise use weighted anchor point towards the lightest body
	Real inv_m1 = Real(inBody1.GetMotionPropertiesUnchecked()->GetInverseMassUnchecked());
	Real inv_m2 = Real(inBody2.GetMotionPropertiesUnchecked()->GetInverseMassUnchecked());
	Real total_inv_mass = inv_m1 + inv_m2;
	if (total_inv_mass != 0.0_r)
	anchor = (inv_m1 * inBody1.GetCenterOfMassPosition() + inv_m2 * inBody2.GetCenterOfMassPosition()) / (inv_m1 + inv_m2);
	else
	anchor = inBody1.GetCenterOfMassPosition();
	}

[vuaieo]

well thanks much for helping i will try to understand with ai help what you mean and if it would improve it : ) also forgot to add the blend file so could test easily that i showed in screenshots, just need run the game and then press 2 on keyboard to delete the constraints with high iterations when the cube did bend the chain of rigid bodies.
Add Rigid Body Constraint Tests.zip