Roy Nieterau

> We could of course edit the exported USD file after its come out of Houdini, just with the USD api completely outside houdini, but this adds extra process time on our farm as it has to spin up new boxes to do this etc (thats a whole other problem I won't get into here)

With what you're trying to do it may be worth it to implement a custom Output Processor perhaps?

Having access to an editable stage from a node - outside of a context that is actually inside the Houdini graph makes little sense, because you'll basically end up altering the in-memory USD stage even though it's not actually a 'change' occurring from Houdini's computational graph. As such, you've then somehow altered the USD stage in memory without it being done by what Houdini produced. An edit that will 1) be confusing because suddenly you may see something in Houdini that it doesn't actually evaluate to and 2) as soon as the graph re-evaluates it will be lost.

I'm unsure why in particular you're trying to do "stage edits" that wouldn't then 'persist' inside of Houdini since as soon as the graph would re-evaluate your change would be immediately lost as Houdini has now generated the full USD stage. As such, this makes me think you're using this for some temporary export process that does not go through a regular Houdini ROP?

Overall you're best off generating a Houdini graph that makes the edits you want, which can be just a heavy Python LOP calling a function from your pipeline - if you want to end up still using that data inside of Houdini.

If not, then likely you may want to do `LopNode.stage()` instead of calling `LopNode.editableStage()` so that you can access the stage. Then technically if you do want a completely managed 'local' version of the stage you'd need to remap all Sdf Layers to copies of your own so you're still not touching any managed by Houdini itself.

Making such an in-memory copy can be done similar to this: https://github.com/ynput/ayon-houdini/blob/3fcb1641d60e72725d684c0a9d7910c341da6485/client/ayon_houdini/plugins/publish/collect_usd_rop_layer_and_stage.py#L158-L175. [github.com]

Be aware though that technically there I'm making anonymous copies which may mean that any 'relative asset paths' may not end up evaluating to what you'd expect because technically those anonymous layers are not anchored on disk.

I'm sure there must be better ways to do this - so I'm all ears.

I know this is an old thread - but did there actually end up being a reason to have no Object Merge equivalent in Copernicus?