This implement the holdout flag by switching to
the holdout case in the shader. This has a few benefits:
- Doesn't recompile the shaders.
- Makes the object infos mandatory (already the case in
practice)
- Handle transparent materials properly, keeping the
transparency working.
Fix#123284
Pull Request: https://projects.blender.org/blender/blender/pulls/123315
When using particle system the generated coordinates where not set.
The reason is that a loose resource handle was created for particle
system that didn't contain enough information to calculate orcos.
This PR will create the object info from its parent object.
Pull Request: https://projects.blender.org/blender/blender/pulls/123307
I didn't think the BMesh extraction mode could arrive at the case where
only loose edges are requested, but turns out it can because of the
mesh wrapper system where the evaluated mesh is actually a BMesh with
deformed positions.
When navigating the samples were always reset. This was introduced
by 7ec59b05ff where samples needed
to be reset when painting.
This PR solves it by separating the navigation and the painting more
clearly in the API. Also cleans up some calls that are also encapsulated
via the EEVEE Instance class.
Validated that painting and navigating still worked with these changes
applied.
Pull Request: https://projects.blender.org/blender/blender/pulls/123064
This should not happen and any failure here should be considered a bug.
But for end users better not to hang Blender, and to have a better
diagnostic for developers in bug reports.
Ref #82483
Pull Request: https://projects.blender.org/blender/blender/pulls/123023
With two viewports, and one viewport with overlays turned off, one viewport
first requests positions without calculating loose geometry, then the second
viewport can request the loose geometry index buffer. In that case the
previously-calculated positions VBO has the wrong size.
To fix this, always calculate loose geometry when the positions are requested.
That's required because we no simple way of checking whether the previously
uploaded positions included loose geometry. That was the state before recent
refactors in this area anyway.
This makes it clear that the optimization to not calculate loose geometry is
meaningless, because the positions buffer will always be requested at some
point when drawing a mesh.
The `nor` vertex buffer wasn't large enough for the indices in the lines
index buffer. This is undefined behavior at best AFAIK. On some drivers
it caused crashes when there was only loose geometry.
This commit makes the VBO large enough for all indices, filling the loose
geometry normals with (0,0,0,0), which the overlay wireframe shader
already checks for.
Pull Request: https://projects.blender.org/blender/blender/pulls/122720
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
This ports the `lock_material` layer property to GPv3.
For this, the `layer_index` is also required in `retrieve_editable_points`
and `retrieve_editable_strokes` to choose strokes based on
the `lock_material` property.
In `retrieve_editable_elements` we now pass the `MutableDrawingInfo`
to get both the `drawing` and `layer_index`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119913
By removing the check we make it possible to render volume objects
even if the shader doesn't require any volume attribute.
We still check if there is any attribute to not draw empty
volume objects that have no attribute as a unit cube.
Fix#103683
Fix for sculpt mode: invert visible hides all faces with Multires modifier #95419
Grids face indices should not change on the fly based on hidden state.
It caused the rendering glitches shown on the original bug report and the attached recordings.
* this PR removes the unnecessary check and dependency of grids visibility with the smooth/sharp of faces.
* replaces smooth flag for sharp flag which better express the intent and simplifies the logic.
Pull Request: https://projects.blender.org/blender/blender/pulls/121929
Part of #116901.
Avoid the "extractor" abstraction for creation of edit mode overlay data
vertex buffers. Use threading::parallel_for loops instead. Also prefer
code duplication over linking things that are unrelated. This is the
last "extractor" loop that runs by default in edit mode so there is a
small performance improvement there. Besides that, the changes is the
same as the other similar refactors.
Pull Request: https://projects.blender.org/blender/blender/pulls/122386
The `overlay_wireframe` shaders uses a `nor` input but it wasn't added
to the GPU batch since the normals were split to a separate vertex buffer.
Adding that input gets closer to the appearance in 4.0. But it still looks a
bit different-- the outline is not as bright overall.
Fixes#120781.
Pull Request: https://projects.blender.org/blender/blender/pulls/120827
The loose edge section of the index buffer was built incorrectly,
essentially assuming that all the hidden edges came at the end of the
loose edge indices. To correct this, we need to track the visibility of
each loose edge index rather than the visibility of each edge itself.
This is driven by the need to combine the loose and non-loose indices
into one IBO with the loose edges in a contiguous section, and the
desire to avoid restart "invisible" indices in the buffer to upload
less data to the GPU.
Implementation of the proposal in: #121535
When drawing with "project to surface" turned on, it is now possible to restrict the projection to only the selected objects.
This is really useful for drawing onto surfaces that has a lot of detail meshes that you don't want to project onto.
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
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
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.
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
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
