We’re excited to announce the release of the IKControl Joint Constraint Beta. This new feature will let you use certain Constraints, which normally restrict the movement of physically simulated parts, to now also specify how IKControls can move joints. Using Constraints you can now:
Make elbows and knees only bend about a specific hinge axis, without needing to specify a Pole
Use limits to avoid impossible joint angles
Make a robotic arm!
Below are some visual examples, in all of these the Pole property is not being used
To enable the beta in Studio go to File > Beta Features and enable IKControl Joint Constraint Support.
With the beta enabled you can add limits for IKControl using the existing physics Constraints. For this initial release, only the BallSocketConstraint and HingeConstraint are supported. To use them, add a Constraint between the two Parts in your IKControl’s chain that matches the existing Motor6D between those parts. Specifically, the Positions of the Constraint Attachment0 and Attachment1 attachments must match the positions of the corresponding Motor6D C0/C1 CFrames. The attachments do not have to have the same rotation (in fact you may want them to have different rotations to get joint limits oriented correctly). The Constraint must also be a descendant of the same Model as the IKControl.
To summarize, IKControl will use Constraints for which
The Constraint is a descendant of the same Model as the IKControl
R15 characters already have attachments matching their Motor6D C0/C1 CFrames which you can use for this. These attachments may not be oriented the way you want for a given constraint - for example, on Rthro characters the RightElbowRigAttachment Axis is not perpendicular to the elbow. In that case, we recommend adding a nested attachment underneath the default rig attachment, which you can then orient however you need.
We will be updating the Inverse Kinematics Guide with additional details on how to use constraints to control IK movement.
Known issues and limitations:
Currently only BallSocketConstraint and HingeConstraint are supported. We plan to add support for additional constraint types soon.
Currently does not support BoneInstances, only Motor6Ds
We are releasing this as a beta because this may slightly change the behavior of existing IKControls.
We want to hear from you!
Please share feedback, questions, or any issues you find with how this behaves. We will make sure to take these into account before fully releasing this feature.
This could not have come at a better timing!
Our game uses skinned meshes on the character rigs, which end up with very weird deformations when using IKControls.
However, I have been unable to get this setup working, as I’m far from familiar with constraint systems & Motor6D behavior. Most notably:
I could not get a BallSocketConstraint to become active despite setting Attachment0 to one under RightLowerArm, and Attachment1 to one under RightUpperArm.
I’m unsure what’s meant by setting the attachments’ positions to match the Motor6D. Should Attachment0’s position match RightUpperArm’s Motor6D.C1, or is it the other way around? or something completely different altogether?
Overall, having either a great simplification or test rig added would be much appreciated, as I haven’t been able to get the constraints working in spite of my half-hours testing
I’m very impressed, even more inverse kinematics!
This is going to be amazing for procedural animations and things like mechsuits or complex vehicles with moving parts I’d imagine.
The possibilities are nearly endless!
Is it fast and optimized as well? Could I possibly use this with many many many characters or robot arms at the same time without it lagging?
This update is great and drastically helps with my main concerns with the original release. There are points that cause the arms to bend unnaturally which also are a bit harder for me to reproduce when I am in VR. I do find it annoying that I, which means anyone else who wants to do this, need to specify constraints manually for the default R15 characters, and tuning the limits just right is hard.
This is nice, I would love it if it was quicker to animate using the roblox animation plugin. It would be nice if there was a setting that moved the time frame marker up by increment each time you’re finished with a frame. Maybe a keybind to move it up would be nice to see.
Thanks for the feedback, we’ll see if we can make this easier to set up, and we’re also going to be updating the documentation on this page with a more detailed explanation of how to set up constraints on a character.
In your case, to constrain the LeftElbow Motor6D, Attachment0 should be on the LeftUpperArm (which is LeftElbow.Part0) and should have the same position as LeftElbow.C0. Then Attachment1 should be on the LeftLowerArm (LeftElbow.Part1) and should have the same position as LeftElbow.C1.
Standard R15 characters have built-in attachments that match these positions which you can use as well. For the LeftElbow they’re both named “LeftElbowRigAttachment”: one on LeftUpperArm and one on the LeftLowerArm. You can make your BallSocketConstraint use these directly. Or you can add your own Attachments that are parented to the built in attachments. The benefit of adding your own attachments is you can then change their orientation however you want to control which axis the elbow will bend around.
Yes, we are planning to add support for Bone instances
It’s should be efficient enough to use on a large number of characters or limbs. If you run into any performance issues let us know and we will investigate.
I think this design could have been executed in a better way, but I do like it. It is a hassle to have 500 lines of code just to create attachments and constraints though.
I’m sure it’s not a big deal and I can probably figure out how to fix it myself (I haven’t tried this yet), but will there ever be a version of R15/Rthro that comes preset for this?
I think it would be easiest if it were a drop-in replacement for developers to get things to work. Like with the issue I was having that I mentioned here:
One problem I have with IKControls currently (not sure if it is relevant to this update) is that I need to upload an Animation containing all the parts I want, even if I don’t add any keyframes, otherwise it behaves like a wet noodle and seems to not work how I’d expect. I assume that constraints would help with this, but, the difference in behaviour is still concerning to me and I don’t know what would be the proper way to go about it.
Really, I want the IKControl to behave the same with or without an Animation so that I don’t need to upload one for every model I want to use IKControl on, but it doesn’t seem to do that.
Is that a bug? Or is the animation somehow encoding some pose information that the IKControl is utilizing, and it’s an important piece of that? Would this beta be a proper way to use IKControls without Animations, or are Animations still required to get good results?
