[3.x] Backport DirectionalLight fade_start property
#60246
Conversation
Calinou
force-pushed
the
directional-light-add-fade-start-3.x
branch
2 times, most recently
from
8225ea2
to
659ac9e
Compare
Calinou
force-pushed
the
directional-light-add-fade-start-3.x
branch
from
659ac9e
to
c0e3127
Compare
Calinou
changed the title
fade_start property to 3.xfade_start property to
|
Looks ok, but this is breaking I think, in the sense it will change what the directional shadows look like. Would it be worth introducing a compatibility switch in project settings, to change the shaders back and forth? @clayjohn not sure what you think. |
Calinou
changed the title
fade_start property tofade_start property
We usually accept minor visual changes between minor versions, especially if they'll look better in the vast majority of projects (which I expect to be the case here, as you'll be able to see shadows further with the same performance cost). Tweaking the scene to match the previous visuals is also very fast to do. Adding a compatibility project setting would be a lot of effort for little gain. |
| // Using 1.0 would break `smoothstep()` in the shader. | ||
| state.scene_shader.set_uniform(SceneShaderGLES2::FADE_FROM, -split_offsets[shadow_count - 1] * MIN(fade_start, 0.999)); | ||
| state.scene_shader.set_uniform(SceneShaderGLES2::FADE_TO, -split_offsets[shadow_count - 1]); | ||
|
|
There was a problem hiding this comment.
Do we need to send this? Can we use one of the light_split_offsets in the shader for the furthest value?
There was a problem hiding this comment.
I've copied the 4.x approach, I'm not sure if we can reduce the number of uniforms sent without changing how it looks.
There was a problem hiding this comment.
Well for SceneShaderGLES2::FADE_TO I couldn't help noticing we have already sent this value 5 lines above (as split_offsets), and each uniform is additional extra API (especially in GLES2), and can compete for limited space in GPU for highly cached stuff.
The only question is which of these 4 is the furthest split, but I'm presuming this must have been previously calculated in the shader (for it to have worked previously).
There are 2 questions that appear:
- Is it more expensive to use the existing
ifclauses than to send as an independent additional uniform (this may be the case, dynamic branches aren't good but maybe we have paid the price already) - The existing
light_split_offsetis stored ashighp. This might not be necessary for the calculation so could maybe be downcast.
I guess these can only be answered by performance testing especially on mobile. And I guess could be left to a follow up. I'm not sure whether this was considered in 4.x, but maybe there were additional factors at play.
|
Some screenshots showing the improvement would be handy too! 👍 |
Calinou
force-pushed
the
directional-light-add-fade-start-3.x
branch
from
c0e3127
to
5821b62
Compare
Calinou
force-pushed
the
directional-light-add-fade-start-3.x
branch
from
5821b62
to
29214e9
Compare
I've added screenshots to OP and fixed Fade Start when using the new PSSM 3 Splits shadow mode. |
- Implement shadow fading when using the Orthogonal shadow mode (like in `master`). This allows customizing the distance at which directional shadows start to fade away. Shadow fading will also always start at the same distance now, regardless of the current shadow mode in use. This is useful for enclosed levels to prevent shadows from fading at all with a well-tuned maximum distance. The default fade start value (0.8) results in fading happening later in the distance compared to the previous behavior, where fading started from the last shadow split distance (0.6 in PSSM 4 Splits and 0.1 in PSSM 2 Splits).
Calinou
force-pushed
the
directional-light-add-fade-start-3.x
branch
from
29214e9
to
4fefb13
Compare
|
Thanks! |
Follow-up to #60186 (can be merged independently).
master).This allows customizing the distance at which directional shadows start to fade away. Shadow fading will also always start at the same distance now, regardless of the current shadow mode in use.
This is useful for enclosed levels to prevent shadows from fading at all with a well-tuned maximum distance.
The default fade start value (
0.8) results in fading happening later in the distance compared to the previous behavior, where fading started from the last shadow split distance (0.6in PSSM 4 Splits and0.1in PSSM 2 Splits). I can decrease this default fade start value if desired, but I think this new default is better suited to most use cases.Testing project: test_shadow_fade_start_3.x.zip
Preview
Screenshots taken with GLES3, but this feature works the same way in GLES2.
Fade Start = 0.8 (default)
Different Fade Start values with PSSM 4 Splits