Part of #118145.
These days we aren't really benefiting from making PBVH an opaque type.
As we remove its responsibilities to focus it on being a BVH tree and look
to improve performance with data-oriented design, that will only become
more true.
There are some other future developments the current header structure
makes difficult:
- Storing selections of nodes with `IndexMask` for simpler iteration, etc.
- Specialization of node type for each PBVH type
- Reducing overhead of access to node data as nodes get smaller
- General C++ cleanliness and consistency
This PR moves `PBVH` to `blender::bke::pbvh::Tree` and moves `PBVHNode`
to `blender::bke::pbvh::Node`. Both are classes visible to elsewhere in Blender
but with private data fields.
The difficult part about the change is that we're in the middle of a transition
removing data from PBVH. Rather than making some data truly private I
chose to just give it the `_` suffix, since it will ideally be removed later.
Other things should be class methods or implemented as part of friend
classes. But the "fake" private status is much simpler for now and avoids
increasing the scope of this PR too much. Though that's a bit ugly, there's a
straightforward way to resolve these issues-- it just looks like the sort of
inconsistency you'd expect in the middle of a large refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124919
This patch adds support for multi-pass compositing for EEVEE. This is
done by copying the passes used by the compositor node tree to the DRW
view data, which can then be accessed by the viewport compositor.
The viewport compositor will fallback to the viewport texture or an
invalid output of the passes were not initialized, this is currently the
case for any render engine that is not EEVEE.
A future optimization that we can do is eliminate the film pass copy
shaders and only copy the data that EEVEE rendered, which can be a
subset of the viewport for border rendering. This is not done at the
moment because not all engines support passes at the moment, so the
compositor expects full viewport passes.
Depends on: #123685, #123817, #123815.
Pull Request: https://projects.blender.org/blender/blender/pulls/123378
This PR removes the "Widget Label" text style, found in Preferences /
Themes / Text Style. This results in both labels and the text found in
input boxes sharing settings. This results in a slight loss of
customization but it isn't that useful to have these things separate
and results in code complication and errors.
Pull Request: https://projects.blender.org/blender/blender/pulls/122898
This patch adds two theme entries for data before/after the current frame.
Those entries control what color to use when displaying
reference data from a different point in time (motion path, onion skins).
They are under the `3D Viewport` section of the theme in the user preferences.
## User Facing Changes
### Grease Pencil
When `Custom Colors` is disabled it will now use the theme instead of the layer default color.
Currently this setting is enabled by default. Disable it to get Blender to use the theme.
### Motion Path
If Custom Color is disabled, read from the Theme.
### Annotations
If onion skin is enabled, and custom onion skin colors is disabled, read from the theme.
**Grease Pencil**
* previously the color used for onion skinning (without custom colors) was `U.gpencil_new_layer_col`. This is used in other places as well so it cannot be removed with this PR
* By default, custom colors are enabled with Grease Pencil objects. I specifically did **not** change that with this PR. I will instead let the GP module handle that on their terms.
This PR has been discussed in the Grease Pencil module meeting
https://devtalk.blender.org/t/2024-05-21-grease-pencil-module-meeting/34755#meeting-notes-2
and in the A&R module meeting
https://devtalk.blender.org/t/2024-05-24-animation-rigging-module-meeting/34813#patches-review-decision-time-4
Pull Request: https://projects.blender.org/blender/blender/pulls/120558
The "verts per grid" calculation was wrong for the non-flat/indexed
vertex buffer layout used for smooth shading. For example, for a
multires subdivision level of 8, each PBVH node's vertex buffers
were 3 times larger than they needed to be.
Pull Request: https://projects.blender.org/blender/blender/pulls/123808
Combined with previous logic, this roughly doubles the performance of
sculpt-mode multires draw vertex buffer extraction in my simple test.
That measurement is for when we initially enter sculpt mode when the
VBO creation is single threaded. Otherwise in my testing the copying
was bound by memory bandwidth and the improvement was smaller.
The value was set and transfered to `MeshBatchCache`but never
actually used. Even then, this is clearly not a good solution to the
problem the comments mentioned. If that happens if would be
better to solve it in a different way.
Add a `.data<T>()` method that retrieves a mutable span. This is useful
more and more as we change to filling in vertex buffer data arrays
directly, and compared to raw pointers it's safer too because of asserts
in debug builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/123338
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
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.
The mapping was read multiple times from the `map` structure in that time the `map` value could have changed (set to -1). To stop this, the mapping is read once and set to -1 earlier to reduce the possibility to other threads performing the operation and changing the mapping value.
Pull Request: https://projects.blender.org/blender/blender/pulls/123056
Not a real fix, just preventing crashes due to broken particle data.
Particle draw code can get into an invalid state, which can crash
drawing code. This just prevents the crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/123075
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
Everything here is drawn as triangles in the end, and currently we use
index buffers either way, so "needs_tri_index" isn't a meaningful name.
What this really controls is whether the layout is flattened to duplicate
each subdiv vertex 4 times, for drawing flat shading.
Retrieve the index buffer data as a span and set it directly rather than
using the API functions to add vertices which add overhead. Also pass
all the necessary data as arguments instead of retrieving them from
the "args" struct on every use.
In a test with a 16 million vertex grid, this reduces the runtime of
generating all the wireframe index buffers by about 25%, from 95 to 76 ms
for that step of the drawing process.
Most functions in `draw_pbvh.cc` are inside of the `PBVHBatch` or
`PBVHBatches` classes, besides the more recently added attribute
copying code. This means they have access to "all the information"
and it's hard to get a sense for the proper order of calculation and
what each function is responsible for. This commit is an attempt to
clarify things a bit by changing to regular static functions.
