| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Supporting both object & edit-mode is more involved.
Both cases are now supported with object mode tracking the last-used
state for rotation so it's only reset once when rotation is disabled.
|
|
|
|
Use the term 'mat_final' for calculated matrices used for transforming.
Also rename 'pivot' to 'pivot_local'.
|
|
Multi-threading support for transform modes: bevel-weight, crease,
push-pull, rotate, shear, shrink-fatten, skin-resize, to-sphere,
trackball & translate.
This is done using a parallel loop over transform data.
From testing a 1.5million polygon mesh on a 32 core system
the overall performance gains were between ~20-28%
To ensure the code is thread-safe arguments to shared data are const.
Reviewed By: mano-wii
|
|
The `applySnap` callback of each mode was overwriting the value
calculated in `transform_snap_sequencer_apply`.
|
|
It wasn't so clear why the POINT_INIT check was disabled,
move this into the code comment.
|
|
of the header
This prevents the text from shaking while transforming.
|
|
`t->values` does not necessarily represent a final value of the
transformation, as each mode treats this value differently.
So, unfortunately, we cannot have a generic offset solution for modal
transform operations. Offset needs to be handled by each mode.
Note: Currently only, `Move`, `Rotate` and `Resize` support this.
|
|
|
|
This fixes T88346.
The code is also more readable by making a better distinction between
the texts used for Distances, "Proportional Size" and "AutoIK-Len".
And the text used to translate the "Proportional Size" is reused.
|
|
This makes it clearer that variables are strings and how they are used
in the Move header code.
|
|
Event though in practice this wasn't causing problems as the fixed size
buffers are generally large enough not to truncate text.
Using the result from `snprint` or `BLI_snprintf` to step over a fixed
size buffer allows for buffer overruns as the returned value is the size
needed to copy the entire string, not the number of bytes copied.
Building strings using this convention with multiple calls:
ofs += BLI_snprintf(str + ofs, str_len_max - ofs);
.. caused the size argument to become negative,
wrapping it to a large value when cast to the unsigned argument.
|
|
This fallback is an old hack.
It is difficult to have an orientation convention when several random
factors determine which one should be used.
In this case, to "fix" the problem, a new behavior had to be implemented.
Now the redo when moving the camera in `Camera View` has the default
orientation as `View`.
|
|
When activated in modal, `translate`, `resize`, `rotate`, `shear` and
`edge_rotate_normal` use a different orientation than the set in scene.
This orientation needed to match since some of these modes can be switched
during operation.
The default orientation for these modes was `V3D_ORIENT_VIEW`.
And this changed when finishing the `translate` and `resize` to
`V3D_ORIENT_GLOBAL`.
But this could cause inconsistencies when inputting values from the
keyboard.
The solution now is to change the orientation when you change the mode.
---
Note: Although the user can expect the value entered to reflect the
orientation set in the scene, it would require a lot of changes and would
not be really useful.
|
|
Flags unified:
T_CURSOR -> CTX_CURSOR
T_TEXTURE -> CTX_TEXTURE
Flags moved:
T_CAMERA -> CTX_CAMERA
T_POSE -> CTX_POSE_BONE
T_OBJECT -> CTX_OBJECT
T_TEXTURE -> CTX_TEXTURE_SPACE
Flag renamed:
CTX_EDGE -> CTX_EDGE_DATA
|
|
constraint
This partially reverts commit ad15e764dd92.
The local value is only useful with constraint.
|
|
Showing value in the global space was an unintentional change.
|
|
The incremental snap was always operating in the local space, which in most
cases is the VIEW type orientation.
Use only local space when the operation is affected by constraint.
Differential Revision: https://developer.blender.org/D10052
|
|
ratio
Caused by rB4eda60c2d82d.
T83801 reported not moving in pixel space, but even without that toggle
above commit caused the translation to not take apsect ratio into
account properly [a translation of 1 on the x axis for example on an
image with non 1:1 aspect ration caused the UVs to not end up in the
same place on the next 'tile']
Above commit removed 'removeAspectRatio()' [the counterpart of
applyAspectRatio -- which does the pixel coord correction internally]
from 'applyTranslation()'.
This was also reported in T83352 [which was closed by rBf3b08af24c9f --
but that only solved the displax in header, not the actual
transformation]
Now bring back 'removeAspectRatio()'.
Maniphest Tasks: T83801
Differential Revision: https://developer.blender.org/D9869
|
|
The displayed value was always that of the x axis.
|
|
The incremental was taking priority but the other elements are mandatory.
|
|
Follow our code style for doxygen sections.
|
|
This commit removes `t->snap[0]` and `t->snap_spatial[0]`.
They were not actually being used, and could add overhead for
transformation without snap.
|
|
`applyNumInput` does not write all axis values and does not consider
the orientation.
|
|
Regression introduced in rB546b900194f0
|
|
This commit renames the functions in "BKE_unit.h` to be consistent
with the naming in the rest of blenkernel.
bUnit_AsString -> BKE_unit_value_as_string_adaptive
bUnit_AsString2 -> BKE_unit_value_as_string
bUnit_ReplaceString -> BKE_unit_replace_string
bUnit_ApplyPreferredUnit -> BKE_unit_apply_preferred_unit
bUnit_ToUnitAltName -> BKE_unit_name_to_alt
bUnit_ClosestScalar -> BKE_unit_closest_scalar
bUnit_BaseScalar -> BKE_unit_base_scalar
bUnit_IsValid -> BKE_unit_is_valid
bUnit_GetSystem -> BKE_unit_system_get
bUnit_GetBaseUnit -> BKE_unit_base_get
bUnit_GetBaseUnitOfType -> BKE_unit_base_of_type_get
bUnit_GetName -> BKE_unit_name_get
bUnit_GetNameDisplay -> BKE_unit_display_name_get
bUnit_GetIdentifier -> BKE_unit_identifier_get
bUnit_GetScaler -> BKE_unit_scalar_get
bUnit_IsSuppressed -> BKE_unit_is_suppressed
Differential Revision: https://developer.blender.org/D8828
|
|
Now we have a better distinction of what is snap to grid and what is
snap to increments.
The code also allows the implementation of mixed snap for these modes.
|
|
It is preferable that the value used for interators is defined
close to where it is used.
|
|
|
|
Now all options for "snap to" affect the Vert Slide mode.
Reviewed By: campbellbarton
Maniphest Tasks: T66426
Differential Revision: https://developer.blender.org/D3440
|
|
These functions are very specific to the mode.
More modes can support snap, and there is no reason to keep all
callbacks for each mode in the transform_snap.c file.
|
|
clipping (even if the proportional edit itself is disabled)
Checking T_PROP_EDIT_ALL returns true for _any_ of the options, so just
check for T_PROP_EDIT.
Note: this might expand to other similar checks (e.g. header text)
Maniphest Tasks: T77068
Differential Revision: https://developer.blender.org/D7927
|
|
|
|
During the refactor of the transform operations, in an attempt to
maintain previous behavior, the default orientation of the translate
and resize operations became `Global` and the rotate operation became
`View`.
Now the default is always `View`, and on redo, the translate and rotate
operations are saved as `Global`.
|
|
Normal orientation
`pvec` was confusing and was adding steps that are apparently unnecessary.
So the code has been redone so as not to use this pvec.
|
|
Follow up of b2ee1770d4c3 and 10c2254d412d, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
|
|
|
|
editors
The redo panel does not consider the position of the mouse.
So it is not possible to know the direction to redo the operator.
The solution is to add a new `direction` parameter that can be
saved and used for redo.
Differential Revision: https://developer.blender.org/D6852
|
|
Differential Revision: https://developer.blender.org/D5819
|
