Maximum pitch should vary by zoom level

[1ec5]

It should be possible to tilt the map beyond 60° when the camera is close to the ground. The maximum pitch should vary by zoom level (or by altitude in the iOS and macOS SDKs).

With the current 60° cap, a game or augmented reality application is unable to provide a convincing first-person view; instead, the user is forced to “look down”. For navigation applications, too, it’s important to be able to see far ahead so that the current location and the upcoming maneuver point are both in view. Once we implement 3D extrusion (#6745) and demo tall buildings like in Manhattan, the 60° cap means we can’t zoom in very far without impairing the user’s view of the buildings. At the same time, it’s important not to allow the user to see to the horizon at low zoom levels, as the flatness of the horizon breaks the illusion of viewing part of a globe.

Regardless, tilting anywhere near 90° currently causes mbgl to load all the tiles at the current zoom level to the ends of the Earth. So we’d first need to find a way to load tiles from lower zoom levels the farther out the tiles would be placed.

/cc @ansis @incanus @lbud

[1ec5]

If we allow the user to tilt enough to see the horizon, we may need a way for the style to specify the look of the sky: #2190.

[mtirwin]

An example shot of what's being attempted:

[triceam]

Let me know if you need me to test anything (that's my screenshot above).

[1ec5]

There are a bunch of things we can do at the iOS/macOS SDK level, but I think we’d find that the various special cases for rotation snapping in MGLMapView get in the way when you also want to rubber-band or snap pitch and zoom.

So a gameplan for tackling the web of related viewport bugs might be something like:

• Implement -coordinateBoundsForCamera: (Method to convert arbitrary CameraOptions to LatLngBounds #8499)
• Implement rubber-banding for when -mapView:shouldChangeFromCamera:toCamera: returns NO
• Reimplement rotation snapping atop an internal MGLMapView method that calls -mapView:shouldChangeFromCamera:toCamera:
• Implement pitch rubber-banding the same way (Add elastic bounce-back if tilt gesture hits maximum angle #2191)
• Make the pitch-setting code at the SDK level more sophisticated to account for zoom level (this issue)

#2259 may complicate some of these tasks (probably anything pitch-related), so we should prioritize that issue.

/cc @friedbunny @frederoni @fabian-guerra @bsudekum

[SudarshanMahesh]

Any updates?

[1ec5]

This issue is primarily about allowing the maximum pitch to vary by zoom level, but it’s also sort of tied up with the idea that the 60° maximum should be increased at the highest zoom levels. (We don’t have an issue specifically tracking that change, which would depend on this one anyways.) Before we can increase the maximum pitch beyond 60° at any zoom level, we need to address the issue that distant tiles are loaded far too aggressively when the map is tilted: #9037.

[1ec5]

#12310 increases the maximum pitch to 67.5° across all zoom levels.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[1ec5]

The 60° maximum tilt on iOS/macOS and 67.5° maximum in mbgl are intended to prevent runaway tile downloading. However, a top padding or content inset can also increase the number of tiles: #15163. Until we implement adaptive tile loading (#9037), we should very the maximum pitch based on the viewable distance. The logic could be based on the camera viewing distance calculation in #12966 or the zFar calculations in mbgl:

mapbox-gl-native/src/mbgl/map/transform_state.cpp

Lines 49 to 52 in ae38a22

	// Calculate z distance of the farthest fragment that should be rendered.
	const double furthestDistance = std::cos(M_PI / 2 - getPitch()) * aboveCenterSurfaceDistance + cameraToCenterDistance;
	// Add a bit extra to avoid precision problems when a fragment's distance is exactly `furthestDistance`
	const double farZ = furthestDistance * 1.01;

[astojilj]

Working on it as part of #9037.