This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
This moves the remaining `.c` files in the following `editors` folders to C++:
`physics`, `screen`, `sound`, `space_buttons`, `space_file`, `space_graph` and `space_image`.
One exception is `fsmenu.c` which has platform specific issues on macos and
windows. E.g. the `Carbon/Carbon.h` include also declares a `Collection` type that collides
with ours.
Also see #103343.
Pull Request: https://projects.blender.org/blender/blender/pulls/109918
Pass key that is being removed to `seq_cache_relink_keys()`. This allows
to remove checks before calling the function. Also makes it possible to
assert, that links are actually pointing where they should be.
When the selection mode in the Grease Pencil tool settings changes,
the selection domain of all curves in the active Grease Pencil object
has to change.
This PR handles that conversion. Point selections are converted to
curve selection and vice versa.
Note: this PR only takes care of selection modes 'Point' and 'Stroke'.
'Segment' mode is handled in a separate PR (#109221).
Pull Request: https://projects.blender.org/blender/blender/pulls/109964
Caused by 7a943428de
Looking at history, e.g. 575ade22d4 or prior, it seems the
"fallthrough" [related compiler warning was removed in 7a943428de] was
actually intended in the case of `VPAINT_TOOL_AVERAGE`.
So first, the average color is calculated and after that regular drawing
should happen with that color.
Now make this more clear by calling both `calculate_average_color` as
well as `vpaint_do_draw` before breaking.
Pull Request: https://projects.blender.org/blender/blender/pulls/109971
Add pie and ring styles of progress indicators. Exposes progress bar to
the Python API and adds a "type" property to allow style variation.
This can be used for scripts & add-ons to show progress in the UI.
Ref !109882.
Co-authored-by: Campbell Barton <campbell@blender.org>
Use `BLI_ghash_insert` instead of `BLI_ghash_reinsert` to store images.
VSE links stored cache keys for each frame in style of linked list.
These links must be maintained when any image/key is removed from the
cache. Reinserting can free key without proper relinking, which would
lead to accessing this freed key when cache limiting frees images in
a frame.
This should not happen since reinserting is prevented in
`seq_cache_put()`, but it's safer to assert, that key is not stored in
hash instead.
Make it harder to retrieve a mutable attribute from const a const mesh,
and use the attribute search function to check multiple domains and
colors at once.
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. "Break" functionality can be implemented manually using
Switch nodes in the loop for now. It's likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
* Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
* Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
Pull Request: https://projects.blender.org/blender/blender/pulls/109164
This data-block was originally added in eb4e3bbe68.
However, that original plan wasn't fully implemented, with simulations
now integrated with geometry nodes and modifiers instead of a separate
data-block. We kept the data-block around anyway since we have the
loose plan of using a similar data-block to make global simulations
connected between multiple objects. But it may be a while before we
implement that, and in the meantime having this just causes confusion.
The simulation data-block file isn't used currently, and is unrelated to
the current simulation caches. It would also be reasonable to declare
the function in MOD_nodes.hh, but I went for keeping it together
with the other more public simulation cache code.
Pull Request: https://projects.blender.org/blender/blender/pulls/109967
`outliner_do_scene_operation` wasnt recursive, so it only acted on the
top-level `TreeElement` (which was fine for Scenes view, but failed in
`Blender File` view).
Now use an iterator that handles open subhierarchies as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109810
Many high-level functions with unrelated code were templated based on
the color attribute domain and type. In the end, those were just a few
branches though, similar to other branches. So to reduce binary bloat
and clarify code, move tempates to the point where separate types are
actually needed. Also move constant code out of loops, and use generic
arrays and spans to store some caches. The binary ended up 53 KB
smaller for me, which isn't much but it's in the right direction.
Performance wise nothing really changes. The vast majority of time in
vertex paint is spent on unrelated things like calculating normals or
uploading GPU buffers anyway.
The one ugly part I didn't account for when I started is the casting
between the "ColorGeometry" and "ColorPaint" types. I'm not sure that
this is correct, but it's just a more explicit version of what was
there already.
Pull Request: https://projects.blender.org/blender/blender/pulls/109941
`AbstractTreeViewItem::supports_collapsing()` returns true in the
default implementation, so no need to override that to do the same.
Notes the default behavior in a comment now.
Name collisions can become a big issue in liboverrides when production
files gets messy (weird overrides duplicates, bad resync with heavily
changing assets, etc.).
This commit tries to alleviate a bit the problem by generating 'more
unique' names for liboverrides, when an exact match with the reference
is not possible.
So by default, in most common case, the liboverride ID will still have
the exact same name as its linked reference.
If this is not possible, then the new liboverride ID will get a name
which is unique to within the whole current Main (for its ID type). In
particular, this ensure that new override IDs are either named exactly
as their references, or have a name which is not used by any other
reference (linked) IDs.
Note that this is not a perfect solution, since changes in library data
can lead to name collisions later on. However, it should greatly reduce
the frequency of such problems.
This new namemap allows to generate new ID names which are unique in
current Main (for a given ID type), regardless of the library they
belong to.
This new feature will be used by library override to try to reduce name
collisions with its linked reference IDs when more than one override
exists. It is not intended to be used for general ID naming.
Now that liboverride process on save (the diffing + pruning unused
override operations + reset of non-overridable changes) works better. it
leads to a bad side-effect: all system overrides data indirectly
modified through animation or drivers get reset.
Since in current system e.g. most objects of a rigged asset are system
overrides, but their transform is modified by bones animation, this
leads to entire overrides of assets being reset to their linked state
until next depsgraph evaluation.
While this is the expected and correct behavior in absolute, this is
very bad from a user experience PoV.
This commit address the issue by simply re-running a 'frame change'
despgraph update, to ensure all drivers, animations etc. are properly
re-applied after liboverride diffing cleanup & reset.
While in theory RNA collections of IDs will have unique names in common
use cases, it can happen that there are naming collisions (due to a same
RNA collection having ID pointers to data from different libraries,
having the same name).
This situation is deadly for liboverride applying code, since it rely on
finding which item of the collection to modify by using its name.
To alleviate the problem, this commit changes the way items are searched
for, by adding an extra first check to find an item which matches both
the requested name and index.
While not perfect, this should reduce the breaking cases when production
files get dirty and start having complex mangling of override and linked
data naming.
Code was only considering RNA pointer properties to IDs, but not the
case of RNA collections of ID pointers (like e.g. the Collections' `objects`
property).
This would result in 'resync enforce' fixing tool not working properly
e.g. on liboverride collections' objects.
In RNA collections cases, the cleaning code was buggy and could end up
never cleaning actually unused liboverride operations, resulting in
sometimes tens of garbage operations on e.g. Collection's objects list.
This was a fairly severe bug, since it could lead to very broken
overrides of collections in some cases when things start to get broken
in the production file, amplifying greatly initially small issues.
When the parent ID pointer of an object is a 'system override' (i.e.
matches hierarchy-wise the parent of the linked reference object, or
actually use the same linked object), also clear potential liboverrides
for the other related parenting properties.
This is especially critical for the parent inverse matrix, otherwise if
it ever gets out of sync, in case of re-parenting in the lib data, the
offset would remain and move the liboverride child object into random
places.
NOTE: This may break some very specific workflows where users would rely
on actually overridden parent invert matrix. Not much to be done here,
there is currently no way to support both cases. This is not expected to
be a common use case.
While setting the parent object itself already had its dedicated
liboverride apply function to avoid resetting other related properties
like the invert parent matrix, other related properties also had custom
setter callbacks with similar effect.
This commit fixes the propblem for the `parent_bone` and `parent_type`
properties by adding a custom liboverride apply callback for them too.
We need setters and getters for these two very commonly accessed attributes of grease pencil.
The code is based on the implementation of `CurvesGeometry::positions()` and `CurvesGeometry::positions_for_write()`.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/109733
Note: Change applies to Grease Pencil 3.0 only (experimental feature).
Enables use of drag & drop to reorder grease pencil layers through the layer
tree UI, as well as inserting layers into groups. This is an intuitive and
often requested method of managing such data-structures. Visual feedback should
be improved still, and the gap between items be removed, to reduce flickering
while dragging. These are general improvements for tree views however which
should be done separately.
There is no support yet for dragging layer groups, this requires further
changes in the internal grease pencil APIs.
#109825 introduced the necessary drag & drop support for tree views, #109824
prepared the internal grease pencil API for it.
Pull Request: https://projects.blender.org/blender/blender/pulls/109826
No user visible changes expected, these are just the internal API preparations.
Modifies the Drop API for views so that tree-views can choose to insert items
before, after and into other items.
Note: While there is support for drag-tooltips that can explain how an item
will be inserted, there is no drawing yet like in the Outliner, that indicates
if an item is inserted before, after or into. There is some work on that but
that can be done separately.
Changes:
- Removes `AbstractViewDropTarget` that was shared between tree- and
grid-views, and adds `AbstractTreeViewDropTarget` and
`AbstractGridViewDropTarget`. The tree-view needs specialized handling now,
and although they could share some code still, it's not worth having another
level of inheritance.
- Modifies the drop-target API to use `DragInfo` which contains more info about
the dragging operation than just the `wmDrag`.
- Adds `determine_drop_location()` to the `DropTargetInterface` which drop
targets can use to determine when dropping means inserting before, after or
into.
- Store the block and region in the view. This is needed unfortunately but
shouldn't be an issue since the tree view is recreated on redraws, together
with the block.
- Various smaller tweaks and additions to views as needed.
TODO (outside scope of this change): Increase row height so there is no gap
between tree view items, but keep things visually the same otherwise. This
reduces flickering while dragging.
Pull Request: https://projects.blender.org/blender/blender/pulls/109825
