I'm trying to combine branches of a graph with save paths set so that a sublayer arc is used. I want the trunk to be saved to the main file specified in the rop, however. I'm seeing odd behavior where the first sublayer includes everything in the trunk instead of just the branch to be sublayered. Changing the sublayer position parameter to weakest produces the partition I want, but I don't want the strength of the layering to be changed, just the partitioning.

For example, I create a sphere, and sublayer a camera with save path set. The output main usd is just: “sublayer camera.usd”, and camera.usd contains the sphere and the camera. I wouldn't expect sublayer position to have any bearing on this arrangement. What I expect is: left input of sublayer goes in main stream, right input goes into sublayer file. There's no ambiguity about it. Before using the sublayer I was using a merge, and I expected the save path and ‘start new layer’ option to also produce my desired result. Strangely, sometimes it does, such as when I merge in a third layer.

If I rearrange the inputs to the merge so that the items I want in the trunk are merged last, it outputs the files as I expect, but this is the opposite of what I would expect to happen.

Your setup is basically equivalent to piping all your nodes into each other in a linear sequence, with the sphere node first, followed by camera1, cameras, light1, and then lights. The only difference is that the use of merge and sublayer are effectively the same as turning on the “Start New Layer” toggles on the two Configure Layer nodes. The use of the sublayer and merge will both produce this same result.

Because in this arrangement the sphere comes before the camera, and you have chosen to “flatten implicit layers”, ther sphere layer (which is implicit because it has no save path) gets flattened into the next strongest explicit layer.

If you reverse the order of the inputs so the sphere comes last, then the sphere layer is at the end of the virtual chain of nodes, and so this strongest implicit layer gets flattened into the “scene_geo.usda” layer specified in the ROP Output file.

Perhaps this is just a misunderstanding that the merge (and sublayer) LOPs add the input layers to the stage in weakest to strongest order rather than the other way around?

mtucker
Perhaps this is just a misunderstanding that the merge (and sublayer) LOPs add the input layers to the stage in weakest to strongest order rather than the other way around?

No, I still want the layer strength order to go left to right, although I guess this is why it doesn't agree with how I was expecting implicit layer flattening to work. I was picturing implicit layers all flattening to the root layer, regardless of strength ordering, and any explicit layers would go on top of that. However, since the root layer is stronger than the sublayers, there would be a loss of strength ordering if this were to happen. It still seems wrong to me that the right side of a merge/sublayer with an explicit save path can end up with anything saved to it that wasn't part of the same branch. I'd almost rather get a warning or error message similar to saving implicit sop layers. The implict layers that are weaker than the explicit layer shouldn't be allowed to be flattened together, and should instead save a ‘node layer’ with an error.

Is there another way to construct the network such that the nodes that add explicit layers don't ever combine with the implicit layers and the implicit layers all end up in the root layer? Would it make sense for the sublayer node to have a strength order of “strongest sublayer, but weaker than implicit layers”?

Edit:
I guess this is what “Strongest File Layer's Position” does.

jsmack
However, since the root layer is stronger than the sublayers, there would be a loss of strength ordering if this were to happen

Exactly.

jsmack
Is there another way to construct the network such that the nodes that add explicit layers don't ever combine with the implicit layers and the implicit layers all end up in the root layer? Would it make sense for the sublayer node to have a strength order of “strongest sublayer, but weaker than implicit layers”?

Edit:
I guess this is what “Strongest File Layer's Position” does.

The “strongest file layer position” only works for layers that are already on disk, not for explicit (but still anonymous) layers.

Your point about not flattening implicit layers into explicit layers is an interesting one. My first thought was to object because for many users, they prefer to use a merge instead of connecting nodes inline to add multiple things to a scene (a torus, a camera and a light LOP all pipe into a merge). The intent is definitely to have those three things end up in the same layer. But none of those layers are explicit. So I think you may have hit on something there. The rules and intent for a Sublayer LOP are probably a little different. I don't think you would ever expect the layers coming from the different connections to flatten together.

Could I ask you submit an RFE about this please? I do think this change in behaviorwould need to be made optional to avoid breaking existing hip files, but it could be made the default for new merge and sublayer nodes, if there is general agreement that it would make more sense.

mtucker
Could I ask you submit an RFE about this please? I do think this change in behaviorwould need to be made optional to avoid breaking existing hip files, but it could be made the default for new merge and sublayer nodes, if there is general agreement that it would make more sense.

Sure, so the RFE is for Sublayer to prevent the ‘crossing of streams’ of flattening implicit layers on the left input with explicit layers on the right input, and leave merge behavior stays the same?

At this point the RFE is to rethink the Merge and Sublayer nodes and how they allow layers from different inputs to be combined when flattening implicit layers during a save. I don't feel 100% confident about the details, in terms of default behaviors, and whether the “explicit-ness” of the layers on the various inputs should be a deciding factor. Just make sure to point to this thread so we can come back an re-read the discussion that led to the RFE. Thanks!