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
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
Fix an issue where imported F-Curves were allocated but not zeroed out,
when importing skeletal animation from USD.
When growing the F-Curve array, `BKE_fcurve_bezt_resize()` will now zero
out new array elements, instead of leaving the initialisation to the
caller. There are many fields in `BezTriple`, and the caller is likely
to only set those that can be imported (like the keyframe coordinates &
handles).
This fixes an issue introduced in 857743db9d.
Pull Request: https://projects.blender.org/blender/blender/pulls/135448
Adds a mode option to the node to choose between the existing
behavior and new behavior that converts each face to a cyclic curve.
Generally this is much faster than the existing mode because it's
easy to parallelize and because curve offsets and face and corner
attributes can be implicitly shared to avoid copies.
Resolves#134671.
Pull Request: https://projects.blender.org/blender/blender/pulls/134773
At this point, it is unlikely that we will revert the changes made over
a decade ago to the Dyntopo edge splitting code. The old code will still
exist in the git history, but to improve readability, this commit
flattens out the blocks and removes the `#define` statements.
Pull Request: https://projects.blender.org/blender/blender/pulls/135410
This patch refactors static cache invalidation of images by tracking an
update count. Images now store a runtime update count that is updated
every time the image is tagged for update. Cached images store a copy of
the update count at the moment they were cached, and are invalidated if
if it changed.
Compared to #134878, this is simpler and more robust, since update IDs
are isolated to images only and not to the DEG update count. Though this
only supports images specifically because they are not covered by the
copy-on-evaluation system, which means #134878 will cause multiple
depsgraph to fight over images.
Pull Request: https://projects.blender.org/blender/blender/pulls/134905
The issue was that the versioning code didn't run when loading the action.
Thus it had no slots and so was crashing trying to get the first slot.
This PR fixes that in 2 ways:
* Check the slot count of the loaded action, and return/notify the user
* Actually make sure the actions are versioned
Point 1 is important anyway because actions can have no slots (though unlikely).
Point 2 ensures that old pose assets can actually be used
Pull Request: https://projects.blender.org/blender/blender/pulls/135232
The compositor backdrop is still visible even after a new completely
different file is loaded. This is because compositor contexts cache
things like the backdrop, and contexts are stored on interactive
compositor renders, which are not freed until Blender is closed. To fix
this, we cleanup the interactive compositor renders that were created
upon file load.
Pull Request: https://projects.blender.org/blender/blender/pulls/135390
Add a new function `bke::animdata::prop_is_animated()` that returns
whether an RNA path + array index is animated by anything. This covers
the assigned Action, NLA Action strips, and drivers.
This function is now used in the determination whether the visibility
of a GreasePencil layer is animated.
The easiest way to implement this with the existing F-Curve-visiting
logic was to call `adt_apply_all_fcurves_cb()`. However, that function
did not allow the callback function to signal "stop looping, I found
what was I was looking for", so I extended it to do just that. I don't
expect the extra conditions to significantly slow down the other uses,
as the branch predictor will very likely optimise for the "returning
true" case for those calls that simply visit everything.
Pull Request: https://projects.blender.org/blender/blender/pulls/135317
The issue was that during playback, the evaluated Grease Pencil ID
is not being copied again for re-evaluation. This meant that the
adjustments get re-applied over and over again.
Ideally, we would restore the drawing pointers before modifiying them
again, but this is a bit trickier to implement.
To fix this issue for now, we do the layer adjustments during object
data evaluation. Using the geometry set for modifier evaluation
means that we copy the data and apply the adjustments for every
object.
In the future this can be optimized to only happen once per
Grease Pencil ID (in `BKE_grease_pencil_eval_geometry`).
Pull Request: https://projects.blender.org/blender/blender/pulls/135387
Replace `bNodeInstanceHash` with a `Map`. Move it to the node tree
runtime data. Simplify some code by removing the tag from the hash
value and collecting unused previews directly. Then just remove a
bunch of code that's now unused.
Note that texture node previews haven't been working for a while
anyway, and the experimental shader node previews seem to use
a different system (this one is a remnant of Blender Internal).
Pull Request: https://projects.blender.org/blender/blender/pulls/135310
Code in readfile that copies over brush assets (and related data) from
the old Main to the new one cannot use the namemap reliably, due to how
the linked IDs of the library get temporarily spread between both Mains.
Since in theory there should be no need for name uniqueness processing
in this case anyway, for now disable the relevant code when the library
is re-used.
NOTE: Issue reported in #135315, revealed by recent refactor in
00f406c34c and 16e552298c.
NOTE: This fix is a bit hackish, but seems to be the simplest most
straight-forward way to address the problem. More invasive solution can
be investigated if this proves to still be problematic.
NOTE: While 4.4 also has the same invalid handling, this PR should
likely not be ported to it, as previous BKE_main_namemap code was more
permissive with such invalid behaviors, and there is no known bad
consequences in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/135362
Adds the option to create a boolean socket that can be used as a panel toggle.
This allows creating simpler and more compact node group UIs when a panel
can be "disabled".
The toggle input is a normal input socket that is just drawn a bit differently in
the UI. Whether a boolean is a toggle input or not does not affect evaluation.
Also see #133936 for guides on how to add and remove panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133936
Note: This commit is essentially non-behavioral change, expect in some
fairly rare edge cases.
This commit does a few things:
* Move the whole BKE_main_namemap code to modern C++.
* Split API calls to work with the global namemap, or the local ones.
* Simplify and make the code easier to follow and understand.
* Reduce 'default' memory usage by using growing BitVector for numeric
suffix management, instead of a fixed 1K items.
* Fix inconsistent handling of 'same base name and numeric suffix,
different name' issues (e.g. 'Foo.1' and 'Foo.001'), see
`re_create_equivalent_numeric_suffixes` new unittest.
* Fix completely broken handling of `global` namemaps. This was
(probably!) OK so far because of their currently very limited
use-cases.
It also adds a few minor improvements to existing behavior (essentially
in exotic rare edge cases):
* Names that get too long are now only shortened by one char at a time,
trying to modify the requested base name as little as possible.
* Names that are short, but for which all the manageable numeric suffixes
are already in use, are extended with an (increasing) number, instead
of being shortened.
This work also allowed to detect a few (apparently harmless?) bugs in
existing code, which have been fixed already in 4.4 and main, or in this
commit as well when they depend on changes in namemap code itself.
About performances: This commit introduces a minor slow-down. Some tests
heavily relying on this code (like `bl_id_management` and `blendkernel`
e.g.) get slightly slower (resp. about 1% and 5%). This seems to come
mostly from the added complexity to handle correctly multiple different
names with the same base and numeric suffix value ('Foo.1' and
'Foo.001', but also in the global namemap context where IDs from
different libraries can have the same name).
Pull Request: https://projects.blender.org/blender/blender/pulls/135199
The operator refused to pack libraries with absolute paths (wasnt the
case in its original implementation 16411da41e, but was added in
129fb516f4 -- for the reason of preventing "bad things happen on
unpacking" without an explanation of what these exactly are). It did so
by cancelling as soon as **one** library with ab absolute path was
found.
Now with the introduction of essential assets, we have those absolute
path linkages more or less "by default" as soon as e.g. a brush is
used, so the operator is more or less unusable now. NOTE: these absolute
essential asset library paths seem to be converted to relative on save?
Upon reload, these are then gone... (might be another hint for an
alternative fix, see below)
By "bad things happen on unpacking" I would assume the scenario of
folders being created in unwanted locations (e.g. when moving from one
OS to another), but the same thing is also true for packing **files**
instead of libraries (there, absolute paths are allowed, and unpacking
in original locations can equally fail or create folder structures that
are "unexpected"). NOTE: for files though we have the choice of
unpacking to a relative folder (which wouldnt really be possible since
libraries can be nested and we would have to correct paths all over the
place). NOTE: the chance of creating "unwanted" folder structures with
relative paths might be slimmer, but if you have a lot of "upwards"
parent folders, relative can easily "break" as well.
Possible ways to resolve this:
### [1] skip libraries identified as essentials assets (still cancel on all other absolute paths)
Can check a library path to be contained in `EssentialsAssetLibrary`
`essentials_directory_path`. This would be the safest imo since it is a no-behavior change.
### [2] lift the limitation of absolute paths alltogether
Like mentioned above, things could break with "relative" almost as
easily as with "absolute", there might even be scenarios where
"absolute" is wanted. It is a more behavior-changing fix that we might
explore more after 4.4 is out.
### [3] skip absolute libraries (but continue with non-absolute libraries)
This does change behavior as well (it does not cancel as soon as **one**
library with ab absolute path was found anymore, but the worst case
scenario is that you end up with an "incomplete" file if you really
mixed absolute and realtive lib linking).
This PR implements [1] for now, [2] or [3] can follow for 4.5.
Fixes#134665
Pull Request: https://projects.blender.org/blender/blender/pulls/134839
The `with_smoke` case is handled correctly and checks for reallocation,
but the liquid case was ignored for unknown reasons.
The `with_smoke` distinction was added years ago (c7596cd820)
but for some reason the `with_liquid` case was ignored for reallocation.
Pull Request: https://projects.blender.org/blender/blender/pulls/135247
There is no need for amortized growth for the field interface.
Array seems slightly better than Vector because it's smaller and
doesn't give the impression that the size might change.
Pull Request: https://projects.blender.org/blender/blender/pulls/135257
The enum items propagation mechanism for Menu sockets makes a local copy of item
pointers to propagate between node group inputs and interface definitions.
In case these items are not used (e.g. because they are already shared with the
socket) the local copy must still be released to avoid leaking the memory.
This only happens with more than 4 enum items, because of the internal default
buffer for `Vector`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135226
This adds a new `Visual Geometry to Objects` operator which is added to the
`Apply` menu.
It creates new objects from the evaluated geometry of the active object. Other
than e.g. applying modifiers, this operator does keep all generated data and
creates new objects and collections for instances. It does have some
similarities to `Make Instances Real` with the main difference that it doesn't
actually realize instances, i.e. instanced geometry is still shared between all
objects using it.
It does intentionally not replace the original object, because the semantics of
that aren't all that obvious. It's especially tricky when the object was
referenced by other objects. Instance attributes are not preserved currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/134119
Same was true for SimpleDeform.
Invert vertex group influence should only have an effect if there is a
group specified.
Shrinkwrap always uses a weight (gets weights via
`BKE_defvert_array_find_weight_safe` -- which gets full weight for no
group specified, rightfully so), if this gets inverted, we get no
influence at all.
Now move the inverting of the weights to `BKE_defvert_array_find_weight_safe`,
adjust the other callers accordingly (Bevel also does not need to check for a valid
vertexgroup beforehand).
Pull Request: https://projects.blender.org/blender/blender/pulls/121625
There's no point in having non-threaded image color space conversion functions.
So merge the threaded and non-threaded functions and clarify names while at it:
- IMB_colormanagement_transform & IMB_colormanagement_transform_threaded
-> IMB_colormanagement_transform_float
- IMB_colormanagement_transform_byte & IMB_colormanagement_transform_byte_threaded
-> IMB_colormanagement_transform_byte
- IMB_colormanagement_transform_from_byte & IMB_colormanagement_transform_from_byte_threaded
-> IMB_colormanagement_transform_byte_to_float
These places were doing single-threaded colorspace conversion previously, and
thus now are potentially faster:
- IMB_rect_from_float (used in many places)
- EXR image "save as render" saving (image_exr_from_scene_linear_to_output)
- Object baking (write_internal_bake_pixels, write_external_bake_pixels)
- General image saving, clipboard copy, movie preparation
(IMB_colormanagement_imbuf_for_write)
- Linear conversion when reading HDR images/movies
(colormanage_imbuf_make_linear)
- EXR multi-layer conversion (render_result_new_from_exr)
For one case I benchmarked, which is to render out a 2D stabilized 10 bit input
movie clip out of VSE, the total render time went from 49sec down to 44sec
(Ryzen 5950X), one of the single-threaded parts was the colorspace conversion
in the movieclip code.
Pull Request: https://projects.blender.org/blender/blender/pulls/135155
