Constraints can sometimes go whacky mode

[Joshua-Ashton]

Sometimes having a system of fixed constraints can go crazy and fly all over if you prod them enough.

I have attached a repro case

Before:

After:

I had to change the LoadSnapshotTest to account for my object layers:

	Ref<PhysicsScene> scene = result.Get();
	for (BodyCreationSettings &settings : scene->GetBodies())
	{
		if (settings.mObjectLayer == 0 || settings.mObjectLayer == 1)
			settings.mObjectLayer = Layers::NON_MOVING;
		else
			settings.mObjectLayer = Layers::MOVING;
	}

	result.Get()->CreateBodies(mPhysicsSystem);

It's also marginally annoying that mUp points the wrong way too, but not the end of the world.

snapshot.zip

[jrouwe]

I've looked at this, It's quite a complex scene. I wouldn't recommend creating a large level section build out of physics objects connected with fixed constraints. I assume you do this because you want to make certain parts fall off at some point (disabling the fixed constraint maybe if some force threshold is exceeded)? What we would normally do is create the object as a static object and change part of it into a physics object when a certain condition is met (e.g. it being shot). Perhaps you can convert the tower into fewer sections constrained with fewer fixed constraints and only activate the internal constraints as soon as part of the structure exceeds the max force (assuming you need the internal forces).

There's one thing that is definitively wrong with the setup and that is that you're not using BodyCreationSettings::mCollisionGroup to disable collisions between connected objects. If you activate the manifold view (M in the viewer) you will see that there are many internal collisions which cause objects to be pushed apart which will fight the fixed constraints:

Other than that if you go to the mass view (I) you can see that you have heavy objects being constrained by light objects:

This is also not good for an iterative solver (the light bodies are not able to push the heavy bodies very well). And finally those light bodies are long and thin which makes everything worse.

What you could try is to make the mass of the pillars a lot larger (same mass as the top, i.e. in the order of 400-600) and keeping the mass of the crossbeams low. Also you could try to change the inertia tensor so that it represents a box that is not so elongated (see MassProperties::SetMassAndInertiaOfSolidBox and put it in BodyCreationSettings::mMassPropertiesOverride). Another thing you can try is to specify the actual points where the crossbeams connect in FixedConstraintSettings::mPoint1/2 instead of letting the system guess through FixedConstraintSettings::SetPoint. All of these are very hard for me to test with this binary snapshot, so I have to do a bit of guessing here.

Finally, the simulation becomes more stable if you lower PhysicsSettings::mBaumgarte and increase mNumVelocitySteps and mNumPositionSteps (at the cost of a lot of extra CPU cycles).

[jrouwe]

Also, make sure that when you connect 2 bodies that body1 can be seen as the parent (closer to the root) and body2 the child. I have the feeling that the whole construct becomes more stable if I swap all your bodies around.

[jrouwe]

B.t.w. I added a Z-up mode + layer override mode in ab85142716a44d2a227e7c586b00ae80ec982630

[Joshua-Ashton]

Thanks, I will try some things out.

I should have said that this is just a random community creation I spawned, so I have no control over what it does.

I can definitely try disabling internal collisions and the other tweaks that were mentioned, though.

I also wasnt aware there was a difference between parent and child for FixedConstraint, the old physics system we used didnt have such a concept.

[Joshua-Ashton]

I also have the issue where with some of these creations (not this one) the constraints end up making the object go to NaN with some tugging. The game is smart enough to kill any object that goes there.

[jrouwe]

The constraints don't really have a concept of parent and child, but some constraints have calculations that favor body1 (e.g. hinge, not sure about fixed constraint) so it is usually best to make that one the closest to the root. Shouldn't make a huge difference though.

When you push the construction around, and the whole thing becomes unstable, it is usually a matter of time before the numbers become so big that a NaN gets introduced and the whole thing explodes. If you fix the instability, you'll fix the NaNs too.

While playing around with your scene, I noticed that it takes very long to load the snapshot and it takes about 1 GB of memory. It looks like you create many many convex hulls (a lot of them containing only a single triangle). This really hurts memory and performance as well. I would suggest to collapse static geometry in MeshShapes (1 per area / group).

[jrouwe]

Hello,

I've been trying to improve the behavior of this scene and in the process I made a similar scene to yours through code and implemented it in Bullet, PhysX and Jolt to see how they compare. First movie is how the construction behaves under influence of gravity, second movie is shooting a sphere with radius 1 with 100 m/s at the base of the construction.

Jolt holds up under gravity, but starts behaving erratic when shooting a sphere (if you try harder the scene will explode): https://user-images.githubusercontent.com/1621693/173144851-f6ee69f1-a666-457d-88be-1f3e848292ab.mp4 https://user-images.githubusercontent.com/1621693/173144860-df182918-7c99-4f84-8d68-670d554fbd76.mp4

Bullet doesn't hold up under gravity at all but at least is stable at all times (I think that's mainly because the constraints are too soft to explode): https://user-images.githubusercontent.com/1621693/173144831-5de14a4b-89e0-4d26-860f-87dd86f211e7.mp4 https://user-images.githubusercontent.com/1621693/173144844-3270f9c0-645c-42e7-b81f-89fc0a80c207.mp4

PhysX holds up under gravity but explodes immediately when shooting a sphere at it: https://user-images.githubusercontent.com/1621693/173144871-c016aae9-6a5c-4164-9626-bb5139bacd78.mp4 https://user-images.githubusercontent.com/1621693/173144877-9f5f88eb-33a6-4a9f-885a-42b0ede5b2bf.mp4

Code for the tests: https://gist.github.com/jrouwe/5494733c7aecb7ce6fe68dfada3e5789 (code for Jolt was submitted in 7a2991f6bdc29e3dec292637a9586d3c87d5a647)

Given that all physics engines seem to have great difficulty with this type of scene, I'm not sure how much can be done about it.

[Joshua-Ashton]

Hmm, it holds up fine with Havok (Havok by name, it is actually IVP + Havok Constraints)

I'll try playing with the jolt constants more, and see what impact it has for me.

[Pierre-Terdiman]

That's because IVP (Ipion Virtual Physics) was not using a linear solver.

[Pierre-Terdiman]

FWIW this seems to work better in PhysX 5 (it looks more stable than PhysX 4 for similar setups). I managed to make it work there with 128 iterations, both with PGS and TGS:

https://www.youtube.com/shorts/V2AJ4SPdSqU

https://www.youtube.com/shorts/lu2_bw3yjbk

[Joshua-Ashton]

That's because IVP (Ipion Virtual Physics) was not using a linear solver.

Makes sense, I didn't think of that.

[jrouwe]

With 128 iterations it seems to work for Jolt too (e.g. with 64 velocity steps and 64 position steps, but that's quite a lot of iterations :). Also, I said earlier to decrease mBaumgarte in that case, but actually you should increase it to make the structure stiffer (just beware that things can also explode if mBaumgarte is too large).

Is the IVP source code somewhere? (I've never worked with IVP and I don't know what solver it was using)

[Joshua-Ashton]

It is not available publicly.

[jrouwe]

I've made it possible to specify the number of position/velocity iterations per constraint (#223). This should make it possible to increase them for certain constructs. I'm going to close this issue now as I don't think there is much else that can be done.

[Joshua-Ashton]

Interesting! I will hook this up to a convar and try it out