Is it a bad idea to use Constraints with Rididbodies?

So I’m getting into the different constraints Unity offers:

I’d like to use an object that is constrained with a ParentConstraint and have another phycis object connected to that constrained object by a DistanceJoint.
This does work, but the results are different between something that moves in FixedUpdate vs the ConstrainedObject.

0.02 fixed delta time:

0.1 fixed delta time:

  1. The top square is moving in FixedUpdate
  2. The bottom square is moving by a ParentConstraint

The sphere’s are connected to each object respectively with a DistanceJoint2D.

What I have noticed is that if I set “autoConfigureDistance” to true, the bottom sphere goes beyond the starting distance of “2”, while the top sphere always stays at “2”.

So I’m wondering if using Constraints with Physics objects is a bad idea?
Disregarding the obvious differences between physics vs constraint versions. Could there be any performance issues if I use a physics object and a constraint?

Are there any plans to support updating constraints in FixedUpdate maybe?

EDIT: Ha, looking at your post on a phone means I didn’t see your first link! I know what you mean by constraints now sorry. Removed my post and questions as they are not relevant now.

1 Like

So regarding my edit above, I’ve never used those constraints but it has nothing to do with physics. I guess they just set the transform which isn’t going to play well with physics whose job it is to set the transform too.

In short, I certainly wouldn’t use anything that’s going to modify the Transform which would include stuff like Constraints, Animation etc.

It’s not clear if your problem is also related to how smooth the movement is. Depending on how you’re moving it, that would be solved by using Rigidbody2D interpolation.

If you want to parent something then you can also use things like Kinematic children or the RelativeJoint2D or simply use Rigidbody2D.MovePosition or TargetJoint2D in a script relative to some other object. It all really depends on what you’re trying to achieve here.

1 Like

So my use case is this:

Moving a rigidbody along a path/spline. That rigidbody is kinematic and can optionally have physics joints added to it that drive other physics objects.

It was nice and easy to simply use a parent constraint and in my custom “Mover” class, that has the attribute [ExecuteAlways]. I sample a position on my spline and set the constraints offset to that position.
This means that in edit mode, my “Mover” is snapped to the splines position. And also if the Splines transform moves, the “Mover” would also move to the correct location. I could also playback the “Mover” and preview the movement along the spline in edit mode. Which is really helpful.

I guess my reason for wanting to use a ParentConstraint is that my custom class doesn’t need to do much more than set some offsets on the ParentConstraint class and it all just works… Making my life that much easier :wink:

But I see now, that it’s not a good approach as can produce incorrect physical responses/results in play mode.
So now I’m looking at replicating the functionality of the ParentConstraint in my custom “Mover” class in edit mode.

You could say, I was just being lazy :wink:

Anyway…

Maybe an example project I created in my GitHub 2D Physics repo might help you. Specifically, this scene. You can see the primary script that drives a TargetJoint2D.target here.

It basically does this:

1 Like

Oh awesome. Had no idea that repository existed!

I’ll check this out, thanks.

1 Like

The only issue is that if you must use a Kinematic body then it won’t be affected by a joint such as TargetJoint2D however the script can be modified to not use a joint but instead just use Rigidbody2D.MovePosition so maybe it has value still.