EEVEE and backlighting #57752
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
17 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#57752
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Windows 10
Nvidia GeForce GTX 1070
Blender 2.8
Hash:
2c2c996a1bWhen 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.
Added subscriber: @Lteng
#63627 was marked as duplicate of this issue
#60154 was marked as duplicate of this issue
#60165 was marked as duplicate of this issue
Added subscriber: @lichtwerk
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: SUZANNE_BACKLIGHT_TEST.blend
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).
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.
Added subscriber: @brecht
This is a tough one:
This is due to
61e4e3178dwhich 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 could figure out.
Should
viewNormalbe 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.
Added subscriber: @jeacom
This seems to be due to the specular lighting not being masked by shadow:
Added subscriber: @elkid
{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 @elkid
Added subscriber: @jwin64
Added subscriber: @spiegelball
Added subscriber: @zhanghua
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.
Regarding 2.: I'm diving into the code atm, @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:
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....)
Thanks for clarification.
I tried a few things as a makeshift workaround and found that plugging the layerweight node in the specular of the principled shader provides a bit of a "relief" even if not too perfect. It sort of temporarily "covers" up the blown out bleed through, at least until the bug gets sorted out eventually. Have not tried this on more complex geometry / scenes and I don't know if this will drastically affect specular highlights in general,, but I suppose Eevee is not really for super-realistic renders so may be able to get away with this for now.
I"m attaching a screen cap of it here:
Added subscriber: @Tysa
Oh this is just a temporary workaround (at least for me in some situations) to address the bleeding back light. Right now some lighting scenarios in Eevee with backlight and SSS shader will leak in backlight and fail to cast shadows. It seems to be a complicated kind of bug and may take a bit longer to fix.
Added subscribers: @Amarzbar, @ZedDB, @AdamPreisler
Added subscriber: @Interference
With the blend for the layer weight node set to zero, surely this just sets the specular of the material to zero? The reason it fixes the "specularity isn't masked by shadows" issue is because you've effectively turned specularity off, which is less than ideal if you've got a glossy material.
Yeah it is sort of an attempt to "tame" the specularity. It's a little bit different from turning spec off completely. I had it set to zero to just show the effect, but it does need to be set close to it. Anyway this is not really a "fix", just me trying to cheat and attempt some workarounds until the issue really gets addressed. I did find in the end that this cheat only works for certain lighting situations....oh well.
Added subscriber: @Querrr
Hi. Could you send this blender build 10.26.2018 (hash:
6479e800bc) for test?blender-2.80.10-26.zip
It is a big file. Hope I"m allowed to attach it here...
Thanks.
Testing the same file today and noticed a new light behavior on top of the light leaking. The light strength is 20 in this screen cap, but the effect is still visible even if I reduce the light to 1. Attaching the screen cap and comparisons here:
And here is the same effect when light strength is reduced:
I thought the issues was fixed because the lighting seemed to be working at least in the some versions last week, but somehow the issue returned again in the version yesterday and in the one today. Attaching a screen cap. Not sure what made the fix on the versions last week.
I can confirm it was working in the 2019-06-07 23:24 Windows build (hash:
749d53effd), so it was working at least as far back as then.Yeah, not sure what "fixed" it in those versions, but the subsequent versions (up to the one today) reverted back to the light bleeding scenario again. I am wondering if this issue will get addressed before 2.8's actual release.....
Added subscriber: @tokenyete
Added subscriber: @slowburn
Just wanted to mention that in the 2.81 Beta (2019-10-15 build), this problem still exists. Is it scheduled to be addressed in 2.82? Just hoping for the best. Thanks guys!
Added subscriber: @fclem
The new shadow system reduce the issue but cannot remove it completely. I will classify this as known limitation for now.
Changed status from 'Confirmed' to: 'Archived'
Closing as this is a documented limitation.
https://docs.blender.org/manual/en/latest/render/eevee/lighting.html#shadows (see contact shadows description)