We’ve recently upgraded our project to Unity 5. However, we’re running into problems with the new Joints that came with the new version of PhysX.
In Unity 4.6, we could attach a chain of rigidbodies to a ragdoll, and then drag the ragdoll over obstacles like rocks, stairs, etc. Even if we managed to get the ragdoll stuck in an area where it couldn’t fit through the simulation would remain very stable even as we continued to pull on the chain. If, somehow, the ragdoll or the chain started to jitter around because you were pulling on the chain too hard, as soon as you stopped pulling on the chain it would become stable again.
However, in 5, the exact same setup causes the joints to freak out very easily. Once the freakout starts, it never subsides, even after the force that introduced it is taken away. In other words, once it starts, it never stops.
To combat this, we’ve increased the inertia tensors to something much higher than what it gets set to by default. This fixes it in most cases, but then objects don’t behave realistically at all - the rope was stiff and seemed as though it could not be rotated - the ragdoll looked as though it were being held up by some ghost force.
But even with these measures in place, it was still very easy to drag the ragdoll through something that’d cause it to explode forever. These are all situations that Unity 4.6’s PhysX version could handle very easily, and with almost no instability.
The next thing we thought of doing was decreasing the maximum angular velocity of all of the rigidbodies involved… but… why exactly are we needing to butcher the physics so much in the first place, just to get it working?
Confirmed - yes, they are very unstable by comparison.
UPDATE: I’ve created a simple test that is identical between Unity 4 and Unity 5, (while still following the upgrade guide), and Unity 5’s PhysX joints… well, frankly, they’re abysmal.
It’s almost as though someone screwed up on the math, and it’s applying twice the amount of torque to correct joints, causing them to flicker back and forth across their goal mark.
A chain of rigidbodies held together by configurable joints.
The configurable joints do not use spring or damping - their positions X, Y and Z, are set to Locked. No other limitations or drives are given.
The rigidbodies’ masses alternate between 1 unit mass and 0.01 unit mass along the length of the chain.
The first and last rigidbodies are kinematic, and move back and forth through the Rigidbody.MovePosition() method via script.
No projection is used in either demo.
Enable Preprocessing is disabled on the Unity 5 demo.
The Unity 4.6 demo uses 15 iterations (though it behaves comparably at 6).
The Unity 5 demo uses 6 iterations (it behaves significantly worse at 15).
(The differences in iteration count were actually a mistake. I will quickly upload a new version of the demos where the iteration count is 6 on both, just to be fair.)
Fun fact: In all test configurations, Unity 4.6’s physics consumed less frame time (hovering around 0.1 - 0.15 ms) than Unity 5’s physics (hovering around 0.2 to 0.225 ms). (This was determined in the editor however.)
I can confirm this. I’ve been working with PhysX several years and have never encountered anything like this. Ragdoll with joints are useless right now. Even when using ODE I never saw problems like this. I do hope this gets fixed, but in the mean time I’m going to use another physics engine, like Bepuik (http://www.bepuphysics.com/).
No, it’s just the ranges are different in Physx 3.x. Basically, in 2.x they were clamped over a certain amount. In 3.x they’re unclamped and have different ranges. In short you need to redo any joints work and learn the new best settings.
If you can prove your scenarios exhibit buggy behaviour with brand new joint settings please file a bug.
So, I’ve had some conversation with Unity QA and they acknowledge that the current state of the Joints in Unity 5 are “not close to optimal” and that the current issues with joints are very visible in games made with Unity. Thankfully though, they are slowly heading in the right direction. No ETA is possible though, understandably.
you can disregard my post.