PointInstancer Object Model

Introduction

Several years prior to developing general scene-level instancing in USD, at Pixar we were using a specialized point/array/table instancer consisting of a schema, optimized drawing support in Hydra, and plugin support in Katana (read only), Houdini, Presto, and Maya (export only). Today, even though scene-level instancing is broadly deployed in our pipeline, there are still scalability use cases for a vectorized instancer over having many prim-instances: when the number of instances grows to the tens or hundreds of thousands or more (largest instancer to-date in production had around nine million instances) and the need to interact with individual instances is small, an instancer will load faster and consume less memory than individual prim-instances.

Our Houdini plugins rely on pointInstancers as they map so closely to Houdini's instancing model; therefore to enable open-sourcing of those plugins, we are reformulating our internal pointInstancer - mostly simplifying, plus applying some lessons learned from earlier versions - for inclusion in UsdGeom.

This document attempts to define the motivation and expected behaviors for the PointInstancer schema, then provide the details of the schema itself, and finally discuss the kinds of integration we expect to provide in DCC plugins.

PointInstancer Behaviors

The proposed PointInstancer schema is very similar to Houdini's point instancing scheme, with a few simplifications in terms of specifying the per-instance transforms, and a few extra features designed to meet the needs of migrating this kind of data down a CG pipeline. The PointInstancer schema must meet the needs of our sets/environments department, and the needs of our FX department.

Sets Department Needs

The sets department relies on PointInstancers for dressing large numbers of simple and complex geometries, typically in the tens to hundreds of thousands of instances of one to tens of "prototypes". Some examples:

• The leaves in the canopy of a deciduous tree
• Rocks or other debris scattered on a landscape
• Fields and crops of vegetation/shrubs
• Forests

The requirements deriving from these needs, beyond the most basic, that the encoding (and decoding of it) must scale, are:

• Prototypes must be animatable - which means that if the sources for the prototypes on the UsdStage have timeSampled animation, it will be honored. This allows us to apply "keep alive" or simulated, wind-driven motion to trees and other vegetation scattered in PointInstancers.
• PointInstancer prototypes can themselves contain PointInstancers - or stated more broadly, there is no restriction on what geometry a prototype can contain, or limit to its complexity. In the forest example, we are PointInstancing trees, each of which may have one or more PointInstancers as part of its own geometry. For added scalability, typically each prototype itself will be a native, scene-level instance. This took several iterations to get working properly in Hydra and Katana, but now does, with the internal version of this proposed schema.
• Must be able to sparsely 'promote' instances - typically an environment will be liad out and referenced into sequences prior to knowing where action will take place. Often, some number of PointInstancer-dressed models must interact with characters, which is difficult. Therefore, we must facilitate "promoting" an instance into full, hero geometry that can be collided against, deformed, etc. To facilitate this, the schema must minimally provide a means of sparsely pruning out certain, identified instances without needing to re-author all of the vectorized transformation-related attributes and primvars.