A housing authority inspector needs a temporary inspection color on one instanced kitchenette. Which strategy marks that unit while keeping the other units instanced?
Select an answer to reveal the explanation.
Short Explanation
Instance proxies are read-only, so you can't paint one kitchenette through its proxy. Turn instanceable off for just that unit in an inspection layer and color it there; every other unit keeps sharing the prototype.
Full Explanation
Housing-authority kitchenette packs are repeated across units as instanceable components so a tower twin stays memory-efficient and easy to update. Per the OpenUSD scenegraph instancing documentation, scene description cannot be edited through instance proxies or on descendants beneath an instance, so a color cannot be authored on one kitchenette's proxy. The instanceable flag is ordinary metadata that a stronger layer can override, so the right move is to set instanceable to false on that single kitchenette in a clearly named inspection override layer and author the temporary color on its now-editable prims. Every other unit still shares the prototype, and removing the inspection layer restores the unit to an instance.
Duplicating the kitchenette file for every unit and painting the duplicate abandons sharing at scale and multiplies maintenance. Authoring the color on the prototype paints every unit, the opposite of a single-unit mark. Deleting instanceable metadata and promoting every unit to a unique reference deinstances the whole tower for a temporary color, failing both performance and governance goals.
Exam caveat: only the one marked prim leaves instancing; the cost is small and the change is reversible because it lives in its own layer.
Operational check: confirm the marked unit composes with the inspection color, verify the other units are still instance prims sharing one prototype, and check that clearing the inspection layer leaves no residual unique opinions.