It seems only d3d11 that shows division by 0 warnings for shaders, though maybe other platforms do when used…
But could Unity not auto detect and fix such maths on shader compile, because it makes writing a shader messier than it could be if you must check all divisions (even when they should never occur).
You can use unity’s Unity_SafeNormalize() as Unity does for normalization.
I am not sure about float3 x = y/z where z.x or z.y or z.z could be 0 - what is best there?
As far as know the divide by 0 warning only shows up when there’s a divide with a constant value of 0. Direct X, nor any other graphics API, is going to police material properties being zero. Literally any of those values could be a zero and there’s no way to know at compile time.
but a simple division line in a shader can show the warning, as per thread: floating point division by zero at line warning in Unity 5.1
I do not know if there is a common practice to get around this or the warning is highly ignorable!
for float division and float3
Those are all surface shader examples, and there are situations (ie: bugs) where the surface shader will generate code that sets input struct variables to be hardcoded zeros… which produces the error. Specifically screenPos, worldNormal, and viewDir all have this issue.
The screenPos value is broken in the shadow caster pass, the worldNormal is broken if you include INTERNAL_DATA, and might be broken if you assign o.Normal at all, and I don’t remember which situations viewDir gets broken in since I think that got fixed at some point.
This is indeed surface shaders & is ugly Unity!
If I use INTERNAL_DATA then I have to deal with reflection & division BEFORE writing out to normal, to avoid the warnings (result is same!).
If I need to use In.worldRefl (and no INTERNAL_DATA) then dividing by IN.worldRefl gives me the warnings!
Fix the basics please!
(surface shaders are probably way behind the times, but it’s a long running project…)
This is specifically because I am doing my own Box Reflection shader code (which I do not understand 100%) but here is the problem area with 2 problematic divisions warning-wise (functionally fine)
float3 boxStart = _BoxCubePosition - _BoxCubeSize / 2.0;
float3 firstPlaneIntersect = (boxStart + _BoxCubeSize - worldPos) / nReflDirection;
float3 secondPlaneIntersect = (boxStart - worldPos) / nReflDirection;