search

yomotsu / camera-controls

A camera control for three.js, similar to THREE.OrbitControls yet supports smooth transitions and more features.
https://yomotsu.github.io/camera-controls/
MIT License
2.05k stars 256 forks source link

Transition updateCameraUp #505

Open johnperry-math opened 6 months ago

johnperry-math commented 6 months ago

Is your feature request related to a problem? Please describe.

Unlike most other modifications of the camera, updateCameraUp and applyCameraUp don't offer a variable to transition. As a result, updates to camera.up are immediate, rather than transitioned. It would be nicer to have a transition.

Describe the solution you'd like

The API chagnes to updateCameraUp(enableTransition?) and applyCameraUp(enableTransition?), much like rotate and dolly and all the rest.

Describe alternatives you've considered

I've animated this manually, but it's a pain, and the end didn't quite work right, though that may be due to the data I was working with.

Additional context

No response

yomotsu commented 6 months ago

The function applyCameraUp triggers several calculations, as seen here: https://github.com/yomotsu/camera-controls/blob/cf392955edfec75e45c6a2dc36f53891319f3918/src/CameraControls.ts#L2475-L2491

I am concerned that making it animatable within the tick function might lead to performance issues. Typically, changing the camera's up direction is uncommon in regular usage, so it might be more efficient to handle this as a separate function and call it only when necessary.

What are your thoughts on this approach?

ShaydeNZ commented 4 months ago

I've also had some issues with this. For me it's mostly about updateCameraUp().

I use a six view system, where a view looking along each axis can be selected. Moving to a view that looks directly towards the previous camera up requires me to change the camera up so that camera orbiting does something useful. So I select a new camera up vector, do an updateCameraUp(), then perform a setLookAt() with a transition.

On the surface, this is fine, as setLookAt only uses the new _yAxisUpSpace to set _sphericalEnd. But it seems the update() function also uses _yAxisUpSpace during the transition, even though the original orientation was built with the previous camera up value. So the transition "snaps" then moves.

Not a biggie really, as I just don't use a transition if I change the camera's up value. Just mentioning it as it may not be such an obscure request as it may seem. Not sure of an easy solution to it though, given the update() function's reliance on _yAxisUpSpace.