Character FX & Animation / Houdini & Procedural Workflows / Houdini
Simple APEX Character Rig Walkthrough
Written guide

Playing loads YouTube content. YouTube processes data after activation.
Watch on YouTubeIf the player is blocked or unavailable, use Watch on YouTube.
This walkthrough adds APEX controls to an FBX character that already has a skeleton and skin weights. It builds FK deformation, a spline-driven spine, limb IK and IK/FK switching, eye look-at controls, and a more readable control interface. It is especially useful for seeing how imported joint names, tags, units, and orientations affect a component-based rig.
Two outcomes remain incomplete in the recording: the reverse-foot toes flip incorrectly, and a late attempt to reposition the IK/FK abstract controls is abandoned. The archived video description later links a creator post described as a fix, but that post’s contents were not accessible during this reconstruction. The article therefore preserves the recorded failure and does not claim to include or verify the later repair.
The description calls this a beta APEX workflow; the exact Houdini build is unverified. The instructor follows SideFX’s character-rigging guide, whose current version has changed parts of the setup. That guide confirms the Base.shp and Base.skel conventions and case-sensitive naming, but its current example should not be treated as a frame-for-frame copy of this recording.
Prepare the imported character and stable outputs
From 00:00, inspect the imported Character Creator asset. Its skin and skeleton already exist; this lesson does not create weights from scratch. A Color node clears an unwanted shaded appearance, and Clean removes leftover points associated with geometry that had been deleted beneath the clothes.
Add named Null outputs for the character geometry, skeleton, and guides. The instructor reports that changing the node directly connected to the packed folder had caused problems in earlier attempts, while editing upstream of a stable Null was more manageable. Treat that as the observed organization strategy, not a proven explanation of every possible packing failure.
Compare the importer’s skeleton outputs. In this asset, the capture-pose view shows disconnected-looking eye, head, and jaw elements, whereas the animation-skeleton output has the hierarchy the instructor expects. Because this example has no animation, the latter can be used directly for the demonstrated setup.
A Rig Stash Pose arrangement is shown as an option when an animated skeleton needs a fixed pose. One input is initially connected incorrectly and corrected. The captions do not provide a complete reusable wiring prescription for all FBX imports, so inspect the actual pose and hierarchy rather than assuming that an output’s position alone makes it suitable.
Pack the character and prove basic deformation first
Around 05:00, connect the geometry, skeleton, and guide streams to Pack Folder. Name and type the elements consistently with the components that will consume them. The recorded base entries use the shape and skeleton conventions represented as Base.shp and Base.skel; the guides are another skeleton element.
Add Attribute Adjust Array for the joint tags used later. Set its attribute class to points when working on the skeleton. The tags will identify anatomical segments without requiring every component to hard-code the imported joint names.
Add APEX AutoRig Component configured as FK Transform, then enter the animation state to inspect its controls. The controls exist but are unexpectedly small. The instructor traces the mismatch to the FBX import’s unit conversion and scales control shapes by 100 in this scene.
That is a display adjustment for these imported proportions. It does not establish that every rig should have a 100-times control scale or that changing control size repairs the skeleton’s units. Check the controls relative to the character before proceeding.
From 08:02, add a Bone Deform component. Rotate a joint and verify that the skinned mesh follows. This separates two tests: a visible movable control proves that a control exists; deformation of the character proves that the rig is driving the skin through the intended relationship.
Tag the spine and match the component’s selectors
At 09:00, select the spine joints in Attribute Adjust Array and add the segment tags. An initial spine/spline mismatch is corrected to match the chosen component’s driven selection. The instructor also assigns the root and tip tags used by this setup.
Use an AutoRig Component set to Spline and compare its selectors with the actual tags, including capitalization. Tags are only useful when the consuming component selects them. A nearly identical name can leave a component without the intended joints.
Temporarily disable the broad FK-control promotion so it does not clutter the developing interface. Enlarge the new spine shapes as needed, then test the root and tip controls. The recording shows the body following the spine setup, and leaving and re-entering the unkeyed test state resets the exploratory pose.
Name the component nodes according to their roles, such as bone deformation and spline, before adding more systems. This makes it easier to return to the component that owns a behavior rather than editing whichever controls happen to be visible.
Add limb IK and an IK/FK blend
From 13:00, add a Multi IK component. Tag each leg separately for left and right, then inspect the resulting leg targets, hip-related controls, and pole vectors. Scale the shapes to a readable size. The source shows the limb system following the existing root/spine arrangement, although the instructor does not fully trace the automatic parent relationship in the interface.
Extend the segment selection to include the arms, then tag each shoulder–elbow–wrist chain independently. Keep the left and right tags distinct. The demonstrated selectors use wildcard matching for the limb segment names; inspect the field’s expected format instead of assuming every rig parameter accepts the same tag-expression syntax.
Around 17:00, add IK/FK Blend. The default lowercase segment pattern does not match the tags used in the scene, so the instructor corrects its case. Test the switching control: one mode should respond to the IK target, while the other exposes FK joint rotation.
The newly revealed FK controls are again small. Changing the abstract switch-control scale does not fix those FK shapes, because they belong to a different part of the interface. Their appearance is addressed later with Configure Controls.
The instructor also notices that applying one positional offset to all blend controls moves them in the same direction, rather than placing each one relative to its limb. Separate per-limb configuration is proposed, but the final successful method is not established here.
Keep the reverse-foot failure explicit
At 22:00, add Reverse Foot and tag the left and right foot segments, ankles, and balls. Match the case of the component’s segment selection to those tags. With no explicit toe joints, the component creates the expected toe-related setup, but the toe behavior is visibly misaligned.
Adjusting the tilt offsets improves where the side pivots sit. It does not correct the underlying upward toe flip. The instructor also tries changing the toe-up direction without resolving the problem.
From 27:02, test the documented approach of adding toe joints. In a Rig Attribute VOP, retrieve the ball joint’s transform by name, create an offset transform, and add a child joint. The point-number connection establishes the parent, while the transform connection places the new joint. The example offsets it by 10 scene units, duplicates the arrangement for the opposite side, and changes the joint names accordingly.
Return to the tagging node and include the new joints in the foot selections with toe tags. When the Reverse Foot component is pointed at them, the toe position improves but its orientation still flips incorrectly. Reversing trial settings does not produce the intended alignment.
The instructor says the issue has been sent to SideFX support and remains unresolved at recording time. The later creator post linked in the archived description is a separate follow-up reference whose content could not be checked here. Until that evidence or a reproduced fix is available, this section is a diagnosis trail and an incomplete result, not a reliable reverse-foot recipe for this imported skeleton.
Build eye look-at controls from the actual joint axes
Around 34:04, add a Look At component for the eyes. Use the geometry spreadsheet to identify the imported eye-joint names, then add left and right eye tags. Enlarge and move the target shapes so they can be selected away from the face.
The first eye aims in the wrong direction. The instructor inspects joint orientation with Rig Pose and experiments with the look-at and up axes. There is also confusion between the target control and the up control; moving the wrong one makes the behavior appear inconsistent.
This is why joint orientation should be inspected rather than copied from a different character. The recording eventually gets a usable eye target by adjusting the axis sign and placing the target and up positions appropriately for this skeleton. Several trial values are superseded, and the captions do not establish one clean axis tuple that can safely be applied to every imported eye.
An attempt to create the other eye by copying the component produces overlapping or overwritten control definitions. The instructor removes that arrangement and adds another setup within the Look At component, giving the driven joint, target, and related controls distinct right-eye names.
After correcting the second eye’s inverted behavior, disable the exposed up controls to reduce clutter. Both eyes can then be aimed independently in the demonstrated test. Their naming and orientation work is specific to this character; the tutorial does not build a broader facial-expression system.
Make control selection and appearance readable
From 48:03, use APEX Configure Controls to establish a center/left/right color scheme: a muted yellow base, red for the right side, and blue for the left. The first wildcard pattern is in the wrong order, and some eye and FK control names use different case or suffix conventions. The instructor adjusts patterns and names until the intended controls receive their colors.
Treat the matched control list as a checkpoint. A color or shape change that affects nothing may indicate a selector mismatch, not a broken rig. Conversely, a pattern that matches too broadly may alter unrelated controls.
Around 52:01, resize the FK controls generated for the limb blends, replace their shapes with circle wires, and rotate those shapes into a more useful orientation. Then tag the clavicle, neck, head, and finger joints that should remain available as direct FK controls and enable those through the earlier FK component.
The head selection initially chooses a facial-base joint instead of the actual head. Two joints occupy nearly the same position, making viewport selection unreliable. Inspecting the name in the spreadsheet and replacing the mistaken name resolves the selection. The head then receives a box-wire control, while the neck uses a rotated circle.
Continue with smaller eye controls, distinct pelvis and chest shapes, and readable finger controls. Finger shapes need separate left and right adjustments because a rotation that points outward on one side points the opposite way on the other. The instructor uses a line-style shape, scales it down, and reverses the rotation for the mirrored side.
These changes affect how an animator finds and selects controls. They should not be mistaken for corrections to the still-unresolved reverse-foot solver behavior.
Finish the master control and identify what remains
From 1:14:04, revisit the IK/FK blend controls. Moving the visual shape does not move the abstract control’s functional position as intended. The added configuration entries are removed, and separate blend components are discussed as a possible approach but left unimplemented.
Around 1:17:03, insert an AutoRig Component configured as Transform Driver above Bone Deform in the existing chain. Drive the skeleton’s root and verify that the resulting control moves the whole character. In Configure Controls, find the generated main control, replace its shape with a circle, rotate it, and enlarge it as the master control.
The resulting walkthrough demonstrates a connected rig with many usable controls, along with specific unfinished areas. Its strongest verification points are mesh deformation under FK, spine response, limb-mode switching, independent eye aiming, and whole-character motion from the master control. It does not establish a corrected reverse foot, seamless IK/FK matching over an animation sequence, or a completed export workflow.