Account for negative terrain elevation in frustum far plane definition #10432

karimnaaji · 2021-03-04T19:03:34Z

Prevent cutoff artifacts by accounting for negative terrain elevation in view frustum definition. We currently assume the minimum bound to always be mean sea level, by taking into account the minimum possible elevation of the current view, we can push the far plane further by that amount to eliminate that visual artifact.

Fixes #10317

Before / After

negative-elevation-cutoff.mov

negative-elevation-cuttoff-fix.mov

Launch Checklist

briefly describe the changes in this PR
include before/after visuals or gifs if this PR includes visual changes
write tests for all new functionality
[n/a] document any changes to public APIs
[n/a] post benchmark scores
manually test the debug page
[n/a] tagged @mapbox/map-design-team @mapbox/static-apis if this PR includes style spec API or visual changes
tagged @mapbox/gl-native as this needs a native port
apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Prevent cutoff artifacts by accounting for negative terrain elevation in view frustum definition</changelog>

rreusser

This looks great! I poked around and had come up with a slightly different permutation of the same thing. I just had one little nit about a redundant abs.

It's definitively better so I marked it "approved", but I checked out this branch and did notice one glitch. When I initially load, it sometimes does or does not trigger a final redraw which applies this clipping. The result is sometimes-bad clipping which does not resolve itself until an externally triggered redraw. I'm not great with async loading behavior yet, but is there a way to trigger a redraw when data has loaded and the minimum has been computed?

src/geo/transform.js

rreusser · 2021-03-04T19:35:30Z

src/terrain/terrain.js

@@ -740,6 +741,15 @@ export class Terrain extends Elevation {
        return {efficiency: (1.0 - uncacheableLayerCount / drapedLayerCount) * 100.0, firstUndrapedLayer};
    }

+    getMinElevationBelowMSL(): number {
+        let min = 0;


Nice. I think this is a better initialization than +INFINITY, since when things were initially loading, I found that infinity percolated through to the camera adjustment.

rreusser · 2021-03-04T19:51:23Z

Oh, sorry, the location of my screenshot: http://localhost:9966/debug/terrain-debug.html#12.38/31.37145/35.37661/0/9

rreusser · 2021-03-04T21:10:42Z

Ah, this also exposes a bug which will be necessary to open as a followup issue, but I'll hold off since it can't currently be reproduced in anything except this branch. Snapping the camera to elevation >= 0 prevents zooming in on features < 0. (cc @future-me)

Co-authored-by: Ricky Reusser <rreusser@users.noreply.github.com>

karimnaaji · 2021-03-04T21:49:46Z

The result is sometimes-bad clipping which does not resolve itself until an externally triggered redraw. I'm not great with async loading behavior yet, but is there a way to trigger a redraw when data has loaded and the minimum has been computed?

That's a good catch, I will debug more to see how it can be directly accounted for without redraw.

Ah, this also exposes a bug which will be necessary to open as a followup issue, but I'll hold off since it can't currently be reproduced in anything except this branch. Snapping the camera to elevation >= 0 prevents zooming in on features < 0. (cc @future-me)

I wouldn't be surprised if there are other locations in our code where we make an assumption that all values are >= 0, especially in camera related behavior. Do you remember the location of the gif where this was triggered?

rreusser · 2021-03-04T22:58:54Z

Do you remember the location of the gif where this was triggered?

Anywhere around the Dead Sea works pretty well 😄 E.g. http://localhost:9966/debug/terrain-debug.html#17.1/31.417303/35.379056/0/9 (A somewhat niche issue, at least until someone imports bathymetry data 🐳 )

karimnaaji · 2021-03-05T17:36:45Z

I took some time to look at the issue mentioned around the frustum plane not being pushed enough until an interaction on first load. It's a bit of a hard one to reproduce, but so far what I noticed is that we're only off by one frame. I'm a bit hesitant to play with frame sequences just for this issue due to the possible unexpected consequences it may have.

All of the data necessary to render correctly is there (the minimum elevation is found and applied to the transform) but the rendered frame itself has this artifact, and only one sequential new frame is necessary to render it correctly.

If I don't find a simple way forward today I'll leave that as a follow-up issue as it's fairly hard to reproduce it, at least from the testing I've done.

rreusser · 2021-03-05T19:40:16Z

What do you mean by "hard to reproduce"? Just curious because depending on the location, it shows up ~100% of the time for me.

I think you're right though. This is still definitely an improvement 👏, so I think it's completely reasonable not to block this fix on a more general/complete fix.

karimnaaji · 2021-03-05T19:58:53Z

What do you mean by "hard to reproduce"? Just curious because depending on the location, it shows up ~100% of the time for me.

I have almost no chance of triggering it for the location you posted or any other that have similar elevation (hard refresh with network caching disabled). I'm still investigating though.

Screen.Recording.2021-03-05.at.11.42.31.AM.mov

rreusser · 2021-03-05T20:45:26Z

For that location, I have almost no chance of not triggering it on hard refresh. I observe that it's pretty sensitive to the precise position (and maybe window size?). Otherwise maybe the GPU/system-dependent timing affects it? Somewhat surprising, but not ultimately urgent, I think.

astojilj · 2021-03-08T10:18:11Z

src/data/dem_tree.js

@@ -308,6 +310,7 @@ export default class DemMinMaxQuadTree {
    }

    _addNode(min: number, max: number, leaf: number) {
+        this.minimum = Math.min(this.minimum, min);


Leftover?

Minimum among _visibleDemTiles is reduced at getMinElevationBelowMSL - this seems to track minimum among all tiles loaded.

Not a leftover, this minimum is for one DEM only, after going over the mips. In getMinElevationBelowMSL we then reduce it over the visible dems.

@karimnaaji
Thanks. It is then redundant calculation since the minimum of a DEM tile is already available at DemMinMaxQuadTree.minimums[0].

e.g. this never asserts:

diff --git a/src/terrain/terrain.js b/src/terrain/terrain.js index c74f6535e..b2f1beff7 100644 --- a/src/terrain/terrain.js +++ b/src/terrain/terrain.js @@ -747,6 +747,7 @@ export class Terrain extends Elevation { const maxDEMError = 30.0; this._visibleDemTiles.filter(tile => tile.dem).forEach(tile => { const minMaxTree = (tile.dem: any).tree; + assert(minMaxTree.minimum == minMaxTree.minimums[0]) min = Math.min(min, minMaxTree.minimum); }); return min === 0.0 ? min : (min - maxDEMError) * this._exaggeration;

Similar (max for tile too) reduce is done in getBounds3D where minimums[0] is used for the same purpose.

mapbox-gl-js/src/geo/transform.js

Line 996 in 74afcb2

const minmax = elevation.visibleDemTiles.reduce((acc, t) => {

Good catch, I'll update for minimums[0]

karimnaaji added the bug 🐞 label Mar 4, 2021

karimnaaji requested review from astojilj and rreusser March 4, 2021 19:03

karimnaaji added 2 commits March 4, 2021 11:37

Push far z plane using min elevation of visible tiles

7b49794

Add unit tests

ae53b54

karimnaaji force-pushed the karim/negative-elevation branch from 31ced0c to ae53b54 Compare March 4, 2021 19:39

rreusser approved these changes Mar 4, 2021

View reviewed changes

karimnaaji and others added 2 commits March 4, 2021 13:41

Update src/geo/transform.js

ee6d0e9

Co-authored-by: Ricky Reusser <rreusser@users.noreply.github.com>

Update src/geo/transform.js

cc9c5d6

Co-authored-by: Ricky Reusser <rreusser@users.noreply.github.com>

astojilj reviewed Mar 8, 2021

View reviewed changes

karimnaaji merged commit 74afcb2 into main Mar 8, 2021

karimnaaji deleted the karim/negative-elevation branch March 8, 2021 16:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Account for negative terrain elevation in frustum far plane definition #10432

Account for negative terrain elevation in frustum far plane definition #10432

karimnaaji commented Mar 4, 2021

rreusser left a comment •

edited

Loading

rreusser Mar 4, 2021

rreusser commented Mar 4, 2021

rreusser commented Mar 4, 2021

karimnaaji commented Mar 4, 2021

rreusser commented Mar 4, 2021 •

edited

Loading

karimnaaji commented Mar 5, 2021

rreusser commented Mar 5, 2021

karimnaaji commented Mar 5, 2021

rreusser commented Mar 5, 2021 •

edited

Loading

astojilj Mar 8, 2021

karimnaaji Mar 8, 2021

astojilj Mar 8, 2021

karimnaaji Mar 8, 2021

Account for negative terrain elevation in frustum far plane definition #10432

Account for negative terrain elevation in frustum far plane definition #10432

Conversation

karimnaaji commented Mar 4, 2021

Launch Checklist

rreusser left a comment • edited Loading

Choose a reason for hiding this comment

rreusser Mar 4, 2021

Choose a reason for hiding this comment

rreusser commented Mar 4, 2021

rreusser commented Mar 4, 2021

karimnaaji commented Mar 4, 2021

rreusser commented Mar 4, 2021 • edited Loading

karimnaaji commented Mar 5, 2021

rreusser commented Mar 5, 2021

karimnaaji commented Mar 5, 2021

rreusser commented Mar 5, 2021 • edited Loading

astojilj Mar 8, 2021

Choose a reason for hiding this comment

karimnaaji Mar 8, 2021

Choose a reason for hiding this comment

astojilj Mar 8, 2021

Choose a reason for hiding this comment

karimnaaji Mar 8, 2021

Choose a reason for hiding this comment

rreusser left a comment •

edited

Loading

rreusser commented Mar 4, 2021 •

edited

Loading

rreusser commented Mar 5, 2021 •

edited

Loading