Possible bug when evaluating light linking collection when includeRoot attribute is blocked

Community USD
1

Hello!

I’m trying to compute light linking members after blocking the collection:lightLink:includeRoot attribute. As the fallback value for this attribute is True, I am expecting the collection to be in relationship-mode and thus ignore membershipExpression attribute value if set which is not what I see after running below snippet.

from pxr import Usd, UsdGeom, Sdf
stage = Usd.Stage.CreateInMemory()
sphere = UsdGeom.Sphere.Define(stage, "/sphere")
light_prim = stage.DefinePrim("/lights/light", "DiskLight")
lp_ll_coll = Usd.CollectionAPI.Apply(light_prim, "lightLink")
include_root = lp_ll_coll.GetIncludeRootAttr()
include_root.Get()
# None
include_root.Block()
mem_expr = lp_ll_coll.GetMembershipExpressionAttr()
mem_expr.Set(Sdf.PathExpression("/sphere"))
mquery = lp_ll_coll.ComputeMembershipQuery()
Usd.CollectionAPI.ComputeIncludedObjects(mquery, stage)
# [Usd.Prim(</sphere>)]

Is this a bug or am I using the wrong API to compute collection membership?

2

Per UsdAttribute documentation, an attribute that has been blocked is considered to be unauthored, and the membership computation considers relationship mode active only if one of the related rels/attrs is authored. We’ve come to realize this is not a great state of afairs, and we have an enhancement lined up (that should be backwards compatible) that will allow youtomake a CollectionAPI be explicitly one or the other mode, regardless of what properties have been authored. I don’t have a release data for that enhancement, though. I think that if instead of blocking the includeRoot you explicitly author it to true, you should get the behavior you’re looking for?