Suggested improvements for map-like controls scenario

[codedpalette]

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

I've been recently trying to adapt this library for a map controller. Most of the things work out of the box, so first of all thanks for an amazing library and all the hard work you've done. Below I want to document what I had to change and discuss ways to integrate it in the library.

Describe the solution you'd like

• Pan and zoom work as intended on both desktop and mobile (I tested with perspective camera and dolly, but I suspect the orthographic and zoom would also work)
• Map rotation on desktop also works as-is by azimuthal rotation, but you have to manually set controller.polarAngle = 0 when you place the camera in top-down orientation. Without setting polar angle to zero the camera would orbit around the map's plane, but when polar angle is set to zero, azimuth rotation causes camera to rotate around it's own axis, producing the illusion of map rotating. Of course, If you want to allow users to rotate the camera by mouse/touch, you have to enable Action.ROTATE, which would also allow them to tilt the camera by polar rotation. That's why I introduced Separate actions for ROTATE_POLAR/ROTATE_AZIMUTH #618, but it also may be solved by locking maxPolarAngle to 0
• Camera tilt on desktop: see point above but with polar rotation instead of azimuth
• Rotation on mobile is when things get difficult. Current rotate implementation in library doesn't take into account around which point on screen the rotation is made, which is how map controllers usually implement rotation. What I had to do is: detect rotation gesture without using camera-controls (I am using mjolnir.js), convert gesture midpoint from screen to world space, rotate camera position around pivot using matrix math, and then rotate camera forward vector by the same amount to calculate new target point. I then use setLookAt to update both camera position and target. The problem is it feels a little bit janky, especially when paired with some other two finger action, like TOUCH_DOLLY_TRUCK. I assume it's because setLookAt interferes with other animations, so If you don't want to change your rotate action implementation, at least providing some method to rotate camera around arbitrary point while preserving direction would be a viable solution
• Last problem was with dollyToCursor. When camera is top down it works fine, but for tilted camera dollyToCursor causes target point to move outside of a plane which is not good for map controller. I tried setting boundary to Box3 infinite on x and y axis and z constrained to [-1e-6, 1e-6] which caused target to stay roughly on an xy plane, but the dolly to cursor functionality was breaking. What I had to do in the end is raycast from camera position through cursor to xy-plane to find new target to lerp to instead of cursor position. It could be possible to allow users to set target boundary as a THREE.Box3 or a THREE.Plane, and use raycasts in the latter case, but I understand that this is a drastic change to the library. Alternatively, we could restructure the code a bit to make parts of dolly to cursor behavior more customizable by inheritance, and implement MapController as a subclass (kind of like Three.js own MapControls is extending OrbitControls). It can be exported from package alongside existing CameraController, or we can just create another example showing people how to extend the class for future reference.

Describe alternatives you've considered

No response

Additional context

I've implemented parts of this already so I'd be more than happy to organize them into pull request

[Macroz]

I've bumped into the same problem of using camera-controls for a map-like view. Specifically, the dollyToCursor, and panning when the camera is rotated. I am just trying with a regular computer, browser and mouse so far.

I have the map on the XY-plane, and the camera looking down from positive Z to origo. Z-axis is set as up for the camera. It mostly works until I rotate "down" a bit and then the dolly and panning isn't perfect anymore.

[codedpalette]

Regarding panning when rotated down - make sure you set action SCREEN_PAN instead of TRUCK, that should fix it. As for dollyToCursor, like I said the only viable solution is raycasting to plane

[Macroz]

SCREEN_PAN indeed works slightly better, but it's not "pixel perfect" either.