h3r2tic / dolly Goto Github PK

Somethings it needed to get a value from driver without it modification. In unit tests, for example. It would be great to have a function that behaves like driver_mut, but returns a non-mutable reference.

I'm noticing that when using smoothing, and when the camera is following an object, there is jerkiness that seems to be coming from the smoothing. And any changes I make to the smoothing parameters don't seem to help.

If the object makes a single jump from point A to point B, or the object stops moving, then the camera moves smoothly to it, but when the object is in constant steady-state motion, the camera has some small jerkiness/oscillation and is not as smooth as I might expect.

Simple test exhibiting this behavior is a small modification to the nested_driver.rs example, just changing the camera rig position to follow the target, and adding a dolly arm (similar to the follow example shown in the README):

diff --git a/examples/nested_driver.rs b/examples/nested_driver.rs
index 643ad0c..9bbd1e5 100644
--- a/examples/nested_driver.rs
+++ b/examples/nested_driver.rs
@@ -20,11 +20,13 @@ impl<H: Handedness> MovableLookAt<H> {
         target_position: dolly::glam::Vec3,
     ) -> Self {
         Self(            
             CameraRig::builder()
                 // Allow moving the camera
-                .with(Position::new(camera_position))
+                .with(Position::new(target_position))
                 // Predict camera movement to make the subsequent smoothing reactive
                 .with(Smooth::new_position(1.25).predictive(true))
+                .with(Arm::new(dolly::glam::Vec3::new(0.0, 1.5, -3.5)))
                 // Smooth the predicted movement
                 .with(Smooth::new_position(2.5))
                 .with(LookAt::new(target_position + dolly::glam::Vec3::Y).tracking_smoothness(1.25))
@@ -37,7 +39,7 @@ impl<H: Handedness> MovableLookAt<H> {
         camera_position: dolly::glam::Vec3,
         target_position: dolly::glam::Vec3,
     ) {
-        self.0.driver_mut::<Position>().position = camera_position;
+        self.0.driver_mut::<Position>().position = target_position;
         self.0.driver_mut::<LookAt>().target = target_position;
     }
 }

Then if you hold down one of the WASD keys, you'll see the jerkiness. Not sure if there's some combination/ordering of smoothing drivers that can help with this, or if it's inherent in the smoother itself. Or any other ideas?

Hey! We're using dolly and wanting to swap out camera drivers at runtime (specifically Rotation and YawPitch). There are no helpers to expose this in the public API, but since the drivers Vec is (perhaps unintentionally) pub we can patch those in. Is that an intended use-case?

As an alternative approach we also looked into having both drivers on the stack so that we could set one of the two to IDENTITY, but as it turns out dolly doesn't really stack the drivers sequentially, instead the Position/Rotation/YawPitch (and maybe all the other) drivers replace a translation or rotation on update(), meaning only the last rotation or position sticks. This is also visible in the README example, where a camera has a Rotation (that is updated) but useless because the subsequent LookAt overwrites the rotation.

How would you feel about changing the public API to use mint types?

It could help avoid glam version issues and make it easier to use with other maths crates too.

I saw in the readme that field of view is (intentionally) not part of this. But could it be?

Framing an object (smoothly) based on its bbox/bsphere is a common task for such rigs in the wild.

When implementing collisions you usually smooth arm distance if it increase.
I proposing to add a driver that implements this behavior.

Very high rotational smoothing values in combination with high sensitivity causes the camera to snap (to the closest quat rotation) and roll which is mildly dizzying 😅

The current implementation in

pub fn look_at<H: Handedness, V, Q>(forward: V) -> Q
where
    V: Into<mint::Vector3<f32>>,
    Q: From<mint::Quaternion<f32>>,
{
    let forward: Vec3 = forward.into().into();

    let result = forward
        .try_normalize()
        .and_then(|forward| {
            let right =
                H::right_from_up_and_forward::<Vec3, Vec3>(Vec3::Z, forward).try_normalize()?;
            let up = H::up_from_right_and_forward(right, forward);
            Some(Quat::from_mat3(&Mat3::from_cols(
                right,
                up,
                forward * H::FORWARD_Z_SIGN,
            )))
        })
        .unwrap_or_default();

    From::from(result.into())
}

hard code Vec3::Y as the look at up direction. It would be great to have that configurable, so this package can be used in different camera setup.