Your comments
Hi Joachim,
this bug does not seem to be fixed in 1.22 but I could narrow it down to the Lighting tab. When disabling Reflection probe support I get the error above:
undeclared identifier 'viewReflectDirection' at line 106 (on d3d11)
When enabling Reflection probe Support all is well.
Shader is on PBL.
Deferred or Forward, Metallic or Specular, Gloss or Roughness doesn't seem to have any impact on the repro.
Any ETA for 1.22?
Sounds like a viable hotfix solution for now. Enables prototyping of these kind of shaders.... and for optimization there's always the option to restructure the shader source code.
Just make a note somewhere for when you come around to overhaul the dependency system. So it doesn't come knocking at your door unprepared. :)
Just make a note somewhere for when you come around to overhaul the dependency system. So it doesn't come knocking at your door unprepared. :)
Same with lightDirection... variable gets used in clip call before it has been declared.
I am on a shader thats clipping fragments based on their distance to a plane. For testing purpose I also had the shader go pink when dotting the worldPos with a constant vector3 and putting the result into alpha clip.
I am on a shader thats clipping fragments based on their distance to a plane. For testing purpose I also had the shader go pink when dotting the worldPos with a constant vector3 and putting the result into alpha clip.
Just to let you know that this is still an issue as of 0.31 - bug confirmed.
Oorrr ... you could try to convince UT to get rid of hardcoded naming conventions as the ones required by Beast and to cook up something more generic and useful.
Sorry. Thats my April fools joke for today.
Sorry. Thats my April fools joke for today.
Great. Having no numerical values next to a slider made me abandon those things completely in Unity. There are times when you need to have 2 different materials have the same values for a specific variable. And although a clamped range would make sense you have to expose a float... annoying as hell.
Also for sliders: give them some room aka pixel length.
Often the jumps in numbers are too big when you drag that thing around.
Also for sliders: give them some room aka pixel length.
Often the jumps in numbers are too big when you drag that thing around.
I'd like to clarify.
The function returned a float2.
But the fragment shader used the function like this:
float node_12 = MyFunction(input);
So where node_12 should have been of type float2 it was not. This directly results in shader compile error.
The function returned a float2.
But the fragment shader used the function like this:
float node_12 = MyFunction(input);
So where node_12 should have been of type float2 it was not. This directly results in shader compile error.
Could you show me an example? Sounds like a very useful feature ... is this some kind of custom material editor?
Customer support service by UserEcho
Agreed. Nested nodes in nested nodes is kind of a special case that - probably - not many artists will utilize. No need for endless recursion where I work. I rather prefer a goto set of functions that I repeatedly use in a bunch of shader graphs. Some examples:
- Triplanar mapping
- Unpacking custom normal maps
- Clipping plane gradient
- Circular gradient
- Worldspace Top-Down mapping
- Vertex Colors masks for custom coloring
Code nodes inside nested nodes would be nice, too.