Jump to content

Flickering shadows!


gameboy
 Share

Recommended Posts

  • 2 weeks later...

This kind of problem is typical of games using the method whereby the scene is rendered to a depth texture from a light source, and then the depth info is transformed and compared with when rendering from the camera.  "Depth buffer" is it called?  Precision is a big issue with this method.  There are offsets that can be tweaked, but ultimately you'll end up either with shadows that don't make it like they should, or light that doesn't make it that should have.

  I once saw a paper about a possible solution for this problem, but I no longer have the link;  it involved transforming the scene BEFORE rendering the depth textures, then compensating for it numerically in the depth render, so as to end up with a depth buffer that roughly aligns with the view frustrum and better uses the depth bits.

A more expedient solution is to make sure the assets don't have cases of self-shadowing that's cast too shortly (from too shallow a depth difference).  In the case of the building shown a few posts back, making that ledge twice as high would probably cure the problem, if the problem is what I think it is.

Edited by DanW58
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

9 hours ago, DanW58 said:

This kind of problem is typical of games using the method whereby the scene is rendered to a depth texture from a light source, and then the depth info is transformed and compared with when rendering from the camera.  "Depth buffer" is it called?  Precision is a big issue with this method.  There are offsets that can be tweaked, but ultimately you'll end up either with shadows that don't make it like they should, or light that doesn't make it that should have.

I suppose the mentioned problem is more about the light space moving. So each next camera position (particularly rotating, it's not so visible during camera translating) a shadow map texel has a different position in the real world space.

9 hours ago, DanW58 said:

I once saw a paper about a possible solution for this problem, but I no longer have the link;  it involved transforming the scene BEFORE rendering the depth textures, then compensating for it numerically in the depth render, so as to end up with a depth buffer that roughly aligns with the view frustrum and better uses the depth bits.

We already have a some kind of solution for that. It's not the production ready, but it works. I plan it for A25.

Link to comment
Share on other sites

Ah, really glad to hear you guys are working out a better solution.  In the meantime, perhaps all this needs is a little bit of offset.  I was looking through the shadow parts of the code and could not find a single offset tweak parameter anywhere.  I think a tiny bit of tweaking is needed to make sure shadows are not killed by rounding errors.  But perhaps there is tweaking in the shader;  haven't looked at your shaders yet;  not even sure what language they are in;  I used to do a lot of glsl hacking in the good old days.

Edited by DanW58
Link to comment
Share on other sites

3 hours ago, DanW58 said:

In the meantime, perhaps all this needs is a little bit of offset.  I was looking through the shadow parts of the code and could not find a single offset tweak parameter anywhere. 

Shadows have offset, it's called bias. But it won't help here, since offset/bias removes flickering on surfaces that cast and recieve own shadows. But the issue above is about flickering on edges when camera is rotating.

Link to comment
Share on other sites

/binaries/data/mods/public/shaders/glsl  ?

Ah, yes...  Good job with the shaders...  Looking at water_high.fs and so far I find nothing to fix.  Except Fresnel, maybe;  I once implemented real Fresnell, the whole equation, no simplifications, and it looked a lot better than any approximation.  That was after 2 weeks of trying to find a good simplification, using DataFit, and finding nothing that approximated real Fresnel well enough, and finally biting the bullet and doing it by the book.

Anyways, getting off topic here;  can't say I understand how bias would not help, not that I insist it would.  Anyhow, if a better solution is in the works, I rest my case.

Link to comment
Share on other sites

On 04/02/2021 at 4:01 AM, wowgetoffyourcellphone said:

It's part of a larger problem of models self-shadowing. Could be a shadow rendering bug or a model mesh issue (maybe some seams need welded, or there could be duplicate faces causing some sort of Z fighting).

Indeed, a duplicate face could be the culprit.

Does anybody know the filename/path of that mesh?  I'd like to look at it in Blender.

Edited by DanW58
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...