Using solution shown below doesn’t result with getting negative values.
And the flag “Allow negative emissive value” doesn’t work with decals.
1 Like
It is insane! why?
It is intended and not a bug. Use Abs material expression before power node to get the functionality, you’d expect.
Indeed.
But power doesn’t work like that - so it is a bug. If you want to add such node which works like that then add another one - don’t mess with basic math please.
I fount this only in one place right now - obvious to fix, but it can cause a lot more bugs, and why? this change is totally illogical and counter-intuitive.
It’s not. It is how shaders work:
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/pow.xhtml
As you may notice:
I am not talking about shaders - only about math - in math power works also for negative values - so wehn you see a node with name “power” you expect to see it works like power.
If you want to use in other way name it differently.
It should not be needed to read description for such simple and basic nodes.
Also you don’t change such basic functionality without giving alternative solutions.
And argument about working in such ways in shader is irrelevant - because otherwise we should work on ones and zeros.
It was still working in 4.15 - so why it was good then and not now? please explain.
It is shader optimization. pow(x,2) will be compiled to x*x.
Try to change exp to 2.1.
This is change is totally backed up by logic and is intuitive. Before 4.16 Power Material Expression used to translate to:
pow(max(abs(X),0.000001f),Y)
in 4.16 and above Power Material expression translates to:
pow(max(X,0.0f),Y)
Reason is pretty obvious: errors when using X values near 0;
Not a bug. Intended change.
why should you optimize shader on this level with cost of usability?
why from 4.0 - 4.15 it worked fine?
From my point of view it doesn’t matter - I generate effects based on nodes - and suddenly the mechanics of node changes - and in a way it is not logical in math point of view (I don’t care about code).
Don’t ask me. Ask Microsoft and Khronos Group. It is how shaders work.
If you’re talking why Epic changed it. So it’s to avoid spiking when negative base is used.
I think it is clear that optimization made not by Epic.
Wen you type pow(x,2) it will be interpreted by the driver as x*x. Shader code will be the same.
But that creates major issue. pow(x,y) is defined as pow(x,y) = exp2 (y * log2 (x)) and it is not defined when X < 0. So even values of Y produce “errors” when Y defined explicitly.
Fair enough. At least now i know who to blame.
For me the main issue is that for years I used power to modulate values in places like normals and coordinates which naturally have negative values - an now I would have to check all my functions and materials if they are still working properly. And As I tend to generate a lot of procedural complex materials it will potentially generates a lot of bugs - that is the main reason I am considering this a bug - because from my perspective it brakes things.
What’s wrong with the content example?
“Notice that negative values become positive just like ABS”
Hah. I didn’t notice the description.