Fixed some Transform3DGizmo behavior to make more consistent
#53684
Conversation
TokageItLab
force-pushed
the
orthogonal-mode
branch
11 times, most recently
from
8ea951d
to
a302770
Compare
TokageItLab
changed the title
Node3DTransform3DGizmo behavior to make more consistent
TokageItLab
force-pushed
the
orthogonal-mode
branch
4 times, most recently
from
80efc79
to
9c15629
Compare
|
In previous discussions with @reduz, it was decided that Node3D should be forced to be orthogonal if the rotation mode is not basis. It may be necessary to orthogonalize with an importer or migrator for objects that are currently in shear regardless of the rotation mode is not basis. |
| @@ -1876,14 +1881,14 @@ void Node3DEditorViewport::_sinput(const Ref<InputEvent> &p_event) { | |||
| if (se->gizmo.is_valid()) { | |||
| for (KeyValue<int, Transform3D> &GE : se->subgizmos) { | |||
| Transform3D xform = GE.value; | |||
| Transform3D new_xform = _compute_transform(TRANSFORM_SCALE, se->original * xform, xform, motion, snap, local_coords); | |||
| Transform3D new_xform = _compute_transform(TRANSFORM_SCALE, se->original * xform, xform, motion, snap, local_coords, true); // Force orthogonal with subgizmo. | |||
There was a problem hiding this comment.
Currently SubGizmo is forcing orthogonal, but I'm wondering how to make this work better.
At least it's independent of Node3D's RotationMode, but if you want to manage it on a per-SubGizmo make orthogonal, we need to make the SubGizmo store more info than just Transform3D.
For now, it is only the manipulation of bones in Skeleton3DGizmo that is being transformed using SubGizmo, so I don't see a problem with it, but if there is a suggestion in the future, I think it should be resolved.
There was a problem hiding this comment.
Yeah, that should work for now. We can expand what's being stored for each subgizmo in the future if we find the need.
|
When multiple objects are translated with local mode, there is a possibility that the Gizmo will move to an unexpected position due to a shift in the center. It's mathematically and programmatically consistent, but it's may hard to know, so it might be better to visualize the center using a bounding box or a dotted line from each origin to the center. Or, in such a case, not moving the Gizmo during the transformation may be a solution. It might be better to find a solution for Gizmo's visual effects in conjunction with #48307. |
TokageItLab
force-pushed
the
orthogonal-mode
branch
3 times, most recently
from
ac311fb
to
e92ac5b
Compare
TokageItLab
force-pushed
the
orthogonal-mode
branch
from
e92ac5b
to
c6abd43
Compare
TokageItLab
force-pushed
the
orthogonal-mode
branch
from
c6abd43
to
61759da
Compare
|
Added @JFonS Please review when you have time. |
| @@ -1876,14 +1881,14 @@ void Node3DEditorViewport::_sinput(const Ref<InputEvent> &p_event) { | |||
| if (se->gizmo.is_valid()) { | |||
| for (KeyValue<int, Transform3D> &GE : se->subgizmos) { | |||
| Transform3D xform = GE.value; | |||
| Transform3D new_xform = _compute_transform(TRANSFORM_SCALE, se->original * xform, xform, motion, snap, local_coords); | |||
| Transform3D new_xform = _compute_transform(TRANSFORM_SCALE, se->original * xform, xform, motion, snap, local_coords, true); // Force orthogonal with subgizmo. | |||
There was a problem hiding this comment.
Yeah, that should work for now. We can expand what's being stored for each subgizmo in the future if we find the need.
|
Thanks! |
Note: According to the discussion with @reduz on the contributors chat, it was decided to go ahead with the implementation of the 8 rotation modes (euler combinations, quaternion and custom basis). After that is merged, we will consider this change again.#54084 has been merged.This PR makes some changes in Gizmo.
Implement a mode in global transform mode that keeps orthogonality (and add an orthogonal option to Node3D for this purpose)Superseded by Refactored Node3D rotation modes #54084.It addresses the problems those were mentioned in #51164 (comment). Fixed #18987.
Implement non-orthogonal Gizmo
Currently, even when an object's axis is non-orthogonal in the 3D view, Transform3DGizmo tries to keep it orthogonal, so local transformations along the axis are not performed correctly in such cases. This will fix that.
Fixes for moving and scaling when multiple objects are selected in local transform mode
In Local Transform mode, when multiple objects are selected, rotation correctly takes into account the local axis, but translation and scaling do not. This will make these a consistent system.
2021-10-12.5.07.47-1.mov
Implement a mode in global transform mode that keeps orthogonality (and add an orthogonal option to Node3D for this purpose)
The current global transformation causes shear in basis. Shear is not allowed in glTF and is not compatible with the compression track that @reduz is working on, especially in bone animation. So this will implement global scaling that does not cause shear like in Blender.
2021-10-12.5.10.34-1.mov