Author Topic: Exposing Gradients  (Read 20011 times)

Hi everyone.

I've been using Substance for a couple of weeks now, and so far so good, I'm starting to get a bit more pro-efficient with it.

There is one thing though that would make my life easier : being able to Expose gradients when exporting a substance.
I'm trying to build a library of fully procedural materials for myself, and the gradient feature is great to get basic colour pass out from the height map.
Unfortunately I've not managed to find a way to expose colour gradients for later modification.

I've hacked a way with levels and colour blends, but it doesn't give me as nice a result and it adds a bunch of unnecessary nodes to the graph.

Is there any technical limitations that stop us from exposing gradients ?


You're right, the "Gradient map" node keys cannot be exposed (color or position) because of optimization reasons.
The only way to do this would be to reference each key (which can be problematic in some cases). For now, this filter is static.

We started to think about a way to modify the "Gradient map" keys using a second (new) input: the idea would be to create the keys by sampling it.
Lead technical artist

Thanks for the answer ,

I'll try to find a slightly more efficient workaround than my multiple levels masks if I can.

I don't know if it's doable or not, but a node that would take 2 input, the grayscale image on one end and a color gradient on the other and do the same computation that what you have now could maybe do the trick.
Then we could plug a gradient as an input from outside of the main graph.

Yes, that's exactly the idea for a new version of the "Gradient map" node. :)

Unfortunately it's not possible to do it in an "optimized" (=usable for realtime) way.

But it's possible to do it. I just made a filter that can help you (better use it for "offline" generation than in a game or realtime app).
It's based on an FX-map that takes 2 inputs.The idea is to generate one morphlet (=shape) per pixel, get the luminosity value of the grayscale input, and use it as a position in a second input (a 1D color gradient).

You can, for example, replace the gradient by a "Color input" node to have the possibility to change the gradient based on an image input.

Lead technical artist

Awesome, I'll give this a try as soon as I can.

As I work mainly offline, that seems like a perfect workaround for me, thanks a lot !  :D

EDIT : I actually tried it this morning before going to work, and that's exactly what I needed, thanks again.
Last Edit: September 19, 2014, 01:59:07 am

Ok, perfect! :)
Lead technical artist

Excellent, I'm going to try it on monday.
Question :you said it will not fit for real time,  but it is OK if we compute on scene loading time right?

Hi guys, here is another version with an additional parameter that allows you to change the Y position (the idea was suggested by a colleague, that was one of the possible parameters in the next version of the gradient node).
This way you have the possibility to gather all your gradients in 1 image (X position for the gradient, Y position to switch between gradients) and dynamically change the gradient based on the input.

Vincent: sure it's possible to use it for runtime/realtime, it's just that the performances are not as optimized as they could be. It also depends of the target platform/resolution of generated image, but on PC, the generation time in 512x512 can be pretty quick (around 30ms).
Lead technical artist

Thx for the info Gaetan ! (The colleague is Nicolas right ? we were just speaking about this  :D)

Yep! :) It was also in the design document one of our developers provides us (so we can imagine to have it in the future gradient node).
Last Edit: September 24, 2014, 02:03:13 pm
Lead technical artist

Am I correct to assume that this made it's way into SD5 as a Gradient (Dynamic) node?  :)

Yes, you're right, we now have it as "Gradient (dynamic)".  :)
Lead technical artist

I know it's an old discussion, but I've been struggling with this as well. I understand why the gradient isn't exposed for realtime purposes, but is there any other work around or like turning a gradient node as an input? The FX map node isn't gonna do the tricks for me.

I'm streamlining the workflow by creating reference graph for every repetitive process, namely the hand painted effect it work perfectly except that i wasn't aware of the gradient limitations.

So my guess right now it that using this  graph as a custom node isn't gonna happen, I could for now copy and paste that part of the graph to every other substance i'm gonna make, but it seems to be a really unoptimised way for my streamlining of designer process. I use my gradient map with the histogram range that take the height as input, then a second one for small variations. nothing to fancy but yeah, exposing the gradient would make my workflow soo much more versatile and solid.

Thx in advance if anyone has tried something like this and have insight it would be really awesome  :)

if you don't need too much control points, there may be some solutions (like pixel processor)

In my search on this topic, I came across some discussion of using Pixel Processor to compile a kind of gradient atlas. It wouldn't be hard to set up an array of rows (a set length/range from 0-1), but how would you get the gradient editor to sample it? (On a side note, I do wish it was possible to constrain the sampling; basically toggle between freeform and snap-line, with hot-key orthogonal constraint as an option. Well, there's my next feature request!  ;D)
David Roberson
Freelance 2D|3D Artist

Auburn CA, United States of America