This is due to hardcoded color and subdivision value. Also scale and
offset properties stored in overlay stuct was not considered. Now
multiply the transform matrix with `grid_mat` to make use of these
properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/134382
This patch removes the compositor texture pool implementation which
relies on the DRW texture pool, and replaces it with the new texture
pool implementation from the GPU module.
Since the GPU module texture pool does not rely on the global DST, we
can use it for both the viewport compositor engine and the GPU
compositor, so the virtual texture pool implementation is removed and
the GPU texture pool is used directly.
The viewport compositor engine does not need to reset the pool because
that is done by the draw manager. But the GPU compositor needs to reset
the pool every evaluation. The pool is deleted directly after rendering
using the render pipeline or through RE_FreeUnusedGPUResources for the
interactive compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/134437
In certain setups where passes are used in the viewport compositor,
blender will crash. This happens because passes may not be available
when the compositor first run but then become available in later runs.
Possibly because EEVEE is still compiling shaders. This is problematic
for the compositor because it caches the result of node tree compilation
for the specific data available, like passes, and the compositor does
not get informed when data becomes available like in the case of EEVEE
to invalidate the cached node tree compilation result.
Caching of node tree compilation was always a source of bugs but we
managed to workaround them in the past, so before we work on a fix for
this crash, we first evaluate the removal of caching to see if we can
live without it. Especially since a fix will be rather involved for the
release branch at this stage.
The time it takes to compile the node tree is:
- Small Tree (~10 nodes): 0.3ms.
- Medium Tree (~50 nodes): 0.6ms.
- Huge Tree (~300 nodes): 3ms.
The difference is not noticeable to the eye, probably since as the tree
becomes bigger, the evaluation time becomes more dominant, and small
trees are fast to compile.
It should be noted that we intended to remove caching in the future to
support things like lazy evaluation of node inputs, but we though a few
optimization needs to be done on the GPUMaterial compiler side to make
compilation faster, since it is the main bottleneck during compilation.
So considering this, I think it is acceptable to disable caching of node
tree compilations for the time being. I intend to optimize it such that
it always becomes less than 1ms, but we will have to delay that to 4.5.
Pull Request: https://projects.blender.org/blender/blender/pulls/134394
The root cause is still unknown. But this patch disables
rendering of objects that will produce no volumetric effect.
This does fix the issue reported.
The changes from 29356e2bf7
fixed a readability issue with loose wire not being as prominent as
regular surface wireframe.
But also added a regression where the object color wireframe mode
made the object color imperceivable when the object is selected.
This commit fixes the issue by setting the facing factor to 0.5 for
loose wires. This way, both the theme color and object color wireframe
more are blended enough to be distinguishable and still retain the
object color hint.
Use sub-pixel differentials for bump mapping helps with reducing
artifacts when objects are moving or when textures have high frequency
details.
Currently we scale it by 0.1 because it seems to work good in practice,
we can adjust the value in the future if it turns out to be impractical.
Ref: #122892
Pull Request: https://projects.blender.org/blender/blender/pulls/133991
This patch allows the compositor context to specify exactly which
outputs it needs, selecting from: Composite, Viewer, File Output, and
Previews. Previously, the compositor fully executed if any of those were
needed, without granular control on which outputs are needed exactly.
For the viewport compositor engine, it requests Composite and Viewer,
with no Previews or File Outputs.
For the render pipeline, it requests Composite and File Output, with
node Viewer or Previews.
For the interactive compositor, it requests Viewer if the backdrop is
visible or an image editor with the viewer image is visible, it requests
Compositor if an image editor with the render result is visible, it
requests Previews if a node editor has previews overlay enabled. File
outputs are never requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/133960
Make sure the gpu subdiv shader variant is only used if there
is no cages as the requested batch has a different layout in
this case.
Also add the missing shader variant for vertex normal display
with GPU subdiv.
Now EEVEE outputs the in-progress render depth buffer
for GPencil to intersect with.
The overlays will clear the depth buffer in such situation
and still do the depth prepass for correct intersection.
Moreover, this patch makes overlay engine not requiring
a depth prepass when run with EEVEE at 1:1 render resolution.
This avoids significant overhead of the depth prepass.
Pull Request: https://projects.blender.org/blender/blender/pulls/133971
Add workaround path to process the vertices the same way as
the `overlay_extra_vert` shader.
We nudge the non-origin vertices in the batch to be able
to not require loading the VCLASS attribute. Thus making
the change local to the shader and not requiring another
shader variant.
There is a special case in the compositor code where viewer nodes are
treated as composite nodes. This patch renames relevant methods and
updates comments to clarify this use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/133811
Previously, there was a `StringRef.copy` method which would copy the string into
the given buffer. However, it was not defined for the case when the buffer was
too small. It moved the responsibility of making sure the buffer is large enough
to the caller.
Unfortunately, in practice that easily hides bugs in builds without asserts
which don't come up in testing much. Now, the method is replaced with
`StringRef.copy_utf8_truncated` which has much more well defined semantics and
also makes sure that the string remains valid utf-8.
This also renames `unsafe_copy` to `copy_unsafe` to make the naming more similar
to `copy_utf8_truncated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133677
This was caused by using the same factor as in dithered.
But dithered already has the transparency applied from
the dithered transparency. The transparency needs to be
applied to holdout in forward.
Since one user-defined conversion operator is allowed during implicit conversion,
and after this conversion here is a constructor which can accept result
of conversion, there was a backdoor for a vector types to up-cast their
dimensions via cast to pointer type of a component of a vector. Since it was
implicit and non-intentional it led to buffer overflows.
Pull Request: https://projects.blender.org/blender/blender/pulls/132927
Uninitialized textures are bound when simplified anti-aliasing is disabled.
The textures are initialized later. Fixing by referencing the textures
similar to the other passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133648
The core issue was that the geometry batch cache (e.g. `MeshBatchCache` or
`PointCloudBatchCache`) was dependent on the object. This is problematic when
the the same geometry is used with multiple different objects because the cache
can't be consistent with all of them.
Fortunately, the only thing that was retrieved from the object was the number of
material slots, so if that can be avoided we should be fine. We can't just use
the number of material slots stored on the geometry because that may have no
material slots but still has material indices which are overridden on the object
level.
The solution is to take make the number of materials for a geometry only
dependent on the actual `material_index` attribute and not on the number of
available slots. More specifically, we find the maximal referenced material
index and handle that many materials. This number does not depend on how many
material slots there are on the object, but it still allows the object to
override materials slots that the mesh references.
A downside is that the maximum material index has to be computed which often
requires an iteration over the mesh. Fortunately, we can cache that quite easily
and the computation can be done in parallel. Also we are probably able to
eagerly update the material index in many cases when it's set instead of
computing it lazily. That is not implemented in this patch though.
The largest part of the patch is making the maximal material index easily
available on all the geometry types. Besides that, the material API is slightly
replaced and the drawing code now makes use of the updated API.
Pull Request: https://projects.blender.org/blender/blender/pulls/133498
