When the median was being calculated, the division was by the total number of transform data, rather than the selected number of transform data.
Under most circumstances this would be the same, but when transforming bezier control points without the handles selected, or when having proportional editing on. This the median calculation would return a wrong result.
Note: This problem could occur almost every object type not just Grease Pencil.
Resolves: #143534
Pull Request: https://projects.blender.org/blender/blender/pulls/144245
Now that the `t->data` and `t->data_ext` arrays have the same ordering,
it is no longer necessary to include each member of `t->data_ext` in
`t->data`. Access can be done using the same index.
Pull Request: https://projects.blender.org/blender/blender/pulls/141563
Remove `BLI_assert(tc->sorted_index_map);` calls. Add one special case
in the function that investigates whether there is any selected item in
`tc->data`.
Earlier, I've been quite liberal in spreading these asserts around, to
guard against code paths that should have originally sorted `tc->data`
but by mistake didn't create `tc->sorted_index_map`.
They've been removed now, as they seem to be causing more trouble than
they're worth: the "sorting selected first" behaviour is only explicitly
there for proportional editing. With proportional editing disabled,
`tc->data` **only** contains selected items, and those are trivially
sorted first.
By now `tc->foreach_index_selected` can work without `sorted_index_map`;
if it is `nullptr`, it will assume that we're in the trivial case, and
that the array items can just be visited in index order.
Pull Request: https://projects.blender.org/blender/blender/pulls/141386
After changing the transform mode, `initSnapping` was called, resetting
the increment values.
The solution is to create the `transform_snap_reset_from_mode` function
with only the changes needed when changing modes.
This commit also makes the properties set in the operator take priority
over the scene properties.
Calling transform over the redo panel would access the regiondata
as a RegionView3D for any region type.
Resolve by checking the region type - as done elsewhere transform code.
The 2 values in `t->snap` are not enough to indicate the transformation
value for each axis including precision.
Therefore, imitating the snap to grid solution, `t->snap` has been
replaced by `t->increment` and `t->increment_precision`.
Pull Request: https://projects.blender.org/blender/blender/pulls/140980
Correct an oversight in df6d345bb4: without proportional editing, all
the transform data is "selected" by definition. This means that the
assumption "the selected data is sorted first in the array" is
trivially true, without calling any sorting function. So instead of
using the sorted index map in these cases, just fall back to regular
iteration.
To make the code handle this nicely, I made two "foreach" functions.
The first one transparently uses the sorted index map when available,
and performs regular iteration otherwise. The second function only
visits the selected items.
This makes the usage of these functions clearer, and the fact that
selected items are expected to be sorted first (either trivially or
explicitly) can be documented in a central place.
Pull Request: https://projects.blender.org/blender/blender/pulls/140720
Avoid modifying the order of transform system data. Instead, create an
index map and use that to traverse the data arrays in sorted order.
The issue observed in #139042 stems from the assumption, in _some_ of
the code, that `tc->data[i]`, `tc->data_ext[i]`, and `tc->data_2d[i]`
all contain information about the same "transformable thing". Since
`tc->data` was sorted (by selection state and, optionally for
proportional editing, by distance) but the other arrays were not, this
caused issues.
The most obvious solution, sorting all arrays the same way, turned out
to be hard to do, as some elements in one array have pointers to
elements in another array. Reordering those arrays would therefore
also make it necessary to find and update those pointers.
Instead, I decided to implement a sorted index map. The arrays can
then be kept in their original order, and the index map can be used to
visit them in sorted order.
Pull Request: https://projects.blender.org/blender/blender/pulls/140132
Remove the last uses of `BKE_boundbox_init_from_minmax` in
favor of the newer `bounds::corners`. Besides clearer naming
and better ergonomics, it's also inline-able which seems to be a
good thing for such a simple function.
In order to get the same behavior as before I changed the
C++ bounds function to give the same vertex order as the
older function.
Pull Request: https://projects.blender.org/blender/blender/pulls/140401
This prevents the use of unaligned data types in
vertex formats. These formats are not supported on many
platform.
This simplify the `GPUVertexFormat` class a lot as
we do not need packing shenanigans anymore and just
compute the vertex stride.
The old enums are kept for progressive porting of the
backends and user code.
This will break compatibility with python addons.
TODO:
- [x] Deprecation warning for PyGPU (4.5)
- [x] Deprecate matrix attributes
- [x] Error handling for PyGPU (5.0)
- [x] Backends
- [x] Metal
- [x] OpenGL
- [x] Vulkan
Pull Request: https://projects.blender.org/blender/blender/pulls/138846
With the move to the new snapping system,
the snapping flags were no longer stored on the editor but on the scene.
While that is good for all editors that deal with animation,
it also affected the Driver Editor since that is effectively a Graph Editor.
However since the driver editor doesn't deal with frames,
it is unlikely that settings should be shared with other animation editors.
With this PR the Driver Editor gets it's own snapping flag,
which means snapping can be controlled without affecting
other animation editors.
This also removes snapping options
* Snap to markers doesn't make sense, there are no markers in drivers
* Snap to seconds also makes no sense
Only snap to frames, i.e. whole numbers is kept with the option
to snap directly to whole numbers or offset the current position
by a whole number.
Pull Request: https://projects.blender.org/blender/blender/pulls/136826
The bug was partially caused by the fact that
`translate_snap_increment_ex` would interpret sequencer-specific
snapping bit `SEQ_SNAP_TO_FRAME_RANGE` as `SCE_SNAP_TO_INCREMENT`. Add a
check to fix this.
Technically, #122759 never added snapping for cursors in the preview,
but we can take this opportunity to also add the support, which is
relatively simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/136579
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
Move the code dealing with converting float3 to GPU normals
out of the vertex format header into a separate header. Use a
proper C++ namespace and remove duplication by only using
the more recently added C++ templated conversions.
Most of the diff comes from the removal of the indirect includes
from GPU_vertex_format.hh. A lot of files ended up mistakenly
depending on that.
Pull Request: https://projects.blender.org/blender/blender/pulls/134873
- Use new blender::transform namespace, to reduce verbosity
- Move snap_data allocation upstream, and use unified logic:
No points? Free data.
- Snap points are stored in Vector instead of Array to avoid
incrementing index.
- Point counting functions are removed. Vector size is not reserved,
since adding 10K points takes less than 1ms (AMD 5950X)
- Functions are renamed to avoid overly long names and make them as
distinct as possible.
New function naming scheme is:
`<what is done>_<sources/targets>_<timeline/preview>_<subcategory>`
for example `points_build_sources_timeline_retiming`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134308
Enabling `use_snap_rotate` in 3D viewport caused rotation in sequencer
to apply snapping. Rotation snapping was using mixed snapping functions,
which aren't implemented in sequencer.
Ignore affect rotation/scale tool setting property and force increment
snapping to be used with these transform modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133272
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
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.
The snap cursor internally snaps to the Face to define the occlusion of
the Grid or to calculate the "Surface" orientation set by the tool.
Even though this is not the snap point enabled by the user, this
internal Snap to Face takes precedence over the Snap to Grid that is
enabled by the user.
To solve this, the solution is to do a second snap test but now only to
Grid and using the hit point as a reference for the closest grid.
Also fixes Absolute Increment Snap not being detected as Grid by the
tool.
Pull Request: https://projects.blender.org/blender/blender/pulls/130092
This introduces partial functionality of Precision mode to 'Snap to
Grid'.
However, it behaves differently from 'Absolute Grid Snap', as it lacks
smooth mouse movement.
Precision mode is now available specifically for Transform operations.
The issue occurred because the code block that read the snap flag was
out of sync with the code block that saved the flag.
The solution was to centralize snap flag handling in the
`transform_snap_flag_from_spacetype_ptr()` function. This function
retrieves the appropriate snap flag and property based on the editor
type, eliminating the need for repetitive conditional checks and
ensuring that the correct snap flag is set for each editor.
The snap-to-grid constraint in the rotation operation should not be
limited to the grid closest to the constraint axis, as this restricts
rotational freedom.
The 'Closest' 'Snap With' option does not work well with 'Snap to Grid'
due to the unpredictable nature of this 'Snap With' option. That's why
another option is used in this case.
The option chosen in this case is the same one that was used in
'Absolute Grid Snap', that is, 'Median'.
Missed after 'Set Snap Base' commit.
Just like in 3D View, UV editing can also benefit from selecting
multiple snap target elements.
The C++ code was already done, it was only necessary to edit the
interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/124986
Adds snapping in the VSE preview area.
Source points are the four corners and origins of all selected, visible
image quads. Targets can be preview borders, preview center, or
corners/origins of other strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/122759
The `Snap to Grid` and `Snap to Vertex` modes were being mixed if
either mode was enabled.
Support for mixed snap modes doesn't yet fully work for UVs.
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.
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
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
