Hi,

I'm doing some work at the moment to try and get Solaris rendering on our farm. What would the suggested approach be for this?

I had been thinking along the lines of:
- Write flattened usd of loaded stage
- Render with husk on the farm

I have been hitting some issues about how to handle layer breaks when writing the USD file to be rendered. The usdrender_rop seems to ignore layer breaks when it generates the temp USD files that it then renders through husk, which seems desirable in this case. Is there a way of configuring the usd_rop to behave in the same way, or is it a matter of bypassing any layer breaks whilst writing the render USD?

Is there a better way of going about this?

Cheers,

Jon

I do not recall writing any code, nor do I see any code that indicates that the USD Render ROP does anything special related to Layer Breaks. Which doesn't mean it isn't, but if you could provide a sample file that would help…

Also the USD Render ROP does the equivalent of “flatten all layers”, not “flatten stage”. Flatten stage is going to make enormous files by bringing all referenced data into the one uber-file. This is useful if your farm machines don't have access to the same network paths as the machines authoring the USD. Or if you are worried about the referenced content changing (and you don't have a versioning system in place). But if you have a common set of shared paths, and aren't worried about the referenced files being changed unexpectedly before the render happens, I'd recommend using “flatten all layers” to keep the USD files smaller.

Thanks for the reply and clarifying the type of flatten that takes place with the USD Render, that makes sense.

I've attached am example that hopefully explains my question regarding layer breaks a bit. In this example the usd file produced by the usd render rop (the one that gets written to $HOUDINI_TEMP) includes the parts of the stage before the layer break, so that everything is rendered as expected, where as writing using a usd rop doesn't include anything before the layer break.

It seems that there are two options open to produce a usd file of the whole scene that can then be rendered on the farm using husk:
- Use usd_render to submit to farm (by using an alternative Render Command to husk), during which the temp usd files created are copied to somewhere available on the farm.
- Use usd_rop to generate a usd file which gets submitted to the farm and again rendered by husk (ie. “write_render_usd” in my example). In this case, we would need to bypass the layer break (programmatic or otherwise) in order to capture the entire working scene and pass it on to husk.

Not sure if that workflow makes sense? I'm leaning towards the second of the two options above, but was hoping there might be a better way of handling the layer break rather than adding a step to bypass it to the submission process.

Sorry if I'm missing something really obvious, still getting up to speed with LOPs.

Thanks again,

Jon

Ah yes, now I see where that is happening… At the moment there is nothing you can do to make one behave like the other other than, as you suggest, bypassing all the lay break LOPs. You can RMB on your layer break nodes, and under Parameters and Channels choose “Create Activation Parameter”. Then in that activation parameter use a context option expression (@saving==0). Set “saving = 0” as a global context option, then on your USD ROP add a context option value of “saving = 1”, which should deactivate the layer breaks during the save to disk.

But that seems like it should be unnecessary. I'll talk to some people here. Probably the USD ROP should just have a checkbox to ignore layer breaks…

Also, I think option 2 definitely makes the most sense. The USD ROP gives you the most control over how and where your USD gets authored (aside from this layer break issue). And even if you don't need that control right now, I suspect at some point you will…

FWIW, I ran into this exact same issue just the other day and was meaning to talk to you (Mark) about it. I would almost consider we may want to set the default to default ignore Layer Breaks for the sake of consistent behaviour? (I was attempting to render USD from a light-rig section.)

Why are there layer breaks in the graph in the first place? Isn't the idea of a layer break that the layer will go back over another layer at some point? Maybe the usdrender should be fixed so that it doesn't ‘ignore’ the layer break and require layering over the root layer before rendering?

I'm with jsmack Why would you have Layer Breaks other than to restrict what data is written out by a USD ROP? There are cases where you branch from a node with a layer break on one branch (such as in for each loops, or add variant operations), but in my experience you would always merge those branches back together before reaching the USD ROP, meaning the operation of the ROP is unaffected by the Layer Break.

As in the hip file posted above you may have a layer break so that you can _choose_ to write out the post-break USD to a separate file while also wanting to be able to do renders of the fully composed scene. If the default was to write out the fully composed scene, that would be saying that by default layer breaks should do nothing, which seems weird… USD Render ignores layer breaks by default so that WYSIWYG when comparing to the viewport. Though maybe USD Render also needs a toggle to apply layer breaks instead of ignoring them…

mtucker
Why would you have Layer Breaks other than to restrict what data is written out by a USD ROP?

In our (admittedly high WIP) template, we place a layer break in start of the Lighting section to do add convenience around writing out USD light-rigs. When I bumped into the issue, I was trying to debug something by writing out the flattened stage at various points. I was surprised I wasn't able to get a full flattened stage at some point downstream and found myself needing to search up the graph for the Layer Break causing the issue.

That's basically the same way we are making use of layer breaks - in order to write out only the changes made by the current dept - ie. a light rig, or an FX layer.

I would have thought that the only time you would want to ignore layer breaks would be when rendering the current working scene. Currently the only easy way to do that is to use the usd render rop or to bypass the layer break. I think it would be useful to be able to output the scene in that state without doing that though, maybe a toggle on the usd rop (default to obey layer breaks obviously).

I guess the alternative to this is to always layer back over the root layer before rendering, but I'm not sure that is ideal as it's not as convenient as being able to easily drop down a farm render hda at which ever point in the graph a render is required (the same as you would with the usd render rop for local renders).

Thanks everyone. I'm fully convinced now that there needs to be a check box (on both the USD and USD Render ROPs) to control the behavior around Layer Breaks. I think the only question is what the defaults should be. Unless there is a strong argument against it, I would leave the defaults such that current behavior is preserved (strip layers for the USD ROP, don't strip layers for USD Render)…

mtucker
Thanks everyone. I'm fully convinced now that there needs to be a check box (on both the USD and USD Render ROPs) to control the behavior around Layer Breaks. I think the only question is what the defaults should be. Unless there is a strong argument against it, I would leave the defaults such that current behavior is preserved (strip layers for the USD ROP, don't strip layers for USD Render)…

Sounds most prudent to me.

mtucker
Thanks everyone. I'm fully convinced now that there needs to be a check box (on both the USD and USD Render ROPs) to control the behavior around Layer Breaks. I think the only question is what the defaults should be. Unless there is a strong argument against it, I would leave the defaults such that current behavior is preserved (strip layers for the USD ROP, don't strip layers for USD Render)…

Sounds like a good idea to me - I agree the defaults should mirror the current behaviour. Thanks!

Fixed in 18.5.265.