Starts scrolling when dragging a node or node link and going outside the current window.
Largely copied from the VIEW2D_OT_edge_pan operator.
Edge panning operator customdata and supporting functions now in
UI_view2d.h, so they could be used by operators in other editor
libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and
shared functions now. Operators properties can be used to configure
edge panning margins and speed for each use case, rather than using
hardcoded values.
The speed function for edge panning has been tweaked somewhat:
* "Speed per pixel" has been replaced with a "speed ramp" distance.
This is more intuitive and also creates an upper bound for the speed,
which can otherwise become extreme with large cursor distance.
* "Max speed" is reached at the end of the speed ramp.
* Padding the region inside and outside is applied as before, but both
values are operator properties now.
Node transform operator also supports edge panning. This requires
an offset for changes in the view2d rect, otherwise nodes are "stuck"
to the original view.
Transform operator had cursor wrapping categorically enabled, but this
gets quite confusing with the edge scrolling mechanism. A new TransInfo
option T_NO_CURSOR_WRAP has been introduced to disable this behavior.
The double negative is a bit annoying, but want to avoid affecting the
existing transform modes, so by default it should still set the
OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY
flag during modal execution).
Reviewed By: HooglyBoogly, JacquesLucke
Differential Revision: https://developer.blender.org/D11073
This patch exposes functionality for performing partial mesh updates
for normal calculation and face tessellation while transforming a mesh.
The partial update data only needs to be generated once,
afterwards the cached connectivity information can be reused
(with the exception of changing proportional editing radius).
Currently this is only used for transform, in the future it could be
used for other operators as well as the transform panel.
The best-case overall speedup while transforming geometry is about
1.45x since the time to update a small number of normals and faces is
negligible.
For an additional speedup partial face tessellation is multi-threaded,
this gives ~15x speedup on my system (timing tessellation alone).
Exact results depend on the number of CPU cores available.
Ref D11494
Reviewed By: mano-wii
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.
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.
Currently, `createTransData` is doing much more than the name implies.
This commit makes it clearer through smaller and more specific functions
what the real purpose of that function.
The local orientation chosen was that of the active object, but as
confirmed in other parts of the code, the orientation of the selected
Bone has priority.
As shown on the T85383, attempts are made to edit the precision mode key.
But that key was hardcoded.
That key now appears among the custom modal keymap items.
The code takes many turns to get a suitable "target" for the snap to grid.
Perhaps there were other reasons awaited for `transformCenter_from_type`
and `TransCenterData center_cache[5]`.
But since nothing is defined, it is better to simplify the code.
No user functional changes
Simple change that shows all the enums used in the transform code and helps
to better understand the role of the members of the struct TransInfo.
It also allows the IDE to show the name of the value represented by the
member instead of a number that needs to be consulted.
Differential Revision: https://developer.blender.org/D10312
This fixes and reverts commit c7287ffaec
Due to hardcodded keys, the modifier for auto contrain plane did not
work with custom keymaps and was in conflict with other keyitems.
Its usability is also confusing since it cannot be used without
`MOD_PRECISION`
But instead of removing it, it is better to make this modifier compatible
with custom keymaps and keep the conflict.
Remove the condition preventing orientation from being obtained out of
the 3d View context.
Also pass the `ob` and `obedit` arguments obtained from the caller.
Keymaps must be customized by the user.
But this is not the case for hardcoded keymaps.
Also the repetition of hardcoded and user-defined keyitems may induce
the user to think they have made a mistake or it is a bug.
Differential Revision: https://developer.blender.org/D6454
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.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
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`.
