Transition updateCameraUp

[johnperry-math]

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]

The function applyCameraUp triggers several calculations, as seen here:

camera-controls/src/CameraControls.ts

Lines 2475 to 2491 in cf39295

	applyCameraUp():void {
	const cameraDirection = _v3A.subVectors( this._target, this._camera.position ).normalize();
	// So first find the vector off to the side, orthogonal to both this.object.up and
	// the "view" vector.
	const side = _v3B.crossVectors( cameraDirection, this._camera.up );
	// Then find the vector orthogonal to both this "side" vector and the "view" vector.
	// This vector will be the new "up" vector.
	this._camera.up.crossVectors( side, cameraDirection ).normalize();
	this._camera.updateMatrixWorld();
	const position = this.getPosition( _v3A );
	this.updateCameraUp();
	this.setPosition( position.x, position.y, position.z );
	}

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]

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.