# \`PointInstancer\` Prototype Scope Best Practices

**URL:** <https://forum.aousd.org/t/pointinstancer-prototype-scope-best-practices/2662>\
**Category:** USD\
**Created:** [August 28, 2025, 8:02pm UTC](https://forum.aousd.org/t/pointinstancer-prototype-scope-best-practices/2662 "2025-08-28T20:02:11Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![nvmkuruc](https://avatars.discourse-cdn.com/v4/letter/n/76d3ee/32.png) [@nvmkuruc](https://forum.aousd.org/u/nvmkuruc)\
**Post date:** [September 22, 2025, 1:57pm UTC](https://forum.aousd.org/t/pointinstancer-prototype-scope-best-practices/2662/3 "2025-09-22T13:57:03Z")

</div>

Thanks Spiff for the thoughts. I think we’d be happy to contribute a PR.

Regarding the cleanup example, I think you could imagine different users might have different perspectives on what they might consider cruft. Consider the following spec tree authored on the root layer with `Asset_1` being originally introduced (concretely defined) on a sub layer

```auto
over "Asset_1"
{
   over "Geometry" (append apiSchemas = "MaterialBindingAPI")
   {
       rel material:binding = <../Materials/OverrideMaterial> (materialBindingStrength = "strongerThanDescendants")
   }
   over "Materials"
   {
       def Material "OverrideMaterial" (references = @material_library.usd@</metal>)
       {
       }
   }
}

```

It defines a new material and overrides the material binding on the geometry scope. Were `Asset_1` to be removed on the sublayer, you could imagine wanting a helper available to remove the entire `Asset_1` spec tree on the root layer, even though it contains a concretely defining specifier as a leaf.

---

_[View the full topic](https://forum.aousd.org/t/pointinstancer-prototype-scope-best-practices/2662)._