Declared property with same value as literal gives different results for power.

Unity Engine
, ,
1

I’ve seen this a couple of times since starting a new project but this is the most easily isolated case.

Versions:
Unity 2021.1.18f1
Shadergraph 11.0.0
Render Pipeline: HDRP

Trying to add a softness slider to a depth based “pulse” effect but when I expose a simple float property the output seems oddly truncated and I can’t reason about what’s casuing it.

This shows the graph with the Softness property disconnect and a literal value of 1 plugged in. Result as expected.

7469708--917650--upload_2021-9-3_17-14-35.jpg
7469708--917650--upload_2021-9-3_17-14-35.jpg1756×976 179 KB

Same expected result with a literal value of 4 instead of 1.

7469708--917651--upload_2021-9-3_17-16-30.jpg
7469708--917651--upload_2021-9-3_17-16-30.jpg1756×976 177 KB

Then I plug in softness and get this result with a property driven value of 1 from the material.

7469708--917654--upload_2021-9-3_17-16-42.jpg
7469708--917654--upload_2021-9-3_17-16-42.jpg1756×976 171 KB

Can anyone shed some light on what’s happening here? I suspect this is a bug as swapping a literal for a property with the same value should never cause this to happen but maybe there’s something about shader graph I’m not aware of here. I checked and tried forcing the same precision across everything and got the same divergent outputs. Stranger still, if I don’t expose the property to the material inspector and jsut default the value to 1, the effect doesn’t render at all.

Full graph:

7469708--917663--upload_2021-9-3_17-43-22.png
7469708--917663--upload_2021-9-3_17-43-22.png2055×619 83 KB

Pastebin of graph YAML: Ping shader - Pastebin.com

Put on object close to camera, set material to transparent and look through it to origin property’s world position and should render over any opaque geometry near origin property value.

2

Ok, so not really a bug, but it presents like one.

I should have checked the compiled output. Can’t have negative f values for pow(f,e). If I move the softness parameter to after that abs() it’s fine. Still confused about the strange output though and why it would work with a literal value for e and not for a parameter of the same value. Perhaps the generates does some optimisation trick when pow has literal inputs. Also, having to check the compiled shader in the inspector to see errors feels like poor UX - shader editor should validate power inputs and warn if there’s a potential issue.