This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Caused by 580e0af309
The above commit fixed the condition that caused the hang in #128702 but
it also changed the `while` loop to a `do while`.
The do while loop executes the content of the loop once before checking
the condition of the while.
Whereas a while loop will check the condition first before executing the
content.
As a consequence, we could (falsely) enter the loop and return with a
(false) best direction.
To resolve, keep the check from 580e0af309 but go back to a `while`
loop (instead of the `do while).
Needs to go into 4.2 LTS
Pull Request: https://projects.blender.org/blender/blender/pulls/132270
This renames the `Strip` struct to `StripData` and also renames
the `Sequence::strip` member to `Sequence::data`.
This is a first step towards naming the `Sequence` struct to `Strip`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132165
When using the "individual origin" pivot mode, calculate the center
based on the following:
* If the stroke is a Bézier stroke, use the center of each handle as the pivot.
* Otherwise, if the stroke is not a Bézier stroke, compute the mean position
of the selected control points in the stroke and use this as the center.
This center value is then used e.g. by the rotation or scale transform modes.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130723
Currently each node's position is stored in the coordinate space of
its parent. To find the location of a node on the canvas, we have to
apply the translation of each of its parents. Also, nodes have hidden
"offset" values used while transforming frame nodes. Together,
those made the system much more complicated than necessary,
and they made the Python API ineffective.
This commit removes usage of the offset values and moves nodes
to be stored in the "global" space of the node canvas. It also resolves
some weird behavior when resizing frame nodes, and fixes a few bugs.
The change is forward compatible, so we still write files with nodes in
the old parent-space format. In 5.0 the conversion when writing can be
removed. The existing Python API also stays the same. A new
"location_absolute" property gives node locations in global space,
and changing the old property also moves the child nodes of frames.
Resolves#92458, #72904.
Pull Request: https://projects.blender.org/blender/blender/pulls/131335
Edit mode for curves and Grease Pencil was using the plain object transform for
all points without support for individual crazyspace transforms. This patch adds
support for the local rotation matrices, so editing curves on top of modifiers
converts offsets into original geometry space.
For Curves objects these matrices are currently only computed by the surface
deformation node, so editing on top of a surface deformation is the only case
that works currently.
For Grease Pencil the armature modifier is supported and more should be added
in future (see overview task #131599).
Pull Request: https://projects.blender.org/blender/blender/pulls/131619
For a bit of (somewhat related) history, check 8d590e4b86.
The real problem here is that for non square images, the
`applyAspectRatio` works with "wrong" vectors if translation constraints
(`CON_APPLY`) are used. Then, the passed vector might actually have axis
changed, e.g. constraining to the Y axis does not hold the Y translation
value in dvec[1], but in dvec[0]. This is expected by design, but
`applyAspectRatio` is not aware of this and does wrong things.
The easy way around this is to actually call `applyAspectRatio` before
the `CON_APPLY` stuff takes place.
NOTE: future improvement might be to split (or rename)
`removeAspectRatio` / `applyAspectRatio` becaues these functions also
handle the "conversion" to pixel values which is not obvious atm.
Pull Request: https://projects.blender.org/blender/blender/pulls/131608
Proportional editing expects `IndexMask` from all Bezier points not only from selection as it affects not only selected curves.
Therefore `selected_editable_strokes` changed `editable_strokes` and initialized with `retrieve_editable_strokes`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131519
Mutliframe editing wasn't using the falloff.
The fix adds a new field `Vector<float> grease_pencil_falloffs` to
`struct CurvesTransformData`. References it's values with `TransData.extra`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131147
Grease Pencil animation data is stored in the object-data, not the
`AnimData` of the Grease Pencil ID. This meant that the object was
not properly tagged for an update, because the code assumed that
the object had an `adt`.
The fix calls `ANIM_id_update` to directly tag the Grease Pencil
ID for an update (which will also update the Grease Pencil frames
animation data).
Avoid rebuilding BVH trees when meshes are copied.
Similar to the other uses of the shared cache system,
this can arbitrarily improve performance when meshes
are copied but not deformed and BVH building is the
main bottleneck. In a simple test file I got a 6x speedup.
The amount of code is also reduced and the system is
much simpler overall-- built out of common threading
patterns like `SharedCache` with its double-checked lock.
RAII is used in a few places to simplify memory management
too.
The downside is storing more `SharedCache` items in the
mesh runtime struct. That has a slight cost when copying
a small mesh many times, but we have ideas to improve that
in the future anyway (#104327).
Pull Request: https://projects.blender.org/blender/blender/pulls/130865
Oversight in 09d2108bf5
For one, numinput for keyframes would be broken unless the mouse is moved first.
Secondly, redo would also be broken (using the `Adjust Last Operation` panel or the `Repeat Last` operator).
Above commit did a check for `TRANS_RUNNING` before calling `grease_pencil_layer_update_trans_data`.
This isnt set in any of the above scenarios (it only gets set once the moues moves).
This PR removes `TRANS_RUNNING` check to have proper calls to `grease_pencil_layer_update_trans_data`.
It has one downside: you now get a `grease_pencil_layer_update_trans_data` as soon as you hit `G`.
So it does remove_frame / add_frame unnecessarily (since we are still on the same frame), but only once, sees harmless in comparison to the two regression it fixes.
Fixes#131092Fixes#130793
Pull Request: https://projects.blender.org/blender/blender/pulls/131143
These are useless now that PointerRNA has explicit default values, and
become a problem when real constructors are added to this struct. Simply
use the default empty value initialization instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/130927
Compositor: UI: remove snapping to nodes.
Snapping nodes to other nodes behaves in a very unpredictable way, which makes most snapping options useless.
The patch removes the following:
- Snapping options `Node X`, `Node Y` and `Node XY`
- Menu `Snap Node Element`
- Menu `Snap Target`
New behavior:
- Activating `Snap` always acts as 'Snap to Grid'
Part of https://projects.blender.org/blender/blender/issues/128612
Pull Request: https://projects.blender.org/blender/blender/pulls/127667
The root cause of this bug can be traced to:
- `ANIM_nla_mapping_get(ac, ale)` conditionally returns an `AnimData *adt`.
- This can be `nullptr` in various cases, depending on the editor (in `ac`) and
the type & source of data (in `ale`).
- This `nullptr` has different meanings:
1. There is not enough information to return an `adt` (like `ac` or `ale`
being `nullptr` themselves).
2. NLA time remapping should not be done. For example for NLA control F-Curves
(like animated strip influence), or Grease Pencil (because that doesn't use
the NLA).
- The above-returned `adt` is passed to other functions. Some of them are aware
of the "`nullptr` means no NLA time remapping" scenario, and gracefully handle
it. Other code, however, just gets "an adt" from the caller and handles it as
normal (and likely crashes on `nullptr`). Other cases start out as the first,
but somewhere in the call stack shift over to the second.
The approach taken in this PR to fix the bug is to (generally) stop signaling
"do not use NLA time remapping" via `adt = nullptr`, and instead explicitly
indicate/check whether remapping should be done.
In most cases this means passing a `bAnimListElem *` instead of an `AnimData *`,
because the former has the information needed to determine if time remapping
should be done or not. However, in some cases there is no `bAnimListElem *` to
pass, and instead other information determines whether remapping is needed. In
those cases we add a `bool` parameter or field in the appropriate place so that
calling code can explicitly indicate whether remapping should be done or not.
To accomplish this a variety of functions have been added to help handle things
correctly. Of particular note:
- `AnimData *ANIM_nla_mapping_get(ac, ale)` (that conditionally returned an
`adt`) has been removed entirely in favor of the new
`bool ANIM_nla_mapping_allowed(ale)` function that simply returns whether
nla remapping should be done or not.
- `ANIM_nla_tweakedit_remap(ale, …)` has been added, which wraps
`BKE_nla_tweakedit_remap(adt, …)` and only performs the remapping when
`ANIM_nla_mapping_allowed()` indicates that it's allowed.
- `ANIM_nla_mapping_apply_if_needed_fcurve(ale, …)` has been added, which is an
alternative to `ANIM_nla_mapping_apply_fcurve(adt, …)` that also only performs
the remapping when `ANIM_nla_mapping_allowed()` indicates that it's allowed.
Note that even with this PR there are still a couple of places remaining that
use `adt = nullptr` to indicate "don't remap", because they appear to be correct
and would require larger changes to make explicit. In those cases comments have
been added to explain the situation, with a reference to this PR. In the future
we way want to take the time to change those as well.
Also of minor note: this PR moves the definition of the type `slot_handle_t`
from ANIM_action.hh to BKE_action.hh. This is due to `BKE_nla.hh` (which needs
that definition) now being included directly and indirectly in a lot more
places. Moving the definition to BKE_action.hh prevents all of those new places
from gaining dependencies on the animrig module.
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130440
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
This member was only really used by `transform_convert_object.cc` and
`transform_convert_object_texspace.cc`.
So instead of using a super-specialized member, use `TransData::extra`
instead.
This implements the proposal from #124512. For that it contains the following
changes:
* Remove the global override of `new`/`delete` when `WITH_CXX_GUARDEDALLOC` was
enabled.
* Always use `MEM_CXX_CLASS_ALLOC_FUNCS` where it is currently used. This used
to be guarded by `WITH_CXX_GUARDEDALLOC` in some but not all cases. This means
that a few classes which didn't use our guarded allocator by default before,
are now using it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130181
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
