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
This applies to modifiers, constraints and shape keys.
Any driver on such data was not removed with it,
leaving invalid drivers on objects.
With this patch, the drivers are removed, but animation is left untouched.
This is because animation might be reused somewhere else and we don't
want to introduce potential side effects there.
This also adds unit tests for the fixed cases
Pull Request: https://projects.blender.org/blender/blender/pulls/134511
Remove GP legacy obtype and unused functions
Few hidden bugs are fixed with that:
- Outliner drag-drop for GP material/effect elements now works
- Correct stats are shown in status bar.
Pull Request: https://projects.blender.org/blender/blender/pulls/133957
Only remove a grease pencil layer from the evaluated copy when its
visibility is not animated.
Animation evaluation does not recreate the evaluated copy from scratch,
and thus once a layer is removed due to it being invisible, it never got
back.
The animatedness of the `.hide` property is determined once, when the
evaluated copy is created. This is subsequently used during evaluation
to determine whether the layer can be removed or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/135057
Grease Pencil ID data was being evaluated in the
`BKE_grease_pencil_data_update` function, but this function
is called from the evaluated objects.
The fix adds a new `BKE_grease_pencil_eval_geometry` function
thats called as a callback from `build_object_data_geometry_datablock`.
Resolves#134980, #135004.
Pull Request: https://projects.blender.org/blender/blender/pulls/135051
Update `BKE_fcurves_id_cb(id, callback)` so that it only reports
F-Curves for `id`. With legacy Actions this used to be "all F-Curves in
the Action", but with slotted Actions it should only report the F-Curves
for the assigned slot.
`BKE_fcurves_id_cb()` is used in two places:
1. Updating F-Curve paths in versioning, for example when node sockets
were added/removed. For this it is vital that the updates only happen
for those nodes that were actually affected by this versioning code,
and not blindly for all F-Curves in the Action.
2. Marking properties as 'animated' in the depsgraph, and the 'value
backup' for those properties. This should also be only done for the
properties of that ID, and thus be limited to the F-Curves for the
assigned slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/134851
This shared state between original data and depsgraphs was added in
98a0bcd425. Other physics systems also share
the pointcache, but not the simulation state to this extent, which leads
to this kind of crash.
The mutex lock is not a great solution, you don't really want both render and viewport to be filling the same cache in parallel. However
this kind of problem also exists in other physics systems, and solving
that is certainly beyond the scope of 4.4, and probably needs to wait
for a bigger physics rewrite. In general the recommendation is to bake
everything before rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/134779
The issue was that in the macro used, the wrong ID was passed into
the rename function. Since nodetrees are a separate embedded ID,
the rename function couldn't resolve the RNA path and thus failed.
This broke keys and drivers when renaming nodes.
Not only for the compositor, but all node trees.
This was caused by 1c7c1829b6
Pull Request: https://projects.blender.org/blender/blender/pulls/134936
This commit contains the following changes:
* Reduces scope of variables where possible, joining declaration and
assignment where necessary.
* Uses const for parameters and local variables where possible.
* Uses static_cast or reinterpret_cast where possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/130487
* Reduces scope of variables
* Joins declaration and assignment where possible
* Uses static_cast and reinterpret_cast instead of C-style cast
* Uses const where possible
* Uses reference instead of pointer where possible
Pull Request: https://projects.blender.org/blender/blender/pulls/134816
The `BKE_fcurve_bezt_shrink()` function had an artificial limitation to
only allow shrinking the `bezt` array. That limitation is now removed,
and therefore the function renamed to `BKE_fcurve_bezt_resize()`.
A note was added to the documentation that newly added array elements
should be initialized by the caller.
Pull Request: https://projects.blender.org/blender/blender/pulls/134864
