If we were not in x-ray/wireframe mode, the snapping would treat all
objects like they were in solid mode. This were not desirable if you
had objects that were in wire or bounding box display mode.
Now objects that are in bounding box mode is ignored (unless the object
is in edit mode) and objects with wire display mode is treated as if
they were in x-ray mode.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D4493
When using a transform.select_orientation keyboard shortcut, the
orientation change would not update the viewport.
So if you had the move gizmo visible, it would not change transform
orientation.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D4386
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
Keymap: E - Extrude Gizmo supported.
If the extrude points are the first or last of the stroke, the stroke is extended.
If the extrude points are in the middle of the stroke, a new stroke is created because the grease pencil strokes can be only with 2 extremes and fold the stroke to get a new point gets very bad results.
Still pending define a new icon. Also, it could be good to set by default XYZ axis in the gizmo.
Note: There is a change in the transform_gizmo_extrude_3d.c gizmo for OB_MODE_EDIT_GPENCIL. This change must be undo when the mode will be integrated into OB_MODE_EDIT, but while we have both modes, we need to keep this code in order to keep running the gizmo.
Was caused by another fix in the area, and root to the wrong though that
transformation is only initialized from a fully evaluated dependency graph.
The latter one is not a case when changing transformation mode.
Solved by copying transform to an evaluated object.
It was being drawn when any Gizmo was highlighted.
There are several ways to solve this (creating a new parameter to the operator, checking the gizmos in the invoke or creating a global context).
Also, for a micro-optimization, all of those conditions in the `drawDial3d` could be done once in the invoke.
But since all of these changes involve changing the customdata (`TransInfo`), which is already a bit confusing with so many members, I thought it best to make minimal changes.
Shear gizmo now uses a single orientation and sets
different ortho axis instead of constructing a different matrix for
each handle - allowing the redo panel to select orientations.
ApplySnapResize did not take into account invalid distances. Added check for this.
Reviewed By: Campbell Barton
Differential Revision: https://developer.blender.org/D4417
Transform orientation was previously related to constraints,
recent changes meant it was used even when not constraining to an axis.
Now transform orientation is separate from axis constraints.
- Add XYZ option.
- Orientation now works as expected.
Now a redo for rotation works logically,
setting the axis to Z & the orientation to view.
Resolves T57205
Before 1bfbfa2810 this wasn't essential because the constraints
prevented the axes from being applied.
Now redo ignores constraints - the input values must be constrained.
Transfomr init code called just after duplication (presumably before
regular depsgraph update is executed) would erase new objects'
transflags.
This is more like a hack than a real fix, but since that transform piece
of code is already a hack... Other solution would have been to force DEG
to run after object duplication, think it's better to go with that
solution for now.
Not to mention to fact that dupli flags are put into transflag... ;)
Constraint options had confusing behavior:
- When non were pressed, the orientation was ignored.
- When any were pressed, the orientation was used,
but only unconstrained axed could be adjusted.
Now constraining is only used for modal execution
so there is no need to show these in the interface.
When an orientation is selected, the XYZ values always transform
using that space.
Note, transform system should be refactored to support different
orientations w/o having to use constraints.
Addresses T57204
-Use distance for Shrink/Fatten Distance
-Use factor for Smooth Factor
-Use Factor for Randomize Uniform and Normal values
-Use Distance for Randomize distance amount
-Randomize Transform Scale was wrongly using distance
Previously, the curve self snapping would only snap to points that were
earlier in the curve structure. This was because of a simple coding
snafu of using break when meaning to use continue.
