You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The desired workflow is to allow for a set of tokens to be recognized within the context of a nodegraph / node and used for string substitution. One common use case is for image filename identifier resolving but can be used to resolve geometry identifiers. Tokens allow for more greater graph reusability as the same graph can be reused with different token replacement values. e.g. a brick shader that can accept different resolution tokens applied to the same base color filename requires only one tokened image node.
As of 1.38 it is given that:
A <token>can be a children of <node> or <nodegraph>
"Variations" (for which one application is user "presets") on tokens can be applied via <variant>s and <variantsets.
For 1.38.2 support logic for tokens will be completed. This means tokens
Are considered when creating nodedefs from compound nodegraphs.
Are "transparently" applied by String Resolvers when determining a "resolved" value. (Basically be part of the "get resolved value" API interface.
Are resolved during shader code generation by via the new resolving logic (and hence are also resolving "transparently".)
For 1.39 updates the proposal is to support a workflow where a user can create reusable "token nodes" and "publish" these are interfaces on nodegraphs.
These new nodes:
Contain a list of string/token replacement values.
Can only exist within nodegraphs.
A inputs on a node in a nodegraph (including those found on a "token node' can be "published" as child tokens on the associated nodegraph. (part of the 1.38 assumptions). The addition is that such inputs are "connected" to the nodegraph child tokens.
1.38.2 Status: Changes in ADSK fork. In PR for LucasFilm merge, except Runtime which is not part of main yet.
Usage of tokens at nodegraph level and nodedef level. (confirmed as part of specification - no "work")
Publishing <token>s to nodedefs from compound nodegraphs. Updates have been added to "publishing" utility.
Resolving tokens inside or outside code generation
<token> element children of a node, nodegraph or nodedef can be applied for string resolving of sibling inputs.
Support of <token>s in Runtime module (added -- added)
**To fix **: Runtime stores tokens with uniform="true" attribute. This should not be added as tokens are always uniforms.
1.39 Details : Token "node" and token interface publishing : Under review
Add a new node definition: "".
This node for now is a fixed list of child <token> Elements.
Proposed definition is as follows (here there are 5 tokens which is the ADSK proposed number):
"Image_Path" from the token node "tokennode" is "exposed" as an interface on the nodegraph.
The resolved value for "Image_Filename" input it still "Resources/images/cloth.2k.png".
A possible node definition (<nodedef>) and associated functional nodegraph created from the compound nodegraph:
When an instance of such a definition is created it will have modifiable "published" token values:
In this example, the resolve "Image_Filename" would be "Resources/images/brick.4k.exr".
The text was updated successfully, but these errors were encountered:
This change list adds a missing uniform flag to interface inputs which are connected to uniform inputs on internal nodes. An inconsistent use of the uniform flag will cause compilation of generated MDL code to failed, since MDL is strict about the use of the uniform keyword in source code.
Workflow context
The desired workflow is to allow for a set of
token
s to be recognized within the context of a nodegraph / node and used for string substitution. One common use case is for image filename identifier resolving but can be used to resolve geometry identifiers. Tokens allow for more greater graph reusability as the same graph can be reused with different token replacement values. e.g. a brick shader that can accept different resolution tokens applied to the same base color filename requires only one tokened image node.As of 1.38 it is given that:
<token>
can be a children of<node>
or<nodegraph>
<variant>
s and<variantset
s.For 1.38.2 support logic for tokens will be completed. This means
token
sFor 1.39 updates the proposal is to support a workflow where a user can create reusable "token nodes" and "publish" these are interfaces on nodegraphs.
These new nodes:
token
s on the associated nodegraph. (part of the 1.38 assumptions). The addition is that such inputs are "connected" to the nodegraph child tokens.1.38.2 Status: Changes in ADSK fork. In PR for LucasFilm merge, except Runtime which is not part of main yet.
<token>
s to nodedefs from compound nodegraphs. Updates have been added to "publishing" utility.<token>
element children of a node, nodegraph or nodedef can be applied for string resolving of sibling inputs.<token>
s in Runtime module (added -- added)uniform="true"
attribute. This should not be added as tokens are always uniforms.1.39 Details : Token "node" and token interface publishing : Under review
<token>
Elements.<input>
s, ,<token>
would have "interfacename" attributes to form the "connection".Example:
The resolved value for "Image_Filename" input would be "Resources/images/cloth.2k.png".
"Image_Path" from the token node "tokennode" is "exposed" as an interface on the nodegraph.
The resolved value for "Image_Filename" input it still "Resources/images/cloth.2k.png".
<nodedef>
) and associated functional nodegraph created from the compound nodegraph:When an instance of such a definition is created it will have modifiable "published" token values:
In this example, the resolve "Image_Filename" would be "Resources/images/brick.4k.exr".
The text was updated successfully, but these errors were encountered: