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.
If we run into NULL `RegionView3D` `regiondata` [which e.g. happens if
we just set `bpy.context.area.type = 'VIEW_3D'` without further actions
in the text editor prior to calling the transform operator], we can make
it gracefully work just by using `t->spacetype = SPACE_EMPTY` in
`initTransInfo`.
Similar check is already done in ba229e3859 (marked /* running in the
text editor */).
Transform code is smart enough to have fallback code in place that sets
matrices etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/119205
Add two snapping increment options: a regular value
(activated with Ctrl) and a precise value (activated with Ctrl+Shift).
These values are separate for 2D and 3D views.
Ref !118760
Transform operators for mesh do partial updates and don't reallocate
the looptris arrays that may be incorrectly sized. Therefore, we must
check the array size before performing updates.
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
The Edge Slide code was practically redone to correct errors and to
enable this operator to become a generic transform operator.
The errors are;
1. Unpredictable slide direction when the vertex "slides" over multiple
edges.
2. Incorrect direction when the sliding edge has disconnected faces.
The fixes were:
- When the sliding direction splits into multiple directions, the
chosen target is now the intersection of the destination edge lines
(instead of the average point or a randon point)
- If the edge faces disconnect, the vertex slides in different
directions on each face.
Other changes:
- Use C++ for Array e Vector types.
- Create methods to access or edit struct parameters.
- Use `TransData` to access the initial position of the vertex.
- Acess slide vertice by reference.
