We are looking into adding a much needed Shadow Terminator Bias to EEVEE for 4.5.
This is necessary because of the increased shadow precision and the removal of the light shadow bias option that happened when EEVEE-Next was released. This is also one of the most reported issue since the release of 4.2.
I would try keep that control similar to Cycles, or to a single slider for ease of use - though it’s always nice to have a bit more control sometimes, but maybe as a sub-set of sliders or controls in the GUI.
On first observation - it does improve the terminator line, but with some geometry it’s shifting such that the end result of location might not be desired.
Current release: obviously, poor quality on the cone.
What is your expected result for that cone geometry?
This cone is literally the worse case scenario (well, almost). So you need to make the bias extremely large (0.5m in my tests for a default cone). And yes, it will create other artifacts.
Then it looks like what you want is not what this feature is doing.
One thing you can do to make the shadowing sharp enough on a cone like this while keeping smooth shading on is to subdivide as much as needed (Cycles example).
I highlighted where the shadow terminator should be.
If you want the shadowing of the left cone but the shading of the right cone. Then you simply want unbiased raytraced shadows like below (Cycles example).
This, was never possible in EEVEE and will not be possible until we implement hardware raytracing. The only feature that was close to this was the screen space contact shadows which were far from being reliable either.
So, unless I am totally mistaken, this sounds like a feature request.
(As to Cycles - well, I never use it - so, i don’t compare Eevee to Cycles, and whatever Cycles does. That’s not meant as an attack or … anything like that at all, just for some insight on how my thinking works approaching Eevee renders.)
Obviously the improvement here is striking. While it is shifting the terminator over, and technically changing the overall shading result - in this case, that’s perfectly acceptable to me as I can still adjust the main blue/black position within the shader ramp itself (if even desired) and get a nice result.
ETA: The very slight noise you see in the second image is due to forum image compression, or something - the true image is very clean.
Looks good to me!
Rasterised shadows need a ‘bias’ control, and screen space contact shadows are still ‘filling the gaps’ in modern games.
So I guess this as good as it gets, before we get real-time ray-traced shadows.
