-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Conversation
0c503c5
to
ed972b2
Compare
ed972b2
to
11969d0
Compare
@brunoabinader Can you please kindly clarify the following?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new maximum pitch would be a good change to add to the Android, iOS, and macOS changelogs. It improves not only the developer experience but also potentially the end user experience.
We start limit (clamping the range of) tile coverage when pitch trespasses Notice, however, that in continuous rendering mode, we also calculate pan tiles, which throughputs bigger tiles that should cover the remaining part of the visible map - more about this in #7741.
We only need the rotated values to calculate clamping when limiting (and we rotate back after). Otherwise, we proceed with the original tile coverage algorithm.
We don't need pitch because it has been already taken in consideration when calculating the
Not sure what you mean here - in |
Worth mentioning that using an arbitrary fixed limiting factor of 4 is a simpler solution to a somewhat complex problem. When implementing this, I've also considered the following:
double rangeX = (topRight.x - topLeft.x) * std::cos(pitch); For future consideration, we can also think of:
|
11969d0
to
5145a76
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brunoabinader In playing with this branch I see that the order in which tiles are fetched and rendered is prioritizing the panTiles
over the idealTiles
. This works great for satellite imagery. With vector tiles, Im sometimes seeing that low zoom tiles at the top edge of the screen are being loaded before tiles in the center or bottom of the screen. It's rare, but wondering if there's something to be done about it ?
Is there a reason for enabling the clamping only past 60 degrees pitch ? It seems like it would be useful starting ~ 45 degrees.
5145a76
to
faa16d9
Compare
I believe that's intended - my understanding of pan tiles is that they prevent empty areas when panning - so we want to start showing off these faster than the higher zoomed tiles. However, we could add some logic to prevent this prioritization when not gesturing (
We can modify that 👍 However, clamping past 60 degrees preserves the current behavior (because we've been limiting pitch to 60 degrees until now). Also, the amount of visible tiles also depends whether your zoom level is close to its integer value (e.g. |
faa16d9
to
691bf55
Compare
Render tests |
691bf55
to
e5491d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Any chance you can add a render test too?
Good idea, I'll add one 👍 |
e5491d8
to
8400fd7
Compare
8400fd7
to
3e5c7a2
Compare
3e5c7a2
to
1b795ea
Compare
@asheemmamoowala could you please re-review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brunoabinader Im not sure I understand why Symbol layers are skipped on the pan tiles, and how that relates to this PR.
@@ -43,6 +45,22 @@ TEST(TileCover, Pitch) { | |||
{ 2, 1, 2 }, { 2, 1, 1 }, { 2, 2, 2 }, { 2, 2, 1 }, { 2, 3, 2 } | |||
}), | |||
util::tileCover(transform.getState(), 2)); | |||
|
|||
// 2 tiles on the left, 1 center tiler, then 2 tiles on the right. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Break this into a separate test
uint8_t integerZoom = std::floor(zoom); | ||
transform.setZoom(zoom); | ||
auto fullTiles = util::tileCover(transform.getState(), integerZoom, util::TileCoverMode::Full); | ||
auto limitedTiles = util::tileCover(transform.getState(), integerZoom, util::TileCoverMode::Limited5x5); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to also check the correctness of the returned tiles as part of the test.
point = util::rotate(rotated, -bearing); | ||
}; | ||
|
||
// Limit tile coverage in continuous mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment still appropriate? How is continuous mode being checked here?
const Point<double>& tr, | ||
const Point<double>& br, | ||
const Point<double>& bl, | ||
std::vector<UnwrappedTileID> tileCover(Point<double> tl, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: non-uniform input arguments.
Would it be better to keep these as const references, and conditionally return a clamped point from limitTileCoordinate
?
auto scanLine = [&](int32_t x0, int32_t x1, int32_t y) { | ||
int32_t x; | ||
if (y >= 0 && y <= tiles) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This condition is no longer necessary? I think it is necessary at the poles.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This would be great to resurrect! Related discussion is still going on the JS side: mapbox/mapbox-gl-js#3731 |
This pull request has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions. |
This PR:
From the example above, the topmost tile is a higher zoom tile (configurable via
Map.prefetchZoomDelta()
that covers the remaining visible area.Using pan tiles to cover the horizon reduces the amount of rendered tiles, and because they are barely visible, the lower fidelity doesn't account much. This PR is an ongoing effort to eventually support modifying the projection matrix eye according to the edge insets (#12107) - modifying the eye position can also cause more tiles to be visible.
Most rendering failures in render tests are caused by setting a pitch value higher than maximum pitch, which causes different results between GL native (max pitch: 67.5) and GL JS (max pitch: 60.0).
/cc @asheemmamoowala @kkaefer @tmpsantos