Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map pitch not accounted for in text orientation #4376

Closed
nickidlugash opened this issue Mar 7, 2017 · 6 comments
Closed

Map pitch not accounted for in text orientation #4376

nickidlugash opened this issue Mar 7, 2017 · 6 comments
Assignees

Comments

@nickidlugash
Copy link

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
Copy link
Author

@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
Copy link
Contributor

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
screenshot 2017-03-27 12 15 43

Panned to lower right
screenshot 2017-03-27 12 15 31

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.

@lucaswoj lucaswoj reopened this Mar 28, 2017
@ChrisLoer ChrisLoer self-assigned this Mar 28, 2017
@ChrisLoer
Copy link
Contributor

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
Copy link
Contributor

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:

screenshot 2017-04-25 13 34 22

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
Copy link
Contributor

#4781 should address this!

@ChrisLoer
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants