Summary

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
• remove deprecated API usage of insert_bundle() and use insert() instead

Maintenance

• update all crate dependencies

Movement/Turning (at least using the FPS camera) is heavily dependent on Framerate:

Pay attention to the FPS counter in the video, and how it correlates with the camera movement and movement speed.

https://user-images.githubusercontent.com/24855949/191105564-909f7a44-4e10-4d05-9471-1c7893b28c91.mp4

(video from an example of testing large particle systems, which is why the angle is so weird as to not kill the video compression by looking at 500K particles.)

Hello! Me again 😅

This PR is to allow external systems to pause the automatic smoothing and let them control the LookTransform themselves. When they give back control, the smoother shouldn't animate either. Finally, it fixes the "up" vector always set to Vec::Y for all LookTransform. Indeed, the resulting transform from external systems might have another up vector and we shouldn't break continuity when getting the control back.

Note that this branch builds upon my other PR #11 to update bevy.

I have a simple scene, just the standard Bevy 3d example with the orbit controller added instead of the example's camera. When I zoom all the way in or out, I get a panic with an assertion failed in look_angles.rs:

repro scene:

use bevy::prelude::*;
use smooth_bevy_cameras::{
    controllers::orbit::{OrbitCameraBundle, OrbitCameraController, OrbitCameraPlugin},
    LookTransformPlugin,
};

fn main() {
    App::build()
        .add_plugins(DefaultPlugins)
        .add_plugin(LookTransformPlugin)
        .add_plugin(OrbitCameraPlugin::default())
        .add_startup_system(setup.system())
        .run();
}

fn setup(
    mut commands: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
    mut materials: ResMut<Assets<StandardMaterial>>,
) {
    // plane
    commands.spawn_bundle(PbrBundle {
        mesh: meshes.add(Mesh::from(shape::Plane { size: 5.0 })),
        material: materials.add(Color::rgb(0.3, 0.5, 0.3).into()),
        ..Default::default()
    });
    // cube
    commands.spawn_bundle(PbrBundle {
        mesh: meshes.add(Mesh::from(shape::Cube { size: 1.0 })),
        material: materials.add(Color::rgb(0.8, 0.7, 0.6).into()),
        transform: Transform::from_xyz(0.0, 0.5, 0.0),
        ..Default::default()
    });
    // light
    commands.spawn_bundle(LightBundle {
        transform: Transform::from_xyz(4.0, 8.0, 4.0),
        ..Default::default()
    });
    // camera
    commands.spawn_bundle(OrbitCameraBundle::new(
        OrbitCameraController::default(),
        PerspectiveCameraBundle::default(),
        Vec3::new(-2.0, 2.5, 5.0),
        Vec3::ZERO,
    ));
}

When using this with bevy in the browser, this previously would give some whacky behavior with the scroll wheel. Previously, this library was just using event.y, which was 53 on my machine. When I ran with a desktop backend, it was using Line, so it was just feeding back 1, so I assume that's what you were testing with because that looked fine.

It seems this hasn't been published on crates.io, which would make trying this a lot easier and less concerning (no worries this repo will update automatically and break my build). Additionally, not publishing means anyone could come in and publish a malicious package with the same name and new users will install it without checking. Please publish a release on crates.io!

(after going down a rabbit-hole for the last 8 hours, I'm guessing you're also running into this issue, so maybe it will have to wait until after bevy fixes that issue)

Hello, and first of all: thank you for this plugin, awesome work and very useful/readable.

I'm using Unreal Editor 4.27 in my day-to-day job, and your mapping for the "Unreal" camera were not exactly mimicking UE4 perspective viewport controls.

I've modified your unreal module to follow them more closely. I've also tuned the default values of the UnrealCameraController to have better default speeds compared to the Bevy unit. They feel better when navigating in a scene with meshes of diameter 1 but we might want to put them back up if that's not the ordinary case. They just felt better for the simple_unreal.rs example!

Please don't hesitate to comment/review my code :)

I see you're working on updating the master to follow bevy 0.6.0.

Any chance you can follow bevy tag v0.6.0 or rev 9599af2? ( They are the same commit ). I see you've grabbed on to a slightly newer revision.

Thanks for a great little plugin!

This separates the PerspectiveCameraBundle from bevy_render and OrbitCameraBundle UnrealCameraBundle FpsCameraBundle so that this could be used with applications with custom rendering backend.

Previously used render feature is a group that contains unneeded stuff, like bevy_ui or bevy_text. Specified features in this PR is the required minimum. You can read more about in in this issue: https://github.com/bevyengine/bevy/issues/4202

This PR makes the UnrealCameraPlugin work identical to the FpsControllerPlugin and OrbitControllerPlugin, without it override_input_system is useless because we cannot actually override the input system without access to ControlEvent !

All the examples are using 3D, but I was trying to get it to support 2D as well. It seems i have to manipulate the eye as well to keep the player in the center of the screen, but it makes for a jagged movement

There is an observable error in the camera angles for the first-person controller (at least), which seems to worsen as you get further from the origin. I assume this is introduced when creating LookAngles or maybe Quat. Anyway, I think it means that we'll need to store the angles separately rather than calculating them from global coordinates every frame.

This convinces me even more that we want separate coordinates systems for angles and positions, and a different type of smoother for each coordinate system.

The orbit control example seems to bring the camera closer to the look-at point when rotating fast - presumably because it's taking the shortest path in 3D space. Would it be possible to maintain the distance from the centre when rotating?

Games usually make their own camera controllers. So I would suggest to put controllers under a feature which is enabled by default. If you like the idea - I can send a PR for it.