For the brush assets, this mechanism makes brush, texture, node tree and
image datablocks editable even when library linked.
This commit should introduce no functional change yet, as the code to
actually tag such libraries as editable will come later.
* These libraries and their datablocks are preserved when loading a new
blend file, much like the UI can be preserved.
* Operators that create new datablocks to be assigned to such datablocks
will put the datablocks in the same library immediately. This was
implemented for datablocks relevant for brush assets.
* RNA does not allow assignment of pointers from such linked datablocks
to local datablocks.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121920
* Linked datablocks should not point to local datablocks.
* Main datablocks should not point to non-main datablocks.
This is checked now both in the poll function for UI lists, and in the
pointer assignment code used by the Python API.
Image's render result might get freed from another thread while the
compositor is running.
Add an utility function which invokes callback on the image's stamp
data from a thread-guarded block.
Ref #118337, #121761
Pull Request: https://projects.blender.org/blender/blender/pulls/121907
Image operation's get_im_buf() function was not thread-safe:
- It had TOCTOU issue around calculating multi-layer indices and
requesting to load the image buffer.
- It accessed render result, render layer and pass pointers without
any thread guards.
This change moves all the logic needed to access the image buffer
into a single function with proper guards around the access. The
result is user-counted, so it is usable in a thread even if another
thread modifies the image.
The is still potential TOCTOU in the compositor since the image is
acquired twice: once from init_execution(), and once from the
determine_canvas(). It could cause issues if image resolution is
changed between these calls. It is still to be looked into.
Ref #118337, #121761
The `Layer::get_frame_duration_at` was not working for frames
with a fixed duration. While this is not an issue at the
moment (because fixed duration frames are not exposed
yet), this would have been broken in the future.
This fixes the issues, cleans up the code a bit, and also
adds regression tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/122052
There were multiple places in the GPv3 code that assumed that the
frame key is equivalent to the start frame of the frame with that key.
But this is not the case. The `FramesMapKeyT` is either the start frame
*or* the end frame (for frames with fixed duration).
This adds a new function `start_frame_at` that returns the start frame
number of the frame at `frame_number` or -1 if no such frame exists.
One place needed the index into sorted keys (for onion skinning) so
this was replaced with a new function `sorted_keys_index_at`.
With these changes, `Layer::frame_key_at` is now a private method.
Pull Request: https://projects.blender.org/blender/blender/pulls/122045
Other code also uses the suffix `T` to indicate that this is a type.
Note that `FramesMapKeyT` is just an `int` but with a very specific
meaning. Hence the alias to avoid confusions.
- Directly check for vertices with two edge neighbors instead of looping
- Use arrays of C++ types as return values
- Use lambda to avoid repetition for each edge vertex
- Use `edge_other_vert` utility
`mesh_final` isn't really the final mesh but the "current" mesh. Adding the
extra word here isn't helpful. This also helps to reduce the size of the diff
in #119968 where the mesh variables have much smaller scopes.
After recent commits, the .cc file is only used for actual object data
evaluation in the depsgraph, and the header is only used for the old
DerivedMesh data structure that's still being phased out.
Mesh object evaluation is unrelated to DerivedMesh nowadays. Change the
name to something similar to the other evaluation functions called in
BKE_object_handle_data_update.
Grouping the legacy DerivedMesh code in the same place helps keep
the actively maintained code clearer and clarifies what we are hoping
to remove in the future.
Move to a file with the more consistent "mesh_legacy" naming, out of the
modifier evaluation code which has nothing to do with this anymore. That
file can be renamed in a separate step.
Using a non-virtual derived struct for polymorphism is error prone,
especially combined with the requirements of DNA. Instead, use a
separately allocated runtime struct as done for many other DNA structs.
In a followup commit, the remaining runtime members of `PreviewImage`
could be moved to the new runtime struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/121509
This commit prevents considering Scenes (and a few other ID types, like
WindowManager or Library) as being part of liboverride hierarchies.
Having collections, objects, obdata etc. depend on a Scene ID is
typically not considered as a valid setup for linked data.
And in any case, Scenes are not officially supported for liboverrides
currently.
In the case of #121410, where a driver of the armature object was using
the Scene ID, it will simply keep that scene reference pointing to the
linked scene, instead of overriding the whole scene.
Code checking whether an ID should be considered as part of the
currently processed liboverride hierarchy or not was very similar all
over the liboverride code.
It is now deduplicated into two util functions, which helps ensuring
coherence in these checks, and future potential changes in this
filtering process.
NOTE: While no pratical changes are expected form user PoV with this
refactor, technically it does modifies the behavior in some cases (added
checks).
This required making a whole bunch of other functions in the call chain
take const parameters as well. It also required changing some function
pointers in some types to take const parameters, which in turn required
changing all the functions that are pointed to by those function
pointers to take const parameters as well.
Additionally, there was one mutable usage of the `FModifier *` parameter
in `fcm_cycles_time()` that had to be removed to make the call chain
const. However, this turned out to be a code path that shouldn't be
reachable, and would represent a bug elsewhere. So it was changed to
an assert.
All in all, the non-constness was deep and tangled.
There's still a lot more that we can make const, but I wanted to keep
this change as narrow and focused as possible.
Code used to tag liboverrides references as 'pre-existing' to force code
further down the way to always keep these IDs linked.
However, this was a (bad) hack, since it could have uncontrollable
side-effects, abusing a tag for somethig else than its original meaning.
And this should not have been needed for quite some time already, as
liboverrides handling was already properly done by append
post-processing code.
No behavior change expected here.
In a nutshell, the handling of dependencies in the 'append' part of the
code was not fully correct, and could break badly in some complex cases
(like appending complex hierarchies of data partially re-using some
dependencies from other previously appended data).
This could lead to e.g. some linked data referencing some local IDs...
straight way to crash in undo case (among many other problems).
Previous code was fairly compact and tried to be smart and efficient,
making some not-always-correct assumptions, and being quite hard to
fully understand.
So the first step of this fix was some refactoring:
* Splitting the post-process part of the 'link' case into its own
function (it is fairly trivial, and while it does duplicate some
logic to some extent, it makes the overall link/append process
clearer).
* Heavily refactoring the part of the 'append' code that decides how
to handle each linked ID.
The append-related post-processing is now significantly more complex,
but hopefully better divided in reasonably logical steps. And it is now
expected to deal with complex re-usability cases properly.
Pull Request: https://projects.blender.org/blender/blender/pulls/121867
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
The end of a fixed duration frame is stored as a special
`GreasePencilFrame`, notably with a `drawing_index` of
-1.
These were previously called "null" frames (because they
don't point to a drawing). But this name wasn't great.
This commit renames these to the more descriptive
"end" frame. In code, they are `GreasePencilFrame::end()`
and can be checked for with `frame.is_end()`.
All comments and function names referring to "null"
frames have also been updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/121868
The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can
discover and install add-ons and themes directly from the internet, and notify users about their updates.
By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit
the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for
extensions.blender.org upon startup.
When will Blender access the remote repositories:
* Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json)
* Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json).
* Every time you start Blender: selected repositories get checked for the latest info (json).
------------------
From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender
will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are
deemed core functionality which just happened to be written as Python add-ons.
Links:
* Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/
* Extensions website: https://extensions.blender.org/
* User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index
* Technical specifications: https://developer.blender.org/docs/features/extensions/
* Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
------------------
This PR does the following:
* Move extensions out of experimental.
* No longer install `scripts/addons` & `scripts/addons_contrib`.
* Add `scripts/addons_core` to blender's repository.
These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences
moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period.
For more details, see #121830
From scripts/addons:
* copy_global_transform.py
* hydra_storm
* io_anim_bvh
* io_curve_svg
* io_mesh_uv_layout
* io_scene_fbx
* io_scene_gltf2
* pose_library
* ui_translate
* viewport_vr_preview
Extra: bl_pkg (scripts/addons_contrib)
Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core
which is enabled by default.
All the other add-ons are already available at extensions.blender.org. To use them you need to:
* Go to User Preferences > Extensions
* You will be greated with an "Online Extensions" message, click on "Enable Repository".
* Search the add-on you are looking for (e.g, Import Images as Planes).
* Click on Install
Over time their maintaince will be transferred over to the community so their development can carry on. If you used to
help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593
Ref: !121825
To simplify propagation of the attribute with joined geometry
(0.0 defaults are generally easier to handle with attributes, and
even more performant), store the inverse of the current "hardness"
attribute as "softness" instead. This change involves adding a few
`1.0f - value` operations, though in the future as the renderer is
replaced that mostly should become unnecessary.
Updated version of #118007.
Pull Request: https://projects.blender.org/blender/blender/pulls/121578
This PR changes the `vert_hide_update` function to flush visibility
from the selected vertices to their corresponding faces on the node
level instead of on the mesh level. This ensures that in certain cases
where vertices exist along the border of a nodes are selected that
all corresponding faces are updated and their PBVH nodes are tagged
for updating appropriately.
Additionally, this provides a roughly 15ms improvement over the current
implementation operating on a subdivided sphere of 32 million vertices
when selecting a relatively small portion of the mesh. (50ms -> 35ms).
Spawned from a discussion on #120798
Pull Request: https://projects.blender.org/blender/blender/pulls/121678
Caused by 85ce2a34e3
Default layers added with the primitive gpv3 object has the `use_mask`
property enabled. To fix this, set `GP_LAYER_TREE_NODE_HIDE_MASKS`
inside `add_layer/groups()` function instead of the operator's code.
Falk found this in #121734
Pull Request: https://projects.blender.org/blender/blender/pulls/121780
This implements and exposes the `View`/`Scene` brush radius option.
* `View`: Brush units are in pixels. Zooming in and out in the viewport will make the brush stay the same size relative to the view, but grow/shrink relative to the scene.
* `Scene`: Brush units are in meters. Zooming in and out in the viewport will make the brush grow/shrink relative to the view, but stay the same size relative to the scene.
The default radius unit is `Scene`, which is what GPv2 did.
The "2D Animation Template" was updated to disable using the radius in the unified paint settings. This means that using the template by default will use the brush radius, which also mimics the behavior of GPv2.
The user can change the radius brush unit from the `Advanced` panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/120257
This just hid that freed memory was being passed to
CTX_wm_region_popup_set.
The change from [0] exposed this issue, however the problem has
existed for a long time (likely since the inclusion of popups in the
context) it's just that setting the context member when popups
are first displayed made problems more likely to show up.
[0]: 38d11482f5
