Hierarchy Models: Building Blocks for Procedural RiggingMichael

Hutchinsonm.s.hutchinson@

gmail.com

Sandy KaoDreamWorksAnimationsandy.kao@

dreamworks.com

Kevin OchsDreamWorksAnimationkevin.ochs@

dreamworks.com

Gilbert Davoudgdavoud@gmail.com

Alex Powellalexander.powell@

gmail.com

Figure 1: Hiccup and Astrid from How to Train Your Dragon 2 using Hierachy Models

ABSTRACTHierarchy Models provide an encapsulation mechanism for jointhierarchies that yield an essential building block for proceduralrigging. With Hierarchy Models, joints travel through dependencygraphs (DGs) as an atomic entity. Operation nodes in the DG canmodify all aspects of input hierarchy and even perform topolog-ical modifications like adding or removing joints. The HierarchyModel reduces complexity in character rigs, improves separation be-tween data and behavior, provides a clean interface, and simplifiesunderstanding and debugging rigs. It offers geometric evaluationoptimizations, and promotes parallelism in the DG structure.

KEYWORDSCharacter Rigging, Procedural Rigging, Dependency Graph Opti-mization

ACM Reference Format:Michael Hutchinson, Sandy Kao, Kevin Ochs, Gilbert Davoud, and AlexPowell. 2019. Hierarchy Models: Building Blocks for Procedural Rigging.In Proceedings of SIGGRAPH ’19 Talks. ACM, New York, NY, USA, 2 pages.https://doi.org/10.1145/3306307.3328160

© 2019 DreamWorks Animation, L.L.C. Originally published in Siggraph 2019 Talks. https://doi.org/10.1145/3306307.3328160

1 INTRODUCTIONIn typical Digital Content Creation tools (DCCs), joints are repre-sented as named, first-class entities that are organized into hier-archies with directed acyclic graphs (DAGs). Each joint has oneset of values representing a single state. Complex behaviors aredefined by layering transforms, adding constraints, and drivingvalues through dependency graph nodes.

This works well for simple cases, but can become unwieldy ascomplexity increases. In production rigs it is not uncommon to seejoints nested below a dozen intermediate transforms, each witha specific but esoteric purpose. Joints may be duplicated acrossmultiple hierarchies, reverse hierarchies, or broken hierarchies,all tied together with complex constraints and connections. Stateand execution order become increasingly difficult to design, debug,and understand as execution weaves in and out of the DAG anddependency graph.

As the industry shifts towards greater levels of procedural-basedsolutions ([Nieto et al. 2018]), joint hierarchies are not able to takeadvantage of mass manipulation operations that we see in geometry.The Houdini procedural effects and modeling is a paradigm thathas not been applied to joints and motion systems natively in apackage, except at DreamWorks. The hierarchy model representsa solution that can be more in-lined with operations to geometryand use the same approach and methodology. It could also takeadvantage of SIMD graphics cards harware which exploits datalevel parallelism.

SIGGRAPH ’19 Talks, July 28 - August 01, 2019, Los Angeles, CA, USA Hutchinson, Kao, Ochs, Davoud, Powell

2 PROCEDURAL BUILDING BLOCKSRather than joints being represented by individual first-class objects,joints are components of theHierarchyModel, much like a vertex ona poly model. Besides the base level transformation data, each jointcomponent have additional attributes, including, but not limitedto, parent, rotation order, scale propagation, flipping behavior, andcolor. The hierarchy can then flow through the dependency graphjust like a geometric model with the output of each of these nodesrepresenting a distinct state of the hierarchy that can be viewedand inspected independently.

Like geometric models, the Hierarchy Model can be modifiedprocedurally in many different ways. Topological modificationscan be made to add, remove, or re-parent joints. Or, more com-monly, joints can be translated, rotated, or scaled, or have theirtransforms set directly. Constraints can be written that modify oneor more joints in complex ways all represented by a single nodewith minimal inputs and outputs.

3 USAGEAs an example, consider the construction of a simple limb rig withthe following behavior: independent IK and FK chains with a blendin local-space, and an additional layer of FK offsets on top for subtlesecondary motion.

Using first-class joints, each of these states must be representedusing duplicated (but slightly different) explicit hierarchies. Localspace blends and FK offsets are difficult to set up, and rely on jointproperties like rotation order staying in sync between the differentversions of the hierarchies. The DAG and dependency graph becomedifficult to trace and lack meaningful semantic clues about intendedbehavior. (Figure 2)

However, using Hierarchy Models, the dependency graph simplylooks like a flowchart used to explain the desired behavior (Figure3). The construction of the graph flows naturally from an intuitiveunderstanding of the desired behavior, and provides good semanticinsights into intended behavior when later debugging or modifying.

Figure 2: Typical DAG based joints in fk and ik setup

Figure 3: Hierarchy Model joints in fk and ik setup

Another example is the reverse hierarchy. In the typical con-struction, a literal reverse hierarchy would be constructed to blend

to the normal hierarchy. This usually requires 1-to-1 mapping ofduplicated math nodes to process the transformation and a seriesof constraints to accomplish the behavior as well as ensuring at-tributes of the hierarchy such as joint rotation order are matchedand do not get out of sync.

With the Hierarchy Model, we have an operation type that canspecify an arbitrary joint as pivot. This can then modify all thejoints within the hierarchy, including itself. Transient propagationstate can also be set along the hierarchy per operation. For instance,you could make a chain of joints curl or spin in place based on thepropagation attributes.

A benefit of Hierarchy Models is the ability to scale. When jointsare treated as individual nodes, a computationally expensive op-eration, such as a constraining joints to a surface, will rely on theefficiency of theDG to parallelize the evaluation. ButwithHierarchyModels, since the joints are essentially points, they can be deformedby geometry like any other geometry. All of the optimization ofthe deformation, can take advantage of any parallel-processingavailable in the deformation libraries.

Figure 4: Hier Models flowing through character sections

The encapsulation of Hierarchy Models allows for the simplifi-cation of the character graph. Figure 4 shows an example of how acharacter’s dependencies can be represented. Downstream systemscan point to a single output Hierarchy Model instead of a list ofjoints. It also illustrates how the user can replace the input jointdata quickly with one model. The separation of input data to thecharacter motion systems allows the interface with other data typeswith less rewiring of the graph. For instance, crowd data can controlthe entire character using FBX motion capture and the arm can beintercepted to use Hierarchy Models by changing one connection.

4 CONCLUSIONThe DreamWorks Hierarchy Model provides a solution for jointdata that is self-contained and can be optimized using known ge-ometry techniques. It allows the users to make complex motionsystems with less operations and makes the flow of operations moresequential in a motion system. The resulting graph of HierarchyModel operations represents the logic of the system as bundled stepsinstead of individual operations per transform. The data model canbe expanded on through promising new interchange formats likeUSD.

REFERENCESJesus Nieto, Charlie Banks, and Ryan Chan. 2018. Abstracting rigging concepts for a

future proof framework design. In ACM DIGIPRO 2018. ACM. DOI:http://dx.doi.org/10.1145/3233085.3233088