Changing rotation (i.e. up-vector) of camera?

[Andlon]

I cannot for the life of me figure out how to change the rotation of the camera. By rotation I mean rotation with respect to the direction the camera is pointing, i.e. changing the up vector, or, I think, the "roll" of the camera. Am I simply looking in the wrong places?

[sebcrozet]

The only way to change the up-vector is to define your own camera (implementing the Camera trait). Currently, both ArcBall and FirstPerson have an up-vector hard-coded to y. They could be modified to allow setting their up-vector to an arbitrary value but some care have to be taken regarding input handling.

[Andlon]

If I find the time, I might prepare a PR. Something like a set_up(&mut self, up: Vector3<f32>) method on the respective cameras?

(P.S: I find it strange that the default up-vector is not the z-axis. Wouldn't most people want to use z as the vertical axis in the world frame...?)

[sebcrozet]

Yup, .set_up(...) seems good, but taking the Vector3 by reference.

I've always worked with the y axis as the "vertical" direction, and so did the few teams I've worked with so far. But I guess conventions differ depending on the field and on the people!

[JoshLambda]

I submitted PR #145 with a function to change up-axis.

• Default is still Y axis.
• It only changes First Person camera.
• Procedural objects are still pointing upward toward Y direction when generated.

Example:

let eye = Point3::new(20.0_f32, 20.0, 20.0);
let at = Point3::origin();
let mut first_person = FirstPerson::new(eye, at);
first_person.set_up_axis(Vector3::z());

[JoshLambda]

I submitted PR #146 with a function to change up-axis on Arc Ball camera.

Important! I didn't mention it in previous PR, but for both First Person and Arc Ball cameras, view only is affected, not camera movements. It means camera movements using keyboard/mouse are only consistent when using Y axis up.

PR note:

• Only view is modified, not camera movements (they stay consistent with Y axis up).
• Default is still Y axis up.
• Procedural objects are still pointing upward in Y direction when generated.

Further consideration on camera movements: Making camera movements consistent with chosen up-axis would require adding conditional statements in many functions, hence complexifying code source and increasing its length significantly. I'm not sure that's what you want in a KISS project.

Usage example:

let eye = Point3::new(20.0_f32, 20.0, 20.0);
let at = Point3::origin();
let mut first_person = ArcBall::new(eye, at);
first_person.set_up_axis(Vector3::z());

[alvinhochun]

I'm trying to fix up the controls for the Arc Ball camera at least, but possibly also the First Person camera later. I only care for the right-handed Z-up case but I also want to do it properly for it to be merged, so there are a few questions that need to be answered:

1. Do we want to handle set_up_axis(Vector3::x())? Is there a use case? (I would expect no.)
2. How should set_up_axis behave if any other vectors are passed into it? (I would expect that it should panic, however doing this can be considered as a breaking change.)