Author Topic: Why Grayscale and Color seperate nodes?  (Read 3405 times)

As I keep using Substance Designer, I keep wondering why grayscale and color are so split apart from one another. For instance, "Tile Generator Color" and Tile Generator Grayscale". What's the point of having two nodes? Wouldn't it be easier and simpler to just have a grayscale/color toggle like in  the Gradient Map node (i think some others are like that.) Or better yet, just have it be able to use color AND grayscale? It seems like a very easy thing to implement and would save on workflow and the amount of nodes having to search through. Seems like with how cool Designer is, the program itself should handle under the hood, for the most part, if something needs to be grayscale or color.

I agree with your point and have wondered since the same. My guess it's due to how data is being handled inside the nodes (and core). For example, scalar data is only 1 float and color data is 4 floats and so it makes sense to separate the two from that point of view, although you could of course add a boolean condition to disable one or the other... Then again, that would also increase node size and computation (a bit) if you'd build in something like this. Maybe not by a big margin if we're talking single nodes, but consider having a node system of 200+ nodes and all of them individually are checking for float1 or float4. That's a lot of extra computations you probably don't want.

Hey, this is indeed a design choice (as color nodes are 4 times more expensive than greyscale). A way to make sure people don't overuse color nodes when they shouldn't.

The discussion is still active internally on this topic.

Good explanation (and is what was expected).

Since we have other nodes (e.g. Blend) where you can input either Grayscale or Color, I wonder what the "cost" would be of doing that sort of dual input to more nodes.

a) Perhaps the "input check" process would be so fast and easy that the cost would be almost immeasurably small
b) What if the interface used a "dummy" node (that looks normal to the user), and when you plug in the input, it would essentially subsitute in the correct gray or color node.  Hmm, a downfall I see to that idea is it could be complicated if you then changed the input to be a different (gray-vs-color) source.

Bottom line for me is... Not a big deal, but I do support the idea of minimizing the number of duplicated nodes with both gray/color versions.
Hobbyist
----------
Common "Help" suggestions:
- LOG FILE tips - https://forum.allegorithmic.com/index.php/topic,22451.0.html
- LICENSING issues https://www.allegorithmic.com/contact
- ATTACH files and pictures to posts: https://forum.allegorithmic.com/index.php/topic,23670.0.html

I bet it's because initially Allegorithmic hoped to do a kind of  real time solution  to use substances directly in a game renderer.   So everything had to be super simple and straightforward.   

They killed very cool manual noise recomposing from old MapZone for the same reason I think.

As a result we have super flexible solution and at the same time super inconvenient   to work with and unfriendly from an art person point of view.

Lacking so many simple tools and features from elsewhere and making us spending more time  to debug our substances  than on actual creative process. 

ps. Wonder if it's super complicated thing to make a node to recognize color vs grayscale inputs on its own?  Seems Blender nodes do it.       

 Another things  I found crazy inconvenient is exposing process/no clones  and sub-graphs instead of node groups like in Blender.

  I can't even fix anything in a sub-graph  easily since I have zero visual feedback there.   I have to copy/paste some  sample inputs first , then switch output size and finally don't forget to switch its all back off before I do a final saving.
 
 I have to say it's totally crazy design solution  from some alien universe. ;D      It's nothing new although.  SD is holding honorary second place here after Zbrush.  So we are accustomed already and happy to tolerate it  in exchange for a few really cool features.
Last Edit: April 03, 2018, 12:18:34 am

It's done mostly for speed and memory. Invisible/implicit auto-conversions always break down at some point and are impossible for the user to fix when it happens, so we let the color/greyscale typing explicit and user-manageable.
However, I agree that the subgraphs should be able to have inputs/outputs that can automatically determine whether they are greyscale or color depending on what is plugged there (like some of the atomic nodes do). In fact, this was part of the initial Designer design document, but unfortunately we never found the time to complete that.
As for why we need the speed, even if nobody cared about real-time uses of the Substance engine (which is not the case, otherwise the UE4 and Unity questions subforum here would be empty), Substance files are used in Painter for its brushes, layer effects and smart materials, and speed is paramount there as well.
Last Edit: April 03, 2018, 02:55:08 pm

it makes absolute sense to have the user be able to select for color or grayscale with a node, its often necessary to have that fine level of control in a graph.
however, i am not entirely sure why it isn't just a toggle set by the user on a node and designer does the dirty work behind the scenes essentially doing your "Invisible/implicit auto-conversions" by user request rather than during export.

-j


This is exactly the problem I've run into today, and after hours of searching for some way to make a function distinguish between color and grayscale inputs I've forgotten why I needed to do it in the first place. Sadly, my AD/HD kicked in and now I am obsessed with finding out how to check numeric variable types (i.e. if int, int2, int3... etc.). I know it'll come up again and again, because I'm used to doing it in other programming and scripting.

It also makes me wonder if there are ways to catch errors in functions.

In anycase, I would expect it to be simple and economical to test num var vector length and conditionally step down from color in instances where you could automatically shift from 4 channels to 1.
David Roberson
Freelance 2D|3D Artist

Auburn CA, United States of America
davidbryanroberson.artstation.com

This is exactly the problem I've run into today, and after hours of searching for some way to make a function distinguish between color and grayscale inputs I've forgotten why I needed to do it in the first place. Sadly, my AD/HD kicked in and now I am obsessed with finding out how to check numeric variable types (i.e. if int, int2, int3... etc.). I know it'll come up again and again, because I'm used to doing it in other programming and scripting.

It also makes me wonder if there are ways to catch errors in functions.

In anycase, I would expect it to be simple and economical to test num var vector length and conditionally step down from color in instances where you could automatically shift from 4 channels to 1.

Maybe creating a new thread would be better as it's a different topic (?)

Not so much. I got to this thread by asking the same question. I pointed out that distinguishing between a float1 and a float4 is the obvious test to determine what type of input was connected.


I just failed to mention that you answered my actual question, which was "why" they're segregated into color and grayscale nodes. Of course I did spare you the bit about why I needed an input that could receive both inputs, which was to construct a switch to color and grayscale processes for handling either type of user-supplied graphics. But that part can be handled with an input parameter and "visible if" logic.
David Roberson
Freelance 2D|3D Artist

Auburn CA, United States of America
davidbryanroberson.artstation.com