Page MenuHome

EEVEE and backlighting
Open, NormalPublic

Description

System Information
Windows 10
Nvidia GeForce GTX 1070

Blender 2.8
Hash: 2c2c996a1b2

When lights are used for backlighting, in EEVEE the light seems to bleed into the front of the object (as if it 's not casting shadows). This was not the case in an older version (from Oct 26). In both cases, no settings have been altered.

Thanks.

Details

Type
Bug

Event Timeline

Philipp Oeser (lichtwerk) triaged this task as Needs Information from User priority.Nov 12 2018, 9:24 AM

Could you please share your blendfile?

Without this it is hard to tell what changed (you seem to be using multiple lights, it would also be good to have the an example to check other related settings....)

Marking as incomplete until we have this.

Hi,

This is the test file I used:

Thanks.

Hi,

Just want to follow up if there is any progress on this. Whether this is indeed a bug or if it's a setting that I was not aware of.

Thanks.

Also a follow up. The version today gives another variant result. I know that the energy for the lights is very high (i.e. 30) but it should not explain the variance). The energy of the light in this new version creates a blown out image compared to the same setting in yesterday's version. Again in both versions...compared to the October 26 version...the backlighting does not cast shadows (or is it a light setting that I did not know about).

Philipp Oeser (lichtwerk) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Nov 18 2018, 8:52 PM

Will check on it again

Update on some more tests made for today (Nov 28) with a new blender test file with one light (only the backlight this time) just to isolate the effect.
So far the same problem. Somehow since Oct, backlighting in eevee seems to behave differently.

This is a tough one:

This is due to rB61e4e3178d4a which remove self shadowing on contact shadows from surfaces.

The problem is that we separate visibility (shadows) and light power evaluation. The light power do the lighting correctly as if no occluder was present.
The issue is we need to determine the visibility of the fraction of the light received by the fragment.
Shooting shadow rays towards the light direction and rejecting the ones that are below the surface means that the shadowing term slowy decrease to 0 (1 being full shadowed) as the area light dives below the horizon. If we don't reject them, we have overshadowing (and shadow acnee because the horizon visibility term is applied twice.

This mean we need to shoot rays in a CONE that approximate the visible light portion that is above the horizon. Or do some weighting magic that @Brecht Van Lommel (brecht) could figure out.

Should viewNormal be flipped here depending if the BSDF does reflection or transmission? I would expect it to bias towards to the side the BSDF is on.

At least for Cycles we do that kind of thing for the ray start position, though I didn't look into the context here to see if it's really equivalent.

Contact shadows are only evaluated for reflection and not transmission.

Ah ok, I thought this was about diffuse transmission, should have checked the .blend file first. That is indeed more complicated.

This seems to be due to the specular lighting not being masked by shadow:

Ed (elkid) added a subscriber: Ed (elkid).EditedDec 4 2018, 4:38 AM

{F5806835}FYI ... I found this thread because I am also having this problem on 2.80 Beta downloaded today (2018-12-03).

My .blend file is quite large (156Mb), but I can describe it easy enough: I used a cube mesh to create a closed room, and cut out a doorway. A spot light outside the room shines through the doorway (with volumetric light and shadows). The camera is on the far inside corner of the "room," facing the doorway (thus, facing the light). EEVEE has light bleeding through the "walls." Cycles does not.

EDIT: I created a small blend file based on what I described above (it's only about 726Kb), and have attached it to this comment. If you open the attached file, you'll notice that the outline of the spotlight hitting the outside of the room is visible on the *INSIDE*, and it shouldn't be.

Its just a guess but there's something wrong with the shadow computation when its multiplyied by the reflection, seems like its not completelly zero allowing verry bright spots to "LEAK" when lamps are too strong.

I think it is more than the specular behaving oddly, when I disable the the specular for the light we still see a bit of the bleeding, although not as obvious (and of course without specular enabled it won't look as nice). I wonder if there is a temporary workaround, since this bug (?) may take a bit of time to address.

This comment was removed by Ed (elkid).

I have been paying attention to this issue and I am looking forward to solving it.

Yes hopefully this issue can be solved before the actual release.

It seems to me that there are two separate issues in this task.

  1. Diffuse light bleeding, as explained by Clément.
  2. Specular lightning not influenced by shadows.

Regarding 2.: I'm diving into the code atm, @Clément Foucault (fclem) could you point me to the right direction? I think I understand how lightning is calculated in lightning shader and that we have a out_spec and a out_diff factor, which are accumulated in the result.radiance field. Then the material pass is blended with the shadow pass. But somewhere some kind of separation must be still present, as shown above:

This seems to be due to the specular lighting not being masked by shadow:

There is no separation. The problem is that the specular lighting is VERY strong and even if multiplied by a very low value (the shadow) it will still produce a visible amount of light.

What could be done for this is to introduce a clipping value (or bias) at which the shadows is considered completely dark and will let no light pass trough (basically a step function). I think the VSM already have something like that but not the ESM.

I find a way to avoid leaking light, just flip normal in Interior design, better than solidify modifiers.

Won't flipping normals lead to complications down the pipeline? (Particle emission hair, textures, etc....)

There is no separation. The problem is that the specular lighting is VERY strong and even if multiplied by a very low value (the shadow) it will still produce a visible amount of light.

What could be done for this is to introduce a clipping value (or bias) at which the shadows is considered completely dark and will let no light pass trough (basically a step function). I think the VSM already have something like that but not the ESM.

Thanks for clarification.