A missing `CONSTRAINT_OFF` check in `transform_convert.c` causes the
inverse matrix of that constraint to be added on top of the translation,
causing weird translation response in the viewport. Now fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/108217
fc854fc252 caused the precision modification to be removed after
navigation was complete.
The ideal is when starting navigation.
This is because the precision button can be released during navigation,
thus confirming the precision change.
In order to execute the navigation of type "VIEW3D_OT_move," the user
is required to press both the `Shift` and `MMB` keys.
However, pressing `Shift` also activates the precision modifier for the
transform.
Consequently, while the `MMB` is unpressed, the transform operation
unintentionally remains in precision mode, altering the mouse position.
To address this issue, the solution was to eliminate the precision
changes immediately after the navigation is initiated.
Unfortunately, we have no way of knowing whether the user actually
unintentionally enabled precision, so this solution serves as a
workaround. Ideally, keymap conflicts should be avoided.
Goals of this refactor:
* Reduce memory consumption of `IndexMask`. The old `IndexMask` uses an
`int64_t` for each index which is more than necessary in pretty much all
practical cases currently. Using `int32_t` might still become limiting
in the future in case we use this to index e.g. byte buffers larger than
a few gigabytes. We also don't want to template `IndexMask`, because
that would cause a split in the "ecosystem", or everything would have to
be implemented twice or templated.
* Allow for more multi-threading. The old `IndexMask` contains a single
array. This is generally good but has the problem that it is hard to fill
from multiple-threads when the final size is not known from the beginning.
This is commonly the case when e.g. converting an array of bool to an
index mask. Currently, this kind of code only runs on a single thread.
* Allow for efficient set operations like join, intersect and difference.
It should be possible to multi-thread those operations.
* It should be possible to iterate over an `IndexMask` very efficiently.
The most important part of that is to avoid all memory access when iterating
over continuous ranges. For some core nodes (e.g. math nodes), we generate
optimized code for the cases of irregular index masks and simple index ranges.
To achieve these goals, a few compromises had to made:
* Slicing of the mask (at specific indices) and random element access is
`O(log #indices)` now, but with a low constant factor. It should be possible
to split a mask into n approximately equally sized parts in `O(n)` though,
making the time per split `O(1)`.
* Using range-based for loops does not work well when iterating over a nested
data structure like the new `IndexMask`. Therefor, `foreach_*` functions with
callbacks have to be used. To avoid extra code complexity at the call site,
the `foreach_*` methods support multi-threading out of the box.
The new data structure splits an `IndexMask` into an arbitrary number of ordered
`IndexMaskSegment`. Each segment can contain at most `2^14 = 16384` indices. The
indices within a segment are stored as `int16_t`. Each segment has an additional
`int64_t` offset which allows storing arbitrary `int64_t` indices. This approach
has the main benefits that segments can be processed/constructed individually on
multiple threads without a serial bottleneck. Also it reduces the memory
requirements significantly.
For more details see comments in `BLI_index_mask.hh`.
I did a few tests to verify that the data structure generally improves
performance and does not cause regressions:
* Our field evaluation benchmarks take about as much as before. This is to be
expected because we already made sure that e.g. add node evaluation is
vectorized. The important thing here is to check that changes to the way we
iterate over the indices still allows for auto-vectorization.
* Memory usage by a mask is about 1/4 of what it was before in the average case.
That's mainly caused by the switch from `int64_t` to `int16_t` for indices.
In the worst case, the memory requirements can be larger when there are many
indices that are very far away. However, when they are far away from each other,
that indicates that there aren't many indices in total. In common cases, memory
usage can be way lower than 1/4 of before, because sub-ranges use static memory.
* For some more specific numbers I benchmarked `IndexMask::from_bools` in
`index_mask_from_selection` on 10.000.000 elements at various probabilities for
`true` at every index:
```
Probability Old New
0 4.6 ms 0.8 ms
0.001 5.1 ms 1.3 ms
0.2 8.4 ms 1.8 ms
0.5 15.3 ms 3.0 ms
0.8 20.1 ms 3.0 ms
0.999 25.1 ms 1.7 ms
1 13.5 ms 1.1 ms
```
Pull Request: https://projects.blender.org/blender/blender/pulls/104629
Many "UV island" style operations internally use #UvElementMap, including:
- Transform tools
- Smart-Stitch
- UV Pinch, UV Grab and UV Relax sculpt tools.
Normally, every UV in the mesh is included in the #UvElementMap.
However, with hidden geometry, only the visible geometry is included in the map. [0]
This change enforces stricter usage, reducing the chance of crashes in other areas.
Regression from [0] which was a fix for "UV Island calculation doesn't ignore hidden faces" [1].
[0]: 8f543a73ab
[1]: #99659
Pull Request: https://projects.blender.org/blender/blender/pulls/108130
Implements a new option in keymap settings:
- "Navigate during Transform"
Note that with the option enabled, the keymap changes as follows:
|Modal Map (Blender):| Conflict: | Current: | New:
|---|---|---|---
| Increase Proportional Influence | VIEW3D_OT_zoom | Wheel Down | Alt Wheel Down
| Decrease Proportional Influence | VIEW3D_OT_zoom | Wheel Up | Alt Wheel Up
| Adjust Proportional Influence | VIEW3D_OT_rotate | Mouse/Trackpad Pan | Alt Mouse/Trackpad Pan
| Increase Max AutoIK Chain Length | VIEW3D_OT_zoom | Wheel Down | Alt Wheel Down
| Decrease Max AutoIK Chain Length | VIEW3D_OT_zoom | Wheel Up | Alt Wheel Up
| Automatic Constraint | VIEW3D_OT_rotate | Middle Mouse | Alt Middle Mouse
| Automatic Constraint Plane | VIEW3D_OT_move | Shift Middle Mouse | Shift Alt Middle Mouse
Design Task: #106008
Pull Request: https://projects.blender.org/blender/blender/pulls/105764
Store bevel weights in two new named float attributes:
- `bevel_weight_vert`
- `bevel_weight_edge`
These attributes are naming conventions. Blender doesn't enforce
their data type or domain at all, but some editing features and
modifiers use the hard-coded name. Eventually those tools should
become more generic, but this is a simple change to allow more
flexibility in the meantime.
The largest user-visible changes are that the attributes populate the
attribute list, and are propagated by geometry nodes. The method of
removing this data is now the attribute list as well.
This is a breaking change. Forward compatibility is not preserved, and
the vertex and edge `bevel_weight` properties are removed. Python API
users are expected to use the attribute API to get and set the values.
Fixes#106949
Pull Request: https://projects.blender.org/blender/blender/pulls/108023
See: https://projects.blender.org/blender/blender/issues/103343
Changes:
1. Added `BKE_node.hh` file. New file includes old one.
2. Functions moved to new file. Redundant `(void)`, `struct` are removed.
3. All cpp includes replaced from `.h` on `.hh`.
4. Everything in `BKE_node.hh` is on `blender::bke` namespace.
5. All implementation functions moved in namespace.
6. Function names (`BKE_node_*`) changed to `blender::bke::node_*`.
7. `eNodeSizePreset` now is a class, with renamed items.
Pull Request: https://projects.blender.org/blender/blender/pulls/107790
Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
Flickering observed when snapping to edge or face with axis constraint.
It was probably introduced in 4eda60c2d8
The snapping code has a timer, so `t->tsnap.snapElem` isn't always set.
So avoid changing the value of `t->tsnap.snapElem`.
For derived mesh triangulation information, currently the three face
corner indices are stored in the same struct as index of the mesh
polygon the triangle is part of. While those pieces of information are
often used together, they often aren't, and combining them prevents
the indices from being used with generic utilities. It also means that
1/3 more memory has to be written when recalculating the triangulation
after deforming the mesh, and that the entire triangle data has to be
read when only the polygon indices are needed.
This commit splits the polygon index into a separate cache on `Mesh`.
The triangulation data isn't saved to files, so this doesn't affect
.blend files at all.
In a simple test deforming a mesh with geometry nodes, the time used
to recalculate the triangulation reduced from 2.0 ms to 1.6 ms,
increasing overall FPS from 14.6 to 15.
Pull Request: https://projects.blender.org/blender/blender/pulls/106774
cc623ee7b0 did not consider some implications such as the habit of
users initiating transform operations just to change the size of the
Proportional Edit.
Therefore, partially revert the cc623ee7b0.
Remove micro optimization that seeks to reuse the active center
alculation.
This operation is lightweight and reusing its result only adds an
unnecessary dependency.
The issue happens because the algorithm used to calculate the center of
the selection first needs to create a TransData array. In this array,
the code calculates the "mirrored" elements which can be quite slow in
dense meshes.
The solution is replace this slow algorithm used for calculating the pivot
point with the fast algorithm used to calculate the position of transform
gizmos.
Pull Request: https://projects.blender.org/blender/blender/pulls/107203
Animation: Adds a new "Parent Space" Orientation option for the Transformation Gizmo.
---
For child targets (objects, bones, etc) being able to transform in parent space is a desired feature (especially when it comes to rigging / animation).
For objects:
* with a parent, the gizmo orients to it's parents orientation
* without a parent, the gizmo orients to Global space
For Armatures:
* Child bone shows parent's space regardless if "Local Location" is set for parent bone
* For root bone **without** "Local Location" set, use the armature objects space.
* For root bone **with** "Local Location" set, use local bone space.
---
No new transformation orientation code needs to be written, we can achieve the desired results be using the existing `transform_orientations_create_from_axis`, `ED_getTransformOrientationMatrix`, and `unit_m3` methods. To do this, we check to see if the bone has a parent, if so, we use the bones pose matrix (`pose_mat`). This is done similarly for objects using the parent's object matrix (`object_to_world`).
Pull Request: https://projects.blender.org/blender/blender/pulls/104724
Add the ability to retrieve implicit sharing info directly from the
C++ attribute API, which simplifies memory usage and performance
optimizations making use of it. This commit uses the additions to
the API to avoid copies in a few places:
- The "rest_position" attribute in the mesh modifier stack
- Instance on Points node
- Instances to points node
- Mesh to points node
- Points to vertices node
Many files are affected because in order to include the new information
in the API's returned data, I had to switch a bunch of types from
`VArray` to `AttributeReader`. This generally makes sense anyway, since
it allows retrieving the domain, which wasn't possible before in some
cases. I overloaded the `*` deference operator for some syntactic sugar
to avoid the (very ugly) `.varray` that would be necessary otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/107059
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
Apply the changes suggested at #103782
It includes:
- Draw dot at the origin the active gizmo
- Hide other gizmos while dragging (except the move arrows)
Other changes:
- Draw shadow for the move and scale circle gizmos (while transforming)
Pull Request: https://projects.blender.org/blender/blender/pulls/104624
Check the specific case of `OP_IS_REPEAT_LAST` and recalculate
the orientation.
To that, pass the `OP_IS_REPEAT` and `OP_IS_REPEAT_LAST` flags as
inheritance to macro operators.
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
Regression caused by 98bfa8d458
The `XRAY_ENABLED(v3d)` check was lost during a modification to
`transform_snap_context_project_view3d_mixed_impl` function.
This caused vertex snapping in solid shading to jump between visible
and occluded faces.
Pull Request: https://projects.blender.org/blender/blender/pulls/106495
Allows NLA strips to horizontally translated over each other. If a strip is dropped when translating, it'll cause the strip to shuffle into place.
---
Abstracted large conditional branch in `recalcData_nla` into it's own `nlastrip_fix_overlapping` method for increased readability. No logical changes were made.
---
[Archived Phabricator Patch](https://archive.blender.org/developer/D10102)
Pull Request: https://projects.blender.org/blender/blender/pulls/105532
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).
YimingWu
Campbell Barton
Germano Cavalcante
Jacques Lucke
Chris Blackbourn
Germano Cavalcante
Philipp Oeser
Hans Goudey
Iliya Katueshenock
Sebastian Parborg
Yonatan Maor
Nate Rupsis
Falk David
Germano Cavalcante