foresightminingsoftwarecorporation / bevy_transform_gizmo Goto Github PK

I find this warning when I use this great crate:

2022-05-30T07:28:55.784722Z  WARN bevy_ecs::schedule::graph_utils: bevy_transform_gizmo::hover_gizmo wants to be after unknown label: UpdateSettings

So I dive into the code and see this:

The UpdateSetting label is defined in PostUpdate stage (Line 101) but it is used in PreUpdate stage (Line 87).

Is just deleting Line 87 is ok?

Would be very useful for level editing.

Should just need to remove a couple of handles.

This only seems to happen when translating away from the camera, perhaps tied to projection, or there is a 1-frame lag between systems causing a lag that is more visible far from the camera?

Add angle and translation snapping

Make it clear which part of the gizmo are interactable by highlighting when the cursor is hovering those parts.

There seem to be events for when gizmos are operating, but it's oddly very difficult to detect via events when an entity is being modified by a gizmo. Is there something I missed, or is this use case not currently supported?

When manipulating the gizmo, the gizmo doesn't move with the drag.

When interacting with a gizmo on an entity with a parent (whose Transform isn't the identity), the entity snaps its position as though the parent transform is applied twice; in other words, it seems like something is doing "Transform = GlobalTransform + whatever".

https://www.youtube.com/watch?v=iTNRtOoZV2o demo video - when moving the parent, everything works fine; when moving the child, you can see the "snapping" behavior, with the child "receding into the background" each time the gizmo is interacted with as the parent's Transform's negative Z offset is repeatedly applied.

My app is crashing on this line in bevy_transform_gizmo.

It is due to a GizmoPickSource not existing.

For smaller scale apps, requiring a camera exist with a picking source seems fine. However it's overly restrictive for more complex setups.

I have an empty scene that loads first based on a default state, that loads into a splash screen, then into a main menu, then my test level (which would spawn the camera with the GizmoPickSource).

I was able to temporarily work around this by altering my level from

app.add_systems(
    OnEnter(LEVEL_EDITOR_SCENE),
    (level_editor_setup, mesh_make).chain(),
);

to

app.add_systems(
    Startup,
    (level_editor_setup, mesh_make).chain(),
);

but it's not a long term solution.

When dragging while looking down the translation axis, if the mouse goes past the point of convergence, the gizmo will start going backward.

Add functionality to freely move the gizmo in the plane parallel to the screen.

bevy_mod_picking has been updated to version 0.13 which includes useful features. Unfortunately, bevy_transform_gizmo does not work correctly with this update. When I run it, I get errors in the console: "ERROR bevy_transform_gizmo: Not exactly one picking camera.
ERROR bevy_transform_gizmo::normalization: More than one picking camera"

As discussed on discord:

sajattack: Using bevy 0.10.1, bevy_transform_gizmo 0.7 and bevy_mod_picking 0.13, in WebGL, on a nested mesh, I can bring up a transform gizmo but not interact with it. It draws and I click it and nothing reacts. Maybe mouse input is broken on web?

aevyrie: Looks like it even fails with a few simple meshes. Hm. Need to do some debugging.

Repro:

Build this project with trunk-rs https://trunkrs.dev/

bevy-repro.zip

@elpiel: creating this issue to discuss your question from your PR
#18 (comment)

Btw is there a way to add the gizmo to a whole scene?

Could you provide a bit more detail? Do you want to:

1. Select everything in the scene and transform it
2. Make everything in the scene possible to transform individually
3. Something else?

Make it possible to set the state of the gizmo, maybe useful if the user wants a menu button that only enables the rotation controls.

translation: bool,
rotation: bool,
scale: ScaleType, // Uniform, Non-uniform, Disabled,
free_translation: bool,

Instead of the plane intersection method, should use vector math for finding the nearest point on skew vectors, something like:

pub fn nearest_point(&self, other: &Ray) -> Option<Vec3> {
    let delta_p = other.origin - self.origin;
    let v1_squared = self.direction.dot(self.direction);
    let v2_squared = other.direction.dot(other.direction);
    let v1_dot_v2 = self.direction.dot(other.direction);
    let determinant = v1_dot_v2.powi(2) - v1_squared * v2_squared;

    if determinant.abs() > f32::MIN {
        let delta_p_v1 = delta_p.dot(self.direction);
        let delta_p_v2 = delta_p.dot(other.direction);
        let t = (1.0 / determinant) * (v2_squared * delta_p_v1 - v1_dot_v2 * delta_p_v2);
        let result = self.origin + self.direction * t;
        Some(result)
    } else {
        // The lines are parallel!
        None
    }
}

This should be more robust to camera view changes and translating at far distances with perspective cameras.

Handles that allow free translation within a plane.

As of today Bevy is 2 open issues behind the 0.9 milestone. See: https://github.com/bevyengine/bevy/milestone/7 and this crate should support it asap ;)

Bevy Migration

remove deprecated API usage of spawn_bundle() and use spawn() instead

Sometimes it can be helpful to limit the sub-gizmos displayed to specific axes. Therefore it would be nice to add a configuration that controls each individual sub-gizmo. A corresponding structure should look like this:

pub struct AxisConfig {
    pub x: bool,
    pub y: bool,
    pub z: bool,
    pub view: bool,
}

pub struct GizmoVisibility {
    // translation helper
    pub translation_arrow: AxisConfig,
    pub translation_plane: AxisConfig,
    // scaling helper
    pub scaling_arrow: AxisConfig,
    pub scaling_plane: AxisConfig,
    // Rotation helper
    pub rotation_arc: AxisConfig,
    pub rotation_arc_ball: bool,
}

It would be nice if it was possible to control whether the gizmo is shown while the program is running, e.g. for an in-program 'editor' like bevy_editor_pls.

Make style user-configurable. As a resource?

Make scaling handles functional.