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.

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 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. 😄

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!

Instead of using Into f32 arrays, using Mint can be much more convenient for both this library, and for users

On input, it's Into<[[f32; 4]; 4>, while on output it's glam::Mat4. If glam is exposed, might as well just accept it on input?

Funnily, when I tried to pass glam::Mat4 into the Gizmo functions, I got compile errors:

error[E0277]: the trait bound `[[f32; 4]; 4]: From<Mat4>` is not satisfied
   --> examples\scene\main.rs:550:38
    |
550 |                         .view_matrix(view_matrix)
    |                          ----------- ^^^^^^^^^^^ the trait `From<Mat4>` is not implemented for `[[f32; 4]; 4]`
    |                          |
    |                          required by a bound introduced by this call
    |
    = help: the following other types implement trait `From<T>`:
              <[T; 12] as From<ColumnMatrix3x4<T>>>
              <[T; 12] as From<ColumnMatrix4x3<T>>>
              <[T; 12] as From<RowMatrix3x4<T>>>
              <[T; 12] as From<RowMatrix4x3<T>>>
              <[T; 16] as From<ColumnMatrix4<T>>>
              <[T; 16] as From<RowMatrix4<T>>>
              <[T; 2] as From<Point2<T>>>
              <[T; 2] as From<Vector2<T>>>
            and 101 others
    = note: required for `Mat4` to implement `Into<[[f32; 4]; 4]>`

Alternatively, in line with #3, it could both accept and return mint::ColumnMatrix3x4 types (for the model matrices. The benefit of this would be - clarity about column major vs row major for the user.

The translation mode has three subgizmos (x, y and z directions). It could also have subgizmos for translating in xy, xz and yz planes.

I'm writing an editor in bevy where the scale of everything is very large (due to the file format I'm trying to edit). However when using a gizmo on a point far away from the origin the gizmo controls don't work properly and the translate is very jittery. Editing a point closer to the origin with the camera closer fixes the problem. Demonstration of the issue below:

It would be great if the gizmo supported a custom viewport size in the bevy integration, e.g. for situations where the viewport is being rendered to an image which does not take up the whole screen. This could be implemented quite simply, by adding an optional viewport_rect field in the gizmo options, which, when set, scales the position to account for the different viewport size. If you don't mind, I'll submit a PR for this soon hopefully!

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.

Currently only rotation and translation is implemented. There could also be a mode for scaling (GizmoMode::Scale).

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'm not an egui expert, but I was hoping that this check would prevent the left mouse click from being processed by my code if it happens to activate the gizmo rotation:

let response = egui_winit.on_event(&egui_ctx, &event);
                if response.consumed {
                    return;
                }

But it looks like Gizmo doesn't mark the event as consumed. Is this intentional?

Hi, thanks so much for your work on this crate. I'd love the free rotation to be a true 'trackball' rotation (rather than just rotating in the direction the mouse is moving). I'm very happy to attempt a PR at this if you don't have time at the moment.

Hello,

I am using egui-gizmo in a multi-viewport context (an editor with multiple 3D viewports using egui_dock). Drawing the gizmos works fine (the gizmo shows up in each viewport in the right position) but there is a problem with manipulation.

If calling gizmo.interact(...) for each viewport, the object would jump around if I tried for example to translate it in a second viewport (two viewports arranged horizontally). The problem was that in that case, the hover position we got from ui.input(|i| i.pointer.hover_pos())?; was outside the viewport, so the calculated x was outside the range of -1 to 1. I guess the root problem is egui-gizmo attempts to manipulate the object in relation to both viewports when the mouse position should only be valid in one viewport at a time.

The problem could be fixed by adding this before calculating x and y in pointer_ray():

if !viewport.contains(hover) {
    return None;
}

In this case, manipulation would only occur in the active viewport.

Thanks in advance,

J-S

Unless I'm missing something, it's currently not possible to translate in the camera plane or scale uniformly. In blender this is implemented with a white circle in the centre of the gizmo.
Another nice thing blender implements is trackball style rotation in the rotation gizmo.
It would be very nice if this gizmo could implement something similar!

Using a reversed z projection matrix leads to the gizmo not being interactable. It might be a good idea to document this behaviour. In the meanwhile, this issue exists to potentially save someone time if they stumble upon the same issue.

Web demo doesn't seem to be working. Tried on both newest Firefox and Chrome.

Hello, great work, this is a very useful crate.

I noticed that when moving the object, the gizmo lags behind the object. This is visible in the demo. Depending on the frame rate it is more or less visible, but it makes the gizmo visuals feel a bit "floaty".

You can fix this by applying the modified transform to the config before drawing the subgizmos. It makes manipulation feel much more solid. I cannot open a PR for now unfortunately...

Since we changed bevy-egui to version 0.26, can you publish a new version so I dont need to patch this library in my toml?

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.

Scaling mode does not currently support global orientation. If scaling is enabled, the whole gizmo uses local orientation, even if it would otherwise use global orientation, which can be confusing.

For reference, this is how it looks like in Blender:

Is there any way with the current system to configure certain GizmoTargets to not be editable in certain gizmo modes? For example, I want some entities to not be rotatable and some not scaleable (the gizmo would just do nothing to those entities' rotations/scales if edited in that mode).
I'm not exactly sure of the best way this could be implemented (unless it is already possible and I'm missing it!). Perhaps an optional GizmoTargetConfig component which contains properties such as use_rotation/use_scale. If the entity has both GizmoTarget and GizmoTargetConfig, the config options would be applied to that specific entity. This approach could be good, as it would open the door to potentially more entity-specific gizmo config options in the future.

If I understand correctly, Gizmo's main purpose is to control models. As such, user provides projection, view, and model transformations, and the result of manipulation is only the latter part (model transform).
I'm looking to have good controls of the orbital camera (i.e. camera rotating around an object) instead of the object itself. Would using Gizmo be a good idea to pursue? So far, I'm hitting an issue that, because Gizmo ends up changing the view matrix for me, and it tracks the mouse pointer to know how much to rotate, it ends up oscillating between multiple states rapidly (which isn't usable).