I played around with APEX in 20.0 and while it was exciting, it was missing some key functionality at the time and I dropped it for a bit. Some of those issues have been solved in 20.5, so I'm diving back in. Once I move past the basics, I have to say I get totally lost about the best way to proceed. An example:

The normal way I prefer to rig quadruped hind legs is with a double-IK set up. You use a multiIK setup between the hip and the foot and that gives you the basic movement of the leg (seen below). However you don't have any control over the angle of the leg bones. The best way to solve that is to create a second IK set up from the knee down the foot. Then when you parent the root of that second IK set up to the hip, when you rotate the hip, you get nice control over the rotations of the leg bones. Hopefully my sketch below makes sense.

I know there's other ways to rig a quad leg that would be easier to set up in APEX, but this is our preferred set up and also, I think it I could solve this, I'd have a better understanding of how to customize APEX rigs.

I tried just adding 2 autorig components to the guide skeleton without any modifications, but they seem to conflict and the whole rig either breaks or collapses. I don't know if I should be setting up additional helper joints in the guide skeleton and parenting them up there, or if I can only do this by diving down into the graph with some component script (which I still don't understand very well).

Any thoughts about the best way to approach this would be a big help. At the moment I'm just not sure which direction to even start in.

Hi. I would also love to k ow as the way you described it is the way I have always done it as well. Best

Any help will certainly be appreciated, but I think I'm leaning toward the idea that I have to dive down into the graph to do this. But maybe someone can let me know if my thinking is right. I'd much rather find a way to set this up with the auto-components.

From what I can see it looks like the logic behind the auto-components is that they take the Guides.skel and generate point transforms to represent any joints found in the guide skeleton. It then looks at the difference between the rest position and post-animation position of those point transforms and applies that back to the Base.skel, which in turn drives the mesh in the bone deform.

Part of the problem then in my set up above is that at some level you have to create the second IK chain (normally for me this would be the 2-bone IK that controls rotation of the upper thigh and knee) from the RESULT of the main spring/multi IK, not from the original guide skeleton.

In kinefx I'm able to create that second IK chain from the post-solve joint positions of the multi-IK. But so far I can't see any way of using the auto-components to calculate things post-multiIK, since from what I can see each auto-component is looking back to the original guide skeleton for its starting position. Am I mistaken about this?

I think I can at least imagine a set up where in the graph, I use the post multi-IK transforms to create new helper point transforms, parent those within the graph and add a new IK solve for those. No idea yet how I go about doing that, and I would really prefer not to, but that's my current plan if no one can suggest something better.

If anyone's interested, I spent some time last night and worked up a basic manual set up. Not production-ready, it would need limits on the upper leg control and the various transform blends are there for some options for foot follow down the road. Also still need to convert it into a component script (by far the most tedious part of APEX), but the basic functionality is there.

I'm still interested if there is a more efficient way.

If anyone from Sidefx is reading this, is it possible (in theory) to automate the creation of the component script? What I find most cumbersome at the moment is that you essentially have to build your rig tools twice. It's like writing instructions once in English and then having to do it again in a completely different language, only to recreate what you've already done in testing.

But it seems possible to me (again in theory) that if I could package up what is new from my manual edits, say in a subgraph where I've set all my ins and outs, that there should be a way to generate a component script automagically. For me that would be a game-changer...

The idea of generating components based on 'blueprint' template graphs is on our todo list, but some other features might need to get priority first.

You get already very far though by using the graph::Template node! That can already make your life a lot easier now!
You can copy the important bits from your manually built template graph into the dive target section of the graph::Template node. The output of that graph::Template node is the content of the subnet as a graph itself. now you can add those contents using graph::AddSubnet(yourTemplateGraphResult, 'myFancySubnet') OR simply graph merge to your existing rig. This is a lot easier than recreating the same setup using AddNode, AddNode, connectNode over and over again to replicate the same setup.

The bit that is left is then connect the new nodes or nodes properly in, into your existing graph.

check out the section about Graph templates here:
https://www.sidefx.com/docs/houdini/character/kinefx/apexscriptgraphs.html [www.sidefx.com]

Here we use apex script but the effect is exactly the same whether you do it with the script language or manually with nodes.

Thanks, Esther. I'll definitely check that out!

made-by-geoff
If anyone from Sidefx is reading this, is it possible (in theory) to automate the creation of the component script? What I find most cumbersome at the moment is that you essentially have to build your rig tools twice. It's like writing instructions once in English and then having to do it again in a completely different language, only to recreate what you've already done in testing.

This is sort of the spirit behind this HDA - https://github.com/noadanimation/houdini_apex_graph_from_templates [github.com]
The purpose is to work closer to the final rig with APEX nodes, but still automate repeating nodes and making connections, so custom rigs are easier to make - it doesn't make component scripts, but expands out and links your own APEX graphs into a rig. It's very hacky and poorly documented, but the repository includes an example with Electra rigged using this system, including IK/FK blending which I don't think is available in the component scripts yet, so if you're interested please check it out!

I'd love to see something like this built in with proper interface support, my version mainly hacks names together from dictionary keys, and it has it's own level of remove from the final rig but I think it's a bit closer than creating a component script to create a rig.

Thanks Dan, I'll take a look at this as well.

But i also have to say that I tried Esther's suggestion and it's become by main way of building up component scripts. It still feels a little beta-ish understandably, but it really cuts down on the repetitive work of finding and making nodes and connections.

The script below is just a simple test script that adds an additional transform object and parents the root of a joint chain to it. I haven't had time yet to go back and experiment with a more complex component script, but the basic idea should hold.

Just build up your custom script manually inside an edit graph node and then when you've got your tool working, create a component script, and copy your manual setup into a graph::template node. Use the graph::AddSubnet to add the template to the graph. Then the only part you have to redo, is to connect the inputs and outputs and promote any necessary parameters (still annoying, but much easier than rebuilding the tool from scratch with a whole bunch of addNode and findAndConnect nodes...

Thanks for sharing this example Geoff! Yes I can see how this makes a big difference for preparing component scripts, although I'd still love to see the connections automated, especially at prototyping stage where you might be tweaking a lot as you test - this seems a good way to package up a finished chunk of rig though.