Can I reference inactive prims?xpe

Community USD
1

I expected I would not be able to reference inactive prims, and this test case actually came about accidentally.
In the following, I have a scene and a library. In the library, I have a sphere that I reference into the scene. Then I or someone accidentally pruned/deactivated the library.
My understanding was that the descendants of a deactivated prim(library) don’t get traversed. So I expected the Local/Layer opinion of “active=false” to be evaluated first, so the stage effectively wouldn’t have the library prim or anything below it. Then I thought the Reference in the scene to basically be invalid. But in Houdini, I see my sphere. In my real scene where the accident happened, it also rendered fine - i.e. referencing a descendant of a deactivated prim.
How/why is this reference still working?

#usda 1.0
(
    endTimeCode = 1001
    framesPerSecond = 24
    metersPerUnit = 1
    startTimeCode = 1001
    timeCodesPerSecond = 24
    upAxis = "Y"
)

def Xform "a"
{
    def Xform "scene"
    {
        def Xform "b"
        {
            def Xform "c"
            {
                def "ref_sphere" (
                    prepend references = </a/library/d/e>
                )
                {
                }
            }
        }
    }

    def Scope "library" (
        active = false
    )
    {
        def Xform "d"
        {
            def Xform "e"
            {
                def Sphere "my_sphere"
                {
                    float3[] extent = [(-1, -1, -1), (1, 1, 1)]
                    double radius = 1
                    matrix4d xformOp:transform = ( (1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (0, 0, 0, 1) )
                    uniform token[] xformOpOrder = ["xformOp:transform"]
                }
            }
        }
    }
}
2

Hi @SteveHwan ,
What you’re seeing is expected, and actually quite useful! If you’re willing to join the (now closed, but still open to membership) usd-interest google group, here are a couple of posts (one, two) that show scenarios where this way of constructing scenes is quite handy, by allowing you to organize but “remove” common source descriptions from a scene, while still enabling the consuming parts of the scene to compose them in where needed.
More similar to your situation is creating a root prim and deactivating it, and then referencing in many models beneath it, adding overrides to them, potentially, and then building a scene that references </Prototypes/ModelA> etc to create native instances.

The reason this works and is expected to work is that active is actually a directive about “stage population” that is relevant only to a UsdStage in its quest to decide what “top level” prims should be present on the stage, whereas references and other composition arcs are consumed by the (lower level) “composition engine” that does not know or care anything about active. THe distinction between “composition” and “population” is subtle, and definitely an “intermediate” level USD aspect. UsdLoadPolicy and “stage masking” are other aspects of stage population management, which you can think about as "various techniques for allowing users and scene authors (in the case of activation) to create manageable ‘working sets’ as filters on top of highly complex scenes created using the lower-level composition features*.

–spiff

* … or not - it’s not necessary to use composition arcs to create ridiculously complex scenes, but if you don’t use them then you are missing out on some of USD’s best scalability and collaborative workflow features, so they’d be even more ridiculous :slight_smile:

1 Like