Gizmo is rendering based on GizmoTarget's Transform not WorldTransform

[ethereumdegen]

Gizmo is rendering based on GizmoTarget's Transform not WorldTransform

Therefore, child entities whose parents are not all Origin cannot be translated properly... I tried changing gizmo config resource too to no avail

[ethereumdegen]

To replicate the bug, simply spawn an entity with a nonzero transform, spawn a child under it, and then try to transform the child with the gizmo. The gizmo will be all messed up . ! This is a huge flaw in this crate

[Shenmarukai]

I'm currently running into the same issue as well.

[Shenmarukai]

I made a fork that makes the gizmo transform based on the entities global transform instead of its local transform: https://github.com/Shenmarukai/transform-gizmo-global-transform you can use it by replacing transform-gizmo-bevy = "0.3.0" with transform-gizmo-bevy = { git = "https://github.com/Shenmarukai/transform-gizmo-global-transform" }. Let me know if it works for you. :)

[Shenmarukai]

I made a fork that makes the gizmo transform based on the entities global transform instead of its local transform: https://github.com/Shenmarukai/transform-gizmo-global-transform you can use it by replacing transform-gizmo-bevy = "0.3.0" with transform-gizmo-bevy = { git = "https://github.com/Shenmarukai/transform-gizmo-global-transform" }. Let me know if it works for you. :)

It puts the gizmos in the correct place but its breaking the gizmo control. :( I will see if I can fix that.

[ethereumdegen]

Oh amazing ! Ill take a look and maybe a pr can be submit . Yeah its tricky lol

…

On Fri, Sep 6, 2024 at 10:37 AM Shane Mulcahy ***@***.***> wrote: I made a fork that makes the gizmo transform based on the entities global transform instead of its local transform: https://github.com/Shenmarukai/transform-gizmo-global-transform you can use it by replacing transform-gizmo-bevy = "0.3.0" with transform-gizmo-bevy = { git = " https://github.com/Shenmarukai/transform-gizmo-global-transform" }. Let me know if it works for you. :) It puts the gizmos in the correct place but its breaking the gizmo control. :( I will see if I can fix that. — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPVWLY3LRXAC76GKXLHTYLZVG43PAVCNFSM6AAAAABNXQ6SWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZUGIYDOMRZHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Shenmarukai]

Yeah, I got the control to work now but when the parent is rotated the control of the children starts to get wonky, I need to figure out why its doing that.

It would be nice to eventually have an enum on one of the gizmo configs that would let you switch between using the local and global transforms.

[Shenmarukai]

Turns out its more difficult to fix than I thought but I'm going to keep trying.

[Shenmarukai]

My latest push seems to be working for rotation and translation. Scaling still needs a fix though.

[ethereumdegen]

ok my pr is both updated to 0.15 and pulls in your changes to fix this issue as well !

https://github.com/ethereumdegen/transform-gizmo

[ethereumdegen]

okay @Shenmarukai and @urholaukkarinen we probably need to test and fix this up a lot more. The new code that allegedly 'fixes' the child local transform (this issue) seems to behave in very bizarre ways. I dont think its rdy to ship.

For example I will rotate an object (who is a child of another object with a non-zero xform) and then i will use the gizmo to translate it and after i translate it about 1.0 units, the rotation will break and go back to default . then if i manually set the rotation Y to 0.0, i can rotate it again to how i want and then translate it again and it works fine. its ... extremely bizarre and weird. Its like it works but i have to fight w it and it does buggy things.

[ethereumdegen]

oh i got it !! i figured it out !! by adding normalization to the rotation!

target_transform.rotation = ( rotation_delta * target_transform.rotation.normalize() ).normalize();

it is absolutely critical to add the normalize before and after when doing this ^ when multiplying a scalar to the rotation

now it works much much better for me