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
Restoring the behavior while transforming keys and pressing `Ctrl`
The regular snapping code has the feature that
when you press `Ctrl` you can toggle the snapping on and off.
Prior to 4.0 the snapping for the Graph Editor used a
completely different system, including a different flag to toggle snapping.
Because of that, the flag that the regular snapping
code uses was never set by default. So the system thought it was disabled.
Now when you press `Ctrl` you would enable that
flag and the snapping code would run.
It would snap to increments because that is the mode that
is returned for the Graph Editor space type.
(Note that this is the mode of the generic snapping
system, not of the Graph Editor specific one)
However at the same time, doing that would disable the
Graph Editor specific snapping code.
So the snapped values from the original system would bubble through.
This did not occur in the Dope Sheet and NLA Editor,
because those never returned a snapping mode.
Those still have a different behavior to 3.6 where they
now snap to seconds, instead of not snapping at all.
Pull Request: https://projects.blender.org/blender/blender/pulls/114607
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Caused by bd305c8d18
`snap_transform_data` adds an offset to each element being transformed.
However, this seems to only work for Move and Extend transformations.
Therefore, the solution is to make the NLA snapping system more generic.
Pull Request: https://projects.blender.org/blender/blender/pulls/113554
Currently object bounds (`object.runtime.bb`) are lazily initialized
when accessed. This access happens from arbitrary threads, and
is unprotected by a mutex. This can cause access to stale data at
best, and crashes at worst. Eager calculation is meant to keep this
working, but it's fragile.
Since e8f4010611, geometry bounds are cached in the geometry
itself, which makes this object-level cache redundant. So, it's clearer
to build the `BoundBox` from those cached bounds and return it by
value, without interacting with the object's cached bounding box.
The code change is is mostly a move from `const BoundBox *` to
`std::optional<BoundBox>`. This is only one step of a larger change
described in #96968. Followup steps would include switching to
a simpler and smaller `Bounds` type, removing redundant object-
level access, and eventually removing `object.runtime.bb`.
Access of bounds from the object for mesh, curves, and point cloud
objects should now be thread-safe. Other object types still lazily
initialize the object `BoundBox` cache since they don't have
a data-level cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/113465
For Blender 4.0 we decided to support individual icons for different
snap elements.
This was originally contributed by Erik Abrahamsson as !107054 with
some contributions by myself (Germano).
This set of icons being simple geometric symbols, that should be
familiar to CAD artists.
Note that Face and Volume share the same icon (circle). This is
deliberate since they communicate a similar functionality - are not
aimed at precision snapping the same way the vertex or perpendicular
are.
Also note that later we should also try to change the icons shown in
the snap menu to match the symbols that the artists see in the preview
window.
———
On the decision process:
The version currently in main (and rolled back here) was an initial
attempt of aggregating more information to the icons (e.g., by aligning
the icons to the target edges) while making them more suitable to
Blender. After presenting both options to (parts of the) community,
there was nothing fundamentally broken found with either option, though
options diverged over personal preference.
With that in mind, in the latest UI module meeting it was agreed to use
the original proposal then.
This final call was proposed by Dalai Felinto on his role of
commissioner (stakeholder) for the snap polishing tasks (#73993) and
designer for the related Snap Base design #66484.
———
This commit reverts commit 9c2e768f5b.
The reverted icons (referred originally as minimalistic icons) may be
proposed later as a separate theme option.
This was introduced with #109015
The issue manifested in two ways.
* snapping did not work with rotate and scale
* the scale and rotate value would increment in steps instead of fluidly
This was caused because the snapping code would force the
mode to `SCE_SNAP_TO_INCREMENT` if the snapping
wasn't enabled for the given transform mode.
This snapping mode is not supported in the Animation Editors though,
causing the snapping `switch` to fall back to `default` which is to do no snapping.
My assumption is that this mode also causes the increments in the transform.
It would be good to support that in the future,
but for now this is just a fix to get the 3.6 behavior back.
Pull Request: https://projects.blender.org/blender/blender/pulls/112088
Part of #91973
Moving the snapping code for the
* Graph Editor
* Action Editor
* and NLA editor
into the common system that lives on the scene.
This includes the Magnet icon for turning
snapping on and off.
The old settings translate to the new in the following way:
* `Frame Step` -> `Frame`
* `Second Step` -> `Second`
* `Nearest Frame` -> `Frame` + `Absolute Time Snap`
* `Nearest Second` -> `Second` + `Absolute Time Snap`
* `Nearest Marker` -> `Nearest Marker`
Since this moves the location of the snapping settings
from the editor to the scene, it changes the behavior.
Previously each editor could have different snapping
settings, where now they are all synced.
Pull Request: https://projects.blender.org/blender/blender/pulls/109015
Add a set of symbols to improve visualization of different snap types.
- Circle: Represents snapping to a vertex.
- Two Aligned Lines: Represent snapping to an edge.
- Closed Aligned Square: Represents snapping to a specific part of an edge (center or perpendicular).
- Face-Aligned Circle with Midline: Represents snapping to a face.
Pull Request: https://projects.blender.org/blender/blender/pulls/109387
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
This is part of what was implemented in #109062
When adding multiple snap points (`A` key), the 'Snap Base' location no longer corresponds to the snap target point, so it becomes invisible.
Therefore, show the resulting `Snap Base` during this operation.
Pull Request: https://projects.blender.org/blender/blender/pulls/109379
Also rename:
- `SCE_SNAP_MODE_FACE_NEAREST` to `SCE_SNAP_INDIVIDUAL_NEAREST`
- `SCE_SNAP_MODE_FACE_RAYCAST` to `SCE_SNAP_INDIVIDUAL_PROJECT`
And arrange the enums in numerical order.
Caused by 5621154185.
The Perpendicular Snap needs a `prev_co` to work.
But in `Snap With` `Closest` mode the `prev_co` is not calculated.
Thus, when isolated, the snap to Perpendicular is never done.
So this commit puts the `center_global` fallback back to `prev_co`.
Also, if `Snap Base Edit` is used when only the snap to
`Edge Perpendicular` is enabled. `Snap To` will be temporarily set to
`Vert`, `Edge`, `Face` and `Edge Midpoint`.
The current `Snap Base` was available and displayed to allow snapping
to `Edge Perpendicular`.
However, the usefulness of perpendicular snapping in `Set Snap Base`
mode is questionable and can sometimes cause inconvenience.
Also, removing the current `Snap Base` indicator (the `X` drawing)
makes the intention of the operation more apparent.
Therefore, this commit removes both the indicator and the effect of the
current `Snap Base` in `Set Snap Base` mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/108776
Caused by 98bfa8d458
Occlusion must consider several factors:
- The `Viewport Display` > `Display As` setting of the object.
- The X-Ray mode of the scene.
- Whether only Snap to Face is being used.
- Whether Snap is set to Cage (always transparent) in edit mode.
- Whether the object is hidden.
In the case of Cage, the final geometry should be utilized for occlusion.
However, to prevent excessive and risky modifications, it was followed
the same approach as before and verified the `Display As` setting of
the object.
This commit removes the transformed `Snap Base` symbol (white target)
and displays only the untransformed `Snap Base` symbol (X) when
confirming the Snap Base Edit operation.
The usefulness of the white target icon representing the transformed
`Snap Base` is debatable since it represents the snap target itself
(orange circle) during the Move operation or the direction between the
pivot and the snap target during the Rotation operation.
Having multiple symbols on the screen can clutter the interface and may
not be intuitive.
Therefore, further discussion is required.
Ref.
#108669
The snap mode called "Face Nearest" (and the "Increment" but that's for
another time) doesn't behave like the other snap modes.
Unlike the other snap modes, "Face Nearest" does not act on a Snap
Base (or Snap Source).
It always acts on the origin of individually transformed elements, (such
as each vertex individually).
It works just like the "Project Individual Elements" option.
So this commit makes the following changes:
- `Snap With` was moved to the beginning of the popover
- `Align Rotation to Target` and `Backface Culling` have been moved closer to the snap targets
- `Snap With`, `Target Selection` and `Align Rotation to Target` are no longer hidden by varying the mode and options
- `Project Individual Elements` has been replaced with the `Face Project` option
- `Face Nearest` has been moved to stick together with the `Face Project` option
Co-authored-by: Germano Cavalcante <germano.costa@ig.com.br>
Pull Request: https://projects.blender.org/blender/blender/pulls/108555
This commit implements a new modifier key (`B`) for the transform
operators.
This new key allows changing the 'Snap Base' of a transform by snapping
it to a defined point in the scene.
Ref #66424
# Implementation Details
- This feature is only available in the 3D View.
- This feature is only available for the transform modes:
- `Move`,
- `Rotate`,
- `Scale`,
- `Vert Slide` and
- `Edge Slide`.
- The `Snap Base Edit` is enabled while we are transforming and we
press the key `B`
- The `Snap Base Edit` is confirmed when we press any of the keys:
`B`, `LMB`, `Enter`
- During um operation, if no snap target is set for an element in the
scene (Vertex, Edge...), the snap targets to geometry Vertex, Edge,
Face, Center of Edge and Perpendicular of Edge are set automatically.
- Constraint or similar modal features are not available during the
`Snap Base Edit` mode.
- Text input is not available during the `Snap Base Edit` mode.
- A prone snap base point is indicated with an small cursor drawing.
Pull Request: https://projects.blender.org/blender/blender/pulls/104443
No functional changes.
This commit reorganizes the transform mode functions by bundling them
into a struct called `TransModeInfo` in the file.
This structural change enhances the readability of the transform code
and simplifies the process of adding or removing modes.
Furthermore, this refactor allows for the inclusion of other essential
mode-specific values, such as 'input', which cannot be separated from
the code.
Overall, this commit improves the maintainability and extensibility of
the transform functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/108467
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Remove micro optimization that seeks to reuse the active center
alculation.
This operation is lightweight and reusing its result only adds an
unnecessary dependency.
Face Nearest only works with individual projection, so always set the
`SCE_SNAP_PROJECT` flag in this case.
Also gray out the `Project Individual Elements` option in the UI if
`Face Nearest` is enabled.
And change the description to indicate that `Project Individual Elements`
is always enabled with the `Face Nearest` option.
(I feel a better design for this option needs to be considered).
No functional changes.
The code previously contained redundant and complex checks for
different snapping scenarios, which involved combinations of multiple
snapping flags and modes on each mouse interaction. This resulted in
unnecessary code duplication and overhead.
To address this issue, the code has been simplified and micro-optimized
by moving these checks to the initialization of the snapping parameters.
This results in a more streamlined and efficient codebase.
