Author Topic: Designer > Painter > Designer > Unity  (Read 2484 times)

Howdy y'all! I'm new to the forums but I've been been reading around a little.

I could use some guidance to save some time and do this correctly. I'm attempting to bring my creature into Unity via Designer > Painter > Designer > Unity workflow.
This works fine in Designer and I actually get my desired result as expected, but when moving to Unity and modifying exposed parameters of nested substance graphs the effect does not propagate to the main material.



The graph shown references the other graphs used to make all the different materials. Masks created in substance painter are loaded in and used to designate which material goes where as they are Blended together. Then height-based normals are combined to the mix, also directly based on alphas exported from substance painter. This creates the final material outputs.



There are a many ways I could go forward from here to which I could create my desired result, which is why I'm seeking guidance from someone who already has experience with this type of setup. I'm not so interested in Optimization as I am in getting this working in Unity.

Next I'm going to try copying and pasting all the graphs into one huge graph so it only has one graph to deal with, just because I think that will ultimately work despite being way too messy to be practical, and I'd like to test that theory.

Another option I am considering is rolling back the base-colors of the materials to be black-and-white then blending the colors on the combined graph. That option still leaves the issue that when I modify the nested graphs, in any way, that they will not update on the combined graph in Unity like I may need them to.

Essentially, I need to be able to access and modify Uniform Color swatches, scattered about several graphs in the substance, in the Unity editor and have them update changes to the material without needing to run the game or use code to force update the materials.

I wanted to give an update and share the result of me brute-forcing and sticking every material onto a single graph.



As expected, once this substance archive is brought into Unity it works as I'd like, minus some metalness/roughness issues that I'm not going to fix for now. The graph may be a headache to look at and set up, but its a headache that works!



I'm able to tweak color values and generate new textures on-the-fly in Unity, exactly what I was aiming for. There must be a better way, though! Thanks in advance for any help you can give!

Update :

One feature I liked about the brute force setup I had in the last post is that the end-user only has one substance that they see. This can reduce confusion when applying the substance to a model. But the overall complexity of the graph negates this positive gain imo.

This time I removed the color information from the underlying substances, and brought the colors up to the top-level material where all the substance graphs are being blended together.



Substances that used masks for color blends got custom outputs of those masks. I was then able to access those outputs during the material blend, and the alphas do carry over to Unity despite the warning saying they failed. I also went through and optimized things a bit. I set Uniform Color nodes to 16px and turned all the other nodes "Relative to Parent" for the ability to scale the material in Unity. Pictured below is where I blend the Rough Skin and Smooth Skin into the material. In order to simplify things in Unity I use the same colors for both the Rough Skin and Smooth Skin.



Organizationally this is an ideal setup as it brings all my custom controls to an area where I can see them all at once. The workflow is odd in that it goes against the non-destructive nature of Substance designer in that I had to visually modify underlying substances to get the approach to work.



One last approach I would like to try is setting Inputs in the Substances and just pumping the color directly in - instead of having outputs and in-between blends. That could perhaps simplify this process farther by having the blends happen behind the scenes. It would also be less destructive to the underlying substance graphs as they could retain their blend information. If this works as could be predicted, it would also get rid of the Unity warning as I'd be using inputs rather than outputs.

HI,

Just to make sure I understand, are you saying that the issue is that if you use a graph within a graph, the subgraph's exposed parameters are not updating in Unity? I have worked with subgraphs before and didn't have an issue. You should be able to work this way and using subgraphs is the more organized way to work. In terms of optimization, when a graph comes across a subgraph, it must then evaluate all nodes in the subgraph which can not be as optimized as having all nodes in a graph where selective computation takes place depending on which nodes changes constitute a recomputed. However, the organizational an reusability benefits do out way the computational hit.

Cheers,
Wes
 
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

Howdy Wes! Thanks for responding!

When editing the subgraph's exposed parameters they do indeed get updated, however the effects of the subgraph being updated would not reach up to the combined graph in Unity - there is no driver to push the changes made in the subgraph upward, as on its own the subgraph functions independently and does not communicate with other substances. The method I came up with allows the main graph to give instruction to the subgraphs and receive feedback - working from the top level downwards then back upwards to force out a result.
Ah I see, so the super-graph with everything thrown on it is potentially the most optimized way to do this, despite being difficult to look at. I bet I could shave half the computation time off doing it that way... Its far too destructive, though, so maybe I'll consider that approach in the future if it is dire to optimize.

Final Update : Input Works!

So I've converted the substance from being output based to being input based and there is a dramatic improvement to the readability of the graph. Also the Unity warning is now gone! The input method does work in Unity, just as well as the output method.



The blending of the skin colors is done internally within substances instead of externally in this upper layer. The Dino-Skin is much more compact and simpler to configure.



As for the interiors of the underlying substances, they have been restored via switches. That way if I'd like access to the %100 original colored material, all I have to do is flip the switches.



A bit of warning, though. If these switches are set to show the original color and not the custom input, it will disable the ability to customize the color in Unity. So the switches are a tad dangerous but well worth it to keep the substance completely non-destructive.


Howdy Wes! Thanks for responding!

When editing the subgraph's exposed parameters they do indeed get updated, however the effects of the subgraph being updated would not reach up to the combined graph in Unity - there is no driver to push the changes made in the subgraph upward, as on its own the subgraph functions independently and does not communicate with other substances. The method I came up with allows the main graph to give instruction to the subgraphs and receive feedback - working from the top level downwards then back upwards to force out a result.
Ah I see, so the super-graph with everything thrown on it is potentially the most optimized way to do this, despite being difficult to look at. I bet I could shave half the computation time off doing it that way... Its far too destructive, though, so maybe I'll consider that approach in the future if it is dire to optimize.

Final Update : Input Works!

So I've converted the substance from being output based to being input based and there is a dramatic improvement to the readability of the graph. Also the Unity warning is now gone! The input method does work in Unity, just as well as the output method.



The blending of the skin colors is done internally within substances instead of externally in this upper layer. The Dino-Skin is much more compact and simpler to configure.



As for the interiors of the underlying substances, they have been restored via switches. That way if I'd like access to the %100 original colored material, all I have to do is flip the switches.



A bit of warning, though. If these switches are set to show the original color and not the custom input, it will disable the ability to customize the color in Unity. So the switches are a tad dangerous but well worth it to keep the substance completely non-destructive.


Very great update! Thanks for sharing. I think you have setup a good optimized workflow for you scene.

Cheers,
Wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja