Inheritance in Substance compositing graphs
This page describes how inheritance is applied in Substance compositing graphs within Substance 3D Designer, and the impact it has on the graph's output.
All nodes in a Substance compositing graph can inherit the value of some parameters from a source. Inheritance means that changing the value in the source will carry out that change across all nodes which inherit from it. This is one of the fundamental concepts underpinning Substance 3D Designer’s power in generating parametric assets.
No inheritance, the value is defined arbitrarily and locally for the parameter
Relative to input
The value is inherited from the data connected to the Primary input of the node
Relative to parent
The value is inherited from the parent of the node or graph
Inheritance methods are applied for a node’s Base parameters, which is the set of common parameters all nodes have which control fundamental aspects of their behaviour. These parameters include:
- Output Size
- Output Format (i.e., bitdepth)
- Pixel Size
- Pixel Ratio
- Tiling Mode
- Random Seed
This should let you appreciate how changes in one node may impact the resolution, precision, and tiling behaviour of all nodes downstream from it.
E.g., two Perlin noise nodes in a same graph are both representations of a same source graph (
noise_perlin_noise.sbs) with their own sets of parameter values.
Changing inheritance methods
In the Properties panel, all parameters listed in the Base parameters section of a node’s properties have a (icon) Set inheritance method dropdown button opposite to their label.
This button lets you select the inheritance method which should be used to for a parameter.
In most cases, a node’s Base parameters are set to Relative to input, to leverage the procedural behaviour of chaining nodes together, while a graph’s Base parameters are set to Relative to parent, so the global parameters can adapt to the context the graph is used in.
Tweaking inherited values
Some Base parameters, such as Output Size, Pixel Size or Random Seed, can be changed relatively to the inherited value.
For instance, when the Output Size parameter uses a Relative to... inheritance method, a value or
(1, -1) means one power of two resolution above the inherited value for X and one power of two resolution below the inherited value for Y such as:
- Inherited value :
(9, 9)which is
2^9, 2^9 = 512, 512
- Relative value:
(1, -1)which is
2^(9+1), 2^(9-1) = 256, 1024
The Output Size page digs deeper into this critical Base parameter, and is recommeded reading to understand how the final resolution of a node is computed.
If a function is applied to a Base parameter, the result of the function will also be interpreted using the parameter's inheritance method.
Keeping the Output Size example in mind, a function aiming at increasing the inherited resolution twofold in X and Y should output the
(2, 2) Integer2 value.
Parenthood for nodes and graphs
When using the Relative to parent inheritance method, you should understand what exactly that parent is in a specific context.
The parent of a node is the graph it exists in.
The parent of a graph is the context it exists in:
- If that graph is a sub-graph instantiated into another host graph as an instance node, then the parent of the sub-graph is the instance node. The parent of that instance node is the host graph.
- If that graph is a root graph, then the parent is the application itself and whatever value the application has set for a given parameter. For instance, graphs will inherit from the Parent Size parameter set in the Graph view’s toolbar.
While this is desirable for Bitmap nodes or optimisation purposes, for instance, we strongly recommend using Relative to… inheritance methods when working in Substance compositing graphs unless there is a clear, deliberate purpose in doing otherwise.
When using In-context editing on a graph instance node, the parent of the graph is the instance node. In that case, the Parent Size setting in the Graph view’s toolbar is disabled, as the graph inherits is base parameters from the instance node.
This trait is the point of in-context editing and should be factored in when setting inheritance method and assessing the current values of any node’s Base parameters.
Inheritance with multiple inputs
When a graph has multiple inputs, each input may inherit from its discrete input data or from the graph, depending on its inheritance method:
- : The input inherits from the graph, and the data it receives is adapted accordingly. Relative to parent
- : The input inherits from its discrete input data, regardless of the graph’s Base parameters. This is very helpful for controlling data per input. Relative to input
One of the inputs may be set as the graph’s Primary input, by clicking RMB on that Input node and selecting the Set as Primary Input option in the contextual menu.
When the graph is instanced into another graph as an instance node, all the instance node’s Base parameters which are set to Relative to input will inherit the data connected to that input. The Primary input of an instance node may be identified by the small dark dot in its connector.
The other inputs which are set to Relative to parent will inherit the same Base parameters’ values, as they inherit from the graph which inherits from the instance node*, which inherits from the Primary input.
*: This is true is the graph uses the Relative to parent inheritance method.
Here are some examples covering different cases of inheritance, and the interplay of the inheritance methods set in the following actors, from top to bottom:
- Host graph
- Instance node in host graph
- Sub-graph – i.e., the graph referenced by the instance node
- Nodes in sub-graph
The inheritance method set for an actor is displayed in orange just above it. The flow of inheritance to its source is displayed with orange lines.
Letters represent separate sets of Base parameters, and should help follow what data is inherited by which actor.
Troubleshooting inheritance issues
As you build your graph and increase its complexity, you may run into unexpected results caused by inheritance. If the output of a node has an incorrect resolution or precision (i.e., bitdepth), you should go up the inheritance chain to pinpoint where these values come from.
A good starting point is checking the data displayed just below a node: these are the resolution, color format and precision of the image output by the first output of the node. While understanding the resolution is straightforward, the second piece of data is worth detailing:
- The letter prefix refer to the image’s color format:
- L: Luminance (i.e., grayscale)
- C: Color
- The number refer to the image’s bitdepth, from lowest to highest precision:
- 8: 8-bit integer (256 steps in 0-1)
- 16: 16-bit integer (65 536 steps in 0-1)
- 16F: 16-bit floating point (low precision values beyond 0-1, including negatives)
- 32F: 32-bit floating point (high precision values beyond 0-1, including negatives)
If the node has more than one output, you can check their resolution and precision in two easy ways:
- Double-click LMB on the output connector to display the image in the 2D view, and check the image information displayed on the bottom left corner of the 2D view’s viewport
- Create a Levels or Transformation 2D node and connect its input to the output you want to check. The node will inherit from the output by default, and you can then check the values below the node.
Now you can go up the node chain in the graph and try to find the first node where the unexpected values appear. Check the inheritance method of its Base parameters.
If nothing is amiss and the node is an instance node, you need to go deeper and open the graph referenced by that instance node. Repeat the process starting from the graph’s Output nodes and going upstream.
A common example
In particular, the Primary input concept is easily overlooked and can result in inheritance issues.
The Blend node is very susceptible to this, as it is used very frequently. Its Background input is its Primary input.
You need to pay attention to the order in which you blend the two inputs: the input which resolution and precision you wish to retain down the graph should be connected to the Background input, if the blending mode you need makes it possible. If not, then you may need to tweak the Blend node’s Base parameters and their inheritance method to compensate.