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.