A couple of edit mesh operators are still using "VCols" terminology,
which should be Color Attributes now. This just renames text seen
in redo panels. Internally it's still called VCols.
Pull Request: https://projects.blender.org/blender/blender/pulls/120075
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
Also fix the poll to properly check for the remaining unsupported types.
Don't add back Quaternion support, since that's arguably less useful,
and we might want different ways to set those values compared to
just entering WXYZ.
Most likely caused by 6d491da0be
In that commit, `knife_pos_data_clear` started to clear (set `-1`) the
value of the current object (which is expected).
However, `knife_snap_angle_relative` relies on the current object to
transform the face normal to global space.
This is weak and error prone since the face is obtained from the
function itself.
The code could be optimized and reuse the face identified in
`knife_snap_curr`, but for now just identify the face object.
Fix the "Merge Vertices" report, replacing "vertice(s)" with either
"vertex" or "vertices". The singular "vertice" is not a word in English,
and thus the regular "append (s)" approach is incorrect.
Pull Request: https://projects.blender.org/blender/blender/pulls/119863
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
Replace the use of the `LIB_TAG_DOIT` flag which cwas used to
only process each object data ID once with a Set. Return the objects
or bases in a Vector. Now we only iterate over the view layers bases
once instead of three times.
Pull Request: https://projects.blender.org/blender/blender/pulls/119788
Converting a color attribute to a non-color domain or type causes vertex
paint mode to try to change the attribute even though it's unsupported.
That leads to a crash here and unpredictable behavior elsewhere.
This PR modifies some poll functions to check for the proper domain and
data type before continuing. Even if converting an attribute properly
updates the active color attribute, we can still run into situations where
the active name references an attribute with incorrect metadata.
Pull Request: https://projects.blender.org/blender/blender/pulls/119657
Fix for a crash after undo "Mask slice to new object"
When creating a new mesh object in the mask slice operator in
sculpt mode it caused a crash when undo to the initial undo step.
Moreover saving the sculpt undo state seems not necessary in
this function since undo/redo doesn't really work reliably for this
operator from the start, but there is nothing can be done about it
without systemic changes.
Note: this PR replaces #119401
Pull Request: https://projects.blender.org/blender/blender/pulls/119443
This could happen if objects were hidden after going to editmode and
knife was used on them.
In that case, raycasting would (rightfully) fail, but there is a
fallback in place using the back-buffer selection method (in which the
hidden object is still present). So a face would be found, but this
makes all following code confusing/wrong since we are working with
coordinates / faces under the assumption there would be a valid/
corresponding object to it in `KnifeTool_OpData` > `objects` -- which is
not the case...
So to resolve, just check if the object is visible before calling
`EDBM_face_find_nearest` in knife code.
Alternativeliy, we could also add a check for Base viewport visibility
to all the bmesh `find_nearest` functions (a bit hesitant though since i
am not sure this would be desired in all cases)
Pull Request: https://projects.blender.org/blender/blender/pulls/119383
I think the issue is that the run-node-group operator overwrites the data stored in the
`Mesh` while mesh edit mode operations typically only change the `BMEditMesh`. It
seems like that causes issues because the mesh edit mode undo stack does not
keep track of changes to the `Mesh`. When hitting undo, Blender assumes that the
`Mesh` stored in the object has not changed and therefore it does not have to be
read from the undo step again.
The preliminary fix implemented here is to just not change the `Mesh` but only the
`BMEditMesh` like any other edit mode operator. This seems to solve the issue.
I haven't quite figured out yet how to tell the undo system that the `Mesh` has to be
loaded from the undo step when undoing out of mesh edit mode. Doing that might
provide a better solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/119015
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
- Remove unused members.
- Use C++ vector types.
- Rename variables.
- Avoid redundant calls.
- Pass the modified value as a function return parameter.
Caused by 1c0f374ec3
When `EDBM_edge_find_nearest_ex` does not find a nearest edge in
`loopcut_mouse_move`, then `loopcut_update_edge` will set
`RingSelOpData` `ob` to nullptr (rightfully so).
This would then crash in `ringsel_draw` (because we are trying to call
`object_to_world()` on the nullptr).
Prior to 1c0f374ec3 this was also "wrong", but
`EDBM_preselect_edgering_draw` would early out before using garbage
data.
Now guard against this and dont call `EDBM_preselect_edgering_draw` at
all if we dont have valid input.
Pull Request: https://projects.blender.org/blender/blender/pulls/118549
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
