How can we build hinge controls (controls that rotate on one axis only) like an elbow FK control?
When I use limits on ‘spawn control’ the control does not rotate past 90 degrees when using the manipulator. It only works in the controlRig editor. There seems to be some limitations or differences how rotations are handled in control rig editor versus sequencer.
I’m looking for best practise how to approach hinge controls, because they are a very common rigging problem, yet I’ve not seen a solution in Unreal. All the example rigs I’ve seen so far, including the UE5 Manny have open rotations (all three axes open), which isn’t realistic for hinge joints like elbows.
-THE ISSUE: In Sequencer "SKM_Cylinder shows the issue. It uses control rig “CR_Cylinder” (/Game/Meshes/CR_Cylinder) assigned, which uses a “Spawn Transfer Control” node with limits, to try to get the elbow behavior. The issue is the rotation is limited to 90 degrees, can be seen in the viewport when playing the animation or roating “elbow” control interactively
-POTENTIAL WORKAROUND WITH NEW ISSUES:
-The sequence also HAS “SKM Cylinder CR2”. It uses control rig “CR_Cylinder_v2” (/Game/Meshes/CR_Cylinder_v2) which uses a much more complicated graph to query control transform and applying it to the bone, where the bone rotation is limited using clamp nodes at the Euler translation level. This works nicely for control a single joint, but problems come when wanting to use this for an FK CHAIN, a chain of fk controls because the controls themselves are not limited so don’t follow the silhouette of the bones.
You’ve run into a long-standing issue in the engine right now, and it’s exacerbated by a locked axis, as shown in the Pitch (Y Axis). The bug has been in backlog for about a year and affects all gizmo rotation, not just control rig. The simple answer is if you can build your locked axis on Z, you won’t have the issue, and most of our rig examples would be doing that. If you must do something on the Y axis, I could mock up an example to get around it, similar to what you’ve done, but how I would approach the problem. Let me know.
In terms of how we build hinges, in your example project, you’re doing the right thing, and there is also the ability to make a control not be affected by translation at all if you like. If you change the value type of the control to a rotator, or if you use a construction event change the initial value property to a rotator type, you can see the lock values a bit easier. This is what we do in the “Hinge” modular rig node, for example.
Thanks for your help, the rotator workaround using Z axis works. But it’s still a workaround and results in extra work where skeletons are not oriented with Z as the hinge axes.
What do you suggest as best practise to deal with such skeletons? I’m thinking to add arguments to our “construct fk control” to allow axis choices for “Down”, “Main” and “Side” control directions. Or would it be better to move towards a “guides” system, building control orients from guides, rather than the joints? I’ve seen both in Maya based rigging systems I’ve seen, but not sure what is most maintainable in Unreal. Off the bat I would not know how to save “guide” locators in a good way. What would you suggest?
Generally speaking, the construct rig workflow is meant to be built on the bone transforms themselves, so I wouldn’t recommend best-practice guides, but it really depends on your pipeline. In the modular rigging workflow, we would have options to handle different scenarios, often limiting the amount of options you need to set with either good heuristics and tests during construction or from knowing that you are building your rig from some known basics. Like, don’t have a forward direction because you know all of your skeletons come from packages where X is the bone direction, vs Blender, which doesn’t. Or something like always make the hinge axis from Z and offer an offset if it doesn’t for the couple of cases where it’s an issue.
[mention removed] thanks for the guidance. Is there an ETA when the bug will be fixed? I think the workaround will be OK to implement, but it should not be in the backlog permanently.
Unfortunately, as I mentioned, this has been in the backlog for a long time, but we are currently updating our gizmos for a future release, which gives us the opportunity to raise its priority.