Fix local 3D translation editing #81609
Conversation
AThousandShips
added
the
cherrypick:4.1
| if (p_local) { | ||
| p_motion = p_original.basis.xform(p_motion); | ||
| t = p_original_local; | ||
| t.origin += p_original_local.basis.xform(p_motion); |
There was a problem hiding this comment.
This matches the other cases and makes the movement smooth, using p_original makes the movement jerky with scale, which doesn't make sense to me, for example if it is scaled the motion is scaled up in the original implementation
|
I have tested my projects, the local 3D transformations/gizmos in the editor seem to work now properly 👍 |
|
I will test it today. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Unrelated to this PR, happens without it, please open a bug report for it on the latest version (also in the future, to avoid giving contributors a fright lol, do test if some bug occurs only with a PR or not, and report it as a bug if it happens without it) Edit: Also the wireframe error happens regardless of local coordinates, it seems like a bug with the updating of the gizmo |
AThousandShips
force-pushed
the
gizmo_fix
branch
from
85314de to
fefebe8
Compare
kleonc
removed
the
cherrypick:4.1
|
Removed |
|
Have you tested that this doesn't happen in 4.1? The code is the same for the compute area (which is incorrect, unless some other tweak elsewhere expanded it) |
Tested v4.1.1.stable.official [bd6af8e], and 4.2.dev1/2/3/4 versions. The issue only happened in 4.2.dev4. |
|
You're right, some other change there interact with it Will take a look at making a pass over it to see how it interacts with itself and see if the discrepencies can be identified, but the current behavior is so glaring I feel it's best to get it fixed |
AThousandShips
force-pushed
the
gizmo_fix
branch
from
fefebe8 to
dae27d1
Compare
There was a problem hiding this comment.
I saw what it broke, but the problem is that translate is not converting correctly, which should be fixed in this PR. I tested this and it works fine.
As for rotate the last argument does not match, but that is not a problem considering it is && true since rotate does not have a plane transform so it will always be true.
|
Thanks! |
|
Thank you! |
Transformation was applied incorrectly, transformation is now smoother and doesn't jump incorrectly