This was caused by 2 things: Shadow map bias and aliasing.
It made the expected depth of the shadowmap further than the surface
itself in some cases. In normal time this leads to light leaking on normal
shadow mapping but here we need to always have the shadowmap depth above
the shading point.
To fix this, we use a 5 tap inflate filter using the minimum depth of all
5 samples. Using these 5 taps, we can deduce entrance surface derivatives
and there orientation towards the light ray. We use these derivatives to
bias the depth to avoid wrong depth at depth discontinuity in the shadowmap.
This bias can lead to some shadowleaks that are less distracting than the
lightleaks it fixes.
We also add a small bias to counteract the shadowmap depth precision.
Alpha blended Transparency is now using dual source blending making it
fully compatible with cycles Transparent BSDF.
Multiply and additive blend mode can be achieved using some nodes and are
going to be removed.
This is to simplify the usage of Volumetrics.
Now it automatically detect if there is any Volumetric material in the
view and allocate the needed buffer if any.
This change the logic a bit, when 2 bsdfs using SSS are mixed, we use the
one with the biggest radius (on a per pixel basis).
This change from previous behavior which was to select input 1 if radius
was greater than 0.
Some GLSL compilers seem to not have problems with \ to break preprocessor
directives. I couldn't find other places with similar code, but fixing this
case by case is not ideal and the same issue may come up again.
Main change are:
- the fresnel LUT is separated from the main GGX LUT.
- LUTs use sqrt(1.0 - NV) as roughness remapping. Improving precision and
removes needs for acos().
- LTC LUT is normalized by matrix middle component. Improving precision.
We are still ditching the specular intensity of SSR (ssr_data.xyz).
But at least now there is some comment about it.
See T61704 for user reports on that matter.
Comments with the blessing of Clément Foucault.
This is an important change. Starting from now, all lights have a finite
influence radius (similar to the old sphere option for BI).
In order to avoid costly setup time, this distance is first computed
automatically based on a light threshold. The distance is computed
at the light origin and using the inverse square falloff. The setting
can be found inside the render settings panel > shadow tab.
This light threshold does not take the light shape into account an may not
suit every case. That's why we provide a per lamp override where you can
just set the cutt off distance (Light Properties Panel > Light >
Custom Distance).
The influence distance is also used as shadow far clip distance.
This influence distance does not concerns sun lights that still have a
far clip distance.
---
This change is important because it makes it possible to cull lights
an improve performance drastically in the future.
This is more like a static optimisation when some parameters are set to 1.0
or 0.0. In theses case we use a more optimized version of the node.
This also revisit the transmission parameter behaviour to make it closer to
cycles.
Do note that it does not match cycles implementation.
Also we could precompute the hash per strand before rendering but that would
suggest it's not per engine specific.
If we make the random value internal to blender then it won't be a matter
because other renderers will have access to the same value.
SSR does not work with hair strands. Basically, the rays are too much
random to ever converge properly and just result in a soup of self
inter reflections.
So forcing it to not produce any SSR. Could potentially save some bandwidth
by not rendering hair to the SSR buffers.
This "improve" the viewport experience by reducing the noise from random
sampling effects (SSAO, Contact Shadows, SSR) when moving the viewport or
during playback.
This does not do Anti Aliasing because this would conflict with the outline
pass. We could enable AA jittering in "only render" mode though.
There are many things to improve but this is a solid basis to build upon.
This gets rid of the need of a geom shader and instancing.
Both are pretty slow compared to the new method.
The only moment the old method could be better is when scene is filled
with lots of objects and most of the objects in the shadow map appear
on every layer.
But even then, we could optimize the culling and minimize the overhead.
This refactor modernise the use of framebuffers.
It also touches a lot of files so breaking down changes we have:
- GPUTexture: Allow textures to be attached to more than one GPUFrameBuffer.
This allows to create and configure more FBO without the need to attach
and detach texture at drawing time.
- GPUFrameBuffer: The wrapper starts to mimic opengl a bit closer. This
allows to configure the framebuffer inside a context other than the one
that will be rendering the framebuffer. We do the actual configuration
when binding the FBO. We also Keep track of config validity and save
drawbuffers state in the FBO. We remove the different bind/unbind
functions. These make little sense now that we have separate contexts.
- DRWFrameBuffer: We replace DRW_framebuffer functions by GPU_framebuffer
ones to avoid another layer of abstraction. We move the DRW convenience
functions to GPUFramebuffer instead and even add new ones. The MACRO
GPU_framebuffer_ensure_config is pretty much all you need to create and
config a GPUFramebuffer.
- DRWTexture: Due to the removal of DRWFrameBuffer, we needed to create
functions to create textures for thoses framebuffers. Pool textures are
now using default texture parameters for the texture type asked.
- DRWManager: Make sure no framebuffer object is bound when doing cache
filling.
- GPUViewport: Add new color_only_fb and depth_only_fb along with FB API
usage update. This let draw engines render to color/depth only target
and without the need to attach/detach textures.
- WM_window: Assert when a framebuffer is bound when changing context.
This balance the fact we are not track ogl context inside GPUFramebuffer.
- Eevee, Clay, Mode engines: Update to new API. This comes with a lot of
code simplification.
This also come with some cleanups in some engine codes.
This is an optimization / cleanup commit.
The use of a global ubo remove lots of uniform lookups and only transfert data when needed.
Lots of renaming for more consistent codestyle.
This is an improvement on the old spining quad method that was giving artifacts when the reflection ray was nearly aligned with the sphere center.
This might be a bit heavier but it's worth it.
- Hashed Alpha materials were outputing their alpha values even if the final pixel has no blending and thus no transparency.
- Opacity was not clamped when using "add closure" nodes.
This augment the existing irradiance grid with a new visibility precomputation.
We store a small shadowmap for each grid sample so that light does not leak through walls and such.
The visibility parameter are similar to the one used by the Variance Shadow Map for point lights.
Technical details:
We store the visibility in the same texture (array) as the irradiance itself (in order to reduce the number of sampler).
But the irradiance and the visibility are not the same data so we must encode them in order to use the same texture format.
We use RGBA8 normalized texture and encode irradiance as RGBE (shared exponent).
Using RGBE encoding instead of R11_G11_B10 may lead to some lighting changes, but quality seems to be nearly the same in my test cases.
Using full RGBA16/32F maybe a future option but that will require much more memory and reduce the perf significantly.
Visibility moments (VSM) are encoded as 16bits fixed point precision using a special range. This seems to retain enough precision for the needs.
Also interpolation does not seems to be big problem (even though it's incorrect).
Previously the lighting of SSS material was not present in reflection probe or irradiance grid.
This does not compute the SSS correctly but at least output the corresponding irradiance power to the correct output.
This option prevent from automatically blurring the albedo color applied to the SSS.
While this is great for preserving details it can bleed more light onto the nearby objects since the blurring will be done on pure "white" irradiance.
This issue is to be tackled in a separate commit.
