EEVEE-NEXT: PCF & soft shadow missing part #119725

New Issue

Open

opened 2024-03-21 05:47:04 +01:00 by Donovane · 9 comments

Donovane commented

2024-03-21 05:47:04 +01:00

System Information
Operating system: WIN 11 23H2
Graphics card: RTX 2060

Blender Version
Broken: DAILY 4.2 ALPHA FROM 21/03/2024
Worked: NONE ALPHA FEATURES

Short description of error
Wheny our using an area light for ligtning a scene when your come close to the mesh a part of shadow doesn't have PCF Shadowing and btw too soft shadow missed ! But if you are distant from the mesh you don't have the error

Exact steps for others to reproduce the error

Create a cube
Create an area light
Switch to Light properties to set custom value (Blend file included in this topic)
Switch to eevee next
and boom you got that :

Video : https://projects.blender.org/attachments/9d7df738-81aa-40f4-b3d4-e83d5ed2b831

Blend file in attachement

**System Information** Operating system: WIN 11 23H2 Graphics card: RTX 2060 **Blender Version** Broken: DAILY 4.2 ALPHA FROM 21/03/2024 Worked: NONE ALPHA FEATURES **Short description of error** Wheny our using an area light for ligtning a scene when your come close to the mesh a part of shadow doesn't have PCF Shadowing and btw too soft shadow missed ! But if you are distant from the mesh you don't have the error **Exact steps for others to reproduce the error** - Create a cube - Create an area light - Switch to Light properties to set custom value (Blend file included in this topic) - Switch to eevee next and boom you got that : ![https://i.ibb.co/p3PwfBd/untitled.png](https://i.ibb.co/p3PwfBd/untitled.png) Video : https://projects.blender.org/attachments/9d7df738-81aa-40f4-b3d4-e83d5ed2b831 Blend file in attachement

PCF AND SOFT SHADOW Broken.blend

901 KiB

2024-03-21 05-50-14.mkv

17 MiB

Donovane added the

labels 2024-03-21 05:47:05 +01:00

Donovane changed title from ~~EEVEE: PCF SHADOW MISSING PART~~ to EEVEE-NEXT: PCF & SOFT SHADOW SHADOW MISSING PART

2024-03-21 05:59:10 +01:00

Philipp Oeser commented

2024-03-21 09:30:26 +01:00

Member

Can confirm

Can confirm

Philipp Oeser added

EEVEE & Viewport

and removed

labels 2024-03-21 09:30:54 +01:00

Vitalijs commented

2024-03-22 07:53:36 +01:00

If you don't mind I would like to tackle with this.

For me it seems like borderline calculation / condition case.
Not sure yet in engine code or in its shaders, still tracing.

In this particular scene in Shadow Tile debug mode (F3 > Debug Menu > 10) the problematic tile is not marked as "used".
Also the case is sensitive to light "size" parameter.
For example, without moving camera the case disappears if the size is reduced from 100 to 96, and yet another pattern appears if the size is increased to 146 or so.

If you don't mind I would like to tackle with this. For me it seems like borderline calculation / condition case. Not sure yet in engine code or in its shaders, still tracing. In this particular scene in Shadow Tile debug mode (F3 > Debug Menu > 10) the problematic tile is not marked as "used". Also the case is sensitive to light "size" parameter. For example, without moving camera the case disappears if the size is reduced from 100 to 96, and yet another pattern appears if the size is increased to 146 or so.

Donovane commented

2024-03-23 02:38:15 +01:00

Author

If you don't mind I would like to tackle with this.

For me it seems like borderline calculation / condition case.
Not sure yet in engine code or in its shaders, still tracing.

In this particular scene in Shadow Tile debug mode (F3 > Debug Menu > 10) the problematic tile is not marked as "used".
Also the case is sensitive to light "size" parameter.
For example, without moving camera the case disappears if the size is reduced from 100 to 96, and yet another pattern appears if the size is increased to 146 or so.

Nah isn't logical because when you are too far of the mesh the shadow is okay and when you come close the changement come here... Need a refactoring

> If you don't mind I would like to tackle with this. > > For me it seems like borderline calculation / condition case. > Not sure yet in engine code or in its shaders, still tracing. > > In this particular scene in Shadow Tile debug mode (F3 > Debug Menu > 10) the problematic tile is not marked as "used". > Also the case is sensitive to light "size" parameter. > For example, without moving camera the case disappears if the size is reduced from 100 to 96, and yet another pattern appears if the size is increased to 146 or so. Nah isn't logical because when you are too far of the mesh the shadow is okay and when you come close the changement come here... Need a refactoring

Vitalijs commented

2024-03-26 20:53:07 +01:00

I got stacked with this one.

The code fragment that causes this case:

vec3 shadow_pcf_offset(...)
{
    ... // various checks

    if (!tile.is_allocated) {        
        return vec3(0.0); // this early return causes "sharp" edges on the problematic tile
    }
    
    ... // actual offset calculations
    return ws_offset;
}

For some reason shadow tile is not marked as is_used and is_allocated. Removing aforementioned early return fixes the shadows, but makes everything slower (which is the point of this check).

As far as I was able to trace/debug the case, the tile data leaving shadow compute shaders is fine (tilemaps_buf). Then it gets converted to tilemaps_img and passed to actual rendering and ray tracing. At this point the tile is not recognized as is_allocated.

Some insights or ideas on how visible shadow tiles are recognized and/or processed during rendering would be valuable.

I got stacked with this one. The code fragment that causes this case: ```glsl vec3 shadow_pcf_offset(...) { ... // various checks if (!tile.is_allocated) { return vec3(0.0); // this early return causes "sharp" edges on the problematic tile } ... // actual offset calculations return ws_offset; } ``` For some reason shadow tile is not marked as `is_used` and `is_allocated`. Removing aforementioned early return fixes the shadows, but makes everything slower (which is the point of this check). As far as I was able to trace/debug the case, the tile data leaving shadow compute shaders is fine (`tilemaps_buf`). Then it gets converted to `tilemaps_img` and passed to actual rendering and ray tracing. At this point the tile is not recognized as `is_allocated`. Some insights or ideas on how visible shadow tiles are recognized and/or processed during rendering would be valuable.

Donovane commented

2024-03-26 21:08:19 +01:00

Author

I got stacked with this one.

The code fragment that causes this case:
vec3 shadow_pcf_offset(...)
{
    ... // various checks

    if (!tile.is_allocated) {        
        return vec3(0.0); // this early return causes "sharp" edges on the problematic tile
    }
    
    ... // actual offset calculations
    return ws_offset;
}
For some reason shadow tile is not marked as is_used and is_allocated. Removing aforementioned early return fixes the shadows, but makes everything slower (which is the point of this check).

As far as I was able to trace/debug the case, the tile data leaving shadow compute shaders is fine (tilemaps_buf). Then it gets converted to tilemaps_img and passed to actual rendering and ray tracing. At this point the tile is not recognized as is_allocated.

Some insights or ideas on how visible shadow tiles are recognized and/or processed during rendering would be valuable.

Tell him to @fclem

> I got stacked with this one. > > The code fragment that causes this case: > > ```glsl > vec3 shadow_pcf_offset(...) > { > ... // various checks > > if (!tile.is_allocated) { > return vec3(0.0); // this early return causes "sharp" edges on the problematic tile > } > > ... // actual offset calculations > return ws_offset; > } > ``` > > For some reason shadow tile is not marked as `is_used` and `is_allocated`. Removing aforementioned early return fixes the shadows, but makes everything slower (which is the point of this check). > > As far as I was able to trace/debug the case, the tile data leaving shadow compute shaders is fine (`tilemaps_buf`). Then it gets converted to `tilemaps_img` and passed to actual rendering and ray tracing. At this point the tile is not recognized as `is_allocated`. > > Some insights or ideas on how visible shadow tiles are recognized and/or processed during rendering would be valuable. Tell him to @fclem

Thomas Dinges changed title from ~~EEVEE-NEXT: PCF & SOFT SHADOW SHADOW MISSING PART~~ to EEVEE-NEXT: PCF & soft shadow missing part

2024-03-27 11:51:42 +01:00

Miguel Pozo commented

2024-04-11 17:19:36 +02:00

Member

@Vitalijs-Komasilovs Good catch!

For some reason shadow tile is not marked as is_used and is_allocated. Removing aforementioned early return fixes the shadows, but makes everything slower (which is the point of this check).

While that may workaround the issue, having actually valid tiles tagged as invalid seems like a pretty bad problem that could cause other issues.

@Vitalijs-Komasilovs Good catch! > For some reason shadow tile is not marked as `is_used` and `is_allocated`. Removing aforementioned early return fixes the shadows, but makes everything slower (which is the point of this check). While that may workaround the issue, having actually valid tiles tagged as invalid seems like a pretty bad problem that could cause other issues.

Miguel Pozo added

and removed

labels 2024-04-11 17:19:54 +02:00

Vitalijs commented

2024-04-12 21:04:51 +02:00

Definitely removing is_allocated check is not a way to resolve this bug.

This is how the "problematic" tile looks like from the distance. In this case shadows are fine.

And here is the same tile close up with wrong shadows. It kind of extends "outside" the viewport. This might be the root cause.
Also there are other similar not valid tiles along borders of the viewport, but their shadow edges are not visible, thought.

Similar effect kicks in if you zoom out. All these marked tiles extend way beyond the viewport. But again, no visible artifacts in this case.

Maybe this will help to find the right clue.

Definitely removing `is_allocated` check is not a way to resolve this bug. This is how the "problematic" tile looks like from the distance. In this case shadows are fine. ![image](/attachments/b51b0c92-2fd4-414d-a6e2-ae60887a406d) And here is the same tile close up with wrong shadows. It kind of extends "outside" the viewport. This might be the root cause. Also there are other similar not valid tiles along borders of the viewport, but their shadow edges are not visible, thought. ![image](/attachments/5838bb0c-ad3b-49f0-bbf0-d7a4b4d99cb1) Similar effect kicks in if you zoom out. All these marked tiles extend way beyond the viewport. But again, no visible artifacts in this case. ![image](/attachments/6217cdfd-b683-4b70-a974-e95da8c05f0d) Maybe this will help to find the right clue.

284 KiB

331 KiB

560 KiB

Philipp Oeser referenced this issue

2024-04-15 12:42:24 +02:00

EEVEE Next: Shadows go sharp near edges of geometry #115475

Clément Foucault commented

2024-04-23 18:56:52 +02:00

Member

Can you test if this is linked to the Normal Bias? Seems like some tagging is missing because of this bias.

Can you test if this is linked to the `Normal Bias`? Seems like some tagging is missing because of this bias.

Vitalijs commented

2024-04-24 20:37:37 +02:00

Can you test if this is linked to the Normal Bias? Seems like some tagging is missing because of this bias.

Did testing. Seems unrelated to the Normal Bias, it visually slightly changes shadow distance from the object, but the tile is still not tagged.

Meanwhile I found that light Size significantly affects number of untagged tiles (see attached screenshots). And in case of shadows it is almost exclusively used for shadow_projection_shift calculations. Maybe due to this shift tagging routine (shadow_tag_usage_tilemap_punctual) is not able to map point coordinates to tile coordinates?

> Can you test if this is linked to the `Normal Bias`? Seems like some tagging is missing because of this bias. Did testing. Seems unrelated to the `Normal Bias`, it visually slightly changes shadow distance from the object, but the tile is still not tagged. Meanwhile I found that light `Size` significantly affects number of untagged tiles (see attached screenshots). And in case of shadows it is almost exclusively used for `shadow_projection_shift` calculations. Maybe due to this shift tagging routine (`shadow_tag_usage_tilemap_punctual`) is not able to map point coordinates to tile coordinates?

326 KiB

356 KiB

Clément Foucault referenced a pull request that will close this issue

2024-04-27 19:45:21 +02:00

WIP: Fix: EEVEE-Next: Wrong LOD tagging for punctual shadow maps #121167

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

5 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#119725

No description provided.