Seeking clarifications on property node handling in USD's SdfPath

Community USD
1

Hello everyone,

I’ve been delving into the USD framework and came across something in the SdfPath implementation that I find a bit puzzling, specifically regarding how property paths are handled. I’m hoping to get some insights or clarifications.

In the Sdf_PathNode::FindOrCreatePrimProperty function, there’s a comment that says:

Sdf_PathPropNodeHandle
Sdf_PathNode::FindOrCreatePrimProperty(Sdf_PathNode const *parent, 
                                       const TfToken &name,
                                       TfFunctionRef<bool ()> isValid)
{
    // NOTE!  We explicitly set the parent to null here in order to create a
    // separate prefix tree for property-like paths.

    return _FindOrCreate<Sdf_PrimPropertyPathNode>(
        *_primPropertyNodes, isValid, nullptr, name);
}.

This implies that property nodes are created with a null parent, which makes sense considering SdfPath comprises a primitive part and a property part. The property part doesn’t need a separate parent since it’s associated with the primitive part. This would mean that in the pool for property nodes, a property like .color is stored once, irrespective of its usage across different primitives.

However, I’m a bit confused about how this aligns with the _WriteTextToBuffer method, which is used for generating string representations of paths:

// in Sdf_PathNode::_WriteTextToBuffer
Sdf_PathNode const *curNode = propPart;
while (curNode) {
    curNode->_WriteText(out);
    curNode = curNode->GetParentNode();
}

Given that property nodes are supposedly created with null parents, how does this loop iterate more than once? Does this indicate that a property node can indeed have a parent? Or is there something I’m missing in how _WriteTextToBuffer functions?

Additionally, I’m curious about the possibility of nested property structures like /path/to/prim.color.r, where both color and r are properties. Is such a hierarchy feasible within USD’s path structure?

Thank you -ms

2

Hi Mark – property paths can also have child path nodes, one example of that is a target path: /foo.prop[/target/path]. Here the prim part would be /foo and the property part would be the [/target/path] child of .prop.

SdfPath (and USD) don’t support nested properties, but they do support namespaced properties. These are represented in SdfPath with : delimiters, like /path/to/prim.color:red. In the current implementation of SdfPath these are just represented as property names with embedded :. So in that previous example the prim part would be the /path/to/prim node and the prop part would be the single property node color:red.

1 Like
3

Thank you Alex for the insight.

I’ve come across references to target path in the code but haven’t had the opportunity to explore it in-depth yet. Your explanation helped clarify how it functions, which I can now understand from the code.

It’s impressive to see people like you with such a deep understanding of this rather large codebase. I’m grateful for having quick and informative responses.

1 Like