I'm looking for a quick clarification on what are legal attribute / primvar names. I've seen some are namespaced, which would imply that I can, for example, use a colon in the name, like this: “foo:bar”. But could I also do this: “foo.bar”? I'm not sure where to find this in the USD documentation so if anyone has a pointer I'd appreciate it.

Cheers,
Jon

Really, an attribute name can have only alphanumeric characters plus an underscore. SdfPath has a few static functions for testing that. Eg, IsValidIdentifier()
http://graphics.pixar.com/usd/docs/api/class_sdf_path.html#a1499271167c20dd276d87693b18f5226 [graphics.pixar.com]
http://graphics.pixar.com/usd/docs/api/group__group__tf___string.html#gaa129b294af3f68d01477d430b70d40c8 [graphics.pixar.com]

It's true however, that an attribute can be namespaced, using a colon as namespace separator. Eg, IsValidNamespacedIdentifier()
http://graphics.pixar.com/usd/docs/api/class_sdf_path.html#a8c66a8d5eadec9b49cd9a5f32747834e [graphics.pixar.com]

USD uses dot as a marker for some special cases, like connectivity of the shader input attributes. And you cannot use it in the attribute name itself.

Nice, thanks! That's what I was looking for.

I'm still getting my head around everything, but might it also make sense to wrap related attributes into a new USD schema, or am I talking nonsense when I say that?

USD allows defining custom schemas, so indeed you can group related attributes into a new schema that can be applied to a USD primitive (or define a new primitive type altogether). It can be handy. Just keep in mind that if you write out a USD file and you want to read it in another package on another machine, your custom schema needs to be also installed there, so that the loading package can properly recongnize it and find out the info about these related attributes (eg, variability, fallback value, etc).

http://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-Schema [graphics.pixar.com]
http://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-APISchema [graphics.pixar.com]

Thanks for that. What I have in mind are attributes that aid in some tools I'm working on for Solaris, and potentially other applications at some point. However, like the custom Houdini data attached in LOPs, once a USD is released into the wild the attributes don't really serve any useful purpose anyways, so it's theoretically harmless to not have the schema installed.

So something related to this…

My attributes define some traits, that can then be used by another custom OTL node at any point in the node tree, to modify the transform. In the OTL I use a primitive pattern to check for the attributes before doing the necessary work… but I'm using the VEX expression in the primitive pattern parameter: .

It's REALLY slow. Would a schema allow me to speed this up in some way, or is there an easy way to speed this up? The tree I'm working with now is only about 9 primitives, but the performance hit is BY far the largest cook time in the node graph.

Cheers,
Jon

Are you using 18.0 or 18.5? There were significant performance improvements to pattern matching in 18.5, though with only 9 prims in your scene graph I can't imagine either version taking any measurable amount of time to run that query…

In a simple test (using the kitchen set in 18.5), `{ usd_isattrib(0, @primpath, “primvars:displayColor”) }` takes 0.17s, and `/Kitchen_set/Props*/Dining*/Table*/Cereal*/Cheerios** & { usd_isattrib(0, @primpath, “primvars:displayColor”) }` (to limit the number of prims that run the VEX code) takes 0.11s. Just running `/Kitchen_set/Props*/Dining*/Table*/Cereal*/Cheerios**` takes 0.003s. So there's definitely some (relatively) significant overhead in setting up the VEX expression, which is probably independent of the number of prims. Is this roughly the kind of times you are seeing?

Houdini 18.5.

That looks about right, actually. I noticed the performance hit during animation playback. The primitive resolution is being calculated for every frame and that is enough to take out real-time performance. Would equivalent Hscript expressions make this faster?

If the set of prims matching that pattern isn't time varying, you could create a collection further up the node graph (above any time-dependent nodes) that contains all the prims you are interested in, and then just reference that collection in later LOPs. If the set of prims is varying over time (which would be weird because attributes can't actually get created and disappear over time in an animated USD file) then I don't have any good thoughts.

The prim hierarchy shouldn't be changing over time. As a matter of fact I do have a collection being generated for each group of prims that I modify. It's always in the “/collections” node as well. However, some get grafted into another tree, so there could end up being a collection at “/root/tree/collections”, for example, as well as a root “/collections”. Do the prim matching patterns let me grab multiple collections at once? For example:
Cheers,
Jon

Yes, though I think the format there is wrong. `collection.SPICE` isn't the name of the “SPICE” collection attribute. So you could either do:
or

The latter approach uses the “%” to indicate a collection, which causes the last component of the path to be interpreted as a collection name. But using the “%” prefix also implies that you want to confine the path traversal to “/collections”, unless the provided path is absolute. So for this kind of traversal, the first approach (similar to the one you suggested) might be the clearest syntax.

Doing this kind of wildcard-based search for collections is going to require a traversal of the stage, so there will definitely be a performace penalty relative to having all your collections in one place, but the time required should be a lot smaller than initializing the VEXpression evaluation (at least until your scene graph becomes extremely large).

Ah great! I knew it was wrong, but not how exactly as it was from my memory…

It sounds like you're implying that the VEX approach could be better once the hierarchy grows to a size large enough to justify the up-front cost of moving data into VEX. I'll see if the pure collections-only approach works to improve performance.

I can't help but follow up with another question. In SOP networks, I can use a timeshift SOP to do things that are time invariant by just setting it to a single frame, even if upstream nodes are time-varying. Is there any way to do this in LOP networks?

Thanks for all the info here, it's been quite insightful!

-Jon

I'm just going to wait a few minutes before I answer this one…

.
.
.
.
.
.
.

Okay, try the Timeshift LOP

Aargh… thank you. D'oh!