With selected strips, it is not clear where one of them begins and another
ends since their outlines are right next to each other.
This changes strip look so that:
- All strips have consistent dark 1pt outline at the outer edge.
- Selected strips have 2pt highlight inside said outer edge.
- Selected strips also have a 1pt wide 33% opacity darker line inside the
selection highlight (and inside possible handles). To improve readability
in case strip content happens to be similar to selection/active color.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/123431
Vulkan backend has recently switched to a render graph approach. Many
code was left so we could develop the render graph beside the previous
implementation. Last week we removed the switch. This PR will remove
most of the unused code. There might be some left and will be removed
when detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123422
The fill tool can take opacity into account ("Advanced" brush settings).
In that case any point with a total opacity lower than the threshold is
rendered as a transparent boundary.
This was still a hardcoded setting in the fill tool, now uses brush
settings.
Pull Request: https://projects.blender.org/blender/blender/pulls/123469
Remove some `nullptr` checks from an operator exec function, which are
unnecessary because the corresponding poll function already checks for
them.
No functional changes.
Prevent creating NLA strips from layered Actions via the 'Push Down'
operator.
Maybe in the future the NLA will support layered Actions (as a transitional
phase, before the NLA is replaced with layered Actions itself). For now,
it's better to create stable boundaries to prevent their use in the NLA.
When NLA support is being worked on, those boundaries can be removed again.
Pull Request: https://projects.blender.org/blender/blender/pulls/123467
Avoid logging actions about `action->idroot` not matching, when evaluating
the NLA and visiting a layered Action. Layered Actions are not limited to
a single data-block type, and so the code should ignore `action->idroot`.
Add layered Action support to `BKE_action_frame_range_calc()`, by
looping over all F-Curves of all Bindings in the Action.
Introduce `animrig::fcurves_all(action)`, which returns a vector of all
F-Curves in the Action, both for legacy and layered Actions.
No functional changes for legacy Actions.
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.
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.
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
