What can a “map range” node do more than a “color ramp” node?
It can remap single float values instead of colors. 
Much more intuitive when dealing with numbers instead of colors. Great addition to the arsenal!
2 Likes
Isn´t that the same as plugging a “value node” or some other float into a “color ramp” node?
Yes, but the output is a float again, not a color. If you’re e.g. remapping a texture going into the roughness slot it’s much easier to deal with a simple “0.3” instead of having to open a color selector and sliding it to 0.3, 0.3, 0.3.
Less overhead, easier to read.
EDIT: And additionally it also deals with unclamped outputs unless you want it to be clamped and activate the clamp option.
1 Like
Ah, I see.
I just tried remapping a value with a color ramp ranging from 1 to 10 but it appears that color ramps can have a max value of 4.875.
Very handy indeed this new node.
Ah, and now that I think about it you can not enter negative values in a color ramp either.
1 Like
Another good use for the map range node is dealing with values that are not between 0 and 1 - or even negative. For example the Musgrave texture produces outputs that range from -1 to 1. The Map Range Node can remap it to 0-1.
5 Likes
Ah, interesting. I didn’t know that.
That was my first thought with the Map Range node as well, it’s far easier to deal with than trying to fit the texture with the brightness/contrast node.
Does the map range node need to have “From” values specified?
Can it just take the values of the input (whatever they may be) and map them to the specified “To” range?
The only reason I ask is that you might not actually know what the “from” values are without experimenting - and may simply want to normalise input to a specified output range (e.g. if you didn’t know musgrave was mapped from -1 to +1).
I was using the “RGB curves” node to remap colors or values
Probably not, for the same reason that you don’t know the value, the node doesn’t know the value.
It would need to render out every sample to know what the max/min from values are, which isn’t really an option.
Why though? In the musgrave example given above, it is stated that the texture is mapped from -1 to +1. Can’t the node just read this as an input as opposed to having to specify it?
Many input values to this node will have a fixed range.
Many, but not all. Plug the x channel of the geometry>position node into a shader and all of a sudden it depends on where in space the pixel that is being shaded is.
You would need consistency across the whole node engine, or you are asking for trouble.
if there were a walled garden for just 2d texture nodes, that would be one thing, but there are so many potential things users can do to generate a value that it’s impossible to be able to reliably map the range.
But is that statement any less true just because you specify a “from” range?
What happens if you specify a “from” range that is narrower than the actual range of values the input can or does have, do values above and below the range just get clipped?
Yep.
Unless you know some other way to sanitize any potential value input, that’s how it’s gonna be.
You could give a checkbox option to read values or specify them (or alternatively try and read them if both “from” values are zero).
Read from what?
You would need to have a system that traverses the nodes in reverse, identifies the source range and anything modifying it in between. I’m not saying it’s impossible, but it would be very very difficult to make it reliable and robust.
From the node supplying the values into the map range node. (e.g. -1 to +1 in the case of Musgrave Texture, or 0-1 in the case of a black and white checker texture). Just because I don’t know what the value is, doesn’t mean blender doesn’t.
Take the following example (I know it’s not realistic - but it’s to demonstrate the principle)
I have a checker texture with squares of grey scale value 0.3 and 0.7.
I then pass this through a math node with a square root operator. This modifies the 0.3 and 0.7 greyscale values to 0.548 and 0.837.
I then want to remap this into the range 0-1.
Blender knows I have supplied the checker texture with values of 0.3 and 0.7. It also knows I have applied the square root math operation to those initial values. So upon input into the map range node - Blender knows the range of my input data is 0.548 to 0.837, even though I don’t (without getting a calculator out).
The point the node is executed??!! In terms of processing you can only know one input per sample. You don’t have access to the whole input set, just a tiny fraction of it (if we are including parallel processing).
So you cannot say for sure what is the max and min of the input set.
The only way is to analize every operation that produces the input, to find original limits and then calculate the extremes…
This process might be easy to solve in some situations, but it gets harder very quickly… In lots of situations there’s not even a solution. Putting a computer trying to find a solution for an np problem is to doom any render!
So the solution is to take all samples at once, and sort them. But this means to render the image first to create that input set.
1 Like
Exactly, which is why the compositor has had a normalize function for years. you have access to the whole set of pixels and you aren’t iterating over them hundreds of times for every pixel.
A map range node that auto detects its input range is just a normalize function with some multipliers on it. People have been asking for a normalize function in cycles for a long time, but that doesn’t change the complexity of the problem.