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
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
This simplifies code using these functions because of RAII,
range based for loops, and the lack of output arguments.
Also pass object pointer array as a span in more cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/117482
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
The graph editor supports an Extend transformation mode, which is
essentially Move that only affects keyframes either before or
after the current frame, based on the mouse cursor position.
This fixes a bug in this mode where it doesn't respect the snap setting.
The issue was that the "Affect" options from the 3D viewport
were also used for the Graph Editor.
This was discussed in the Animation & Rigging module meeting.
https://devtalk.blender.org/t/2023-12-21-animation-rigging-module-meeting/32748
The consensus was that the Animation Editors should have their own copy of the "Affect" flags.
For this commit I opted for a more immediate solution that ignores the "Affect" flag in the animation editors.
The adding of the flag can be left for a feature PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/116781
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Caused by 9c2e768f5b
Since above commit, drawing of the normal is not done in
`ED_view3d_cursor_snap_draw_util` anymore [that function checked the
existence of a valid target location], now add the check back.
Pull Request: https://projects.blender.org/blender/blender/pulls/116292
Implement the next phases of bounds improvement design #96968.
Mainly the following changes:
Don't use `Object.runtime.bb` for performance caching volume bounds.
This is redundant with the cache in most geometry data-block types.
Instead, this becomes `Object.runtime.bounds_eval`, and is only used
where it's actually needed: syncing the bounds from the evaluated
geometry in the active depsgraph to the original object.
Remove all redundant functions to access geometry bounds with an
Object argument. These make the whole design confusing, since they
access geometry bounds at an object level.
Use `std::optional<Bounds<float3>>` to pass and store bounds instead
of an allocated `BoundBox` struct. This uses less space, avoids
small heap allocations, and generally simplifies code, since we
usually only want the min and max anyway.
After this, to avoid performance regressions, we should also cache
bounds in volumes, and maybe the legacy curve and GP data types
(though it might not be worth the effort for those legacy types).
Pull Request: https://projects.blender.org/blender/blender/pulls/114933
