Frank Spalteholz

I'm also working as an animator/TD and currently switching from Maya to Houdini. You are right. Apex is not easy but definitely worthy as it is for all Houdini-stuff where the first couple of steps are pretty hard. The Apex-framework in general is really amazing. You can do stuff that isn't possible in any other DCC or just with a lot of extra work.

1. this seems basic stuff but on a simple apex-transform you have 2 extra inputs for "local" and "restlocal" that can be used during runtime. The local matrix for example can be used for procedural transforms (springs etc) but you can still use trs-inputs for animating on top (that is huge!) Also this restlocal can be set during runtime which is a pure pain in maya.

2. you can change the whole rig-graph on runtime! this was a big "aha!"-moment. what you can do with it is to change the specific parts on the rig while being in animate-state. try that in maya. what is it good for? well ... check out the worm-rig which is more or less a stretchy-spline setup. in a nutshell this example shows that the underlaying spline that controls the rig can be resampled based on the amount of controls the animator is choosing. also the ctrls-position will be updated. it's working with python-callbacks which are also a big pain in maya.

3. to get the whole benefits you must be able to code your snippets rather than sticking them together in the graph. but i'm used to do my prototypes in the rig-graph first (which is visually intuitiv) and if it works i'm translating the prototype to code. for this it took be me a bit to find out the difference between the rig-graph and the component-graph. but since you are there you can use the full Houdini-proceduralism. you can write your own apex-methods and store them so you can use them over and over again (in the rig-graph-context also as subnet-nodes if needed) You can use the inbuild-ui-parameters like ramps and stuff without the need of writing complicated qt-windows or something like in maya.

4.There are additional more kinefx-related things that are super cool like adding new geometry to an already weighted geo or replacing parts of a skinned geometry with no problem. Changing vertex-order several times? Easy.
De-attaching geometry for individual weighting and combining or copying them back? Not so hard.
Where maya has just one crappy weight-painting-tool since years nodody uses, Houdini comes with more than a handful of completely different weight-algorithms and the weight-painting tool is the best i've ever seen and used.

5. vibe-coding. i'm using claude a lot for vex stuff since months and claude is pretty good (but you need a solid linear algebra understanding if something doesn't work in the first place). for apex i'm either provide existing code i already wrote or the apex-api directly to feed into claude and asking then for assistance. this works pretty well!

So i personally feel that there is no simple yes/no-switching-to-Houdini-answer cos it highly depends on your will to learn stuff that has been automated in other DCC's and so on. but this framework is amazing and i already took this to production 5 times and i never regret it (both in animation and rigging). Those were simple chars tbh but each new one got more and more complex and i really hope SideFX will push this framework even further.

But yes ... since maya is now 25years+ ahead there are of course tons of free auto-rigger-tools, tutorials and modules you can grab on the internet. I started as TD and was able to build rigs without any knowledge of matrices and stuff. But on the same side and without "body-shaming" maya ... it's old, it's slow, it's buggy and Autodesk does nothing to change that which i personally really despise since years.

Good luck!

Hello, i'm currently trying to reproduce the automated ik/fk-snap from the autorig-builder. So i was breaking up (and reduced the amount of needed nodes) of such a autorig-builder-setup. It seems to be not so hard although i still not fully understand everything. Before trying to explain what i've found out i'd really appreciate a response from anyone who knows where to find the specific python-callback-function (in general for all) but specifically to trigger the switch (on the worm example the python-callback is available directly on the apex-node as a string). Anyway. Please correct me if i'm wrong but it seems to work this way, that in general there is a custom blend-subnet (3 red nodes) that takes the blend-value, the fk-joint, the corrsponding "ik driven"-fk-joint (orange below fk nodes) for each joint (upperarm, lowerarm, hand). Inside the subnet there is a 4th connection for the rest-position that has no input from the top-level, so i assume it gets set directly in code (which rest-position is it?) ... So the system interpolates between those 2 spaces and not on the ik itself. The ik-setup seems to be straight forward but i still not understand what those "L_upperarm_L_armLimb_rest_global_scale" matrices and multiplications (pink left side -> first 3 inputs of the MultiBoneIK) are used/made for and further more where those matrix-values are coming from. The second thing i don't understand is, what those proxy-transforms (yellow) are doing. Their use is not obvious in the rig-graph and when deleted the switch doesn't work anymore so i assume they have some funtionality used in the hidden python-callback i was asking upfront. Thanks

Good morning! I've written a generic logging helper function for APEX component scripts (for debugging dictionary contents) and I'd like to reuse it across multiple autorig component SOPs. Is there a way to store these Python functions in a library or module that I can import, similar to how subnet templates can be reused? Thanks!