Very simple, very strange:
Obviously the preview should be black because the Power can’t pull something out of the nothingness, the 0.0.0 vector. I can’t imagine what math in the Power node would do that? This is a huge problem for me currently working with world position offset since any slight wrong math results in polys getting separated.
Color visualization is inconclusive. Use DebugScalarValues/DebugFloat3Values material function,
Pow node correctly outputs zero values for 0^1 until something like 7th digit(4.13.2). Beyond that you’ll start noticing precision issues. If those insignificant rounding errors are causing issues for you, including mesh tearing, re-evaluate your whole approach to the task.
But yeah, that preview is black for me with the same node setup.
This is still not correct for me:
The multiply is 99999 and it also happens with 10000. It happens with exponent 2 and 1 but not with 3 and then happens again with 4, then not with 5 and up but with 8 again.
Can you explain that?
Sorry but that still doesn’t make sense to me. If it is a rounding error it would totally make sense to me if it would be a rounding error through using square root. But Power with exponent 2 is essentially just squared without any use of square root. So it would be a multiply node with both inputs being 0 which clearly can only result in 0. While Power with the exponent being 1 does just nothing yet what comes out of the power node is also wrong.
I guess I will have to make my own power function which then really is multiply x times itself which should then work without that problem.
Power node in the engine translates to HLSL as follows:
return pow(max(abs(X),0.000001f),Y);
It is probably being clamped to avoid NAN, because HLSL function pow is most likely implemented as :
return exp(y * log(x));
For general cases, but it might get optimized to several multiplications, when exponent is a constant integer. Haven’t looked up the docs for this regretfully, don’t quote me on this one, but I’d assume it so.
Here is the screenshot for better overview of your problem:
Thanks! Would you then recommend using a custom node that gives out those correct values or would I get unusable NaN error pixels?
You could use custom node with the same formula as in engine, but adding few more zeros, that would be sufficient enough for your precision.
