Hi all,
I don’t quite understand the meaning of deactivating prims if then nothing can be put inside the hierarchy. I took an example of a scene from the Market Scene archive. In this scene, we first deactivate the light sources, and then try to add as part of the layer, but this fails. What could be the mistake?

As is often the case, the USD Glossary provides a good (if dense) description of prim deactivation: https://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-Active/Inactive [graphics.pixar.com]

Because USD doesn't compose (or really even look) inside deactivated prims, it also can't add or edit prims inside a deactivated branch. Deactivating a branch provides a performance advantage over simply making a branch invisible, with the downside that the deactivated portion of your scene graph becomes “off limits”.

mtucker
As is often the case, the USD Glossary provides a good (if dense) description of prim deactivation: https://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-Active/Inactive [graphics.pixar.com]

Because USD doesn't compose (or really even look) inside deactivated prims, it also can't add or edit prims inside a deactivated branch. Deactivating a branch provides a performance advantage over simply making a branch invisible, with the downside that the deactivated portion of your scene graph becomes “off limits”.

I was confused not by the very term deactivation in the context of USD, but by the fact that in the initial lessons and examples of scenes from SideFX that the authors did the same as in the screenshot above. Some data is deactivated, and then they try to add something there, but this fails.
If in the example of the scene there was an idea to show that after deactivation this hierarchy branch becomes inaccessible to us, then yes I understood the lesson.

Thanks!

Could you indicate which example file exactly? Was it used in a tutorial, or mentioned in a video? And if so, could you indicate where? This does not seem like something we should be doing, unless, as you say, iot is to show you what _not_ to do, in which case that should be made clear… Thanks!

I think the scene in question is the “MultiShotWorkflowDEMO”, which was created in a pre-release version of Houdini 18. There are a number of load warnings due to parameter interface changes.
The source of the problem seems to be the addition of the “Prune Ancestors Automatically” option, which is enabled by default, and most likely didn't exist at the time the scene was created. Disabling this option prevents the ancestor prims including ‘/lights’ from being pruned, since they are reused later on. Perhaps editproperties nodes in ‘create mode’, such as a light lop, could automatically ‘un-prune’ the ancestors of the prims they are creating?

Yes, there is a reference to this example, and there is a discussion in the LOPS tutorial 4 Layout Department: Shot Layout

In shot_004, we have grabbed the lighting from shot_001 with a Prune LOP (to remove the camera but keep the lights) and a Merge LOP, (to layer the lights into the scene).

Prune LOP:

Primitive pattern
/ Scene / Cameras / Shot * (removes all cameras begining with “shot”)

Method
Deactivate

Merge LOP:

Merge style
Flatten Into First Input Layer

Thanks @alexwheezy.

I'm pretty sure @jsmack is right, that this problem was introduced by that “automatically prune ancestors” option on the prune, which was added after the 18.0 release.

As to the suggestion of auto-unpruning, that's a very dangerous game. Either you unprune all the ancestors of the prim you are about to create (in which case you risk loading in a dangerously large amount of scene graph), or you unprune your direct ancestors, but prune siblings instead so that only the minimal set of stuff gets activated. But in that case, re-activating things becomes a _lot_ more complicated.

mtucker
Either you unprune all the ancestors of the prim you are about to create (in which case you risk loading in a dangerously large amount of scene graph)

This is kind of what I was thinking, but you have a good point. Is there a node warning when attempting to author a prim with pruned ancestors?

Edit: The screenshot shows a warning, but it's not very helpful.

Hi, I think I'm running into a situation sort of related to this post. I've authored a base layer of USD with scratch lights, render settings, and cameras. I'm sublayering this file into a fresh lops graph and I'd like to prune out the existing lights and build a new lighting setup, but I'm unable to get rid of the old lights in the scene graph tree without pruning the individual light's ancestor prim ("/lights/") This, of course, makes them disappear in the tree view, but when I drop in a new light, it throws an error regarding the ancestor prim.

The only thing that seems to work is to prune out the lights individually by using a wildcard ( /lights/* ) This is all fine and dandy except all of the old lights still show up in the scene graph tree view. Is it possible to prune out lights without having them show up in the scene graph tree without completely pruning out the ancestor prim and causing the ancestor prim-related error?

I'd suggest either putting your scratch lights under `/lights/scratch_lights` (then it's easy to deactivate them all and not see them), or you can hit the toggle at the top of the scene graph tree that says "Show Inactive Primitives", then the deactivated lights won't show up in the tree.

wow, thank you. I had no idea you could disable the inactive prims from the tree view, duh!