This makes it so that Grease Pencil Bezier handles use the same colors and shaders as `Curves` Objects.
This also makes the handles follow `handle_display` and add the option the the edit mode overlay.
Pull Request: https://projects.blender.org/blender/blender/pulls/141524
For paint modes the selection and visibility were encoded in in the W
component of the normals. Separating the normals into a separate vertex
buffer, though it increases memory usage a bit in those paint modes,
means the status doesn't need to be computed outside of paint modes,
and the whole system becomes less convoluted and easier to optimize.
The particular optimization I have in mind is better caching of vertex
buffers, which gets much more complicated when the normals VBO contains
data like selection and visibility and depends on the paint mode.
Internally, a there are now three mesh draw batches that are specific to
the paint overlay. The GPU subdivision normals buffer is now just three
components rather than 4 components.
Pull Request: https://projects.blender.org/blender/blender/pulls/140156
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 uses a fixed point size for selection, so that point selection is always visible
regardless of radius size.
The radius size is used to offset the selection point, so it is always visible, even when the radius is too large.
Co-authored by Hans Goudey.
---
Pull Request: https://projects.blender.org/blender/blender/pulls/134908
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
Especially through DRW_render.hh, there were a lot of unnecessary
includes almost everywhere in the module. This typically makes
dependencies less explicit and slows down compile times, so switch
to including what files actual use.
Pull Request: https://projects.blender.org/blender/blender/pulls/133450
`grease_pencil_edit_batch_ensure` will not create a valid batch when
there's no visible edit geometries (e.g. Current frame is before any of
the GPv3 key frames), this would lead to GPv3 passes drawing an empty
batch. This fix prevent empty edit batch from being put in the pass
drawing command list.
Pull Request: https://projects.blender.org/blender/blender/pulls/130493
Removes unused GPv2 functions in blenkernel.
Notes:
- Functions for layer masks are still in use, but annotations never
have layer masks in the first place. Would be good to remove the data
structures so we can remove the functions too.
- Some multi-frame edit functions are also still nominally used, but
multi-frame editing is not an active feature for annotations. This
should also be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128709
This PR implements the viewport overlay for Weight Paint mode in GPv3.
In Weight Paint mode the stroke points are colored depending on their
weights in the active vertex group.
Pull Request: https://projects.blender.org/blender/blender/pulls/118273
Now that all relevant code is C++, the indirection from the C struct
`GPUVertBuf` to the C++ `blender::gpu::VertBuf` class just adds
complexity and necessitates a wrapper API, making more cleanups like
use of RAII or other C++ types more difficult.
This commit replaces the C wrapper structs with direct use of the
vertex and index buffer base classes. In C++ we can choose which parts
of a class are private, so we don't risk exposing too many
implementation details here.
Pull Request: https://projects.blender.org/blender/blender/pulls/119825
Overall the transition to C++ in the draw module is awkwardly half
complete, but moving more code to a C++ namespace makes cleaning up
this code in other ways much easier, and the next C++ cleanup steps
are clear anyway.
