Context is needed to import and instantiate assets correctly. Previously
the context was stored as "evil" pointer in the drag data. Since
77794b1a7b, context is passed to the dragging callbacks doing the asset
import, so the context doesn't need to be stored that way anymore and
can simply be passed to the import function.
This change is needed for PAINT_OT_weight_sample_group to be accessed
from a menu.
Otherwise using the OPTYPE_DEPENDS_ON_CURSOR flag causes both the
initial activation and the selected vertex group to prompt the user
to select a region.
Similar to 79115c5c56, but for multires sculpting. Improves
the PBVH build time for a 16 million vert multires sculpt by about 100ms
(from 470ms to 370ms). That itself is just a small portion of the time
spent entering sculpt mode though.
At least on GCC on Linux, it appears std::function has noticeable
overhead compared to blender::FunctionRef. That makes some
sense, as the latter generally handles less, and the performance
difference is mentioned in the function ref header as well.
To test performance, I measured the timing of the first data
upload (`BKE_pbvh_draw_cb`) after entering sculpt mode. For
meshes, I observed a 30% improvement, from 1.7s to 1.3s.
For multires, I observed a change from 290ms to 263ms.
The change should apply to regular draw updates while sculpting,
but that's harder to measure.
This is also cleaner semantically, since the callbacks aren't meant
to own any data, they are just lambdas that capture by reference.
Reduces the average runtime of building mesh PBVH nodes from 4.2 to
3.3 seconds in a basic test with a 16 million face grid on my hardware.
This is probably mainly because of improved inlining with C++
templates. It also makes the code easier to understand.
When entering sculpt mode (or another mode that uses PBVH), the
bounds of each triangle are calculated serially. Doing this in parallel
is simple, and about 10x faster (568 to 56 ms) on a Ryzen 7950x.
One thing to point out is that `PBVH::nodes` is now stored in a `Vector`
which replaces the manual amortized growth. That requires explicitly
setting the defaults of PBVHNode fields for default initialization.
Similar to f0b53777c8
revert Outliner: Port grease pencil effect elements to new tree-element code design
This is causing compile errors which I can’t fix right now. Reverting until resolved.
## Overview
Much like node groups, or a VSE clip, when we duplicate we actually want a _linked_ duplicate. This PR updates the NLA key board for Duplicate linked to `Shift + D`, and Duplicate to `Alt + D`.
Additionally, update Tool tips to reflect duplicate vs linked duplicate.
Pull Request: https://projects.blender.org/blender/blender/pulls/110316
In case a blend file opening fails (in the context of library content
listing, e.g. for linking or appending), the File Browser would just
show an emtpy window.
With the new comnpatibility policy, this will now become a fairly common
situation, which requires giving proper explanations to the user.
This commit re-uses and extends the system used to display errors
messages from the Asset browser.
Part of #109151 (PR !110109).
This implements the main aspects of changes to blendfile compatibility
as designed in #109151:
* Blender files which file minversion is newer than current Blender
executable won't be loaded at all.
* Blender files which file version is newer than current Blender will
triger systematic warning to user:
* In the status info bar (lower right corner in default UI).
* When attempting to save (overwrite) them.
This means that the file minversion becomes a hard limit, and not a
soft, warning-only as it used to be. Further more, forward compatibility
warning is now systematic (instead of depending on file minversion),
and more visible for users.
See also https://wiki.blender.org/wiki/Process/Compatibility_Handling
for details over the new policy.
Technically:
* Opening any file with a minversion newer than current Blender file one
now triggers an early abort, with an error message reported to the user.
This is handled by a new utils called from `blo_decode_and_check`.
* Any file newer than current Blender version sets a new
`has_forward_compatibility_issues` flag in Main struct at read time.
* Status bar info area is turned into a template, which uses this flag
to display special warning UI and tooltip when set.
* A new confirmation popup appears when user tries to save (overwrite)
such a 'newer' blendfile, stating potential loos of data, and
proposing by default to 'save as' instead.
* The 'quit unsaved' popup has also been updated to 'save as' instead of
'save' when the edited file is has potential forward compitibility
issues.
Part of #109151 (PR !110109).
Since in rare cases there may be needs to expose file subversion here,
the following format was defined:
<major>.<minor> (sub <subversion>)
Part of #109151 (PR !110109).
This struct was defined in `BKE_fcurve.h` but only used in editor files.
The only function that used this struct in BKE was marked unused.
This commit removes the unused BKE function and moves the struct
to `ED_keyframes_edit.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/110527
Add an API for armature layer access. Instead of accessing `arm->layer`
and friends directly, the code now uses this API. This will make things
easier to replace by bone collections in the future.
The functions are named "bonecoll" (short for "bone collection"), as
that's the soon-to-be-introduced replacement for armature layers. This
API is the first step towards that replacement, and should help to
reduce the changes necessary when functional changes are committed.
This also creates a new module `source/blender/animrig` for Animation &
Rigging code. This will, for example, house the bone collection system
in the near future.
There is a bunch of code currently spread across blenkernel and editors
in a rather ad-hoc way; it is intended that at some point that code gets
moved into `animrig` as well (or at least the subset of that code where
such a move makes sense; brain still required).
Ref: #108941
No functional changes.
The file bmesh_opdefines.c was recently converted to bmesh_opdefines.cc,
but the manual builder was not updated accordingly.
Also, update some comments in the code which were still mentioning the C
version of this file.
Pull Request: https://projects.blender.org/blender/blender/pulls/110532
