Apply fog in fragment shader in terrain_raster program

[endanke]

In GL-Native we do some optimization on the terrain grid by rendering less vertices when the exaggeration is set to zero. (This is to be ported to GL-JS.) In those cases, the fog seems to be applied inconsistently across different zoom level tiles, which is more visible on darker areas.

If we apply the fog in the fragment shader (similarly to our layer-specific implementations) it is rendered correctly.

In render-tests/fog/terrain/equal-range we can see a section of a terrain which is close to the camera, where previously the fog was applied in a sawtooth like pattern. This change fixes it too.

Before (with a low-poly terrain):

After:

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
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/map-design-team @mapbox/static-apis if this PR includes style spec API or visual changes
• tagged @mapbox/gl-native if this PR includes shader changes or 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>Fixes fog rendering on low-poly terrain grid</changelog>

[karimnaaji]

Linking original PRs and profiling related to the evaluation being done in the vertex shader (cc @rreusser):

• Offload terrain fog to vertex shader #10549
• https://github.com/mapbox/gl-js-team/issues/148

In the initial testing done, this had a measurable performance difference (of roughly 1ms of gpu time, with the tradeoff of a minor visual difference due to the evaluation being done in the vertex shader).

It'd be worth profiling this PR on mobile to understand the performance impact. If there's still any measurable difference and this leads to issues with 0-elevation terrain, maybe there's an alternative solution that could retain the performance gain for elevated terrain while still fixing the visual issue.

Otherwise the change looks good to me.

[endanke]

Thanks for the context @karimnaaji !
I think I could add a new define to use a different codepath when the exaggeration is zero. This would be useful in other cases as well to return earlier when we know that the elevation would be flat.

[karimnaaji]

@endanke yes that's an option! But if you don't notice any performance difference in your new measurements, let's keep it simple as you have it here. It's just worth understanding the performance impact before merging as it may offload a lot of computations to the fragment shader and may be beneficial for gpu-bound situations on mobile.

[endanke]

Definitely, I'll run some measurements before merging.

[endanke]

I've run a couple of tests on a Pixel 2 and a Nexus 5 devices, in a setup where the camera moves across different areas with terrain. I've re-run the same sequence 3x10 times, and both the median frame time and the dropped frames are pretty much the same between the before and after cases. (Considering the variance of the runs the difference is within the margin of error.) These tests were run in GL-Native, so there might be still performance changes in GL-JS due to this change.

However, I've also run a couple of tests to measure some optimizations for the zero exaggeration case. We could add a flag to return earlier with a zero in the elevation function and it seems to reduce the frame times around 5%. The same flag can be used here to use the previous implementation if the exaggeration is non-zero.