A city twin needs thousands of identical streetlights across downtown. Which instancing style best fits that scale?
Select an answer to reveal the explanation.
Short Explanation
Thousands of the same lamppost? That’s a stamp-and-scatter job, not a unique sculpture for each block. Point instancing reuses one prototype and places many instances cheaply. Full unique copies or custom-schema tricks blow up memory for no civic gain.
Full Explanation
At downtown city scale, thousands of identical streetlights are a classic mass-instancing problem. The twin should use a pointInstancer (or equivalent mass instancing) with one streetlight prototype for the dense identical set. Point instancing reuses prototype geometry and materials across many instance transforms, keeping memory and composition cost appropriate for dense municipal props while still placing lights along streets from instance data.
Duplicating unique full scenegraph copies of each streetlight with no instancing fails by concept: unique copies explode memory and I/O for no uniqueness benefit when assets are identical. Storing each light as a separate muted sublayer so they load one at a time fails because per-light muted sublayers are not an instancing strategy—they add layer-management overhead without prototype reuse and misuse mute as a substitute for scale design. Encoding every light as a custom schema attribute on the root prim only fails because attributes on the root do not replace instanced geometry/lighting hierarchies and invent a non-standard civic encoding that tooling will not treat as streetlight instances.
Exam caveat: choose point (or mass) instancing for dense identical civic props; native unique copies are for sparse uniqueness. Operational check: after authoring one prototype and a pointInstancer for downtown lights, measure stage open cost and prototype count (expect one prototype, many instances), spot-render a block to confirm lights appear, and confirm editing the prototype updates all instances as intended.