Houdini's Rigging Revolution | Tags

Tags let a rig-building tool identify joints by their intended role as well as their names. In this Houdini session, the instructor adds a point string-array attribute named tags to an existing character skeleton, then prepares the corresponding guide controls for later APEX work. The purpose is to support different naming conventions without making every future component depend on one fixed joint name.

The lesson uses Point VOP networks rather than handwritten code. It covers the whole skeleton, including twist joints, fingers, feet, side conversion and pole-vector guides. It does not build or test the later APEX components that will consume these tags. Exact Houdini version and all on-screen token spellings are unverified; where captions describe a multiword label, check its literal spelling in the scene before using it in a selector.

Create and export a point string array

At 01:00, add Attribute Create near the pelvis point. Set the name to tags, the class to Point and the type to String Array. An array allows one joint to carry several independent roles: it can belong to an arm, be on the left and participate in FK without packing all those meanings into a single name.

The instructor considers tagging a merged chain in one operation, then chooses to work near the individual point sources where the intended role is easy to identify. This costs more nodes, but avoids repeatedly filtering a large combined skeleton during the initial setup.

At 03:01, add a Point VOP. Inside it, use Bind to read tags as a string array and Bind Export to write a string array with exactly the same attribute name. Insert array-append operations between them. The first example appends FK and spine.

At 05:01, inspect the geometry spreadsheet. Without the export connection, the expected result does not appear on the output geometry. Seeing values inside the VOP network is therefore not the final check: inspect the tags attribute on the geometry that leaves the node.

Copy this setup for the remaining spine points, then change the regional label for the neck and head. Initially the head-top point gets an end label instead of FK. That label is revised later because end is also needed for an IK-chain role.

Give the arm explicit chain and twist roles

At 08:00, tag the clavicle for FK, arm and left-side membership. Keep capitalization consistent: the source uses uppercase FK and IK with lowercase regional and side labels. A typed label in a parameter is the data source; an apparent spreadsheet edit is not accepted as the way to maintain it.

At 10:01, add the shoulder’s extra IK and root roles. The intended arm-chain roles become:

Joint	Intended role in this setup
Shoulder	FK and IK; root of the arm IK chain
Elbow	FK and IK; middle of the arm IK chain
Wrist	FK and IK; end of the arm IK chain
Clavicle	FK arm joint, outside that three-point IK-role assignment
Intermediate twist points	FK and twist roles, with regional and sequence qualifiers

At 12:03, inspect the existing twist construction instead of assuming its point count. It contains three intermediate points in the demonstrated branch. The copied shoulder tags would leave unwanted IK/root information there.

The correction at 14:01 removes the incoming Bind from the initial twist-tag network and exports a newly constructed array. This replaces inherited roles rather than appending to them. A later Point VOP reads that corrected array and adds a sequence label to one selected point at a time. The accepted sequence aligns twist_00, twist_01 and twist_02 with local point numbers 0, 1 and 2.

These point numbers belong to the small branch being processed. Do not reuse them blindly after a different merge or topology change. Inspect the branch and confirm that each sequence tag reaches its intended point.

At 18:01, revise the head-top label to endjoint so it is distinguishable from the wrist’s IK end role. At 19:01, add regional qualifiers to distinguish upper-arm twists from forearm twists. A qualifier is initially placed on the wrong node, then moved into the intended twist branch. Check the output arrays after copying: a plausible node name alone does not prove the tag is on the correct joint.

Separate hand placement, finger controls and tips

At 22:00, give the palm a hand-membership and placement role. It is intended as a location for a held object or related attachment, so this example does not mark it as an FK or IK control.

The fingers use FK. Each branch receives hand, left-side and finger-specific labels. The thumb example has four local points, numbered 0 through 3: the first three receive FK and the last receives the terminal-joint role.

At 26:01, the instructor tries a caret-based exclusion to select everything except point 3. It does not work in the demonstrated field. The accepted correction explicitly selects points 0, 1 and 2 for the first operation, then selects point 3 separately for the tip operation. This failed attempt should not be copied as a working selection expression.

Repeat the setup for index, middle, ring and pinky, changing the finger identifier in both the regular-point and tip networks. Several spoken names are corrected during copying. Inspect the completed left-hand output around 29:00 to catch a branch that still carries a neighboring finger’s label.

Reuse arm tags for the leg through array replacement

At 30:01, the instructor explores a more efficient way to adapt copied tags. Read the existing string array, find the index of a known label, then use Set Array Element to replace the value at that index. Connect both the original array and the found index to the replacement operation, and export the resulting array.

The first conversion replaces arm with leg. It preserves other roles already assigned by the copied arm networks, such as FK, IK, root and side. After adapting the hip, knee, ankle and twist branches, the output is inspected again.

At 37:00, extend the replacement chain so the upper-arm region becomes thigh and the forearm region becomes calf. Feed each replacement’s resulting array onward; merely searching for another label does not update the final export. The lesson demonstrates this with expected labels present. It does not add a general missing-label check, duplicate-label cleanup or a reusable validation system.

At 39:01, handle the foot separately. The ball receives FK, foot and side roles, while the terminal foot point receives the terminal-joint role with foot and side. The source first considers retaining leg membership, then changes these points to foot membership. Preserve the accepted distinction when checking the final arrays.

Copy to the right side and inspect connections

At 41:00, copy the appropriate tag networks to the right arm, including both twist branches. Repair their input and output connections before evaluating the result. An error around 43:01 turns out to be a disconnected source connection, which is restored.

Adapt the replacement network so it searches for left and writes right. Remove the earlier arm-to-leg and upper-arm/forearm conversions from this right-arm copy: its anatomical roles should remain arm roles. Inspect root, mid and end as well as the side label.

Repeat for the right hand and leg. Copying the relevant point-source context helps the instructor keep palm and finger connections identifiable, but the leg already has some names in place and does not need every naming node copied again.

At 50:02, inspect the combined skeleton spreadsheet and continue downstream to Rig Pose. The demonstration confirms that the expected tags are present and the existing skeleton still displays correctly there. This is a structural inspection, not an APEX animation test.

Adapt inherited tags for global and pole-vector guides

At 51:01, work on the separate guide skeleton. Add output nulls and consistent names for the global control, center-of-gravity control and elbow/knee pole-vector points. The naming changes break existing parenting references, so parenting is deliberately repaired after the tag edits.

Global and center-of-gravity guides receive center and driver roles. A guide imported from an already tagged point can inherit unsuitable roles; when the intended result is a fresh driver array, remove the incoming Bind and export only the new tags. Attribute Create is unnecessary in the demonstrated imported branch where the attribute already exists.

At 57:01, treat pole-vector guides differently. They should retain useful inherited information, including IK, side and limb, while removing FK and replacing the chain’s mid role with PV. Find Index and Remove Index remove the FK entry; a subsequent search and Set Array Element replace the middle-chain role.

Follow the data through each operation and inspect the exported array. Array removal and replacement are separate transformations, and the required labels should be verified after both. The recording does not establish robust behavior for arbitrary input arrays or missing search values.

At 01:00:01, the right-elbow guide unexpectedly still carries left. Its source is taken upstream of the earlier side conversion. Add the required left-to-right replacement on this branch. The knee guides likewise need arm-to-leg conversion because of where their source data was imported. One copied knee setup is briefly changed to right even though it belongs to the left knee; that extra conversion is removed before the final check.

This is the central dependency lesson: a downstream correction on one branch does not retroactively alter another branch that imported an earlier point. Inspect tags at the actual input of each guide, rather than assuming they match the final main skeleton.

Repair parenting and inspect the combined guide output

At 01:02:02, return to the rig tree and parent the guide controls beneath the global/root control. The instructor notes that parenting through the center-of-gravity control is another choice, but uses the global arrangement here. Confirm the resulting hierarchy after the naming changes.

At 01:03:02, import the original skeleton with Object Merge and merge it with the guide skeleton. A no-longer-needed Rig Pose is bypassed or removed in this branch, and the combined result is exposed as the guide-skeleton output.

Inspect the final spreadsheet around 01:04:01. Every expected point should have an appropriate array, but presence alone is not enough: check side labels, regional qualifiers, unique twist sequence roles, terminal joints versus IK ends, and pole vectors versus ordinary middle joints. Save the scene after those checks.

The session ends with tagged skeleton data prepared for later rig construction. It explicitly leaves room to fix issues when subsequent components expose them. A complete tag vocabulary has been demonstrated for this character, but compatibility with an arbitrary skeleton or a finished automatically generated rig has not been proven.