Roy Nieterau

Whenever you enable a slap comp for a USD Render ROP and have it configured to "COP node" it will write out a .bgeo.sc of the slap comp network to apply to the render. This file will be auto-generated by the USD Render ROP.

How can I find out what path that file will end up at?

I'm getting files like

It seems to generate them with a `_slapcomp_{id}.bgeo.sc` suffix where the id is a three character unique identifier. But how can I consistently know what the filename should be?

In short, how do know what .bgeo.sc path that file will be generated at so I can pass it in my custom submission to a Deadline job for Husk Standalone.

Apparently this logic all exists in libROP.dll or at least it contains the error texts for "Unable to create APEX program" from exactly that hardcoded suffix.

---

Side note: This documentation page [www.sidefx.com] describes husk argument --slapcomp, but it should be --slap-comp. It's correct on the Husk command line [www.sidefx.com] page however.

> 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.