Improve Shadow Quality?

[aVersionOfReality]

I'm trying to figure out how to get the cleanest cast shadows that I can. I have a toon shader, and am using the ID pass to get lines on the edges of the shading.

With default settings, it looks okay on the shadow cast by Suzanne, but the self shadows on the skirt are too blurred.

If I crank the cascades up to 32 (seems to be the max) then it looks better, but still not great, and triples the render time.

If I up the Sun resolution to 4096 as well that helps a bit more. The cast shadows are now fine, but the self shadow still isn't wonderful. And this takes it from 5gb VRAM to 11gb!

Is there something I'm missing to improve the self shadows? I was sure I had better results than this in the past. I tried Grid Size but it doesn't seem to help with shadows at all.

[aVersionOfReality]

Oh I'm silly. Its the regular old shadow terminator problem. If I change the Offset on the toon shader, it gets covered up. Here's without and with offset of .2. This same problem happens in eevee and cycles.

[aVersionOfReality]

Thank you! I will experiment with all these things.
A related question: Is it possible to get just the shadow mask separate entirely from shading? In earlier versions of Malt this was possible, but it doesn't seem to be with any of the new nodes or internal nodes. Do I have to build that myself?

[pragma37]

That should be the same as a diffuse node with the gradient and offset set to 0, right?

[aVersionOfReality]

malt.shadow.offset-1.mp4

Offsetting the position with the Normal seems to be working very well! Is there any downside to doing this?

Changing the Distribution doesn't do much (the default 0.9 is already the best looking.) changing the min and max clip and max distance did help some (equivalent of doubling the cascades).
So overall its a huge improvement!

[pragma37]

Is there any downside to doing this?

Well, you're offsetting the shadowed position, so you're technically getting "wrong" results.
In practice, this should be ok for small values. Some shadow bias is always required for shadow-maps (Malt already applies a bit internally). The tricky part is making it as small as possible, but not smaller.
The problem here is that the more different the true and the shading normals are, the larger the bias may need to be.

The main issue with offsetting the position like that is that you're offsetting the whole shading position (affecting light distance attenuation too), while shadow bias is typically only used for the shadow computation.
But again, it should be ok for small values.

I could add a shadow bias parameter to the nodes, or try to do a better job at computing it automatically. 😅

[aVersionOfReality]

That makes sense. It may especially need a lot of bias in some of my setups since I'm using smoothed Normals from geometry nodes. I suspect I could also feed a geonodes attribute with something based on the difference between the base and smooth Normals and use that to modify the bias further per vertex.
It also sounds like a reason I would want to separate the shadows from the shading, so that I can handle this on just a shadow basis.

[aVersionOfReality]

That should be the same as a diffuse node with the gradient and offset set to 0, right?

Its not quite the same. I'm looking for only the shadow pass. If you have A diffuse set to 0 and 0, there's still a lot there if you disable the shadows.

I'm after this for several reasons:

• to better visualize exactly what is shading (from dot(n,l)) and what is shadows
• Because I will be blending many Shading passes, but only need 1 shadow
• I want to get the shadows into a screen shader and try some effects on them.

[pragma37]

The problem is that any "shading" self-shadow (dot(n,l)) is also a shadow-map shadow.
You can read only the shadow-map, but those self-shadows are going to be in the shadow-map too (just a bit less cleaner).
You can disable self-shadows and set the node to full range, but then you'll also lose some projected shadows from the same object.
You may try baking mesh thickness for better detection and rolling your own thing, but if you want true perfect self-shadow detection (as in, ignore any non projected shadow) you need ray-tracing.

[pragma37]

Well, another much simpler option could be rendering shadow maps with front-face culling and adding a bit of bias.

[aVersionOfReality]

It is fine if there is redundancy between the shadow map and dot nl shading, and if the isolated shadow map looks yucky. I want to make a video showing people what these different parts of the pipeline are actually doing and how they combine.

[pragma37]

In that case, something like this should do it:

vec3 only_shadow(bool self_shadow)
{
    ivec4 light_groups = ivec4(1,0,0,0);
#ifdef IS_MESH_SHADER
    light_groups = MATERIAL_LIGHT_GROUPS;
#endif
    
    vec3 result = vec3(1.0);
    for (int i = 0; i < LIGHTS.lights_count; i++)
    {
        for(int group_index = 0; group_index < 4; group_index++)
        {
            if(LIGHT_GROUP_INDEX(i) != light_groups[group_index])
            {
                continue;
            }
            Light L = LIGHTS.lights[i];
            LitSurface LS = npr_lit_surface(POSITION, NORMAL, ID.x, L, i, true, self_shadow);

            result *= LS.shadow_multiply;
        }
    }

    return result;
}

[aVersionOfReality]

Excellent, I'll try that!
Is it also possible to do something like this to get info about the light, like its color and strength? I thought there used to be a light info node of some sort. I know we have these two light nodes, but if I remember correctly those are for making new lights within the shader, not for getting the info of existing lights?