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.
This patch adds warnings when view transform or FPS values are changed
by dragging in an initial strip with "Set Scene Frame Rate" or "Set View
Transform" enabled.
In the case that both occur at the same time, reports are not
interweaved but both still show up in the info viewer -- this is a
limitation of `BKE_report` itself. Future work could modify the report
system to support queuing, but this is still an improvement over
previous behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135494
The Alembic file in the issue had 0 points, and 4 widths, defined for
frame 33 which is certainly incorrect from whichever software produced
said file. However, our import code should have proper guards in place
to more gracefully handle the situation.
Pull Request: https://projects.blender.org/blender/blender/pulls/135548
When using Alembic procedurals, the Mesh Sequence Cache attempts to
replace the original geometry with a plain old cube. However, it never
frees this new cube geometry. Transfer ownership to the underlying
GeometrySet instead.
Investigating the scenario also showed that the `~AlembicProcedural`
dtor was removing an item from the `nodes` vector while iterating over
it, which triggers debug asserts on at least MSVC. I believe the removal
is unnecessary since this is the dtor and ASAN appears clean now.
Pull Request: https://projects.blender.org/blender/blender/pulls/134085
This avoid having to flush explicitely and the need for syncing.
It also removes a lot of complexity in the process.
These updates are not granular and do not need to so much
boiler plate code.
The depsgraph update counter now becomes atomic to avoid
undefined behavior when a depsgraph is being destroyed and
its memory reused (same thinking as the non-copy-on-eval IDs).
I tested some use cases (object update, sculpt update,
shading update) and they are all working.
Pull Request: https://projects.blender.org/blender/blender/pulls/135580
Screen initialization is more context dependent than it used to be
because of region polling, so the context needs to be set up correctly.
Here was a case where the initialized window/screen passed to polling
didn't match what's in context (UI context was unset in fact).
Some asserts could be added to ensure data passed to screen
initialization matches context, but can do that separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/135568
As a small addition to the import node features for 4.5,
this simple node imports a text file as a string. Potential
use cases include retrieving text for motion graphics.
Currently this just allows .txt files. More extensions could
be allowed in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/135459
Identifying layout-panels using strings and storing their open-state in their
parent panel is generally very convenient. However, right now there is no
mechanism to free the open-close state of panels that are not in use anymore.
It's generally not possible to know if a panel is not used anymore (e.g. it may
also belong to a temporarily disabled add-on). So every mechanism here will be
based on heuristics. A simple but typically very good heuristic is to just
remove the least-recently-used panel states when there are too many. So that's
what is implemented here.
This introduces a logical clock that increases whenever a panel state is used
and stores the last usage time on the panel state. This allows us to remove the
least-recently-used states later on. Specifically, that is done when the .blend
file is loaded the next time. It's not done at another time, because it quite
difficult to be sure that freeing panel states wouldn't cause dangling pointers
in such cases. I think doing it on-load should be good enough for all practical
use-cases.
Note, I don't know if the lack of such garbage collection has ever caused a
problem anywhere. However, it seems better to have some solution now than trying
to solve it after the problem has occurred and made someone's file unusable.
Pull Request: https://projects.blender.org/blender/blender/pulls/135569
When iterating over the layers in a Grease Pencil object,
removing the layers can lead to crashes.
This PR is a better alternative to !135253.
Instead of checking if the layer is valid, simply fetch the latest layer
cache for each iteration and check if the index is valid.
This means that we will skip over layers if they get removed during
iteration, but we no longer can crash. If users want to remove multiple
layers at once, it's better to do this in two passes. E.g. by first
collecting the names of the layers to remove, iterating over
these names and then removing the layers by getting it by its name.
Pull Request: https://projects.blender.org/blender/blender/pulls/135574
The Mesh to Grease Pencil conversion would convert every edge into a stroke.
This was not the case prior to Blender 4.3. Edges with no branches would be
converted into a single stroke instead of mutliple ones.
This fix uses `geometry::mesh_to_curve_convert` from geometry nodes to
achieve more optimal result with edges connected into one stroke when
possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/135557
When inserting keys in the viewport by pressing `I`,
certain custom properties would not get keyed if their name
was identical to existing properties (for example `scale`).
That was because we use the name of the property to resolve
an rna path and check if the path resolved. This was of course
true in the described case and the square brackets would never be added.
The solution is to check for `RNA_property_is_runtime` which is false
for properties defined inside Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/135304
The owner of the context is now always the local context.
The `DRWContext` is now a temporary object that owns
no data.
The draw debug API is being put in a non-working state by
this PR as it conflicts with the new lifetime / ownership of
the `DRWContext` class.
A new design with a global (threadsafe) debug module is needed
to add back support for these debug features. Note that these
are not user facing features.
Some parts of EEVEE are still calling the global context and that
caused crashes in the volume probe baking pipeline where
the context is not yet known. Sort circuiting these function
calls in this case fixes the issue, but a more longer term
solution would be to alway have a `DRWContext` available inside
`eevee::Instance`.
I did some testing and didn't find much of a difference in frame time.
However, we should still strive to remove all global access in the future
to avoid potential overhead of `thread_local`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135521
