Map pitch not accounted for in text orientation

[nickidlugash]

From @ajashton #3057 (comment):

Noting that one specific aspect of this is that perspective is not accounted for in text orientation. If you look at this JSFiddle First, 2nd, & 3rd Streets should be rotated 180° to be closer to "upright", but if you change the pitch to 0 the same orientation is correct.

[nickidlugash]

@ChrisLoer We haven't yet discussed this issue, but this may (or may not) be something worth thinking about in conjunction with other pitched label rendering refactors.

Right now if text is kept upright, we calculate which orientation of glyphs we should not add to symbol arrays based on the angle of the glyph, but this doesn't account for how the final angle may change based on pitch.

I'm not sure how vertical text is affected – this issue is not as evident in vertical-enabled line labels, but that may just be because there are four possible orientations so the flip between orientations is more subtle and an "incorrect" orientation is not as suboptimal.

[ChrisLoer]

Hmm, interesting -- yeah, this is something we could tackle at the same time.

This is another case where doing the fully correct solution at high speed requires sending a lot more information down to the GPU. Consider these two views of 15 St NW:

Panned to lower left

Panned to lower right

Both views came from a map at the same pitch/angle/zoom: the only difference was panning left and right.

We could calculate the right glyph to show in the SDF vertex shader, but we'd have to send down two copies of each glyph (one "upside down" copy). Alternatively, we can try to do this calculation at placement time and re-trigger placement whenever there's a pan operation. It would take a little longer for labels to flip to the right orientation, and it would add CPU intensity.

[ChrisLoer]

From discussion with @lucaswoj , there are two issues here that aren't accounted for by text-pitch-alignment:

• We calculate glyph angle without taking account of perspective, so we can get the calculation wrong.
• Even if we were getting the perspective calculation correct, we would only be doing it at placement time, but the perspective can change without re-triggering placement, so we'd need to handle that case.

[ChrisLoer]

There's a closely related problem: collision tiles also don't account for the parallax effect, with the result that you can start to get collisions near the right and left sides of the screen. Check out "Riviera Country Club" in this screenshot:

The collision logic is separate from the text orientation logic, but the shape of the problem is the same: we need to (1) account for perspective at placement time, and (2) periodically re-do placement to account for perspective changes.

[ChrisLoer]

#4781 should address this!

[ChrisLoer]

Fixed with #4781 (although not the collision issue mentioned in #4376 (comment))