Part of #118145.
Use the recently added utility for base mesh data, and for BMesh and
multires add a compromise that gets some benefits of simpler loops
but still avoids some duplication.
Also add move a recently added utility to only affect visible grid
vertices to the relevant header and reuse it. I expect this won't be a
permanent part of the API but for now it's better than duplicating
all the loops twice.
For base mesh sculpting, we already draw the original data instead of the
evaluated data, so the evaluated mesh doesn't have to be updated to
contain the new attribute. This is different from multires sculpting
because sculpt brushes and drawing only deal with the evaluated
SubdivCCG, not the original multires modifier data. Removing the
unnecessary update removes a noticeable pause when clearing and
adding a mask.
Part of #118145.
Use a utility for updating mask values and detecting changes and
pushing undo steps. Also use the attribute API for accessing color
attributes and pass flood fill data as arguments instead of a separate
struct.
Part of #118145.
There is more boilerplate now, but hot loops are generally simpler,
and I think we can reuse the structure for other operators that create
masks, similar to `vert_hide_update`.
This adds additional logic to `GreasePencil::rename_node` to rename
the strings in the modifier influence data.
This is similar to how `ED_armature_bone_rename` handles renaming of
strings.
Resolves#123321.
Pull Request: https://projects.blender.org/blender/blender/pulls/123365
Add-ons may attempt to load the GPU module in background mode when no GPU
context has been initialized yet. This would give an error on import.
If then later the GPU context does get initialized, for example for a
render engine, import would still fail as the module is cached.
This reverts commit d7f124f06f, and again
throws errors in methods and constructors instead of module import.
Pull Request: https://projects.blender.org/blender/blender/pulls/123395
This was previously attempted in #109518 and reverted in #112234. Now do
both the changes in the mesh and material export, and make it an option
in USD export. Hydra always renamed to "st" and continues to do it.
Fix#122800: Missing textures with MaterialX materials
Pull Request: https://projects.blender.org/blender/blender/pulls/123326
Currently, when color-picking from the viewport, the code will read the final
displayed pixel color and then somewhat attempt to undo the display transform.
However, this has several limitations - for example, precision is limited to 8
bit, and it does not account for e.g. View Transform or exposure/gamma.
Since we have the pre-display-transform color in a GPU texture anyways, this
code therefore adds a View3D-specific eyedropper handler (similar to e.g.
the image space) that reads from the viewport texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/123408
This was due to the fact that the `scale_fac` was not set up correctly for
GPv3.
We now compute the right radius in pixels so we can set up the `scale_fac`.
Note that this removes the logic for GPv2, since it is no longer needed in
Blender 4.3.
This was introduced with b7c570c854.
For the draw tools, we no longer use the unified paint settings.
This means that we can't use the `_template_paint_radial_control` anymore.
The fix explicitly sets up the shortcut to use the `brush.size` and `brush.strength`
for the `radial_control` operator.
We expect the projection to return something instead of crashing.
For the case where we can't project onto a surface, we fall back to
view plane projection.
Currently, before and during brush evaluation on large meshes, a
significant amount of time is spent pushing and searching for undo
nodes. Because the undo node storage must be protected by a lock,
this means the CPU ends up spending a large portion of the total
time just waiting for other threads to release the lock while they
search for the correct undo node.
Finding an undo node is currently O(n) because we use linear search.
It's actually very simple to just use a map to replace this though.
For the draw brush impacting a large portion of a 6 million vertex mesh
(the benchmark file from #118145), this change improves brush evaluation
time by almost 60%-- from 1.1s to 0.7s. This doesn't include the cost of
refilling GPU buffers, but it's enough to probably give a noticeable
change for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/123415
The previous approximation lead to values that were a bit too large.
Generally, there won't be a perfect conversion value, but at least the
defaults from GPv2 should give reasonable results.
Dropping an extension URL for an incompatible package displayed the
"Unknown Repository" dialog.
Resolve by detecting the case of an unknown package being dropped from
a known repository. Noting the package may not be compatible.
The time offset modifier inserts keys sequentially, overwriting earlier
frames with later ones, and only the last relevant frame remains used.
In chain mode this process is repeated for every chain segment and then
all segments are repeated to fill the entire timeline. However, because
all keyframes are inserted for every repetition, they can overwrite
keyframes from earlier repetitions as well.
Clamping the insert keyframe makes sure that no keys are inserted
outside of the target range for a give repetition.
Pull Request: https://projects.blender.org/blender/blender/pulls/123423
This fixes#121695. `float4x4` matrices are generally expected to be 16 byte aligned.
Currently, there is no mechanism (afaik) that allows allocating these overaligned types
when loading files from disk. This patch adds an array with alignment information for
each type in `SDNA`. Currently, the alignment is just `__STDCPP_DEFAULT_NEW_ALIGNMENT__`
for all types and is manually set for the `mat4x4f` DNA type. The .blend file format is
not changed at all. The alignment information is purely runtime data.
In the future it would probably be good to generalize this a bit more instead of
hardcoding the alignment for `mat4x4f`, but would make it unnecessarily complex for
now because this is intended for the release branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/123271
Current look of VSE timeline view strip transformation handles makes them
somewhat "too narrow", especially after recent changes that made them
more narrow than before (handle tweaking feature) and a strip visual change
that made strip outline not go outside of strip bounds. They are now just
2px wide, effectively.
This changes their look as outlined in #123332 design task:
- The inset dark line is no longer over the handles, but rather "inside"
of them (except when handles are semitransparent, i.e. for strips that
are not selected).
- The handles themselves have rounded corners.
Pull Request: https://projects.blender.org/blender/blender/pulls/123391
Timeline markers get a default name of "F_<frame>" when creating with
`marker.add`, but an empty name with `marker.camera_bind`.
Because the name of the current frame's marker is displayed in the
viewport statistics, such markers appear as "<>" after the name of the
active object, which is confusing.
This change gives the same default name of "F_<frame>" to markers
created this way.
It also cleans up a comment in the line copied from, as that line was
introduced in late 2008 so probably not so temporary.
Pull Request: https://projects.blender.org/blender/blender/pulls/122968
Now the `uiBlock` array for node is indexed with `node.index()` instead
of the draw-index which is not as readily available in some cases.
The main alternative would be to create an extra map from node index
to draw-index but that doesn't seem worth it right now.
