This allow to reduce the amount of noise and reduce
the lost energy caused by low thickness and large
stride (low sample count).
Actual number of rays is twice the UI count.
The reasonning is that we already have a resolution limit
slider per light.
The global shadow resolution scale is usefull as a quick
speedup option to reduce shadow cost for viewport regular
work or for quick rendering. For final render, the per
light resolution limit is more suited than a LOD scale
since it doesn't modify the filtering of based on distance
from the camera.
This feature is really not hard to add back if there is
a compelling use case for it.
This make the filter have a constant width in shadow
space making sure to always filter the correct amount
of pixels.
This uses the receiver slope to put the samples on a
cone with its apex at the shading position instead of
setting up the disk in shading tangent space.
We limit the slope bias to 45 degrees and offset the
cone in normal direction if the angle between light and
receiver is greater than 45 degrees. This avoid any
self shadowing artifacts cause by this technique.
Pull Request: https://projects.blender.org/blender/blender/pulls/122266
The goal of this is to make it easier to add more BSDF
support in the future. Avoids code fragmentation and
allows easy entry points to all algorithms using BSDFs.
Pull Request: https://projects.blender.org/blender/blender/pulls/122255
The issue originates to the change in default view transform from Filmic
to AgX, which does slightly different clipping, and clips color to black
if there is any negative values.
This change implements an idea of skipping view transform for viewer
node when it is connected to the Pick output of the cryptomatte node.
It actually goes a bit deeper than this and any operation can tag its
result as a non-color data, and the viewer node will respect that.
It is achieved by passing some extra meta-data along the evaluation
pipeline. For the CPU compositor it is done via MetaData, and for the
GPU compositor it is done as part of Result.
Connecting any other node in-between of viewer and Cryptomatte's Pick
will treat the result as color values, and apply color management.
Connecting Pick to the Composite output will also consider it as color,
since there is no concept of non-color-managed render result.
An alternative approaches were tested, including:
- Doing negative value clamping at the viewer node.
It does not work for legacy cryptomatte node, as it needs to have
access to original non-modified Pick result.
- Change the order of components, and store ID in another channel.
Using one of other of Green or Blue channels might work for some view
transforms, but it does not work for AgX.
Using Alpha channel seemingly works better, but it is has different
issues caused by the fact that display transform de-associates alpha,
leading to over-exposed regions which are hard to see in the file from
the report. And might lead to the similar issues as the initial report
with other objects or view transforms.
- Use positive values in the Pick channel.
It does make things visible, but they are all white due to the nature
of how AgX works, making it not so useful as a result.
Pull Request: https://projects.blender.org/blender/blender/pulls/122177
Add fast image writing and reading variants for RT passes.
These variants do not perform range checking on values
and should only be used in cases where the written texel is
guaranteed to be in range. This eliminates additional
branching and simplifies shader logic.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/121117
Add fast image writing and reading variants for render passes.
These variants do not perform range checking on values
and should only be used in cases where the written texel is
guaranteed to be in range. This eliminates additional
branching and simplifies shader logic.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/121116
While having negative values in the data itself seems fine (at least
there is nothing in the design forbidding it, and it was also allowed in
GPv2 data), drawing code should only accept positive values, and clamp
negative ones to zero:
* It matches GPv2 behavior.
* Drawing code uses negative values as some sort of 'flag' for
rounded tips of strokes.
Note: This is a follow-up of !120840.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/122173
The mesh triangulation data is stored in CPU memory with the same format
as the triangles GPU index buffer. Because of that we can skip creating a
temporary copied owned by the GPU API. One way to do that is to just
upload the data directly and avoid keeping a reference to it. However, we
can only upload GPU data from the main thread with OpenGL, so instead
reference the data and keep track of whether to free it.
When drawing a mesh with a single material and 1.8 million faces, this
change gives a 12-15% improvement in framerate, from about 32 to 37 FPS.
Part of #116901.
Pull Request: https://projects.blender.org/blender/blender/pulls/122175
The pixels size was not computed in the right space.
This is the easy fix as refactoring the directional
shadows is too risky/time consuming right now.
Fix#121641
This was caused by wrong assumption that `shadow_radius`
is also a radius for area light. To avoid the confusion,
use a new property for area light shadow scaling.
In `SyncModule::sync_curves/sync_point_cloud` the material variable
can be used after it has been freed. The cause is that cryptomatte
can request a new material, which might trigger a relocation of the
references material.
This PR fixes this by doing the shadow sync before the cryptomatte
sync.
Pull Request: https://projects.blender.org/blender/blender/pulls/121909
Part of #116901.
The only non-obvious part is changing from using the `MR_DATA_LOOP_NOR`
flag as a signal to calculate normals and store them in `MeshRenderData` to
a more explicit check that the normals buffer is requested. In the future hopefully
these dependencies will be refactored to be part of the task graph instead.
Move the responsibility of deciding whether to calculate face corner
normals closer to the buffers and iteration, in preparation for replacing
the `data_flag` and `iter_flag` abstractions from the extractors system.
Part of #116901. Main benefits to this change are reduced function call
overhead and a simpler hot loop when face corner normals are extracted.
Code duplication is also reduced through use of templates. The downside
is that the access patterns aren't clearly better for the BMesh case where
a lot of data is stored array-of-structs style.
Make better use of the lazy calculation by avoiding storing a reference
to the calculated normals in the mesh render data. This reduces memory
usage from 282 MB to 225 MB in a test file with about 2 million faces.
Extract mesh logic to a separate function, and reorder subdiv loose
geometry extraction function. This is mainly to make a future diff
clearer. Also rename a variable to use more typical naming.
This was happening for any surface behind the near plane.
The sample bias is pushing receivers along normals so it
was visible on lights near the clip plane.
Fix#121815
Refactor subtask of #121929
Simplified void create_index_grids(const PBVH_GPU_Args &args, bool do_coarse)
with 2 extra functions that account for 2 code path generating faces indices.
This increase code readability and reasoning about its behavior instead of having a single uber function.
Pull Request: https://projects.blender.org/blender/blender/pulls/122020
A continuation of #116901. This one doesn't have a performance impact
in my testing. It also adds a bit more code compared to main so it isn't
really obviously "better" like the previous refactors. However it does
get us closer to removing the "extractors" callback iteration loop
(`edit_data` is the only other enabled by default), and I'd argue that
the final code is easier to iterate on in the future since it's more
self-contained.
I made an effort to avoid storing restart indices in the index buffers.
Though this requires a bit more calculation on the CPU (particularly
because the hidden gaps in the IBO need to be compressed out), it
reduces overall CPU->GPU traffic and removes the need to strip the
restart indices on Metal.
Pull Request: https://projects.blender.org/blender/blender/pulls/122084
This was broken when introducing the new lod bias
system. This is not compatible with shadow cascade.
Add TODO to implement the bias on CPU when choosing
the Level of detail of the cascade.
The main change is avoid storage of redundant data in the subdivision
draw cache, mainly by replacing reverse lookup from subdivided edge to
coarse edge. This way loops are structured as iteration over coarse
edges instead of iteration over subdivided edges with optional behavior
for vertices with matching base mesh faces. With that inversion the
information in the draw cache is trivial (or duplicated from an array
in `MeshRenderData`), so it's all removed, except for the subdivided
loose edge positions. That array is also shrunk though, by not
duplicating positions in between each subdivided edge. Its calculation
is more efficient for the same reason too.
Overall, besides code simplification, the effect should be lower
overhead with loose edges with GPU subdivision. Admittedly this isn't
a very important use case, but it's part of a general refactor trying
to use better data oriented design in this area (#116901).
Pull Request: https://projects.blender.org/blender/blender/pulls/122071
We call the `shadow.end_sync()` another time when running
the baking pipeline so that the sun shadow maps can
use the correct camera setup and scene bounds.
