Expose rotateLeft & rotateUp in OrbitControls

[Degubi]

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

I have a use case, where I need to rotate the camera when the user's cursor goes near the edge of the screen. At the moment it is implemented with me rotating the model itself, but this has been causing problems.

Describe the solution you'd like

There are these 2 fuctions in OrbitControls.js that would be useful if they were public: 'rotateLeft' and 'rotateUp'. This way I could call them by hand to rotate the camera.

Describe alternatives you've considered

1 more thing I tried was to use the 'autoRotate' feature, but this doesn't work because in my use case the rotation only happens when the user's mouse button is held down. (however autoRotate doesn't work when the mouse button is being held down) This could be another solution if we could control whether the autoRotation should occur even with the mouse button held down.

[Mugen87]

It was already discussed in the past to expose certain methods of OrbitControls. At that time, it was decided to not do this in order to keep the public interface compact (see #9005). Not sure we want to revisit this topic again...

[Degubi]

Yeah. After seeing the discussion in #9005 I decided to modify OrbitControls for myself. IMO it might be worth to reconsider it tho, because so many people have asked for this. I don't see a reason why everyone should modify it for themselves because of the same missing API-s. But I can see your point too.

[Mugen87]

IMO it might be worth to reconsider it tho, because so many people have asked for this.

True, this feature request came up multiple times in the past. I'm open to reconsider this issue and expand the interface of OrbitControls like suggested in #9005 if it's okay with @WestLangley and @mrdoob.

[WestLangley]

In addition to rotateLeft(), rotateUp(), there is panLeft(), panUp(), pan(), dollyIn(), dollyOut().

@mrdoob has placed the controls in the examples directory, instead of core, so users can modify the code to their liking.

I would be inclined to leave the code as-is.

[LasseD]

I have modified OrbitControls and exposed the dollyIn() and dollyOut() methods in one of my libraries, which makes me believe there are many others who are going this route without raising requests here. It might be much more desired than what is currently apparent.

Also. When using OrbitControls for controlling the camera, while also providing other types of camera controls, the easy and functional way of achieving this appears to be to forward camera movements from the other sources to OrbitControls.

[StefanMueller2022]

Another vote for exposing them ;-)! ... These are useful functions that should be public.

[sguimmara]

We would be really interested with this feature too, to avoid forking the code. Maybe a very minimal PR to simply expose the required functions as methods of OrbitControls, which would not be a breaking change, and would not otherwise change the behaviour of the class.

[arcasoy]

Also interested in exposing these methods, along with creating other public methods to manipulate OrbitControls programmatically.

My application uses state to save OrbitControls position, target, rotation, and matrix at certain points, then reapply those saved states when required later on. I have written some custom code to damp/lerp within a useFrame to smoothly animate that motion, but feel as though something supported by Three and more widely used would be useful for others as well.

This functionality would give users control of the camera, but then allow the application to take over when needed. I can forsee a similar method, perhaps .to(), being used in other Cameras as well such as a PerspectiveCamera. This would be used in conditions where .saveState() and .reset() is not feasible to use since multiple states need to be saved.