Spamming errors greatly reduces the usability of a library, if every second, up to 500 errors are printed in the console, it is as good as if the library panicked.

With this PR, bevy_transform_gizmo will only log stuff if it didn't already emit a similar message within the last second. (note that I downgraded the errors into warnings, since they fundamentally do not break stuff)

I also use system chaining for logging, because of separation of concerns.

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.

@elpiel: creating this issue to discuss your question from your PR https://github.com/ForesightMiningSoftwareCorporation/bevy_transform_gizmo/pull/18#issuecomment-1025533979

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?

This is not inteded to be merged as is.

A rough prototype of how to let users attach their own run criteria to systems of the plugin - this is the building block that lets enabling/disabling the plugin via user-defined states. I haven't considered if the criteria even make sense on all of these systems.

The main hurdle in the way of making this less gnarly is that Bevy's run criteria (and thus states) are stage-specific. Plans to mitigate that do exist, but aren't quite ready yet; resolving this would make a single copy of a criteria (or label) sufficient for the entire config, instead of a producer function (aka bootleg clone).

Another thing I'm not sure if I like is that the nested plugins have to rely on the same config struct as the top-level plugin. This might be possible to rework, but I don't know how valuable would that be in this context.

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: https://github.com/ForesightMiningSoftwareCorporation/bevy_transform_gizmo/blob/5b27518eda2041f45316cdeef2d90bf15d0b5a33/src/lib.rs#L80-L113

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?

• Allow disabling rotation gizmos
• Add handles for movement in viewspace and movement locked to a plane

Notes: requires https://github.com/aevyrie/bevy_mod_raycast/pulls/51 before this can be completed.

Part of https://github.com/aevyrie/bevy_mod_raycast/pull/24, https://github.com/aevyrie/bevy_mod_picking/pull/106, and https://github.com/ForesightMiningSoftwareCorporation/bevy_transform_gizmo/pull/13, a set of changes reworking the transform gizmo plugin stack to compose better.

Depends on bevy_mod_raycast with https://github.com/aevyrie/bevy_mod_raycast/pull/24 merged, and bevy_mod_picking with https://github.com/aevyrie/bevy_mod_picking/pull/106 merged.

Added global plugin on/off switch with GizmoSystemsEnabled, wired up through run criteria. Fixes #11.

Reimplemented picking suspension on gizmo interaction (now with hovering, too!) using PickingBlocker introduced in https://github.com/aevyrie/bevy_mod_picking/pull/106.

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

https://user-images.githubusercontent.com/2632925/119240735-9477a900-bb06-11eb-840b-d61f94238448.mp4

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

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.

A naive attempt to #8.

I wanted to set up a minimal example in 2d using a orthographic camera, but materials used are 3d, so it makes it a bit more difficult than I'd like, anyway I'm sharing my approach in case anyone want to give it a try.