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.
Subdivision had its own store of shaders. Best to move them to
`draw_shader.cc` where all draw manager related shaders are stored.
Includes some small tweaks:
- Use enum class for shader types
- patch evaluation must now be retrieved via the
`DRW_shader_subdiv_get`. Previously there were 2 ways to retrieve
them, and one didn't support all the variations.
- Use strongly types when possible (`GPUVertCompType`).
Pull Request: https://projects.blender.org/blender/blender/pulls/134213
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
The cause was that the shader was expecting both `pos` and `nor`
attribute but only one would be extracted.
This is because the mesh has cage display on but the batch cache
wouldn't extract the `vbo.vnor`.
This patch just make sure the vertex normal just follow the same
condition as the other edit normals batches.
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
Avoid function call overhead and parallelize the creation of the edit
and sculpt mode lines index buffers. Also, remove an extra index that
was added for each curve when there are no cyclic curves.
Though ideally these index buffers would be generated on the GPU, this
simple change makes this part of the GPU data building almost 5x faster
(from 1.23 ms to 0.25 ms for curves with 80 thousand points).
Pull Request: https://projects.blender.org/blender/blender/pulls/133897
