Relative rotation with physics constraints

Hi, there!

I’ve hit a bit of a bent nail here. I’m creating a door, the door is simulating physics, but is constrained entirely to its current position and its rotation is locked. Now, setting relative rotation on a physics object will set its World rotation instead, causing problems with the door’s rotation.

291486-5937f287f3bff022ccb80e31e14ee9ec.png

Now, before you tell me this is “intended behaviour”, because the physics object will be detached. I’m locking its position and rotation. So why can’t this work like it would seem it should be able to. Surely you can calculate its relative rotation while the object is completely parented without having to re-attach it later…

I can sort of understand the problems this Could cause if the objects were in complete seperate locations and rotations.

But they both now, due to the constraints, have the same position and the same World rotation.
Any explanation on why this isnt possible, and/or consideration and looking into changing this is much appreciated.

1 Like

These constraints aren’t actually Physics Constraints. Physics Constraint is a separate component that you can add to a blueprint, and it attaches one component (door) to another (door frame), and there you can set rotation limits.

So you probably want to create a Physics Constraint component and set limits there, and not in the mesh properties.

While i’m aware that there exists a component called “physics constraint”, this isn’t what i’m refering to. The constraint in physics properties of the static mesh i’d also refer to as physics constraint, as they cannot be used without the mesh simulating physics.

I haven’t been able to acheive the effect i’m looking for with the Physics Constraint Component.

Regardless, the Constraint properties exists and could be used for this purpose quite efficiently, and i don’t see a reason relative rotation shouldn’t work in this instance, hence it seems more like a bug or oversight than an “intended behaviour”.

I finally checked it and indeed, it always sets the world rotation with physics simulated. You can add the parent rotation to get the correct result, but yes. it’s a bit weird.

1 Like

I am running into the exact same problem, what did you mean by adding a parent rotation?
I have a BP with a static mesh motorcycle and have physics turned on and the X axis locked, it works perfect until you turn 90 degrees and then it falls over I guess because the axis has change in real world space and not local space.

I think I finally found the problem.

In order to get “Get/Set Relative Rotation” to work correctly with PhysicsConstraint component, the PhysicsConstraint component and StaticMesh must be parented under another StaticMesh as root, NOT a Scene component.

Hope this helps!

After further testing, I realized this solution doesn’t work all the time.

I found another workaround, but not as efficient. Create a “dummy” StaticMesh inside the root component. In the EventTick, get the world rotations from the “door” StaticMesh that is constrained to the PhysicsConstraint component. Use that to set the dummy StaticMesh’s world rotation. Now you can get the dummy StaticMesh’s relative rotation, which equals the “door” StaticMesh suppose relative rotation.

Hope that makes sense. Good Luck

You need to “set constraint reference orientation” . pir axis is the forward vector and sec axis is the right vector and it will automatically calculate the orientation. to invert the z axis, change the frame.
I have used a scene component to orient the physics constraint instead of using gizmo. then set the reference frame of the physics constraint in BP

NOTE: use “get relative rotation” for scene component , i mistakenly used “get world rotation”