Shader Graphs allows me to build a shader with "incorrect number of arguments" / Displacement Shader

Hi all!

I was trying to put together part of a shader which displaces vertices along their normals, think "puffy snow on a log". The strength of displacement is based on a displacement map.



In the above image, the displacement is uniformly applied to all vertices, in the direction of their normals, so the result was uniformly puffy. The output of the Add node goes into a HD Lit Master Position input.



When I combined the output from the One Minus (to only make the "snow" part puffy) with the Normal Vector and fed that into the Add node (see image above), I got the error

Shader error in 'ShaderName': incorrect number of arguments to numeric-type constructor at line 2963 (on metal)

When I look at that line, sure enough, three inputs for a float4:

output.uv0 = float4(input.uv0, 0.0f, 0.0f);

So now I am wondering about two things:

1. Yes, it's a bug, but maybe I am trying to do something fundamentally silly here and this is not the way to combine a displacement texture (the One Minus) with Normal Vectors to Add to the Position to feed into the Position field?

2. Is there a way I could avoid the bug by splitting/recombining the vector4 into a vector3? (I've tried, but it did not work)

Many thanks in advance for any help or hints!

 

That's likely not the line the error is actually occuring on. I suspect input.uv0 is a float2 value, so float4(input.uv0, 0.0, 0.0) is actually correct.

However I've noticed Shader Graph does a lot of float4 > float3 and vice versa conversions without being explicit about them. On Windows these might throw a warning, but Apple's OpenGL and Metal are much more stringent about this kind of ambiguity in shader and will outright error instead. There may be nothing you can do at the moment apart from post a bug or hand modify the generated shader.

 

You are absolutely right – it is correct indeed.

That is very helpful, thank you so much! In addition to posting a bug, I'll also see whether I can continue working on the Amplify shader. Cheers!

 

What's weird to me is that not even an explicit vec4 -> vec3 conversion step helps (if there's a better one than Split/Combine, let me know, please).



Again, I may be looking in the wrong spot.

 

When I said "Shader Graph does", I really mean the shader code that Shader Graph includes, rather than the shader code generated by your graph. Those kinds of splits and recombines, are fine. Even plugging an rgba(4) into an rgb(3) or vice versa I think generates proper code. The problem is more from the extra code outside your control added by the nodes themselves. Like if you add a node to access the tangent vector, that triggers a bunch of extra code to calculate that data, and transfer it from the vertex shader to the fragment shader, then add some code to access it. For some nodes some of that code is what is broken, and indeed it was for the tangent vector.

 

Thanks so much for your clarification, bgolus – helpful as always!

 

I just noticed a similar issue with gradients in shader graph. It turns out, hilariously, that Shader Graph uses string conversion of floats using the current CultureInfo of your machine, which can result in decimal commas in the generated shader code. I've reported this as a bug.