How are HingeJoints supposed to work in Unity 5.x?

How exactly are HingeJoints supposed to work in Unity 5.x?

In 4.x I used them to control doors in my project, by modifying the spring force (for visual effect) and targetPosition of the springs through script to open/close the doors (rotating the HingeJoint), but this no longer seems to works in 5.x.

Example of what I mean: Assuming the targetPosition of a HingeJoint has a starting value of 0, and has a sufficient spring force set (50, in my case), you can use targetPosition = 90 to rotate said HingeJoint 90 degrees in 5.x, and have it rotate back to the starting position if you set targetPosition = 0 before the physics simulation has settled. However, if you wait until the simulation has settled before trying to rotate it back - nothing happens, and no additional changes to targetPosition will make the HingeJoint do anything of note...

...until you toggle the HingeJoint's useSpring property off and then back on, but this has the side-effect of changing the starting-position of the simulation to whatever the position of the HingeJoint is when you toggle the spring back on....

Sad to see this broken, because I had a sweet and easy setup in 4.x, with doors opening and rocking a bit forth and back before settling, then auto-closing after a short period of time - unless players closed the door themselves before then (also with a tiny bit of a wobble before settling). Short video showing how my doors work in Unity 4.x:

Code-example that works in Unity 4.x but not in Unity 5.x:
(Create a cube, add a HingeJoint component, enable "use spring", set spring force to 50, attach this script. Run. Click.)

Code (JavaScript):

1. #pragma strict
2. private var _hinge : HingeJoint;
3. function Start()
4. {
5.     _hinge = GetComponent( HingeJoint );
6. }
7. function OnMouseDown()
8. {
9.     _hinge.spring.targetPosition = 90; // Rotates cube 90 degrees when clicked on
10.     yield WaitForSeconds( 5 );
11.     _hinge.spring.targetPosition = 0; // Rotates cube back to starting position after 5 seconds
12. }

Anyone have any tips for how to get this working again in Unity 5.x and/or to get a similar result from other means?

 

No one's using HingeJoints and have run into the same problem/use them in a completely different manner that avoids the problem altogether? :/

 

....guess not. Custom rotation code or setting all doors up with animated rigs it is then, I guess.

 

there have been some issues with the HingeJoint. I expect that we will get the fixes into a 5.1beta in the Not-So-Far Future (tm).

 

It's inefficient and doesn't look as good as animation to use hingejoint for a door unless the door will be physically affected by other physics, so you could just use a unity anim that plays?

 

Thanks for the replies. I could use a unity anim that plays, but then I'd have to manually animate the "bounce" as the door reaches its target position, as well as make multiple animations depending on how far I'd want to open the doors. With HingeJoints I can (or could) easily make a door rotate in any direction, and open to any degree I wanted (some doors I might want to open 90 degrees, some I might want to open 120 degrees, etc), which was very handy.

Looking forward to trying again in 5.1beta.

 

Looking forward to this fix! Many of our old projects (which I'm trying to update to HTML5/WebGL export) use HingeJoint target position springs in this way.

 

Sorry guys, but you're going to hang on a bit longer... It's not gonna make it for b5, but so far so good on b6.

I can do a custom build for you if you'd really like to play with it in b5 (once b5 is final).

Cheers,
Morten

 

I'd be happy to verify our use case on a custom build if you'd like more eyeballs on the fix (it's the door of the jeep opening/closing in Off-Road Velociraptor Safari). The HTML5 version is a total side project for me, though, so no real urgency on the fix on my end...

 

cool, please give it a spin. Here is the bleeding edge http://beta.unity3d.com/download/e48040f58a81/public_download.html

 

This works! I think the target position value might inverted from before (have to use +90 instead of -90), but in this case "before" is literally a Unity 2.x project moved up to Unity 5. So take that with a grain of salt.

Now I'm just seeing lots of joint explosions, especially with breakForce enabled on one of the joints. Things almost always explode when the break occurs--maybe because the previously-connected rigidbodies suddenly collide once the joint is gone?

I realize joint stability is a general problem with Unity 5, so I'll check in on those other threads and see if I can get the game stable...

 

Great The error have likely been that the joint frame was recorded before the joint was setup properly.

I have not yet looked thoroughly into the joint breakage. You might be quite likely right about the two jointed bodies suddenly colliding. You can try and set the C# property "maxDepenetrationVelocity" on the Rigidbody. Setting it low should allow the bodies to be separated in a very smooth manner. Or you could move the bodies further apart

Cheers

 

This is easier said than done. In this case, it's a chain, and visually it makes sense to overlap the joints:



It's an old game, but it ran well in Unity 2.x-4.x in terms of stability. I'm updating it now because it was a web game, and the web player is dying, and an HTML5 export would be nice to have around. Almost the entire game is ramming ragdolls at high speed:

Now that I'm playing around with it more in 5.x, it's almost impossible to play more than a minute with a terrible stability explosion of some kind. We're actually using CharacterJoint and HingeJoint in most places.

Since then, we only use ConfigurableJoint, and I get that it's more flexible. But at this point I have zero confidence that either CharacterJoint or HingeJoint will ever work stably in 5.x. Maybe that pessimism is unfounded?

(It kind of begs of question of why have simplified joint classes available if their default behavior doesn't work that well at all...?)

 

Thanks for the early build! I have been unable to test it yet myself due to hardware trouble - power blackout busted my motherboard & primary SSD - but I'll try it out as soon as I can.

 

When i try to open my projects with this beta version, it throws some kind of exception saying that: "R6025 - pure virtual fuction call" and then exits.

 

Same here.
This is upsetting because I thought I had finally found a possible solution to our problems.
@MortenSkaaning, how can I get the 5.10b6 beta working correctly?

The game in question is a multiplayer arcade pinball game that used Hinge Joints with Motors to rotate player 'paddles' around the game world, and also used Hinge Joints with Springs (setting targetRotation) for the player 'flippers'. Everything worked fine in Unity 4.6+, when upgrading to Unity 5 - everything broke and we started getting NaN errors. I have been working desperately to create a new version, but 'faking' the physics interactions (tried everything from transform rotations to rigidBody rotations, even tried an angularVelocity approach) has resulted in a game that has lost all of the 'bounciness' and feel that the old version had. We also have run into unexpected physics penetration problems between the flippers and the pinball that were not present in Unity 4.6+.

Here is an old screenshot of the game world so this explanation makes a bit of sense:



No matter what I do, I cannot get Hinge Joints working in Unity 5 the way that they were before.

@MortenSkaaning
Is there going to be a fix soon? Roughly how long will we have to wait?
I need to know as it is affecting our release.

 

@MortenSkaaning still waiting for a response.

 

I have a similar issue, could I ask will the pre release of 5.1 solve the HingeJoint. Motor and Spring support is mutual exclusive. UnityEngine.HingeJoint:set_motor(JointMotor) warning?

 

Did you guys ever get your HingeJoints working the way you wanted? I'm using the latest 5.4 now, but still seeing some major weirdness.

But as this is a new project, I don't know whether this is new behavior or something that's always been broken.