Components are individual isolated rigs that make up one larger rig eg. arm, leg, eye etc which makes up a character/prop/setPiece.

Rigging Components are built with modularity in mind this means that if a particular set of logic can be reused then we should consider it to be a component and we attach it to other components.

We Provide Some out of box components for the most common use cases and will continue to add more as we go.

For More information about how components are constructed see Components


Definition files describe the components in the rawest possible way and allow hive to auto generate scene data eg.nodes, attributes etc with this data structure.

These would have the component guide hierarchy, animation attributes eg.ikfk attribute, component metadata, IO nodes and attributes. These files are built with the JSON format so you can debug and edit them easily too. Without the definition of a component you don’t have a working component. Component definitions are the main access point when creating guides, joints etc, with out it there’s no guarantee that your component will build every possible situation the user throws at it.

API Reference: zoo.libs.hive.base.definition.ComponentDefinition


Hive Templates are Json Files or Raw Python Dictionary data.

The Data inside of a template contain the custom configuration overrides, final composed guide definition, rig name and hive version that was used to create the template. With this information it allows hive to recreate any hive rig from scratch.

alternate text

Hive Layers

Hive Layers are based on a Organizational concept. Each Layer represents a collection of nodes and attributes. Each Layer is responsible for construction, serialization and querying it’s own data.

Each layers always consists of two primary nodes

#.. The metaNode(Maya network node).
  • Links all nodes within the layer.

  • Handles all API queries and meta Data.

  1. Dag Transform.
    • Contains all Dag nodes for the layer. The exception is the Deform Layer at the component level where bind joints are parented to the rig Layer deform.

Hive Layers aren’t display or render layers though they share similarities in the concept of the API.

alternate text

Guide Layer

A Hive Guide layer is a container for all guide related nodes within a single component It contains all API logic for Querying, creating, deleting guides. It’s responsible for (de)serialization of the guide hierarchy for definitions/templates. The guide layer also contains all primary build settings which the user can change in a UI via a connected node called a “Settings Node” which are network nodes with attributes.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveGuideLayer

Rig Layer

The Rig Layer is responsible for the animation control rig and animation settings(attributes). Just like all other Hive Layers is contains all API logic related to Animation controls, system joints(ik/fk). This layer also contains all animation extra attribute like ik/fk stretch etc on a connected network node called the “ControlPanel”. All extra attributes on this node will become proxy attributes on all controls on the component.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveRigLayer

Deform Layer

The Deform Layer is responsible for managing deformation joints ie. joints which are skinned to output geometry, deformers would be parented to this layer on the component level as well ie. lattice. This layer exists at the rig level and the component, use the component deform layer to access the joints. The Rig root deform Layer is used for parenting.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveDeformLayer

Input Layer

The input layer is responsible for managing the incoming transforms from outside of the component, for example when a constraint happens from one component to another. Instead of constraining the control directly from another component we constraint a input node which in turn manipulates the component this allows the internals of the component to be self contained and have complete control over how the node network is managed.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveInputLayer

Output Layer

Similar to the Input Layer the Output layer manages all outgoing transforms which in turn constrains the input layer of another component.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveOutputLayer

XGroup Layer

A Extra group which rigs can use at the component level to manage arbitrary nodes, this layers is not build automatically as it’s not always needed.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveXGroupLayer

Component Layer

The Component layer that only exists at the root of a Rig which manages all components this is how we access a component through the rig. The Layer just like the others contain a transform however all components will be parented too this transform.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveComponentLayer

Geometry Layer

The Geometry layer manages all geometry on a rig ie. both proxy which some people call the calamari and deformed geometry. The Geometry can exist at both the Rig root level and the component level. The Default Rig root level is where all geometry which would be exported gets parented too.

API Reference: zoo.libs.hive.base.hivenodes.layers.HiveGeometryLayer


A Hive Guide Represent to main areas first the Transform which will be referenced by all other aspects of a component to generate nodes calculate math etc. Second is the Animation control shape which can be manipulated by the rigger before it’s serialized and applied to the animation control shape.