No functional changes expected.
This PR extracts the `IndexRange` of the `BeztMap` span and its `size()` call out
of the sorting loop. Doing this removes one `if` condition within the loop and gives a
small performance boost.
(Before: 0.93ms, After: 0.65ms average run of `sort_time_beztmaps`)
Pull Request: https://projects.blender.org/blender/blender/pulls/121267
This is a performance improvement when moving a bunch
of keys on the same `FCurve` in heavy scenes.
When moving keys in such a way that the `BezTriple` array of the FCurve
has to be sorted, the pointers of `TransInfo` also have to be updated.
This used to happen by doing a nested loop over all `BeztMap` and all `TransData2D`.
There was a bit of optimization with the
`blender::Vector<bool> adjusted` which stored if a `TransData2D` has been fixed yet.
But in general the complexity was still `BeztMap.size() * TransData.size()`.
There are two optimizations that can be done here.
* Skip any BeztMap if `old_index == new_index`.
If the Key is not going to move any pointers to it will still be valid.
* Use a `Map<float *, int>` built beforehand to quickly get
the `TransData2D` that needs updating instead of searching.
The `int` in this case is the index to the `TransData2D` array.
Doing this reduces the complexity to `BeztMap.size() + TransData.size()`.
Measurements of `beztmap_to_data`
| - | Before | After |
| - | - | - |
| Moving 1 key of 1 FCurve | ~24000 ns | ~5800ns |
| Moving ~1000 keys of 1 FCurve | 17ms | 0.02ms |
Measurements of `remake_graph_transdata`
| - | Before | After |
| - | - | - |
| Moving 1 key of 279 FCurves | 290ms | 22ms |
| Moving ~300 keys of 279 FCurves | 82 **SECONDS** | 80ms |
Test file used
https://download.blender.org/ftp/sybren/animation-rigging/heavy_mocap_test.blend
The deeper technical explanation.
`TransInfo` has an array of `TransData`.
`TransData` has pointers to the float arrays of a `BezTriple`.
The `BezTriple` array is sorted by swapping data,
meaning the `TransData` will now point to the wrong data in the array.
This has to be updated and we can do that by using the `BeztMap`.
This is all under the assumption that `BeztMap` is sorted in the exact
same way as `BezTriple` otherwise this method will fail.
But by doing it the same way, we can know at which
index the `BezTriple` is before and after sorting.
Now we just need to find the corresponding `TransData`.
That can be done by comparing pointers. The `BeztMap` stores the
`BezTriple` it represents and from it we can
get the pointers to its `vec` 0, 1 and 2. (key and handles)
Pull Request: https://projects.blender.org/blender/blender/pulls/120816
This PR changes the `swap_handles` variable of the
`BeztMap` from `short` to `bool`.
The only reason it was a `short` was so that 0 could be
interpreted as "not checked" within the sorting loop.
Instead, I moved the checking for swapping to a separate loop.
That means the `BeztMap` array needs to be traversed one more time,
but given sorting might already do that multiple times that won't be
a performance issue
(plus we don't have the `if` within the sorting loop potentially messing up branch prediction).
In addition to that this PR also removes `prev_ipo` and
`current_ipo` from the `BeztMap` struct. Those were never used.
This is also partly a fix to restore 3.6 behavior.
With the move to C++, `swap_handles` was never initalized,
so the logic ` if (bezm->swap_handles == 0)` would always be false.
That resulted in the following behavior when
**rotating a bunch of keys 180deg** around their common center.
Pull Request: https://projects.blender.org/blender/blender/pulls/121076
This patch adds the ability to snap strips to markers. Previously, there
only existed options to snap to hold offsets and the current frame.
This snap type works identically to other snapping options by checking
for the relevant bit (here `SEQ_SNAP_TO_MARKERS`) and adding the marker
frame numbers to `snap_data->target_snap_points` within
`seq_snap_target_points_build()`.
To enable `seq_get_snap_target_points_count()` to have access to marker
information, the current Scene object is now passed to the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/120450
The issue was that the transform code kept non-const pointers into the
position arrays of `CurvesGeometry` for an extended period if time and
changed the positions through those pointers. This is not safe, because
the underlying position array may become shared (e.g. with the
corresponding evaluated object), in which case it's not allowed to change
the position array anymore without making a copy.
Generally, the scope at which some code has multiple access to data
should be as small as possible to avoid this kind of issue.
The solution is to store the positions that are modified by the transform
code in a new array and to copy those back into the `CurvesGeometry`
in one go. This way, the program scope in which the positions may be
modified is more obvious and much smaller.
Pull Request: https://projects.blender.org/blender/blender/pulls/120824
After 1c77779160, the snap logic in Edit Mode became the same as in
Object Mode, so Backface Culling started to ignore edges and vertices
of faces seen from behind.
Fix snapping issues caused by commit 1c77779160, where a mesh
representing the edited mesh was introduced.
Mesh snap to vertex now works in the following order:
- Snap to vertices of visible triangles
- Snap to vertices of loose edges
- Snap to loose vertices
The problem arises because in editing mode, faces whose vertices are
being transformed are ignored, marked as hidden in the snap, resulting
in the loss of some vertices in triangles.
The solution involves considering the edges and vertices of hidden
faces as loose elements since, despite being connected to faces, they
are still visible to snap. Two new types of BVHTree were created for
this purpose:
- BVHTREE_FROM_LOOSEVERTS_NO_HIDDEN
- BVHTREE_FROM_LOOSEEDGES_NO_HIDDEN
This modification addresses two related issues:
- snapping in edit mode to vertices and edges of a face being
transformed
- snapping to mesh with hidden loose elements
Optionally, the first issue could be tackled separately by generating
BVHTrees within the snap system itself and storing them in a
`SnapCache_EditMesh *em_cache`, then passing this cache as a parameter
to the `snap_object_mesh` function.
Pull Request: https://projects.blender.org/blender/blender/pulls/120270
Continuation of 3d6bb6ce04
This 'alt' hotkey is captured in the modal map
`TFM_MODAL_PASSTHROUGH_NAVIGATE` in order to appear in the header.
But this modal map is not necessary.
Extract
- Statuses for the external text editor
- Newly created enum node item
- Newly created plane track data
- Newly created custom orientation data
- Operator names in drag and drop menu (need to use operator's
translation context)
- GN attribute statistic node inputs
Disambiguate
- Single-letter colors: A and B can mean Alpha and Blue, or simply A
and B as in two operands in an operation
- Dissolve: issue reported by Tamar Mebonia in #43295
- Translate in the User Preferences. This introduces a new
BLT_I18NCONTEXT_EDITOR_PREFERENCES ("Preferences") translation
context
- Planar (reported by deathblood)
This one is incomplete, because there is currently no way to
disambiguate presets or GN fields. I don't see how either could be
achieved cleanly.
The former would need to define the context inside the preset and
evaluate the file prior to showing it in the presets menu, which
sound bad.
The latter would need to introduce an additional string inside
`FieldInput`s, which would be controversial given how little it
would be used.
Remove
- Unused translation `iface_("%s")` in toolbar
- Remove obsolete N_() tags in a few node descriptions.
Pull Request: https://projects.blender.org/blender/blender/pulls/119065
Instead of using `MEM_callocN` to create an array of `BeztMap`
use a `blender::Vector`. This has the advantage that we don't need to worry about
freeing the memory.
In addition to that it can be passed as a `Span`, removing the need to pass the
length as a separate argument.
Doing that also allows to use the C++ syntax for `for` loops.
This also gives a small performance boost
| Before | After |
| - | - |
| 288ms | 260ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/120507
While selecting and transforming multiple grease pencil frames in the
timeline, frames would sometimes disappear. This happened when the
transformation overlapped, meaning when a frame replaced another moving
one in the timeline. The frames transformation was happening in place
and in series, and thus leaded to the initial position of the frame to
be removed, even if it was occupied by a freshly transformed framed.
This commit fixes the issue by storing two separate maps in the
transform data structure instead of one, one map to store the static
data, meaning the frames that are not affected by the transform, and
another one for the moving data, meaning the frames that are affected by
the transform.
Some changes were made to account for the potential duplication of the
frames (move + duplicate):
* the map of the duplicated frames was renamed to a more explicit name,
* when a duplication occurs, the original frame is stored in the static
frames map, and the duplicate is stored in the moving frames map,
* thus the check for the duplicate flag of the operator is now done at
the init step of the transform, instead of the update step, so that
the maps are initialized accordingly.
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119337
On animations with high key counts, `remake_graph_transdata`
takes most of the compute time when moving keys.
This patch threads the loop over FCurves in that function to speed things up.
Test file with 10.000 keys per F-Curve
| - | Before | After |
| - | - | - |
| Moving 1 key of each FCurve | ~2200ms | ~285ms |
| Moving a single key | ~0.70ms | ~0.72ms |
As demonstrated in the measurements, this speeds up the
case of modifying a lot of data, while not impacting the case
of modifying very little data.
The measurements were taken on an 8c/16t CPU.
The higher the thread count, the better the performance gain.
Measurements of `remake_graph_transdata` using the following test file.
https://download.blender.org/ftp/sybren/animation-rigging/heavy_mocap_test.blend
Pull Request: https://projects.blender.org/blender/blender/pulls/119497
Previously the bounds were accessed on the original object.
That used to implicitly get the evaluated geometry's bounds,
but now that is an explicit choice.
The functionality of snap with constraints relies on the position of
the transformed object.
Previously, snap to grid with constraints was restricted to the Move
operation.
Consequently, the 'Set Snap Base' mode, as well as other transformation
modes, failed to compute the moved position.
As a result, it lacked support for snap to grid with constraints and
would even crash under such circumstances.
The solution involves eliminating the reliance on the Move operator and
instead calculating the position based on mouse position.
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
Addresses two improvements to `Snap to Grid` as suggested in #73993:
- Make 'Absolute Grid Snapping' a new Snap Mode
- Snap to Grid in Non-Side View performed at ground level
Implementation details:
- Snap to Grid has no cursor symbol, unless we are in `Set Snap Base`
mode. Similar to the previous 'Absolute Grid Snap' behavior.
- In Non-Side view, Snap to Grid is performed at ground level.
- If `Snap Base` is `Closest`, Snap to Grid uses the transform pivot
point instead. Similar to the previous 'Absolute Grid Snap' behavior.
- The "Absolute Grid Snap" option has been removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116109
Before this PR the sorting function would receive all FCurves from
the `anim_data` ListBase and sort them + recalculate the handles.
Considering we are already checking
IF an `FCurve` needs sorting we might as well use
that and limit the sorting to FCurves that actually need it.
Doing that gives the following performance uplift.
| - | Before | After |
| - | - | - |
| Moving 1 key only | 109ms | 0.72ms |
| Moving 1 key of each FCurve | ~2000ms | ~2000ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/119735
No functional changes.
The `BeztMap` struct is used when sorting Keyframes during transformations
in the Graph Editor.
Things that were changed:
* Removed unneeded `newIndex`. This was just the index of the
`BeztMap` in the array, which we already have since we iterate with a for loop.
* Access the `BezTriple` array by index instead of pointer offsets.
This makes it a bit easier to see what's happening.
* Renamed struct members to clarify their use.
* Remove forward declaration of certain variables (e.g. loop counter vars)
Pull Request: https://projects.blender.org/blender/blender/pulls/119733
Changes:
- Add Vert Slide and Edge Slide to 'UV -> Transform' menu.
- Add a separator for Vert Slide and Edge Slide in the context menu.
- Don't display the "Correct UVs" option in the Redo menu of UV Editor.
This is a improved solution compared to 20dbcd8814
Caused by 930b11b0fe.
When checking edges that share faces between them, the `find_best_dir`
method cannot use edges that were added in the current loop.
