Why Does Not Shader Mixer Understand Basic Math: A Saga In Three Parts
agent unawares
Posts: 3,513
Part The First
In the beginning, Agent went unto the Shader Mixer and said, "Let us create a default shader," and he clicked on the File menu, and New Shader... and it was so. And the manner of the shader network was as follows.
And when there was no metallicity in the shader, the appearance of the shader was as follows,
And when there was metallicity in the shader, the appearance of the shader was as follows,
And it behaved in all respects like the Uber Shader. And it was good.
Part The Second
In the next hour, Agent said, "Let us add simple mathematical functions to change the results of the shader parameters." And so he did. And every one of these attempts looked normal at first, but other parts of the shader that they did not connect to suddenly behaved wrongly. So Agent said, "Truly, if we add a mathematical function that does nothing, then there should be no change in the shader." And so he added 0 to the diffuse color.
And when there was no metallicity in the shader, the appearance of the shader was as follows,
And when there was metallicity in the shader, the appearance of the shader was as follows,
And it was not good. And Agent wondered "How can a mathematical function that returns the input screw up metallicity when applied to the base color? Such a thing is an abomination."
Part The Third
And in the next hour Agent said, "Truly, addition and subtraction are inverse operations. If addition causes a hidden modifier to be applied, then subtraction should remove it." And after adding 0 to the diffuse color, he subtracted it.
And when there was no metallicity in the shader, the appearance of the shader was as follows,
And when there was metallicity in the shader, the appearance of the shader was as follows,
And lo, not only was the shader still screwed up, the effect of two mathematical functions that did nothing was exactly the same as the effect of one mathematical function that did nothing, there was no doubling of the effect, and neither was it taken away, one was not screwed up more, nor the other less. And Agent said to himself "What the hell," and he tested many mathematical functions that should have had no effect to see whether they had an effect, and lo, all of them caused the same screwup, and always only once, no matter how many of them there were, and none took it away, and in different channels they caused different screwups, and none of it made any sense at all.
And Agent said, "Huh, this must be why no one likes to make Iray shaders," and he went to complain to the forum.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
"Forsooth, and verily, young Agent hath ye not yet know that the bricks work in mysterious ways their wonders to perform?"
While this is not a definitive answer, it is important to remember that MDL 'color' is NOT just an RGB vector. While the block interface to it is, it actually is much more (including wavelength/intensity) and as such, doing color 'math' on the RGB may have unintended consequences elsewhere when you think it should just be 'simple'. I'm not saying it's NOT a bug, just that PBR engines are a bit different in how they do color calculations, so what you expect may not be what's actually happening.
Whoops, forgot to use the right.....Idiom!
"Avast, Agent, for thy machinations may be for naught.....for there be more things in colors and light than are dreamt of in thy wildest philosophies..."
The thing is this also happens if you use a simple float to drive the color (works normally) and then do any math on it (suddenly doesn't work normally) and that float shouldn't have any secret color-specific values nor even know that it's going to become a color downstream.
Seriously, somehow a float of 1 gives different results plugged into the PBR metallicity base than 0.5 + 0.5. It's absolutely beyond baffling. Wailing and gnashing of teeth-level frustrating.
These are MDL math bricks, they should be capable of doing math in an MDL shader.
EDIT: Also a color,color,color direct value works fine. So it understands simple RGB vectors without whatever the user parameter input might be adding. Until you do math on them.
This is not entirely true, as the moment that float gets 'fed into' a color value, the type changes, and that means ALL the internal structures get intitialized. I'm sure the color tries its best to interpret that float into a color, but it's not deterministic in some parts. Some parts work fine for certain values, others not so much (like converting <0,0,0> RGB to HSV.....is it white at zero saturation or black at 100% saturation?) When you bring wavelength/intensity stuff into it, this becomes even more troublesome.
This does not happen until after the math. All the math is on floats. Why does float 1 coming out of a direct value brick directly into color work normally, and float 1 coming out of an add or subtract or any other math brick into color work normally in color but destroy metallicity?
EDIT: Are you saying that if a float eventually winds up fed into a color, the intepreter treats that float like it was a color the whole time? That would be a really bizarre way to handle it, why would the interpreter override every single type setting you set? You can feed a float value into both float and color inputs, is it a float from the beginning or a color from the beginning? I doubt it works this way.
I haven't got a clue, but I still enjoyed reading this thread.
Verily, I think I have an inkling to the matter at hand...
When you do math things to a color with math the color gets turned into not-a-color and when you then try to plug your new not-a-color into something that wants a color plugged into it goes "what? This is not a color!?" And dies.
Rather than math use a color mix node (is it actually called that I haven't fiddled in shader mixer for a while mainly because of stuff like this, it is a silly place) to do the same function.
Do this on paper... and tell me when you get the answer...
(1 / 3) * 3 = ???
Should be 1, but the closest you will ever get is 0.99999999999999999, if you ever get past the 1/3 part, and are still writing 0.33333333333333333333
No rounding, that is cheating...
I am sure it is actually a bit-alignment issue... or a "signed/unsigned" issue... or an INT/Float conversion issue.
Remember, some things don't exist until you connect them. (It doesn't run "through" that code. Could be that the connection, causing it to pass through that segment, revealed the internal default or "safety" value. As opposed to skipping over it, and not seeing that "correction" or "safety" or "default".)
But, yea... maddness sometimes.
They waste so much time "simulating fake values", when they could make it just a simple formula that incorrectly created the real values, faster, without the need for "shaders". Call them "lighters", since shades don't exist in IRAY, as per the manual. 90% of shaders, when not pretending to simulate "rays", are actually just simulating micro-surfaces, poorly.
I still don't get why changing the "roughness" of "gloss" makes the image seen through "refraction" blurry... That isn't how glass works... If the "Gloss" is "rough", that doesn't make the transmition of the light coming from the other side "blur", it should make the reflection blurry, not the refraction. Because gloss is a "reflection", not a "refraction". That would be "refraction roughness", which would only happen if the glass was hazy inside, not outside on the surface. Scratched glass doesn't blur the image seen through the glass. (Well, if it is frosted, that sort-of blurs it... but that is just scattered, not "blurred".)
Math needs to be reinvented again.
So does the way they think about rendering. They need to think from the camera-out to what is seen, towards the light... not from the light, to the scene, to the camera.
I mean you can make (1/3)3 equal 3 pretty easily if you understand the basic rules of math and distribute things out. So (1/3)3 becomes 3/9 which obviously equals 3. Or you could just use basic logical reasoning. Or not convert a fraction to a decimal.... There are a lot of options
As to why the refraction and glossy roughness are connected by default... That's because that's how things generally happen in the real world? Refraction roughness doesn't make the interior hazy (that would be what volumetric scattering does) it makes the surface rough.... As you mentioned, frosted glass. If you can find me some glass that has very rough reflections, but completely clear refraction I'd be pretty interested.
Also its very easy to decouple glossy and refraction roughness. Just click "share glossy inputs." Useful mainly if you're adding just a bit of glossy roughness because irays refraction has some pretty bad energy loss issues when you add roughness
I did test btw and if you use a "blend colors" node to do the math your setup will work.
No argument here. Its pretty dumb
This would make sense, but floats which are not colors work totally fine, unless you do math on them, then they break too. Also I'm only doing color operations on color nodes, which should only output colors? Something about the MDL math nodes are busted.
I will try this.
EDIT: You're right, this totally works. I don't see anything new broken (yet). Oh my god. I can hack most of the math I wanted to do with this, I think. Thanks.
EDIT EDIT: It looks like it works fine on on floats too despite being a "color" node. Yesssss.
"And there was much rejoicing over the land and Agent sayeth, 'mine's a double'"
True Stories of Shader Mixer
I'll do it in base 9.
(1 / 3) * 3 = 0.3 * 3 = 1. Done.