Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Soft shadows of a small light source are not displayed correctly #443

Open
DEBIHOOD opened this issue Sep 9, 2020 · 4 comments
Open

Soft shadows of a small light source are not displayed correctly #443

DEBIHOOD opened this issue Sep 9, 2020 · 4 comments
Assignees

Comments

@DEBIHOOD
Copy link

DEBIHOOD commented Sep 9, 2020

If the point light source is small enough radius(in this example, radius is 0.026 m), it causes problems,
at some point shadow goes from a soft state to an infinitely sharp.
image
image

Example scene
softshadowsbug.zip


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@Dade916
Copy link
Member

Dade916 commented Sep 9, 2020

You may just literally observing the bits in floating point 32 but I'm going to check.

@Dade916 Dade916 self-assigned this Sep 9, 2020
@CodeFHD
Copy link
Member

CodeFHD commented Sep 9, 2020

I believe this condition is responsible:

const float cosThetaMax = sqrtf(Max(0.f, 1.f - radiusSquared / centerDistanceSquared));

It fits with a calculation on the distance and light radius where I observe this change. I'm currently trying to compile what I believe would fix this...

@CodeFHD
Copy link
Member

CodeFHD commented Sep 9, 2020

Ok now after looking closer, the condition as such is actually not calculated wrong. I was misinterpreting at first due to an approximation in it.

If I just remove the condition in the line after, the image in my test scene improves a lot. Only when I use very small light radius some error starts to appear (radius = 0.0175 compared to radius = 0.45).

Maybe it is worth to remove the fallback condition, if it causes more unexpected results than to have it? Unless you know specific scenes that don't work well that way?

@CodeFHD
Copy link
Member

CodeFHD commented Sep 14, 2020

I may have found a solution. What I did was to still do the cone sampling and subsequent shadow ray tracing, but replace the pdfw's and return value with the computations for a point light.

Comparison image:
Top row: current code (shows sudden switch to point light)
Middle row: current code without condition (shows banding in wide top view)
Bottom row: new code

compare

I will submit a pull request so you can have a look if you agree.

P.S.: I was wrong about the condition being an approximation, it is correct. I only wonder about a little optimization: if you really need the Max() evaluation, as there already is a check for centerDistanceSquared - radiusSquared < DEFAULT_EPSILON_STATIC just before?

Dade916 added a commit that referenced this issue Jan 29, 2021
Change spherelight implementation to provide an alternative to the pointlight fallback (issue #443)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants