Whenever a transform operation is activated by gizmo, the gizmo
modal is maintained, but its drawing remains the same even if the
transform mode or constrain is changed.
So update the gizmo according to the mode or constrain set.
NOTE: Currently only 3D view gizmo is affected
Straightforward port. I took the oportunity to remove some C vector
functions (ex: `copy_v2_v2`).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Also minor changes in comments:
- Reference BLENDER_HISTORY_FILE instead of the literal file-name
(simplifies looking up usage).
- Use usernames in tags, as noted in code-style.
Change the 2D Gizmo drawing function to provide a usable transform matrix,
if it would otherwise be degenerate.
Differential Revision: https://developer.blender.org/D17113
On some occasions, as in cases where transform operations are triggered
via gizmos, the constrain orientations that can be toggled with
multiple clicks of X, Y or Z were repeated.
There is no use in maintaining repeated orientations.
There is not much documentation on the "snap_point" property, but by
code it is possible to note that it serves to set a target snap point
and is of internal use as it is hidden from the Redo panel.
However, this property was still very dependent on Tools settings and
if set to an operator's call, it changes the scene configurations
inadequately.
Therefore,
- remove this dependency from UI for rotation and resize operators,
- do not change the state of the snap in the scene and
- cleanup the code.
Some transform modes are changeable, so callbacks should be reset
together.
Currently the unchanged `transform_matrix` callback is not a major
issue as it is only used for gizmos and gizmos stop updating when
changing the operator type.
These warnings can reveal errors in logic, so quiet them by checking
if the features are enabled before using variables or by assigning
empty strings in some cases.
- Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs
note that this may be left unset if it's not needed.
- Remove BOOST/OPENVDB/VULKAN references when disable.
- Define INC_SYS even when empty.
- Remove PNG_INC from freetype (not defined anywhere).
Struct members loc/size were misleading as they read as if the object
data stored object level transform channels. Rename these to match RNA
with a `texspace_*` prefix to make it clear these struct members only
apply to texture-space transform.
Also rename ME_AUTOSPACE & ME_AUTOSPACE_EVALUATED to
ME_TEXSPACE_FLAG_AUTO & ME_TEXSPACE_FLAG_AUTO_EVALUATED.
Due to precision issues, the cosine value calculated with
`dot_v3v3(start, end)` can be outside the -1, 1 range causing `acosf`
to return `nan(ind)`.
Use `angle_signed_on_axis_v3v3_v3` instead. It returns more accurate
values, deduplicates code, and avoids these `nan` issues.
Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
An apostrophe should not be used because it is not a mark of plural,
even for initialisms. This involves mostly comments, but a few UI
messages are affected as well.
Differential Revision: https://developer.blender.org/D16749
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
activeSnap --> transform_snap_is_active
activeSnap_SnappingIndividual --> transform_snap_project_individual_is_active
activeSnap_SnappingAsGroup --> transform_snap_mixed_is_active
applySnappingIndividual --> transform_snap_project_individual_apply
applySnappingAsGroup --> transform_snap_mixed_apply
Also rearrange functions to be close to where they are used.
And use static when possible.
Small roundoff errors during UV editing can sometimes occur, most likely
due to so-called "catastrophic cancellation".
Here we set a tolerance around zero when using Constrain-To-Bounds and UV Scaling.
The tolerance is set at one quarter of a texel, on a 65536 x 65536 texture.
TODO: If this fix holds, we should formalize the tolerance into the UV editing
subsystem, perhaps as a helper function, and investigate where else it needs
to be applied.
Differential Revision: https://developer.blender.org/D16702
This patch allows skipping the automatic insertion of nodes on top of
links when the transform operator ends. When putting nodes into small
spaces this often gets in the way and wastes time. Now, when holding
`alt`, this is turned off.
The header text is also improved to add this shortcut and to remove
the Dx and Dy values and improve the formatting a bit.
Making this functionality optional might allow us to use it in more
places in the future, like for the nodes added by link-drag-search.
Differential Revision: https://developer.blender.org/D16230
After switching over to using start_frame / end_frame, scaling an NLA strip didn't scale the strip, it just repeated the action.
Now withing the NLA transform code, we look for TFM_TIME_EXTEND / TFM_TIME_SCALE transform mode, and handle the update to strip scale accordingly
The `transform_convert_clip_mirror_modifier_apply` code is made more readable by:
- decreasing indentation;
- removing `axis` and `tolerance` variables;
- renaming `int clip` to `bool is_clipping`;
