In my application, I'm using a left-handed, Y up coordinate system.

When setting up this library, I encountered an issue with the rotation gizmos. At first they looked as if they were rotating inverse to the screen, but then I realized the real reason is that the arcs were being drawn with an offset of PI radians.

The gizmo looks correct in the demo, so I'm thinking perhaps there's an offset that needs to be added to the arc that changes with the chosen coordinate system?

This gif illustrates the issue:

Here's what happens when I change rotation.rs:70:

- painter.arc(radius, FRAC_PI_2 - angle, FRAC_PI_2 + angle, stroke);
+ painter.arc(radius, FRAC_PI_2 - angle + PI, FRAC_PI_2 + angle + PI, stroke);

I would like to see a simple way to change the precision/rounding.

i.e. in the demo, you could add so that while holding shift changes the rounding to half a cube size when moving it and for rotation round to nearest 90 degrees

If you use an infinite projection matrix, then this operation will always result in an inf/nan target vector.

Maybe we should try other ways of generating camera rays?

Very nice library, thank you very much!

if I try to cargo run the demo (from within the demo folder), it panics, cannot find the docs/crate.png. Everything fine if I copy that whole docs folder into demo, but I guess that is not the initial intention how this has to go.

Sorry I know this is really specific but I'm making a tool that uses unreal's coordinate system which is the fun left-handed z-up one :| I love the crate but there's no way without editing the source - which I'm not good enough to do - and take this and make it this (the images are of the same scene in the same camera position)

I tried adding multiple gizmos at the same time, and it seems only one of them (the first one I draw) is interactable.

I've tracked down the issue to lib.rs:158

        if let Some(pointer_ray) = self.pointer_ray(ui) {
            let interaction = ui.interact(self.config.viewport, self.id, Sense::click_and_drag()); // <- Here
            let dragging = interaction.dragged_by(PointerButton::Primary);

The problem is that egui will only generate drag events for one widget, so if you call ui.interact() during a frame where a drag starts, and the mouse is inside the interact area, no other call to interact will return a drag_started event no matter what.

I implemented a fix for this (PR incoming) which seems to be working fine. The trick is deferring the call to interact until we're sure that the mouse is hovering something we're interested in. :smile:

Fixes #14

Arcs in the rotation gizmo point in the wrong direction when using left-handed coordinate system. Now the forward vector is inverted for rotation gizmo in such case.

Also fixes snapping with ctrl & shift on Linux

When calculating world space from screen space coordinates, a division by zero would occur if the projection had far plane set to infinity. Now a small non-zero value is used instead.

Closes #7

When looking at the translation gizmo from certain angles (perpendicularly), the figures stretches into some lines.

This can be reproduced in the demo by looking exactly horizontally, the green square of the translation gizmo stretches into a line.

While waiting for https://github.com/optozorax/egui-macroquad/pull/29#issue-1498460381 to be accepted by egui.macroquad, demo's egui-macroquad dependency has been temporarily modified to https://github.com/matthiascy/egui-macroquad.git.

Is it possible for this widget to capture the mouse on hover? So that the egui method below will return true? https://docs.rs/egui/0.19.0/egui/struct.Context.html#method.wants_pointer_input

I am using the above method in my game to know when to listen to interactions with the game. Clicking on the gizmo on a part that is not over the current selected entity will change selection instead of rotating/scaling.

Thank you.