- Make the module global and allow usage from anywhere.
- Remove the matrix API for thread safety reason
- Add lifetime management
- Make display linked to the overlays for easy toggling
## Notes
- Lifetime is in redraw. If there is 4 viewport redrawing, the lifetime decrement by 4 for each window redraw. This allows one viewport to be producer and another one being the consumer.
- Display happens at the start of overlays. Any added visuals inside of the overlays drawing functions will be displayed the next redraw.
- Redraw is not given to happen. It is only given if there is some scene / render update which tags the viewport to redraw.
- Persistent lines are not reset on file load.
Rel #137006
Pull Request: https://projects.blender.org/blender/blender/pulls/137106
Allow detecting passes that can be skipped without side-effects and
don't submit them.
Eases debugging and profiling, and may provide a performance
improvement.
Pull Request: https://projects.blender.org/blender/blender/pulls/135875
This was caused by the cross product changing
sign in view space during planar lightprobe capture.
This can be avoided by making sure the view matrix
doesn't change handedness.
Pull Request: https://projects.blender.org/blender/blender/pulls/137092
Caused by 9b70851d91.
That commit inadvertently switched the order of these definitions. Because the
vertex buffers created by GPU subdivision still have a different format than regular
mesh drawing (the position buffer also includes vertex normals), the order of these
VBOs in the batch matters, since "lnor" attribute can override another.
Pull Request: https://projects.blender.org/blender/blender/pulls/137000
**Problem**
When using Texture Paint mode, the Image Editor will show a UV Wireframe
to display the active object's UVs. In every other mode, this wireframe
is absent. This is currently a big problem for Sculpt Mode since the
Experimental Texture Paint system is a part of that mode, meaning that
the user can't see their UVs while they paint in Sculpt Mode. This is
also troublesome for users that would like to quickly view an object's
UVs without using Texture Paint Mode.
**Solution**
Since it's useful to be able to view an object's UVs at all times, the
Image Editor should display UV Wireframes in all Object Modes regardless
of the Image Editor's mode. This is the best solution since it means
that future Blender features, that would benefit from having a preview
of an object's UV Wireframes, will automatically have that option since
UV Wireframes are supported in all modes. Also, if a user doesn't want
to see UV Wireframes for any reason, it can be disabled with an Overlay
option.
Additionally, when multiple objects are selected, each object should
have its UV Wireframe drawn in the Image Editor. The selected objects
that aren't active should have less opaque wireframes to indicate which
wireframe belongs to the active object. This is the best approach for
having multiple objects selected since it allows the user to quickly
view the UV layout for all selected objects to troubleshoot UV problems,
like texture mapping. This is especially helpful when using a material
for multiple different objects.
An alternative solution would be to only show the UV Wireframe for the
active object, but this would be undesirable because it would make
troubleshooting UV positions tedious when working with multiple objects
since the user would need to select objects individually.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Co-authored-by: Sean Kim <SeanCTKim@protonmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135102
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
The Denoise node crashes if used in the viewport compositor. That's
because OIDN uses the compositor context in a different thread, which
does not have access to the DRW context. To fix this, we assign relevant
context data to the compositor context from the DRW context before
running the evaluator, then make the compositor context return those
data instead of accessing the DRW context.
This was caused by the manager being in sync phase only
between `begin_sync` an `end_sync`. The drawcalls sync
inside `begin_sync` like the lookdev sphere were given
bogus handles.
This also remove some uneeded functions wrappers.
One of the push constant was not set and was thus
in the last state is was in. This is because
we are not using the Batch or IMM API to draw
the batch, and thus, this push constant has to be
set manually upfront.
This adds a new more accurate antialiasing to the Grease Pencil
render engine. This is only available for render.
This Accumulation AA doesn't replace the SMAA. SMAA is still
used by the viewport and for removing aliasing from the
depth buffer. However, using both at the same time can lead
to overblurred result.
Here are some measurements for how much the render time
increases compared to the baseline with different (SSAA) sample
counts (using an example production file, rendered at 1080p,
results might vary depending on the scene complexity):
* 8 samples: +0.14 s
* 16 samples +0.36 s
* 32 samples: +0.58 s
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136551
This allow to store the full object ID inside a `uint32`
buffer. This allows to get the per object data in deferred
passes and avoid to store object data inside the Gbuffer.
This data is only written if needed.
This had to modify the implementation of subpass input
for all backend to be able to bind layered texture.
This currently work because only the layer 0 is bound to the
framebuffer. This is fragile but I don't see a good builtin way
to fix it.
Rel #135935
#### Tasks
- [x] Replace light linking bits in Gbuffer
- [x] Replace Object ID in GBuffer for SSS
- [x] Conditional storage
- [x] Dummy storage if not needed
Pull Request: https://projects.blender.org/blender/blender/pulls/136428
This happened because the viewport was drawn after
the UV editor when some update occur (e.g. canceling an
operator). The requested UV edit batch would require only
one specific UV channel. The viewport, in need of a different
UV channel, requested a VBO rebuild (freing the old UV VBO)
but did not correctly clear the UV batches that were referencing
the said VBO. This lead to use after free which would sometime
works because the same memory would be reused for a random new
batch.
Pull Request: https://projects.blender.org/blender/blender/pulls/136780
Render Overlay Meshes after the Grid.
As a side effect, in-front wireframe objects are now displayed behind
non-in-front edit mode overlays.
Co-authored-by: Clément Foucault
Pull Request: https://projects.blender.org/blender/blender/pulls/136764
Followup to 9b70851d91.
Return buffers by value rather than creating an empty/uninitialized
buffer first, then initializing it in an extraction function. This generally
makes the code easier to follow. And avoiding these half-created buffers
is an essential step to adding some sort of more global cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/136570
The initial goal of this PR is to avoid creating vertex and index
buffers as part of the "request" phase of the drawing loop. Conflating
requesting and creating index buffers might not sound so bad, but it
ends up significantly complicating the whole process. It is also
incompatible with a future buffer cache that would allow avoiding
re-uploading mesh buffers.
Specifically, this means removing the use of `DRW_vbo_request` and
`DRW_ibo_request` from the mesh batch extraction process. Instead, a
list of buffer types is gathered based on the requested batches. Then
that list is filtered to find the batches that haven't been requested
yet. Overall I find the new process much easier to understand.
A few examples of simplifications this allows are avoiding allocating
`MeshRenderData` on the heap, and the removal of its `use_final_mesh`
member. That's just replaced by passing the necessary information
through the call stack.
Another notable difference is that for meshes, EEVEE's velocity module
now requests a batch that contains the buffer rather than just requesting
the buffer itself. This is just simpler to get working since it doesn't require
a separate code path.
The task graph argument for extraction is unused after this change. It wasn't
used effectively anyway; a simpler method of multithreading extractions is
used in this PR. I didn't remove it completely because it will probably be
repurposed in the next step of this project.
The next step in this project is to replace `MeshBufferList` with a
global cache that's keyed based on the mesh data that compromises each
batch, when possible (i.e. for non edit-mode meshes). This changes above
should be applied to other object types too.
Pull Request: https://projects.blender.org/blender/blender/pulls/135699
This makes it possible to restore previous Blender 4.3 behavior of bump
mapping, where the large filter width was sometimes (ab)used to get a bevel
like effect on stepwise textures.
For bump from the displacement socket, filter width remains fixed at 0.1.
Ref #133991, #135841
Pull Request: https://projects.blender.org/blender/blender/pulls/136465
This reintroduce the same behavior as 4.3 with regard to
selection and depth drawing.
This patch also disables facing overlay during depth
drawing to avoid it conflicting with tge auto-depth
feature.
Also fix#136418
Pull Request: https://projects.blender.org/blender/blender/pulls/136427
This improves the situations where the shading normal is far from the
best shadow bias direction. This is particularly noticeable on low poly
meshes with smooth normals.
This patch fixes the issue by storing a quantized version of the
geometric normal in the Gbuffer.
Only 6 bits are used (each axis uses 2 bits). This is stored inside the
gbuffer header since it is always available and has some spare bits to
store this data.
This quantization is only done if the error introduced by using the
shading normal is higher than using the quantized normal. This means
that flat shaded surfaces will not have any quantization artifact.
For smooth shaded surfaces, the quantization is only effective if the
shading normal is quite different (greater than ~20° difference)
than the geometric normal.
The attached blendfile contains an example Material that shows
how the quantization is done. This was used to find the threshold
value with the least amount of error.
To compensate the quantization error, we increase the normal bias by
~20% which is subpixel if the shadow texel density is high enough.
This also changes the forward shading pipeline to use the geometric
normal for bias.
The first Light closure normal is now used for the attenuation function
since this is the most representative of the final shading. This normal
being inverted for transmission closures, we have to negate the normal
in the attenuation computation.
Pull Request: https://projects.blender.org/blender/blender/pulls/136136
This was caused by the select_id not being flushed to
the armature object.
This is because the selection code uses `FOREACH_OBJECT_IN_MODE_BEGIN`
to iterate over the objects. This doesn't call the depsgraph
which would, in normal circumstances, flush the select_id value
to the evaluated object.
Also fix#136141
Pull Request: https://projects.blender.org/blender/blender/pulls/136320
