Hi everyone,

I'd like to ask the Houdini experts here for some advice on an APEX workflow.



1. I have a character rig built using APEX in Houdini.
2. I exported the character's skeleton and geometry to Cascadeur, created an animation, and imported it back into Houdini as an FBX file.
3. My Goal: I need to update the controllers of the original APEX rig to match the animation from Cascadeur. This is so I can continue to use the APEX rig for further modifications and rendering within Houdini.

※ The most important condition: The skeleton used in the original Houdini APEX rig and the one used in Cascadeur are 100% identical in terms of hierarchy, joint names, and Rest Pose.



My current workflow was built by adapting the methods from the official KineFX/APEX Workflow content library by SideFX

((https://www.sidefx.com/contentlibrary/kinefxapex-workflow/)).

I understand that this tutorial primarily covers retargeting between two *different* skeletons and workflows for cleaning MoCap animation. I tried to adapt its concepts for my use case, which led me to the following process:

- First, I import the animation with `FBX Character Import`.
- Then, I use `Apex Control Extract` to get the controllers.
- I match the position/scale with my original skeleton using nodes like `rigmatchpose` and `mappoints`.
- I then copy the skeleton's motion with `rigcopytransforms`.
- Next, I update the controller parameters with `Apex Control Update Parms`.
- Finally, I feed this into a `Motion Clip Create` node and then a `Scene Add Animation` node to apply it to the final rig.



This brings me to my fundamental question: Why is such a complex retargeting and mapping process necessary when the base skeleton is completely identical?

I understand that the APEX philosophy is "controller-centric," but is there a more intuitive or direct way to have the APEX controllers automatically reverse-calculate and update based on the imported skeleton's animation? I'm looking for a way to simplify this "translation" process from skeleton motion to controller values.


****

1. Is the **simplified workflow** I hypothesized above the most efficient and standard "best practice" for this specific scenario?
2. Am I missing a simpler node, a different technique, or a completely different approach that I'm unaware of? (For example, a method that might only require the `Apex Control Update Parms` node).
3. Is the common solution in a professional production environment to simply automate this entire workflow by wrapping it in an HDA?
4. Regarding Controller Types: My character rig has both **IK and FK** controllers. I've noticed that my workflow only succeeds when I extract and process the **IK controllers**. If I try to include my FK controllers in this process (extracting them and mapping them via `mappoints`), the final baked animation becomes corrupted and twisted.
- Is it standard practice to only use IK targets for this kind of reverse-update workflow?
- If not, what is the correct method to properly include FK controllers in this process?

I would appreciate any advice from experienced users. Thank you for your time and expertise.

The process is complicated because we need to do "rig inversion" here. From the world space transforms of the joints, deduce the controller transforms necessary to achieve the same result. Rig Copy Transforms should work but it might screw up if the rest poses are not accurate because it copies them relative to the rest poses on the skeletons. It gets progressively harder beyond IK rigs, and esp. if you have rigs that use abstract controllers for IK/FK switching because you need knowledge of how the rig works in order to do this. For the next major release, we have an HDA that wraps a similar set up to help ease this common problem. But it's tricky so it's not foolproof.

If you have an example can submit an RFE with your files, we can give it a try with our HDA to see if can work.

Been working throught this as well. In mapping, why the switch to the Apex mapping rig triangle layout for the base skel? It is pretty user unfriendly conmpared to the original biped KineFx layout.

Apex mapping vs Kinefx in these pics:

Sorry, what do you mean by "the Apex mapping rig triangle layout" ?

Sorry, my description was as clear as mud. I mean the pink skeleton in the image above. I mostly wondered why the change mainly b/c I thought the biped skeleton mapping in KineFx was so easy to understand and use. Also, I'm not a rigger and just monkeying around with Apex; Kinefx does everything I need.

The pink skeleton in this case the rig controllers, not the skeleton joints. So we're not really comparing apples to apples here. The old KineFX toolset is just as valid so I'd say use the toolset that fits best for your job.

edward
The process is complicated because we need to do "rig inversion" here. From the world space transforms of the joints, deduce the controller transforms necessary to achieve the same result. Rig Copy Transforms should work but it might screw up if the rest poses are not accurate because it copies them relative to the rest poses on the skeletons. It gets progressively harder beyond IK rigs, and esp. if you have rigs that use abstract controllers for IK/FK switching because you need knowledge of how the rig works in order to do this. For the next major release, we have an HDA that wraps a similar set up to help ease this common problem. But it's tricky so it's not foolproof.

If you have an example can submit an RFE with your files, we can give it a try with our HDA to see if can work.

is this HDA inside houdini 21? whats it called?

it does seem rather complicated to rig match pose and all the other bits mentioned justto map the animation from an FBX onto the EXACT same skeleton, but im new to Apex and hopefully this will improve?, Ive got the shapes working in metahuman finally, (from your helpful Python snippet in another thread) but I guess these shape values can transfer straightraway easier than world space rig pose bone matching...

It's called the Animation from Skeleton [www.sidefx.com] SOP.

Ahah ! it was the mapping and trial and error, but indeed this is the node you need , thank you and once correctly setup it all lines up nicely and animates directly from the FBX animation file - which includes skeleton animation and shapes
just finishing off the blendshape mapping list - theres a LOT of remapping and its changed again since you wrote the last snippet Edward, Brow name did at least

Oh! it seems the add animation from skeleton node fails on more complex nested rigs.. like the metahuman head skeleton.

so still the simplest way to put fbx back onto the head rigs at least is to unpack and repack and animation from skeleton works on body still

Well, Animation from Skeleton is really more about body rigs and can only work where we have a "simple" rig inversion. For complicated cases, it will need a lot more information.

For the face, it needs some more manual mapping unfortunately right now. See https://www.sidefx.com/forum/topic/102043/#post-449734 [www.sidefx.com] where I had a contrived example.

Also, just want to mention that the Epic MetaHuman team is actively working on improving the plugin in this area.