Hello,
As I continue my experiments with open exec. I thought of using the UsdCollectionApi with OpenExec. The goal was to get the prims in the collection’s paths and query some properties in them.
I saw there was a “Stage()” method, but the examples only showed a way to get the time.
Is it possible to get other prims in the stage from within the OpenExec lambda? Or do I have to get those before creating the request?
Hi @barbalt.
I think what you’re trying to do here is budding up against the limits of what is possible in this early version of OpenExec. I’ll give more details below.
First off, to answer your question about quasi random access of prims and properties on the stage from within an exec callback: No, this is not something that callbacks can do.
From an architectural point of view, OpenExec needs input dependencies be declared a priori (as part of the Inputs() in the computation registration). New input dependencies cannot be expressed dynamically from within the callback. This is necessary for OpenExec to build and maintain its data-flow network under the hood, and the topology of this network cannot depend on callback code.
Having said that, you can definitely declare input dependencies on prims or properties that are “pointed to” through relationship targets or attribute connections! If the composed targets change by editing the scene, OpenExec will automatically update those dependencies for you. For example, take a look at the Relationship(relName).TargetedObjects<T>(computationName) and Attribute(attrName).ConnectionTargetedObjects<T>(computationName). These inputs will provide the result(s) of the computationName computation on all the scene object(s) pointed to via the relationship target / connection on relName/attrName respectively. If there are multiple relationship targets / connections, pointing to multiple scene objects, you will get one value for each object providing the computationName computation. In the callback, you can use an instance of VdfReadIterator<T> to access the values.
For relationships specifically, this type of input will also forward through intermediate relationships. For example:
relationshipA ──→ relationshipB ──┬──→ primFoo
|
└──→ primBar
In this situation Relationship("relationshipA").TargetedObjects<T>(computationName) will give you the results of computationName on both the terminally targeted objects primFoo and primBar. This mechanism allows you to build powerful interfaces, with implementation details hidden behind relationshipB.
You can also forward through an arbitrary number of relationships: You’re not limited to just one intermediary.
Where you are reaching the limits of the current OpenExec implementation is that UsdCollectionAPI isn’t yet integrated natively. OpenExec doesn’t know anything about how collections work. While you can certainly use the relationship forwarding mechanism above to point a relationship target at the built-in includes relationship, and declare input dependencies on computations included with an instance of UsdCollectionAPI, you won’t see the excludes semantics take effect. Expression-mode collections are a whole different beast that’s not currently integrated into OpenExec in the way that you would expect.
Hope this helps. Let us know if you have further questions.
Hi @florianz ,
This is great! I couldn’t find reference to the ConnectionTargetedObjects (probably because I’m still on 25.08). However, I’ve managed to accomplish what I wanted with the TargetedObjects though.
I was able to add prims to a collection and pass their position to the request through a secondary callback.
Thanks once again for the fast response!