Houdini Crowd Simulation: A Guide to Organizing Agent Setups

This guide draws on the crowd simulation and agent sections of SideFX’s Houdini 22.0 documentation. Its goal is to organize an agent definition for a crowd of characters by separating the rig, geometry, and animation data into reusable components. The documentation does not provide a single setup recipe or recommended parameter values for every scene. The steps below therefore stick to the components and behaviors described in the source.

1. Plan the parts of the agent definition

In Houdini, an agent primitive is a type of packed primitive containing a single point, and in some cases it can be treated like a particle. The shared set of data referenced by an agent primitive is called an agent definition. A definition can contain a rig, shape library, layers, animation clips, transform groups, and optional metadata.

1. Decide which data will be shared. Organize the rig, shapes, and clips shared by copies of the same agent as components of the definition. This lets multiple copies use the same definition instead of rebuilding shared components for each one.

2. Prepare the rig and channels. The rig stores a hierarchy of named transforms and channels. Each transform can have a parent or be a root. An optional rest pose can be used when a joint is absent from an animation clip, or when no pose or clip is assigned to the agent. Default values can also be set for channels that have no corresponding animation in a clip.

3. Consider storing additional information in metadata. Metadata in an agent definition can store custom information, such as details about asset creation. Because this information is shared between definitions, it can be an alternative to creating separate data for every agent.

2. Set up the shape library and layer bindings

The shape library contains the geometry shapes available to an agent, and each shape has a unique name. Layers determine which shapes are used when an agent is unpacked, as well as how those shapes are transformed or deformed. This separation lets you manage geometry pieces independently from how they are connected to the rig.

1. Organize geometry as named shapes. Give each shape in the shape library a unique name. According to the documentation, shapes are stored as packed primitives, and the library can be saved as a single geometry file in the standard geo/bgeo format. The shapelib_includes detail attribute can be used to import additional shape libraries; it expects a two-part path for each additional source.

2. Define shape bindings in a layer. Each binding connects a shape in the shape library to a transform in the rig. A binding can also specify a bounding box scale multiplier for the shape and the deformer to use. If no deformer is assigned, the binding is static: the shape follows the transform of the joint it is bound to.

3. Choose a deformer based on the shape’s needs. For skinning deformation, the geometry must be in its rest pose and contain capture attributes that describe how rig transforms affect the geometry. The documentation lists linear skinning, dual quaternion skinning, and an option that blends the two. Linear skinning is described as the standard and fastest method; it is also the only method used for GPU skinning in the viewport.

3. Add animation clips and rig groups

Clips drive the agent’s transforms and channel values. The agent’s current layers, transforms, and channel values determine the resulting geometry when the agent is unpacked. Clips are saved in the standard .bclip format.

1. Match clip channels to the rig. The documentation says that transform channels are stored in local space and use the transform_name:channel format. Channel names can refer to position, rotation, scale, or shear components. If the source animation has pre-transforms, account for the fact that the full local transforms in the clip may not match the transform channels of the source objects.

2. Apply clips to specific parts of the skeleton. A transform group is a named subset of transforms and channels in the rig. It can be used to apply clips to only specific parts of the agent. The documentation says each transform in the group can be assigned a weight between 0 and 1.

1. Keep states and triggers distinct from animation. In Houdini’s crowd system, a state is a virtual state that controls an agent’s animation and the behaviors it runs. Triggers specify the conditions that cause an agent to transition from one state to another. The documentation also covers topics such as behavior weights, variation, and interactions with other dynamics; these are not the same as the function of clips.

4. Choose a workflow for saving and reuse

The components of an agent definition can be embedded in a geometry file. Alternatively, each component can be saved to a separate file and used through an external reference from the agent primitive. In that case, the geometry file stores the file path rather than the component itself. SideFX notes that this approach can significantly reduce duplicated data, particularly when saving frames of a crowd simulation.

1. Choose a storage method based on the scene. Embedding components keeps definition data with the geometry file. External references call components from separate files. For scenes where the same definition is repeated across many frames, consider using external files and check that they remain accessible in the production pipeline.

2. Write or create the agent definition on disk. The Agent ROP can write the definition of an existing agent primitive to disk or create an agent definition from a character rig or FBX file. Make sure the save format is consistent with your choice to embed components or use external references.

3. Validate the components together. First check that the rig, shape bindings, deformer, and clips produce the expected result; then move on to other topics such as crowd behaviors, terrain adaptation, or obstacle avoidance. This is a practical workflow suggestion for testing interconnected components individually, not a fixed settings recommendation from the documentation. SideFX’s documentation also lists the Crowd Procedural workflow for render-stage optimization, but the source does not specify particular values or hardware requirements.

Common mistakes

• Reusing a shape name in the same shape library; every shape must have a unique name.

• Overlooking the rest pose or capture attribute requirements when using a skinning deformer.

• Assuming local transform channels in the clip will match the source animation exactly when it has pre-transforms.

• Creating external file references without checking that the files are available in the project and render environment.

• Treating states, triggers, and animation clips as if they serve the same function; they have different responsibilities.

For architecture, interior design, and archviz workflows, a potential benefit of this guide is the ability to manage recurring character data more systematically. This is not a claim by SideFX that the documentation is specifically intended for these fields; it is an inference about how the documented crowd agent components could be used in architectural visualization. In scenes with crowds, grouping shared rigs, geometry, and clips under a definition can make components easier to track. External references can also reduce duplicated data. However, the source does not guarantee compatibility with other archviz software or specify GPU or RAM requirements or licensing terms. These points should be verified separately for the Houdini setup and production pipeline in use.