IK Retargeting To Custom Attributes

Hi, so the process of setting up markers with a an FK System is fairly straight forward, it’s more complex with IK Systems, where you have to find the right joints etc, however, the vast majority of rigs with IK limbs will use custom attributes to build poses, a typical IK Foot rig with a reverse foot system joint will have a “Roll” attribute that allows the animator to pose the foot. This system usually uses Set Driven Keys to drive joint rotations and allow the animator to use 1 attribute in the channel box to make a full foot pose.

How can ragdoll integrate with this? You can build markers from joints, and then retarget markers to controllers, but I can’t seem to figure out a workflow that works with how standard IK limbs (especially IK Feet on humanoid rigs)

Something I’ve found and am exploring more, is to not bother recording to IK at all.

The workflow would be.

  1. Assign to IK
  2. Record to FK

That way, you get the advantages of IK such as an easier time posing things or holding onto things, with physics recorded onto a different set of controls you can then switch or blend to. This seems to hold up pretty well, with at least 2 gotchas.

  1. As you pointed out, feet can sometime have controls to pose a foot that only exist in IK. And so there’s no FK controls to record onto.
  2. A lot of times, you don’t have FK controls to spare.

I’ve found (1) quite rare; feet typically have a toe FK control and that would cover most poses any specialised IK attribute would cover, like toe tipping, swivel and what not.

(2) can be ok, since physics would be recorded onto a layer. So you’d be sharing the FK control with physics.

But if this does work, then I think a more pipeline friendly alternative that could solve this riddle at a studio-level would be to have a third option.

  • FK
  • IK
  • Physics

Where you can animate FK and IK like you normally would, leaving those channels untouched by any recording, and where the Physics controls carry the recording and is something you can switch or blend to, like you do between IK and FK.

What do you think about this? Can you see any faults in my logic here? :thinking: It’s something I’d like to explore more. So far, it’s semi-safe to say that I no longer find a need to record to any IK controls - the exception being when I want to manually edit the simulation on those controls after recording.

Hey @marcus , sorry for the late reply. I was going to try this method as you suggested, just making the pose running sim and baking it to FK. However, these are the consistent results I’ve been getting when I try this approach. In my previous experience with my older shot (the dragon/dinosaur one) I had to stick to either FK or IK, because the switch I had in some places completely broke the animation. What do you think could be causing this? The markers are all made from the skinned joints, and then retargeted to FK controls, even though I made the original pose and base animation with an IK System.

This shot is a good demonstration of Ragdoll, as I wanted to see if I could create a full idle animation just with handkeying one controller. The simulation actually looks great, problem is with retargeting.,

Also another issue with being stuck to simulation only on FK, is that it’s much harder to edit after simulating it. Say I decide I want to push the pose a little bit further, and move the cog, but retain all the good secondary motion I had with the spine, etc. well now I can’t just move the cog without breaking the feet. This is why it’d be better to have a more reliable way of baking the marker sim to the IK rig.

Hey MLV,

Nice little idle cycle you got there!

if you making the markers based on the skin joints then you could always retartget to the IK ctrls too.
What looks like is happening is your FK ctrls are getting recorded with an offset …

It’s going to record onto the FK from their offset positions to the markers. Try From Retargeting
or have the fk ctrls line up with the joints before you hit record .

Yep, I can see the problem. It’s because the FK controls started out in that pose when you started the recording.

You can think of recording as putting a Maya Parent Constraint on each of your controls, with Maintain Offset enabled, and then baking out the constraint. Because the FK controls were in their A-pose at the time of recording, that’s how they will be parent constrained.

So you can either try the option Jason suggested, which has a few drawbacks and doesn’t work well if your controls have a custom Rotate Axis or Rotate Pivot, or you can get your FK controls into the same pose as your IK controls ahead of recording. That will make them both align on the start frame, and will record the way you’d expect.

Edit: Just noticed Jason also pointed this same thing out as well, in a more concise way. :blush:

I just took an extra moment to pay attention to that idle animation you got, that looks really nice. :open_mouth: Is the axe hitting the shoulder as he’s bouncing around? That’s the kind of interaction people actively try and avoid because it’s (a) really hard and (b) really hard.