Physics Asset Editor: Constraints Transformation broken

Initial situation: Imagine you have a patient bed and there is a lever that has to be moved in VR with the help of a Physics Handle. The bed is a Skeletal Asset, the constraints are defined by the Physics Asset. When a constraint is created in PhAT, it is initially based on the corresponding bone orientation. However, it is often necessary, for example in the case of a lever, to rotate the constraint so that the limits min/max allows exactly the desired lever movement.

When calculating the limit during runtime/simulation, this rotation should then be included in the calculation. However, the limit is still calculated using the bone orientation and ignoring the constraint rotation, although the visual representation of the constraint limit in the editor takes up the rotation. So the Limit Visualisation in Editor and the Calculation Result while simulating don’t match each other, if the PhAt Constraint was set up in 4.22.

We used version 4.20 until now, and it worked as expected until then. In 4.22, however, the constraint rotation in the Physics Editor with newly created constraints is now ignored from calculation. Funnily enough, as a workaround, the Physics Asset can be set up in 4.20 and then migrated to 4.22. As long as you don’t rotate the constraints again in 4.22, the calculation works as desired.

The same issue also applies to the translation of constraints in the Physics Asset Editor. Constraint Translation is also ignored by the calculation of the linear limits, although the visual representation of the limits in the editor also takes up the shift here. But for translation/linear limits, this did not work for at least several versions. I think the issue exists since the physics asset editor overhaul in 4.18.

I hope that this problem will be addressed as soon as possible. We work a lot in VR, and especially here the possibility to transform constraints is essential, because many interactions in VR need to be based on physics.

Edit: I also submitted a bug report form for this issue.

Edit 2: Epic was able to reproduce the bug and the official ticket UE-72542 is now opened:

Edit 3: I have submitted another bug report form for the same issue but with linear limit calculation of a moved constraint in the Physics Asset Editor

Edit 4: The ticket has been updated to the state “by design”.
There is also this developer comment:

" This was modified and is by design
as many users were not expecting the
old behavior. To do this you should
hold alt and rotate
."

I would just like to give some feedback on this, after testing it:

  1. The functionality mentioned in the dev comment to rotate while holding down ALT actually works (tested in 4.22)

  2. Funnily enough, this functionality also exists for the linear limits (tested in 4.22)!

  3. It’s brilliant that this functionality is actually implemented, but the visual feedback is missing! Visually, it makes no difference whether rotating/moving the constraints in PhAT with or without the ALT key pressed. The change is visualized the same way in both cases. This should definitely be adjusted as soon as possible. It gets very confusing if i rotate/move with and later without the ALT key, because there will be an offset.

  4. And last but not least, I can’t quite understand the reasoning from the Dev commentary. Which user does not expect the adjustments be included in the limits when rotating/moving a constraint? That alone is the reason why you would move/rotate a constraint at all?

You should definitly mention this “hidden” funcionality somewhere, because the current implementation is very confusing

Edit 5: With the new insights this thread can probably be marked as solved.

What are your new insights? I am experiencing similar issues with PhysicsConstraintActors where Swing 1 Motion is pretty much ignored when interacting with a character.

I posted the new insights in Edit 4. But i’m not sure if you experience the same issue as i did, because i’m talking about Constraints in PhAT. Don’t know if there is the same behaviour with PhysicsConstraintActors.