It has been confirmed that the latest release of AMD drivers has fixed
issues for both OpenGL and Vulkan. Users should use AMD driver 25.3.1
or later. Removing the workaround as it has performance penalties on
RDNA2 based GPUs.
Reference: #135516
Pull Request: https://projects.blender.org/blender/blender/pulls/135630
Previously in 6f80d722c6 there was a fix for
not removing layers from evaluated data when their visibility is animated,
however it overlooked that the same thing could happen to layer groups.
This fix basically duplicated the same check for layer groups.
Pull Request: https://projects.blender.org/blender/blender/pulls/135450
Due to recent code changes, `knife_calculate_snap_ref_edges` relied on
the (not yet computed) `kcd->curr.mval` to compute the raycast ray.
The solution is to pass the computed ray right before.
Also `knife_snap_update_from_mval` is now called on the modal to update
the edge as soon as the button is pressed.
Pull Request: https://projects.blender.org/blender/blender/pulls/135649
In the report, the bounds didn't include the curves generated from the
original legacy curve object. Generally we need to access the evaluated
geometry bounds here when the object is a geometry object.
This depends on 06f6d77979 for consistent behavior with
curve radii. That's why the fix is limited to main rather than 4.4.
Pull Request: https://projects.blender.org/blender/blender/pulls/135639
Caused by 21aef81714
Now, pass along `uiname` as `std::optional<StringRef>` early on (and use
`std::nullopt`).
Without this, the `(!uiname || !uiname->is_empty())` condition in
`ui_item_enum_expand_elem_exec` wont be true, resulting in the empty
label.
Pull Request: https://projects.blender.org/blender/blender/pulls/135621
Unlike the legacy type, the radius isn't included in the bounds for the new
curves type. This hasn't been obvious because the drawing is quite broken
and doesn't use the radius properly.
This commit adds a separate cache for the bounds with the radius, which
is now used by default. The old cache is kept around for backward
compatibility in the bounding box geometry node, where a new
"Use Radius" option accesses the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135584
The name of each instance geometry is the character. This makes debugging
in the spreadsheet much easier, and the objects from "Visual Geometry to Objects"
are actually usable too.
Pull Request: https://projects.blender.org/blender/blender/pulls/135599
The issue was happening because the `is_render_depth_available`
state flag was false leading to the depths being cleared.
When we use `is_depth_only_drawing`, we expect
that the depth is valid because the Grease Pencil
engine will write them.
Pull Request: https://projects.blender.org/blender/blender/pulls/135619
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135626
When renaming bones, vertex groups that has the same name as the old
name of the bone will be renamed to the new name, but this may cause
name collision in the vertex group list. When this happens, we should
not change the vertex group's name. Now a warning message will show.
Pull Request: https://projects.blender.org/blender/blender/pulls/135492
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
`MEM_[cm]allocN<T>` templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use `MEM_new` (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135620
The goal is to have a clear separation between active nodes and active viewers in a node tree. Both the compositor and geometry nodes viewers are supported. This will also allow us to implement shortcuts for viewers for geometry nodes.
A viewer node can be activated using
```
viewer_node = bpy.context.scene.node_tree.nodes["Viewer"]
with bpy.context.temp_override(node=viewer_node):
bpy.ops.node.activate_viewer()
```
Pull Request: https://projects.blender.org/blender/blender/pulls/134456
According to reports and testing in blender/blender-addons#104434, DCCs
tend to behave badly when rebuilding normals from 'bitflags'
smoothgroups, if different smoothgroups using the same bitflag value share
(are connected by) some common vertices, even if there are no common
edges between them.
This commit adds a new option to the RNA API generating smooth groups,
to also consider smooth groups only sharing vertices as neighbors.
It also makes related required change to implementation, and some
refactor of the API, splitting public functions between 'normal' and
'bitflags' versions.
This should make changes proposed in blender/blender-addons#105516
much simpler, and allow for a matching behavior in smoothgroups
generated by the OBJ exporter as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/135248
Previously in 43fde8c39c the point span
for calling `extend_curves_straight` was set to a fixed `{1}` with only
1 element, this causes index access to go out of range, which is the
cause of crash #135586. However there are some other issues within the
code path, mainly:
- The meaning of `start/end_points` are unclear
- Behaviour of extending a 2-point stroke is undefined
This PR clarifies these by adding some comments and change a bit of the
logic in the code so it's more understandable.
Pull Request: https://projects.blender.org/blender/blender/pulls/135608
Operator `GREASE_PENCIL_OT_layer_group_color_tag` did not check the
existence of active layer group before executing. Now corrected with a
`poll()` callback.
Pull Request: https://projects.blender.org/blender/blender/pulls/135612
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
`MEM_[cm]allocN<T>` templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use `MEM_new` (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/134452
This commit removes the F-Curve handling from the legacy Curve edit mode
undo code.
The legacy Curve edit mode uses the per-mode undo system. This tried to
deal with changes in the animation data as well, but did so in a very
limited way. Only F-Curves were copied & restored, which means the
Action Groups were effectively deleted as soon as you undo something.
Furthermore, the code wasn't updated for slotted Actions yet, so
effectively it was a no-op, because it only saw the always-empty legacy
`Action::curves` field.
Fixing this properly would mean discarding this undo code, and moving to
the global undo system, as the animation editors allow changing the
animation of anything in the scene, not just the Curve data-block that
is being edited. Since the legacy curve ID type is, well, legacy, I
don't think it's worth going this route.
This is a non-functional change, as `action->curves` is always empty,
and so nothing was backed up or restored anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/135585
Removing the layer would leave the ruler gizmos on screen, only way to
update was changing to another tool and back. Now remove all
corresponding gizmo ruler items found (also in different windows/scenes)
when removing the ruler annotation layer.
Also add a proper notifier that grease pencil was edited (this way we
also get immediate update when a ruler annotation layer was added --
which was also missing).
Pull Request: https://projects.blender.org/blender/blender/pulls/135571
Since the switch to slotted actions, we cannot solely rely on the
Listbase of `curves` (this is for legacy actions only), but need to
consider Channelbag for new slotted actions. There is
`assigned_action_has_keyframes` that handles both of these
and would also early out if we have no keyframes to process,
so use it.
Pull Request: https://projects.blender.org/blender/blender/pulls/135566
This was introduced in 1d2cea1e3e
It was not using any `draw_backdrop` callback though, which is now
added.
Main point of discussion is probably if we want to use `Dope Sheet
Channel` theming (which is only used for `Object` and `Scene` channels
atm., also referred to as "root" in code) or the `Dope Sheet Sub-
channel` theming (which is now used for all kinds things - object data,
but also actions..., also referred to as "dataexpand" in code)
Given the similarity to actions, one might lean towards "Sub", but otoh
that channel occupies a "root" channel in the action editor mode. If I
understand correctly, an `ActionSlot` is also mostly used to "separate"
different objects in the same action, so that then makes an ActionSlot
actually more similar to how the "root" channel is used for `Object` and
`Scene` in dopesheet mode.
This is why this PR makes an `ActionSlot` use the "root" theming.
NOTE: we also might want to revisit the naming in code (suggestion would
be TH_DOPESHEET_CHANNELOB > TH_DOPESHEET_CHANNELROOT,
TH_DOPESHEET_CHANNELSUBOB >TH_DOPESHEET_CHANNELSUBOB), but that is for
another time...
Pull Request: https://projects.blender.org/blender/blender/pulls/135506
The utility function edit_constraint_invoke_properties could return
false without setting the return value, causing the operators invoke
function to return an uninitialized flag.
