Graph Connectivity Understanding / Enhancements

[kwokcb]

Leaving this to perhaps create better documentation, and / or enhance / simplify the interfaces and implementation

Basic Node / Nodegraph Deriviation and NodeDef Association

• A Nodegraph can almost be considered to be Node with some additions for explicit interface publishing. It would be useful to make the implementation to formally make a Nodegraph a Node.
• A Nodedef allows for interfaces to be encapsulated to allow Node instantiation.
• With separate Implementation associations for 1.39, mostly a Compound Nodegraph can be considered a Functional Nodegraph based on these associations.
• The interfacename has the downside of publishing one interface (vs having the user of the Nodegraph specifying the interface. Note that the latter way requires a way to specify a specific path within a Nodegraph (downside)
• Outputs are not published or filtered in any way and use Output->Output connections to "publish" which is inconsistent with how Inputs are published.
• Creation of Nodedef from graphs can be thought of as "publishing", conversion of Nodedefs to graphs is what is currently called "flattening".

Ports / Inputs / Outputs

• Ports always have values, and inputs and outputs determine direction of connectivity.
• It is cumbersome to remember if the connection source or destination is a nodegraph or node, as 2 explicit names are used. It would be useful to simplify this to just reference a node (given the premise above that a nodegraph "is a node".
• the Output used for an input is either the first if not provided or an explicit name.
• A node + input or node + output is basically an Element path. A single interface for this help to simplify connection logic.
• If / when a runtime (non-string) version connections is added then a direct link to an Input or Output is all that is required to correspond to a path name.

Single Level (Non-nested) Connectivity

• This is mostly complete with the addition of Nodegraph<->NodeGraph support in 1.39.

Nested Connectivity

• Though part of the spec, only single level connectivity is supported from an implementation standpoint.
• As with USD, connections cannot occur across more than 1 levels. Example given based on early TSC Slack discussion:

Graph Referencing

• This is a suggested enhancement based on discussion about Nodegraph inheritance.
• Here a "NodeGraph Reference" node is allowed.
• Simple earlier Autodesk discussions had the requirement to "publish" expose interfaces as desired, or to make reference a "closed box" and/or read-only.

Proposals for Consideration

Updates

• Make a Node and a NodeGraph and Document have common derivation as connectable things. (Only outputs are connectable in Documents however). There are many places which look for connections via GraphElements (which are Documents and NodeGraphs but not Nodes so certain connections can be missed).
• Make Input and Output port connectively representation and implementation the same.
  • Easiest is to get rid of one of nodename or nodegraph attribute to specify the node connection.
  • Suggested from Jonathan Stone: remove requirement for explicit Outputs to find connections. e.g. Shader translation logic currently breaks due to explicit Output existence assumptions. To discuss more as code generation creates Output ports as needed, and most likely node editors need a concrete runtime connection data structure.
• Make Port specification the same and path based, hopefully removing string manipulation at runtime for performance.
  • This would remove the need for "nodename" and "nodegraph" attributes.
  • This would greatly simpify connection traversal to be a straight path lookup, which could be cached to support bi-directional traversal. Downstream traversal is currently a different mechanism and upstream traversal, and can be more costly as well.
• Embedded interfacenames publishing for Inputs is inconsistent with Outputs and is a "back reference" to the interface.
  • Make publishing of interfaces for both Output and Input have consistent representation and implementation for connectivity.

New

• Consider referencing for instance reuse vs only allowing embedded content. (Note that this is also in the vein of how imports / includes are handled -- wherein currently all content is embedded and requires elaborate tagging to keep separated).