Hi,
Last few days I've been dabbling a bit in the new features of Houdini; TOPs and LOPs, and I again and again see values being used in parameters with the @name sign, in TOPs as well as in LOPs. They are not really attributes like you have in SOPs right?
Also just read about the Context Options [www.sidefx.com], and I saw that you can also refer to those with the @name syntax.
Now I was wondering: Is this what is being used internally in the TOP/LOP context? Like do these TOP/LOP nodes create these ‘on the fly’ or something, or is something different being used?
Thanks for any clarification, :-)
edit:
Like each network in these contexts is like a big one of these: https://www.sidefx.com/docs/houdini/nodes/lop/begincontextoptionsblock.html [www.sidefx.com]
, but invisible and under the hood. Is this the case?
Full Version: Context Options - (LOPs/TOPs)
There are three different “things” that can be referred to with the “@” syntax:
1. Local variables. These are defined by the node itself during a cook. In SOPs, @P is a local variable representing the value of the P attribute (of the currently evaluating point).
2. Context options. These can be set at a global level using Edit->Context Options, in which case they are like “global variables” or “environment variables” (like $HIP). But context options can also be manipulated within the LOP cook chain, at which point they are “scoped” or “semi-local”. They provide a way for a small set of nodes to share a value. This is what the edit context options node does, and also nodes like For Each and Add Variant LOPs use context options to “transmit” useful bits of information to their input nodes (normally data flows strictly down a chain of nodes, context options reverse that direction of information flow for a few discrete values).
3. TOP Attributes (sorry, I don't actually know the terminology here). These are very similar to context options that are defined by a TOP node and “transmitted” to the nodes that are cooked by that TOP node. Again, “scoped” or “semi-local” variables that have different values for each work item processed by the TOP node.
I should at least mention that VEX “binding” can also be done with the “@” operator, but only within VEX snippet/wrangle nodes. This use has very little to do with the other uses here.
So, why use the same @ symbol to refer to all these different things? Because as a consumer of these variables you shouldn't care where they are coming from. They are just values that can be used to influence the behavior of your node. Whether the “@” is driven by a local context option, a global context option, or a TOP node effectively overriding a global context option doesn't matter. Accessing any of them is easy, because you only need to know the one syntax. And if you decide that a global context option should really be driven by a TOP attribute, or a local context option should be made global, you don't need to touch your nodes, you just set the value differently.
Hope that helps.
1. Local variables. These are defined by the node itself during a cook. In SOPs, @P is a local variable representing the value of the P attribute (of the currently evaluating point).
2. Context options. These can be set at a global level using Edit->Context Options, in which case they are like “global variables” or “environment variables” (like $HIP). But context options can also be manipulated within the LOP cook chain, at which point they are “scoped” or “semi-local”. They provide a way for a small set of nodes to share a value. This is what the edit context options node does, and also nodes like For Each and Add Variant LOPs use context options to “transmit” useful bits of information to their input nodes (normally data flows strictly down a chain of nodes, context options reverse that direction of information flow for a few discrete values).
3. TOP Attributes (sorry, I don't actually know the terminology here). These are very similar to context options that are defined by a TOP node and “transmitted” to the nodes that are cooked by that TOP node. Again, “scoped” or “semi-local” variables that have different values for each work item processed by the TOP node.
I should at least mention that VEX “binding” can also be done with the “@” operator, but only within VEX snippet/wrangle nodes. This use has very little to do with the other uses here.
So, why use the same @ symbol to refer to all these different things? Because as a consumer of these variables you shouldn't care where they are coming from. They are just values that can be used to influence the behavior of your node. Whether the “@” is driven by a local context option, a global context option, or a TOP node effectively overriding a global context option doesn't matter. Accessing any of them is easy, because you only need to know the one syntax. And if you decide that a global context option should really be driven by a TOP attribute, or a local context option should be made global, you don't need to touch your nodes, you just set the value differently.
Hope that helps.
Thanks again for your elaborate answer, mtucker. It's really helpful.
That's interesting. I did not know the For Each nodes also use Context Options.
Is there any way in which you can inspect local Context Options?
I have created Context Options while following the SideFX LOPs tutorials part 1:
Right away I see @input being an Context Option (edit:excuse me, local variable), but are there more or is there a way of knowing there are more?
That's interesting. I did not know the For Each nodes also use Context Options.
Is there any way in which you can inspect local Context Options?
I have created Context Options while following the SideFX LOPs tutorials part 1:
Right away I see @input being an Context Option (edit:excuse me, local variable), but are there more or is there a way of knowing there are more?
The local variables and context options provided by each node should be listed in the documentation for that node. At the moment these are not really discoverable in the UI.
Is there any way to use variables (like environment vars) or other context options as values for context options?
Not for global context options. You can use an "Edit Context Options" LOP to control the in-network value of a context option using an expression, but that's a very different thing. I guess you could have a context option change callback so that when option A changes it recalculates a new value for option B. But if an Edit Context Options node is used to modify option A, the value of option B won't update because there is no change notification for that. But I suppose in an Edit Context Options LOP you could set both option A and option B, but then you're duplicating your expression to set B from the value of A in multiple places...