When setting up a UsdGeomPointInstancer with prototypes defined under an over specified prim (a structure suggested by the docs), the bounding box computed by the registered ComputExtents plugin does not correctly compute prototype bounding boxes. Similar to #1436 which fixed this issue for the usdImaging adapter, I think the compute extents plugin should be updated to allow traversal of prototypes that are under an over.
Steps to Reproduce
Save the following into a pointinstancer_extents.usda layer
2. Open the layer, compute the bbox, see that the bbox is infinite
```python
from pxr import Sdf, Usd, UsdGeom
stage = Usd.Stage.Open('pointinstancer_extents.usda')
prim = stage.GetPrimAtPath('/instancer')
bboxCache = UsdGeom.BBoxCache(1.0, ['default', 'render'])
print(bboxCache.ComputeLocalBound(prim)
Set the Prototypes prim to SpecifierDef and compute the bbox again, see the result is now as expected
There's some workarounds for this that resolve the problem. You can make sure the prototypes are actually defined by defining the Prototypes parent. You can make sure there is extents authored on your UsdGeomPointInstancer prim. But it would be nice if the ComputeExtents plugin supported this suggested workflow without the need for these workarounds.
System Information (OS, Hardware)
Linux (AMD Ryzen 5 2600, NVIDIA GTX 1060)
Usd v24.11
Description of Issue
When setting up a UsdGeomPointInstancer with prototypes defined under an over specified prim (a structure suggested by the docs), the bounding box computed by the registered ComputExtents plugin does not correctly compute prototype bounding boxes. Similar to #1436 which fixed this issue for the usdImaging adapter, I think the compute extents plugin should be updated to allow traversal of prototypes that are under an over.
Steps to Reproduce
pointinstancer_extents.usda
layerdef PointInstancer "instancer" { rel prototypes = [</instancer/Prototypes/sphere>] int[] protoIndices = [0, 0, 0, 0] point3f[] positions = [(2, 0, 2), (2, 0, -2), (-2, 0, 2), (-2, 0, -2)]
}
Workarounds
There's some workarounds for this that resolve the problem. You can make sure the prototypes are actually defined by defining the Prototypes parent. You can make sure there is extents authored on your UsdGeomPointInstancer prim. But it would be nice if the ComputeExtents plugin supported this suggested workflow without the need for these workarounds.
System Information (OS, Hardware)
Linux (AMD Ryzen 5 2600, NVIDIA GTX 1060) Usd v24.11