#"Incompatible keyword states" error in Shadergraph
1 messages · Page 1 of 1 (latest)
Hey! I’ve dealt with similar Shader Graph keyword conflicts before, especially when VR/stereo keywords like STEREO_INSTANCING or ON_UNITY_SINGLE_PASS_STEREO clash with your project’s render setup. I can help debug your custom code node and adjust the shader or graph to make it compatible with your current rendering pipeline.
Quick question—are you using any VR setup or single-pass stereo rendering right now, or is this happening on a standard build? Knowing that will help pinpoint the fix faster.
@pure nest
I'm not, no VR or stereo stuff. Just one camera
The code block that caused the problem as far as I can tell from going through and removing what I added until the error went away was
float4 sampleClipPos = mul(UNITY_MATRIX_P, float4(sampleViewPos, 1.0));
float2 sampleUV = (sampleClipPos.xy / sampleClipPos.w) * 0.5 + 0.5;
```
I couldnt figure out how to fix it 'right' though because afaik in Shadergraph you don't have access to Clipspace
the left result is my own code, you can see intersections are getting highlight, which looks wrong
right is a screen space cavity & curvature implementation, which darkens at intersections which is the desred behaviour
but you can see their result is a lot 'sloppier' pixel-wise
I was trying to port their cavity/curvature to my code which is what resulted in those errors
I wonder if the error is due to what UNITY_MATRIX_P expands into. Maybe look at its source code.
Also, it seems like this macro is from BIRP..?
By the way, from just these screenshots, I think that your current (left) looks a lot more interesting & stylized!
Thanks! Yeah my work is a lot cleaner, but I don't like how the terrain intersections have a lightened edge instead of darkened edge
im going to take a deep dive into the SSCC code tomorrow and see if I can isolate just the terrain edge darkening code and maybe port my code into their stuff instead of the other way around, seems like it will be easier
Trying to make sense of the SSCC code is not going great
I cannot seem to find where the code actually DOES anything?
like, I have been going through it
and all of it is fairly well self explainatory
except when I comment out parts that I expect should cause a change in the shader result, nothing happens
huge chunks of it ive commented out, and I get no errors, and no difference to the end result
but at the same time
other small chunks that don't appear to do anything of meaning or note, commenting them out causes the entire effect do vanish/do nothing
I can't find the meat, the body, the functional core of this mess
it doesn't help that its got all kinds of overloads and alternate paths for specific renderers and built in vs URP type stuff
SSCC?
Screen Space Cavity & Curvature
I made some progress
the line work is still a bit sloppier than I'd like 
float Curvature(float2 uv, float3 P)
{
float _CavityThreshold = 0.5;
float3 offset = float3(_Input_TexelSize.xy, 0.0) * (0.5);
float normal_up = FetchViewNormals(P, uv + offset.zy).g;
float normal_down = FetchViewNormals(P, uv - offset.zy).g;
float normal_right = FetchViewNormals(P, uv + offset.xz).r;
float normal_left = FetchViewNormals(P, uv - offset.xz).r;
float normal_diff = (normal_up - normal_down) + (normal_right - normal_left);
if (normal_diff < 0.0)
{
if (-normal_diff > _CavityThreshold)
{
return -2;
}
}
return 0;
}```
This is the formula for detecting cavity from the view normals
float3 offset = float3(_Input_TexelSize.xy, 0.0) * (0.5);
the 0.5 here used to be a _BorderThickness, setting it to values larger gives a larger pixel border, but no value smaller than 0.5 will work
value of 2 for example
oh wait, cavity threshold might be my number 👀
It's a process!
Seems a bit beyond me
lower threshold is a little better