Hi,

I am using the option context menu to set the shot variable in order to control switches and other nodes in the stage graph. Now, when I use the same variable name in the task/pdg graph (to submit the usd scene to the farm), I would expect that the attribute value set in the pdg node takes priority over the value set in the option context menu, but it does not seem the case. I am wondering what is the best way to achieve the expected behavior: the value set in the context option menu will be ignore or replaced by the pdg graph during render submission.

Cheers
R.

Houdini 19 added the ability to choose where to read the attributes from:

Thanks for the reply, I am still using version 18.5 therefore I am assuming that on 18.5 it is not possible to force it, ill try the when I'll have v19 running.

Sorry for the next silly question, but just to be more specific: for example if I use `P@shot_name` in my shot switch will I be able to use the context option menu to drive my shot switches while I am testing lighting in the graph, or would I need to change it into `C@shot_name` and then switch it back to `P@shot_name` when I want to submit it on the farm with pdg?

Basically the idea is to keep the variable name consistent between pdg and lop networks, when I work in lops it will use the attribute value from the context option menu, and when I use pdg graph the pdg attribute will override the value in the context option menu. So rather than an exclusive use of the variable, the variable can be used for both situation but with a sort of priority rule.

Cheers
R.

Hi,

The @ is just markup, which has been extended in H19. You can still explicitly use contextoptions()or pdgattribs()per your use case in H18.5.

Ruspa
Basically the idea is to keep the variable name consistent between pdg and lop networks, when I work in lops it will use the attribute value from the context option menu, and when I use pdg graph the pdg attribute will override the value in the context option menu. So rather than an exclusive use of the variable, the variable can be used for both situation but with a sort of priority rule.

the point is to not be able to use it interchangeably, that would be too much chaos and randomly overriding setups with conflicting names of attributes, pdgattributes and context options since all of them use @ syntax
hence the introduction of G C P prefixes to avoid that

without those prefixes there is a strength to those so I gess expricitly set context option will be stronger than pdg attribute

in your case (18.5) it's better to avoid using the same names

- you can either use Edit Context Options LOP and override the variable's value using some @pdgattrib preferably different name to avoid issues
so it would feed the pdg value to the context option and your LOPnet will use just @contextoptionname where necessary

- or if you are using global context options you can override those directly on ROP USD TOP or Karma ROP TOP using @pdgname

tamte
the point is to not be able to use it interchangeably, that would be too much chaos and randomly overriding setups with conflicting names of attributes, pdgattributes and context options since all of them use @ syntax
hence the introduction of G C P prefixes to avoid that

I still have some reservations about this design, as generally the users of Solaris's context options will be largely unaware of many of the PDG attributes that are part of users and pipelines TOP nodes and there is a large chance of collision. This pushes us to name our PDG pipeline-maintained ROP nodes with attribute names using a namespacing strategy that seems redundant and over-specified. This still doesn't insulate you enough from artist-maintained TOPnets that might not have the same awareness and diligence we can push down into our pipeline devs.

So there are potentially three groups of people that might contribute to a scene that are unaware of each others' intentions.

jason_iversen
I still have some reservations about this design

I'd rather see nondestructive push workflow being done properly, similar to how CHOP exports work and I have voiced this opinion many times in Beta and RFEs and will probably continue, since I don't like having setups that are directly dependent on TOPnet or other potentially external process
it's like having HDA depending on external references, that would break without those, very bad idea

however with the workflows we are given, I personally prefer to have clear distinction among types of @ references than having N different ones that noone even knows what was the intention

tamte
I'd rather see nondestructive push workflow being done properly, similar to how CHOP exports work and I have voiced this opinion many times in Beta and RFEs and will probably continue, since I don't like having setups that are directly dependent on TOPnet or other potentially external process
it's like having HDA depending on external references, that would break without those, very bad idea

There is lot to be said for the apparent simplicity and safety/usability of non-destructive overlay approach (CHOPs/Takes) but it certainly doesn't fit all models, not when the scene is moving around and suits a pull-driven workflow.