While attempting to migrate a project from r72 to r104, I noticed that my project began exhibiting shadow acne that did not exist when running older versions of THREE js. I tried to pin point which revision introduced the shadow acne. But to complicate things further, I found out there are actually 3 revisions contributing to the shadow acne problem.
In my project, I am simulating a cloth with the material side set to THREE.DoubleSide, and the mesh is able to cast and receive shadows.
r75 - no shadow acne
r76 - shadow acne visible only when cloth is facing certain angles
r77 - shadow acne visible on back side consistently
r91 - shadow acne visible on both sides consistently
I’ve been following the Migration Guide and also googled the issue. I tried playing around with the shadow bias but have not been satisfied with the results. I am wondering if there are any other solutions or workaround, or if there is some additional migration steps specific to these 3 revisions? Or are these THREE js bugs and I should open an issue?
Can you please provide an editable live example that demonstrates the problem, first. We would need this anyway if an issue is reported at github later.
Many things have changed between r72 and r104 so it’s hard to tell what’s going wrong. Especially without seeing your code.
Thanks for the quick reply! I will put together some test cases
I have put together a minimal version of my project that recreates the issue: https://codesandbox.io/s/flagwaver-three-js-shadow-acne-t4e0y?fontsize=14
Thanks again for you help
EDIT: updated link
It seems the glitch can be mitigated by adding the following line of code:
light1.shadow.bias = - 0.01;
What do you think of the result?
I’ve tried different values for shadow bias before and unfortunately the results weren’t good, which is why I came here looking for other solutions. What I’ve found is that a shadow bias of about -0.004 or lower will get rid of the shadow acne, however, this also causes noticeable peter panning and also messes up the self shadowing of the cap at the top of the flagpole.
I think the problem could be solved without sacrificing quality if I could:
- Disable self shadowing on the cloth object only (the cloth should still be able to cast/receive shadows on other objects, such as the flagpole.)
- Set a shadow bias that is specific to the cloth object, as opposed to one specific to the light.
Is it possible to do either of these things? Or do you have any other suggestions for how to solve this issue?
@krikienoid does this happen with other objects? Or just the flag?
If we can confirm that there has been an overall regression in shadow quality since r72, it might be worth putting in the time to investigate why. If it’s just the flag, then not so much.
The flag is the only object I personally have an issue with. However, based on what I’ve researched, other people have encountered similar issues with objects that have zero thickness or have a material with THREE.DoubleSide.
I think this past Github issue may be possibly related to the behavior we are seeing now: https://github.com/mrdoob/three.js/issues/8692
After doing some more tests, I found out that the cloth (or more generally, paper-thin objects with THREE.DoubleSide) did not support receiveShadow in older versions of THREE js. I think when receiveShadow support was added/modified in later versions, it also made it possible for shadow acne to appear on these kinds of objects.
I have currently removed receiveShadow from the cloth as a workaround to the issue.
Not ideal for anyone who actually needs objects like that to recieve shadows, but at least I can move on with the migration for now.