| Age | Commit message (Collapse) | Author |
|---|
|
Unused argument in rB216ebe0b7392d6
|
|
This reverts commit 780857f8e8139613711cba041f5f0af9799804ec.
The `axismtx` argument was supposed to be used.
|
|
|
|
|
|
This solution replaces {rBf9e994d0f463}.
That commit created an inverted orientation matrix but the 'Align to
Transform Orientation' operator doesn't work well with inverted matrices.
This new solution makes the rotate operator use the negative vector of the
axis.
|
|
local orientation
In fact, the drawing was that of the local contraint axis (which is
summarized so as not to fill the screen with too much information).
Use the local contraint axis only when more than one object is selected.
|
|
This reverts commit 54f248fa87afd4836fb7154056cd0e8d920401f1.
And fixes T84259.
Apparently the ideal behavior was the previous one.
|
|
|
|
|
|
This feature was added in D5608.
But in practice this confuses more than it helps.
This fixes T82386.
|
|
To fix the problem, it was necessary to create a fallback for the
zero-sized axis in local orientation.
This also affects the gizmos.
|
|
Improves the organization and identification of the API.
|
|
locking
The result was being affected by the view alignment correction.
Regression introduced in rB4eda60c2d82d
|
|
Fix T81429.
This was an intentional change in rBc75a665c442e as it maintains the
same behavior as the constraint with or without modifier.
But from the user's PoV, it is better to keep the old behavior.
This makes drawing and behavior more intuitive.
|
|
This was the behavior in old versions of blender.
During a transformation operation, when pressing a contrain key, the chosen
orientation is that of the scene.
If you press the same key, the orientation changes to Global or Local.
However, if you choose another contrain axis with the orientation changed,
the orientation does not return to the set for the scene.
It remains Global or Local.
Now when changing a contrain axis, no matter what the current orientation is,
it always returns to the scene orientation.
|
|
This fixes and reverts commit c7287ffaec59cecd4b63b4bb2ea1aaf44f09f704
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.
|
|
The last usage was removed in {rB4eda60c2d82de0d7f7ded8ddf1036aea040e9c0d}.
|
|
Regression introduced in rB546b900194f0
|
|
|
|
When enabled, the modal key item "Clear Constraint" did not reset
the default orientation.
This does not bring changes in the user's point of view.
|
|
It conflicts with MOD_PRECISION and was not really working properly.
|
|
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.
|
|
|
|
We now use GPU_blend for enabling / disabling blending and explicitly
set the blend equation.
|
|
|
|
Caused by rB45f17e10ec50
|
|
This reverts commit e16972389e728eeaf5043bb3cbd85fb7312a6463.
|
|
|
|
This changes the drawing by drawing 2 circles with different intensity to
avoid any readability issues. This removes the need for Logic OP which is
implementation dependent.
|
|
|
|
Now all options for "snap to" affect the Vert Slide mode.
Reviewed By: campbellbarton
Maniphest Tasks: T66426
Differential Revision: https://developer.blender.org/D3440
|
|
This commit changes the behavior of 4 snapping combinations:
**1. While constraining to a plane, snap to an edge element:**
The snap is made at the intersection between the edge direction and the
constraint plane.
**2. While constraining to a plane, snap to a face element:**
The snap is made to the nearest point between the snap point and the
line that intersects the face plane with the constraint plane.
**3. While constraining to an axis, snap to an edge/line element:**
The snap is made to the nearest point on the axis to the edge/line.
**4. While constraining to an axis, snap to a face element:**
The snap is made at the intersection of the axis and the plane defined
by the face.
To avoid unpredictable jumps outside view boundaries, an alignment
check is made for each of these snapping combinations.
Resolve/fix T66422
Differential Revision: https://developer.blender.org/D5608
|
|
|
|
working
This feature was a hack to prevent mmb select to print the orientation from menu in pre 2.80 versions.
Removing this feature as it is no longer an issue.
|
|
transform
|
|
|
|
|
|
|
|
|
|
This was so because of the rotate transformation mode but it can make
other modes confusing and add unnecessary complexity.
|
|
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.
|
|
|
|
|
|
Accident!
This reverts commit ae049a6c6ac545b2c9eadf759f40ad864f436ff1.
|
|
Issue introduced in rBc57e4418bb85.
|
|
(This is a simplified version of D4786)
The advantage of highlighting the points would be to indicate more
clearly what is affected by the proportional edit.
The default circle is not so informative and sometimes it is even off
screen so the user loses the quick identification of the influence.
(See T75482)
The disadvantage of this design is that the points could end up hiding
the mesh.
The original patch added the option `draw_proportional_gradient`, but I
prefer to avoid adding more options and more information to the
interface.
I'm not sure if the advantages outweigh the disadvantages.
{F8504097}
Reviewers: #user_interface, #modeling
Subscribers:
|
|
- Use `t->spacemtx` as the orientation matrix instead `t->orient_matrix`.
- Unify constraint behavior between modal and non-modal.
- Simplify code to remove old workarounds and rearrange struct members.
This fix T66142 since the actual `orient_type` (in the case
`V3D_ORIENT_NORMAL`) is used during Redo instead of always using
`V3D_ORIENT_CUSTOM_MATRIX`).
Differential Revision: https://developer.blender.org/D7469
|
|
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.
|
|
|
|
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
|
