Hair and fur are among the last parts of the character pipeline to move into a shared scene format. The reason is understandable: a groom is procedural, it depends heavily on shading, and every renderer has historically wanted it in its own shape. Node-based grooming closes that gap.
Why hair resisted the pipeline
A groom is not geometry in the ordinary sense. It is a description of how curves are generated, guided, clumped and shaded. When that description lives only inside one renderer, the same character has to be re-groomed for every renderer the studio supports, and a look developed for one shot cannot be reused in another.
Moving the description into a shared format — and describing it procedurally — means the groom can be published once, versioned like any other asset, and consumed by any renderer that understands the description.
Node graphs instead of frozen curves
A node-based hair system lets an artist build the groom as a graph: generate guide curves over a scalp, distribute hairs along them, add clumping and noise, then shade the result. The graph is small, readable and editable. The output — the actual curve primitives — is a consequence of the graph, not the thing the artist maintains by hand.
That distinction is what makes iteration practical. Changing the density of a beard, or the length of a fringe, is an edit to a parameter rather than a re-sculpt.
Open Shading Language as the common denominator
Procedural hair leans on shading. Colour variation along a strand, breakdown of clumps, and the response of the groom to lighting are all expressed through shader networks. Building those networks on an open shader language rather than a renderer-specific node type keeps the groom portable.
In practice this means an artist can author a groom whose look survives a change of renderer, and a pipeline team can reason about one shading language instead of half a dozen proprietary node vocabularies.
The grooming stage, step by step
A production groom is usually assembled in a fixed order, with review gates between the steps:
- Scalp and guides — define the growth surface and generate a small set of guide curves that carry the overall flow.
- Distribution — interpolate the full set of hairs from the guides, controlling density and length.
- Clumping and break-up — group hairs into clumps and add noise so the groom does not read as a uniform sheet.
- Sculpting — hand-adjust the guides, or paint overrides where the procedural result is not quite right.
- Shading — assign the procedural shading network and tune colour variation along the strands.
- Cache and publish — write the result as a versioned groom stage attached to the character.
Where grooming fits in the shot
A groom is an asset, and like every asset it should be referenced rather than copied. The table below shows how the grooming stage interacts with the rest of a shot pipeline.
| Stage | What the groom provides | What the shot provides |
|---|---|---|
| Character build | Growth surface, base groom graph | Nothing |
| Animation | Static or dynamic groom definition | Motion for the deforming surface |
| Simulation | Guide curves and clump structure | Wind, collision and dynamics settings |
| Lighting | Procedural shading network | Lights and render settings |
| Rendering | Curve primitives and shaders | Sampling and motion blur |
Separating the groom from the shot in this way is what allows one character's hair to be lit in twenty shots without twenty copies of the groom drifting apart.
Practical rules that keep grooms manageable
Three habits separate a groom that survives a production from one that has to be rebuilt. First, keep the guide count low and the intent clear — guides are the interface, not a place to hide detail. Second, use the sculpting tools for the handful of places that need a human decision, and let the graph do the rest. Third, publish early and often, because a groom that only exists on one artist's machine is one crash away from being lost.
Dynamics, collisions and caching
A groom that looks right in a still frame still has to move. Hair dynamics adds a simulation stage on top of the groom: the guides become the simulated elements, and the thousands of interpolated hairs follow them. Simulating guides rather than every strand keeps the cost proportional to the groom's complexity rather than to its density.
Collisions matter just as much as motion. Hair that passes through a shoulder or a costume piece reads as a mistake no matter how good the shading is, so collision surfaces are prepared early and kept simple. Caching the result before lighting also pays for itself, because a cache that is fixed for the shot means the lighting team never re-runs the simulation to change a light.
Keeping grooms consistent across a show
A character appears in many shots, and the groom has to stay recognisably the same one throughout. The practical way to guarantee that is to treat the groom as a published asset with versions, exactly like the model. Shots reference a published version rather than holding their own copy, and a later improvement to the groom is a new version that shots can adopt at a controlled moment rather than a surprise mid-render.
Versioning also makes it possible to answer the question every supervisor eventually asks: why does this character's hair look different in shot twelve? With a referenced, versioned groom the answer is a single line in the shot's layer, not an afternoon of diffing files.
None of this makes hair easy. It does make hair predictable, and in a pipeline that runs for years, predictable is the quality that matters most.