Table of Contents Show
Can Houdini leave its reputation as “one does not simply learn Houdini” behind and instead use procedural structures to take new paths and find new strengths? How “fast and easy” is “fast and easy” really? Can an APEX rig be coupled with other technologies like mocap and, above all, re-used as promised?
The interest in the industry is definitely there. Lately, the number of in-house and third-party APEX and character tutorials on the SideFX learning platform is exploding like a good pyro sim. Let’s look at how Houdini approaches rigging.
The advantages of procedural rigging
Houdini separates the mesh from the skeleton/rig, from the animation, and, as a fourth layer, from its execution. These four elements exist completely independently of one another and enable maximum non-destructive work.
A last-minute mesh change does not destroy the rig or the weights. The skeleton can be extended with new joints at any time. A skeleton or the entire rig can be adapted and re-used very quickly for any mesh. Animations can be broken apart, assigned partially to selected joints, modified or completely mixed.
The execution of the rig is separated from the rig and animation, and is therefore not only very performant but also flexible. How that works, why that is the case, what advantages it has in practice and where the limits may be, is what the following lines will tell you.
KineFX, Apex, wtf?
Two terms dominate animation and rigging in Houdini: KineFX and APEX (All-Purpose EXecution). For practical use, we first only need to know that KineFX and APEX are simply toolsets for specific tasks. There are KineFX nodes, for example, to create the skeleton, while the APEX nodes take care of rig logic, such as controllers and dependencies, and later the animation. Because of the clever architecture, APEX is very performant. This is due to “delayed evaluation”, meaning rigging and animation are not constantly calculated, but only executed when required.
The secret? Points and attributes
The most important thing and the biggest difference to other DCCs: in Houdini, at the end of the day, we only move points. KineFX, APEX, and Motion Mixer are all fancy ways to achieve exactly that goal: moving points. Joints? They are points with names and transform attributes, that is the whole difference. But still points. Complex geometry packed to save memory? Also, just points.
Why is this so important? Beyond the “dedicated” animation tools, Houdini offers a lot of fantastic tools for manipulating points, and we can unleash the entire arsenal on our characters almost anywhere. And it allows innovative workflows. Completely outside the character pipeline box in your head—keywords: ragdoll, RBD, dynamic motion and Vellum simulations. High-resolution meshes can, for example, be driven via Point Deform from an animated low-res proxy mesh.
With that realisation right in. How does rigging work in Houdini from v21 onward? When and why procedural, when manual? We will look at the new animation tools themselves in a second part, or this will never be finished.
So, what are we to do? In short: KineFX skeleton > naming/tags > Capture> APEX rig logic & controls > animation. Due to the architecture, as you may have guessed, this does not necessarily have to happen linearly.
The skeleton (Welcome to KineFX)
There are two fundamentally different, yet combinable, ways to create the skeleton.
Manual
Primarily, we draw our skeleton with the Skeleton SOP. Joint names can be assigned right away, the hierarchy can be adjusted, and the orientation of the joints can be adjusted. However, we can also draw lines and points in all imaginable other ways and use the Rig Doctor SOP to give them the necessary attributes.
Procedural
Non-destructively, for maximum precision and to work detached from mesh updates, we no longer draw a skeleton ourselves here at all. Instead, we extract points from existing geometry, put them into a hierarchy and thus create a dynamic skeleton. As we know, joints are simply points with specific attributes, and a skeleton is nothing more than points in a hierarchy. Then we continue processing them.
Here, the Extract Centroid SOP is one of the most important nodes. It extracts the exact centre point from the geometry’s bounding box, which is useful not only for eyeballs.
But we can also simply brutally blast away everything except the relevant points, or let a few nice VEX lines isolate points. If we have splines, the whole thing becomes even easier. Curves are nothing more than connected points, and therefore, almost a skeleton with hierarchy already in place. The Rig Doctor SOP adds the necessary attributes in such a case, Initialise Transforms, and we are good to go.
This allows a skeleton to be constructed from a simple line, a complex curve or a point cloud. For procedural alignment, the Orient Joint node is a good choice. Of course, as is often the case, both approaches can be combined well.
Binding / Capture Geo / Deform
Our freshly rolled joints do not yet know which geometry they are supposed to move.
For non-deforming parts, meaning everything mechanical and rigid, binding is very simple. The connected polygons are packed, given a name tag and assigned to their future joint in the Capture Packed Geo SOP node. Done.
Soft geometry that deforms within itself, meaning most of an organic character, goes into a Joint Capture Biharmonic SOP node. Here, weights are generated automatically and, out of the box, are very usable. Internally, this node creates a tetrahedral mesh. The geometry’s hollow space is filled with “3D pyramids” so that the weighting is calculated cleanly over the volume. More complex setups can consist of several of these nodes and can be manually “painted over” with a Joint Capture Paint SOP. Both approaches can be freely mixed if the mesh includes hard parts as well as soft elements, for example, a robot with rubber at some joints.
To test the weighting, we use a Joint Deform SOP, fed with a Rig Pose node, where the joints can be animated, but please only for testing, followed by an optional Delta Mush node for smoother deformation. Everything else, meaning the rig logic and the animation itself, happens much more elegantly and powerfully in the realm of APEX.
APEX, rig and controls
The input is guarded by a Pack Folder or Packed Character node, which bundles the skeleton, mesh, optional guides, and graphs into a clean, packed structure.
A simple APEX setup after the Pack Folder node consists of two Autorig Component nodes, working in the Forward Kinematic and Bone Deform modes. A Configure Controls node handles the look, limits, and other settings of the controls. The actual animation happens in a Scene Animate node. The output from APEX, for example, for rendering, is found in a Scene Invoke node, which can also dutifully unpack everything again if desired.
Although this already gets you quite far, we are not even scratching the surface. More on that in a moment, including powerful APEX graphs, IK tags, skin controls and simple mesh exchange.
Loneley bike: bicycle rigid body rig
So much for theory. Time for a real project. In a commercial, a bicycle without a rider is supposed to move through a single shot. Because of the intrinsic dependencies like travelled distance to rotation of the elements, and the not yet finally decided props (what kind of bicycle basket? What is in the basket?) versus project timing, it is a perfect test field for an APEX rig.
My goal: the bike follows a drawn spline. The handlebar automatically aligns with the curve, and the wheels, including the pedals, rotate automatically according to speed or distance travelled. The pedals themselves should not simply point upward; that would be unrealistic, but they should rotate slightly forward or backwards, depending on their position. Add secondary movements such as the slight wobble that occurs while cycling.
The brake and the saddle should remain classically animatable, as should the overall lean when cornering. And of course, the travelled distance is the primary driver for all animations. Ideally, the bike can be grabbed directly by the saddle and pushed along the curve.
So we need a skeleton that sits precisely, otherwise the wheels wobble. Perfect for the previously mentioned Extract Centroid. To understand the logic of the automated dependencies, we dare to delve into the depths of an APEX graph.
This is where one of those YouTube captions could appear: “random bullshit job-title dude tries something banal for the first time.” Because how complicated can an APEX graph be if you know Houdini’s VOP nodes, visual operators, basically programming with nodes, well?
Geo Preparation
Before we deal with the peculiarities of the APEX graph, we divide the bicycle into logical elements grouped by planned joints, clean up a few inconsistencies, pack the geometry, assign materials, and assign the immensely important Name attribute. The entire rig is based on the latter.
Skeleton & Capture
As already teased, we want to draw as little of the skeleton ourselves as possible and instead pull the joints from the existing geometry. With the wheels, this is very simple. Since everything is now available as packed geometry, an Extract Centroid node is enough, and we have the two centres of the wheels. Another Name attribute christens the freshly born joint, and a Rig Doctor helps with the transform attributes.
It gets more interesting with the pedals or the handlebars. Here, too, everything has to sit precisely or the rotation will not be correct later. But the same principle of Extract Centroids applies here too, except that we first isolate part of the geometry, for example, one element on the handlebar, and create the centre from that.
Step by step, we go through the individual logical elements created earlier and finally merge them into a whole together with only four manually drawn joints, general parent controllers, and the frame. The hierarchy is created by drag-and-drop in a Parent Joint node or in the Rig Tree panel.
The weighting itself is also done quickly with a Capture Packed Geo node. The previously packed geometry elements are all assigned to the new joints via name tag. That’s it.
Packing for APEX & APEX setup
At first glance, the APEX node tree does not differ from our simple example at the beginning. We have the FK and Bone Deform node, followed by the already known Configure Controls and Scene Animate node. Only the Fuse Graph Autorig Component is new. But that one has teeth because it injects into our APEX graph, which controls the entire dependency logic and the alignment with the curve.
The Graphene curve and the brain
Now it gets interesting. In theory, most of what we want to do in the graph, all the rotation based on the curve and the alignment to that curve, is only simple mathematics. Unfortunately, the nodes in the Graph are extremely numerous and low-level, and are not necessarily named as you would expect for VOPs.
One question did keep me busy for quite a while: how the hell do you get external geometry into the Graph? The solution is as simple as it is unexpected. You rename one of the ports of the parm node, the starter node, to the name of the geometry, including the suffix, here curve1.skel. You have to come up with that first.
But one step back. What are we actually seeing in an APEX graph? Some of the nodes look familiar. We only just placed Bone Deform as an Autorig Component node, and all our joints are also present as Transform Object nodes.
Meaning: all nodes we place in APEX generate an APEX graph under the hood, or a script, but that is another topic, and we can happily connect everything to everything and bring it into dependencies. After rummaging through the menus for a bit, it no longer feels quite so alien, and nodes such as rig_curveconstraint or transform_lookat sound promising for our plan.
A few things are still strange. Why are there, for example, no network boxes for structuring? Sticky notes will do in a pinch, but something can still happen here.
Take the length of the curve (aka the perimeter attribute), divide it by the distance between the two wheels, add that to the current normalised slider, and use it as the u value of the new Curve Constraint. That may sound a bit complicated at first, but it is actually a fast and clear solution.
(Interactive) Controls
In the Configure Controls node, we can not only recolour the rig control elements as desired and change their shape, or hide them, but also set rotation limits and skin controls. The latter allows you to pull directly and intuitively on the geometry instead of on some gizmos.
Secondaries & random motion
The actual animation happens in the Scene Animate node, which we will look at in detail in another article. In this case, only the saddle was pushed forward with the desired timing, and the lean was adjusted; the rest ran cleanly and completely automated—a dream.
So we continue here with secondary motions, meaning the random wobble or the time-offset forwarding of primary movements to small elements like the bell.
For this, we pull the skeleton crosswise via Unpack Character from the APEX stream, modify the desired nodes, and feed them back in with the new APEX Animation From Skeleton node.
This way, the skeleton exists completely as points, which can be wonderfully manipulated with noises or the Secondary Motion node. The latter transmits the movement of one joint to a target joint, with Time Offset, as overshoot or jiggle.
Last-minute changes
And if the model changes, if the director wants a bag in the bicycle basket, do we have to weigh and rig everything again? No, welcome to procedural land. The bag is integrated into the model as a packed object and assigned to its joint in the Capture Packed node. If necessary, a joint is added to the skeleton object or extracted from the bag.
Adding or removing mesh objects from the rig is just as quick and easy. The rig remains stable, and even the animations remain intact. Rigging was fun for me for the first time; even the peculiarities of the Graph were more of an aha moment than a stumbling block. The semi-procedural animation generated this way is a huge timesaver and simply a cool process.
Excursion: Blendshapes
We leave the bicycle behind and ask new questions. How easily can Blendshapes be created, exchanged, and, above all, how intuitively can the animator work with them? Nothing is less sexy than a window with dozens of cryptically and technically named sliders.
The setup in a nutshell: We have our base model and a blendshape sculpted in ZBrush. The latter goes through the Merge Packed node, where additional blendshapes would go directly as well, and all receive unique names, and is assigned to the asset via Character Blend Shapes Add without further settings.
The skeleton consists of a single point and is weighted onto the mesh via the Joint Capture Biharmonic SOP. This finishes the KineFX part, and we throw the first APEX node into the race: Pack Character, fed with the mesh and the skeleton. What is set here and why, see bike.
Three Autorig Component nodes, set to FK, Bone Deform, and Blendshape, complete the basic setup. So that we can operate the blendshapes interactively and enjoyably, we draw a curve over the mesh and feed it into the stream via Pack Folder. This gives us a custom controller, and we are… done.
Controlling the Blendshapes
Exchanging blendshapes requires only loading the new shapes via the File node or sculpting them internally. The still-quite-new Sculpt node saves the road trip to ZBrush for many applications. If it has to be a bit more, the plugin with the meaningful name “Z” helps with direct mesh exchange, including blendshapes and polygroups, from the maker of the Houdini Direct Modelling plugin “Modeller”.
The node stream itself does not need to be adjusted or changed in any way. No exaggeration, it really is fast to do. The fact that custom splines, for example, can also be defined as controllers and animated interactively in the viewport is worth its weight in gold.
Fast challenge: Let’s rig the cat
The editorial cat demands its tribute, and so the following question and challenge arises: how quickly can we get a complex four-legged IK system running? As few nodes as possible and completely free of graphs and scripts. Here, Houdini promises a fast solution with the TAG-based system. Joints tagged by us are automatically recognised, and the IK system is set up for us.
We create and name the skeleton for the cat’s left side as usual, using the Skeleton SOP node, and obtain the exact centre of the eyes via Extract Centroid. We do not use its official name, “Mrs Wigglebottom, Empress of Milbertshofen, Esq.” One Rig Doctor node later, we merge the points with the drawn skeleton and use a Parent Joints node for subordinating the eyes. Then we mirror it into a complete cat with the Skeleton Mirror node and weight the deformable part with Joint Capture Biharmonic and the eyes with Capture Packed Geo. This is quick and clean to do.
Anyone who wants to adjust the calculated weights manually can paint them with Capture Layer Paint. And now the most important part: preparation with tags. We assign an IK tag to the necessary joints BEFORE the APEX nodes, which the Autorig nodes will later pick up. For this, we use an Attribute Adjust Array node, mark the required joints and also name the respective leg segments, front left and so on.
IK and done
Into an APEX Pack Folder node with it. Watch the naming: the mesh as Base.shp (shape), the skeleton as Base. skel and the stream with the tags as Guide. skel. Then follow two Autorig Component nodes for FK and Bone Deform.
To finish, a Multi IK node, in which we assign the tags and the legs. That gives us the multi-IK system, including pole vectors. No matter if two, four or twelve legs. As long as the tags are set correctly, IK works. In the node itself, we can still set the behaviour of the IK solver, such as stretch.
That means we’re done. And because that actually went quickly, we still have time for a few other treats.
IK / FK switch
No IK rig is complete without an FK switch. In APEX, this is done with the Autorig Component node in IKFK Blend mode. Here, the IK segments, for example, the tail, are entered, and the controls immediately appear in the viewport.
Ear rig Mesh & Configure Control
With the bike, we could use a self-contained, pre-packed geo element directly as a controller. But what happens if we have one connected mesh? Can the ear be bent intuitively by simply pulling on the ear, definitely not recommended for real cats, aka rotating around the middle joint? Actually, and sometimes I am still surprised when things in Houdini really are super simple, this can be set up in a few clicks via a prim group created before the Pack Folder node and the Configure Control node, including rotation limit.
Automatic wrinkles. Time saved.
The wrinkle deformer introduced in H20.5 is phenomenal for character and creature animation, enabling very quick addition of interactive organic detail and, therefore, credibility. So naturally, there is an APEX Wrinkles deformer that can be created directly in the rig and later automatically generate wrinkles in the animation.
Nothing more needs to be done than to throw the APEX Add Wrinkles node into the stream and adjust it to taste. The node is clever, too, and outputs deformed geometry, which, of course, requires a high-resolution mesh. Because of the procedural approach, we can add a Subdivide to the cat further up, before capturing, and immediately get the necessary polygon density.
All tags, all weights remain intact. How nice. Or it outputs attributes that we can, for example, use to drive normal maps in the shader. The texture-based approach is, of course, more performant.
What about fur?
Hair and fur can also be animated easily with APEX. This is especially practical for stylised body decoration and feathers. Via Add Groom, we load the guide curves, define some hairs as joints and can animate the groom like the rest of the rig. For very dense amounts of hair, it is advisable for performance reasons to animate only the guides and, after a Scene Invoke SOP (Unpack Groom Guides), move the high-res groom with a Guide Deform. Game engine-optimised hair cards can usually be animated directly in all their glory.
Tail(oring) IK changes
No creature project is complete without last-minute changes to the rig, so the cat wants an IK-driven tail, and we want to check whether such a not-entirely-trivial change is easy to implement with APEX. In theory, we only need to assign an “IK” tag to the joints in the tail and a name tag to the entire tail. And that is exactly how it is.
Dogfight
Still not convinced how flexible and fast the system is? Let us turn the cat into a dog. For that, we load a new mesh, move the joints to the correct position, and we are done. Completely. Everything transfers.
The Mythical Autorigbuilder
SideFX advertises the Autorig Builder as a tool to quickly convert a mesh without a skeleton into a fully animatable character. Sounds good, but we urgently need to clarify what the tool is, and especially what it is not. It is NOT a one-click, ready-to-animate solution, as one might assume. Rather, the Autorig Builder is a rigging and skeleton authoring tool. It interactively creates a detailed skeleton, including fingers in the viewport via drag-and-drop, or builds on an existing one, along with controls and the underlying APEX graphs. The final weighting must be performed separately as before.
What does this construction kit bring? Time savings with full control and a clean skeleton. And if that skeleton already exists in broad strokes, the tool builds on it. It quickly adds otherwise time-consuming elements such as fingers and toes, and complex rig logic such as IK/FK blend, stretching, or reverse foot, along with various sliders.
The whole thing can be saved as a rig template and immediately applied to other meshes. The system is not closed in itself. Everything we create here can be adjusted and expanded in the following nodes, even if it is only the colours in a Configure Control node. This makes the tool more valuable than a one-click solution that is rather rudimentary (see Mixamo) or not cleanly adjustable.
Excursion: Working with MoCap Data
Mocap Data I Apex Retarget
Similar to the bike’s secondary animations, we first bring the packed character back into the land of points and KineFX via the Unpack Folder. Here, as in KineFX times, we perform retargeting using the Rig Match Pose, Map Points, and Full Body IK node. KineFX is incredibly flexible here, so loaded movements can also be applied joint by joint with Skeleton Blend SOP, and a Frankenstein animation can be created.
Via Animation From Skeleton SOP node, we feed the animation back into the APEX stream. Via Scene Animate, the mocap animation can be layered and adjusted.
Mocap Data II Assets with Mocap
Another use case. Simple task for the basic principle: we load a bird from the lovely Zoo Mocap Database, basically free to use, and let it fly along a path. For this, we import the FBX as Character Import, which gives us the correct node structure right away, including Bone Deform.
To turn the single-wing flap into a loop, we convert the Animated Pose into a Motion Clip. A brief but important insert: a Motion Clip in Houdini KineFX is not a saved animation, as in Unreal, but rather a representation of time in space. Aha. Ok. What?
At this point, an image helps:
How to…
First, we want to create a cycle using the MotionClip Cycle node. Here, locomotion can also be added to move the bird from the spot. The final step in every MotionClip modification is the MC Evaluate node, which converts geometry back into skeleton animation. We promptly put that into a Path Deform node and animate the Offset parameter so that it fits the wing flap/path length. We create the path itself with the Curve nodes, give it a nice Orient value directly in the Curve tool with the “O” key so the bird leans nicely into the curve, resample the thing with even subdivision and off it goes into Path Deform.
If the bird is supposed to glide along the curve rather than flap, we can slow the animation speed using an MC Retime.
For a quick look to the side, the Rig Pose node immediately after the Path Deform handles it. Here, the joints can be animated regularly. For heavy animation, however, one should animate in APEX instead. My point here is only to show the open principle: everything is made up of points that can be modified at any time, with all kinds of tools. For diabolical birds, the neck joint could be rotated 360 degrees according to a noise pattern with a Rig Noise (MOPS+).
And because Houdini is the land of unlimited possibilities, here is another way: instead of deforming the skeleton onto a path, we copy-to-point the loop onto a point that travels along a curve. Or we use a particle simulation and apply the cycle to each particle, including the time offset.
Machine learning in rigging & animation
ML Deform
SideFX’s AI policies, which hopefully stay that way, are designed to support users with intelligent tools so they can reach their goals faster. Following this credo, there is, for example, the ML Deform SOP in the CFX area. It replaces Bone Deform, provides nicer mesh deformations, especially in extreme situations, and is mainly trained locally with your own data, such as muscle simulations. For the latter, there is, among other things, ML Pose Generate. This node generates a series of random character poses, which is essential for creating an extensive training data set.
A practical example of the ML Deformer for groom and fur can be found at SideFX:
https://www.sidefx.com/tutorials/ml-groom-deformer/
Kimodo inside Houdini
The third-party plugin Houdini AI Assist takes a hybrid generative-open approach. The tool by Radu Cius offers a Kimodo integration and Nvidia’s text-to-motion model, aka the Kinematic Diffusion Model, directly in Houdini, and can pass the results to KineFX as open data structures or take Houdini geo, such as curves, as input. I have not tried the plugin myself yet, but it sounds worth watching. Kimodo itself can be tested online. The generated movements, however, are devoid of any emotion, details and character, and are only a starting point or rough blockout.
Rigging is only the beginning. In the next article about the character topic, everything revolves around:
Ragdoll: Here, every character is hit by the Bullet solver. Great for letting our protégés collapse correctly, both procedurally and physically, during falls, explosions, or impacts. Including blending between manual animation and simulation.
Dynamic Motion, aka Physics: The Projectile and Pendulum Motion SOPs automatically calculate physically correct flight and swing paths between your rough keyframe blockings. Not only good for baseball.
Crowds: Mass simulations on steroids. Because our skeletons are ultimately only points and attributes, the crowd system can procedurally chase thousands of agents through difficult terrain, mix clips, and then knock everything over with ragdoll physics.
MetaHuman Plugin: Unreal’s MetaHumans can now be imported into Houdini together with Control Rig and animation. For the impatient: https://www.sidefx.com/tutorials/project-violet/
One more thing: Houdini 22
The H22 keynote, streamed a few days ago, showed some great workflow improvements for rigging. Nothing changes about the basic principle; it is even expanded further. gSplats, for example, are also only points with attributes and can therefore be animated in the same way as polymeshes.
You can read an overview of the new features here on DP: https://digitalproduction.com/2026/06/23/here-comes-houdini-22/. After the release, we will, of course, take a closer look at everything.
The truth …
Rigging actually works well and fast and is easy to learn, super flexible and… is fun for the first time?!. Once you have understood the nomenclature and the corresponding rule set, and this time, untypically for Houdini, it does not have encyclopedia thickness, you have an incredibly strong and flexible system at your disposal.
Anyone who wants to can do the most complex things in the Graph script, and anyone who does not want that gets damn far with the autorig nodes. Even the Autorigger for artists without rigging experience, on a tight deadline, works excellently.
What personally gave me a positive feeling, especially with the bike project, is that thanks to the procedural foundation, exchanging or adding assets or elements after the initial setup is super fast.
It is Houdini, after all
As always with Houdini, one could say the setup takes longer, but the exchange and adjustment are faster, though this old rule quickly diffuses here. With the current iteration of APEX and KineFX, even setting up complex elements is quick. Whoever wants can, of course, still invest their time in massive graphs or APEX scripts and thus create even more complex rigs.
The cat model comes from a commercial from the pre-APEX era and was completely rigged and animated in KineFX. Compared to back then, the rig with APEX was created in a fraction of the time and with a fraction of the pain. Even if APEX is “something new to learn again”, it is a big gain and saves a lot of time and frustration in the end.
Downside: you have to know things, learn the APEX vocabulary, for example, “how exactly do I bind the tags?” At the beginning, that is often not clearly obvious and follows its own logic. This also applies to the nodes in the APEX graph, which are not necessarily named the way one would expect with some experience in VOPs.
These hurdles are easy to overcome, however. Download the free Apprentice version of Houdini, grab one of the included test characters or the cute Harry robot and try it yourself.
Further reading, for Basic APEX rigging: SideFX’s Eye Bot
https://www.sidefx.com/tutorials/intro-to-rig-builder/
The Autorig Builder, which Magnus Møller has created, is a detailed and very watchable Guide for Entagma:
https://entagma.com/new-in-houdini-21-apex/
And for everyone who likes to reverse-engineer systems, the “Harry Rig” from SideFX is a good option.
Deep dive into Graph & Script
