What you’ve written sounds great!
Issues I have with the current GeospatialCamera are
- the forced use of “pick,”
- the spinning during pan at/near north and south poles,
- Zoom doesn’t always stop at surface+altitude
I’d prefer to not have to use pick and instead use a position/radius.
I’m not sure if my ideas are fully baked, but here they are:
- clearly define reference points, such as
- forward (e.g. lookAt, target) as TransformNode or Vector3
- up,
- geoCenter as TransformNode or Vector3
- persuant to “clear responsibilities,” offer a few different ways to move the camera, such as
- straight-line movement (vector3 supplied, could be forward)
- movement along radius around geoCenter (specified as 2d tangent vector, but what reference point?)
- optional update forward Vector3 unless forward is TransformNode.
- zoom by forward movement, or by fov
- (possible) zoom to radius/intersection then remaining zoom by fov
- pivot axis/angle around specified Vector3 point with optional “change look” afterwards.
Then if generic input classes are defined that accept callbacks (or used as extended classes), the input actions can be tied to the desired selection of camera actions. (“generic” in the sense of being able to be used with various cameras snd tying them to desried camera actions.)
I kind of prefer zoom by specifying “amount to increase the size of a (hypothetical) object at specified distance.” But the math is more complicated than moving the camera position by a Vector3.
For a distance d, a width of one unit (world space) is:
2*d*Math.tan(camera.fov/2)
(see my dolly zoom post to see changing fov and zoom such that width at a distance is constant.)
I’m very interest in seeing your next release of GeospatialCamera!