I’m trying to compute the membership of a collection. I do not care if it’s relationship or expression mode. I just want to give it a stage and get the list of paths (or prims) that the collection will contain.
Now, from the API documentation, I would have guessed that calling ComputeMembershipQuery
to create a query followed by a call to ComputeIncludedPaths
would do the trick. The code I’m using is:
def computeMembership(self):
query = self._collection.ComputeMembershipQuery()
if not query:
return []
return Usd.CollectionAPI.ComputeIncludedPaths(query, self._prim.GetStage())
Turns out, it almost, but not quite work. Now I don’t know if this is normal or is a bug. I’m using USD 23.11. The problem is:
- If the collection is a pure expression, then it works.
- If the collection is a pure relationships, then it works.
- If the collection contains both relationships (include/exclude) and an expression… the expression wins.
The last case is entirely opposite of what the documentation claims. The documentation says that if both an expression and relationships are used, the expression should be ignored.
The stage contains three planes named “/Plane1”, “/Plane2” and “/Plane3”. The light linking collection looks like this:
def DiskLight "DiskLight1"
{
prepend rel collection:lightLink:excludes = </Plane2>
uniform bool collection:lightLink:includeRoot = 0
prepend rel collection:lightLink:includes = </Plane3>
uniform pathExpression collection:lightLink:membershipExpression = "/P*"
// ...
Is the fact that ComputeMembershipQuery
+ ComputeIncludedPaths
fails in mixed mode a bug?
PS: I tested with USD 24.11 too and got the same results.
PPS: I suppose I’m more interested in knowing if USD internal behavior in respect to membership would follow the same bug or not. On some level, if this behavior matches what USD also does internally, then I’m OK with it, we just want to reflect how the collection will work, even if the collection does not respect its own documentation.