Fix fog sky blending

[rreusser]

This PR restores a small fix which was lost along the way, in which terrain that sits above the horizon at high pitch is still obscured by fog, even though it stands out in stark contrast with the unobscured sky. It does this by multiplying fog by the fog sky blending function. Haze doesn't seem to require this change.

The reason we'd cut this out before was that it didn't play well with culling so that blank terrain showed through the fog. I'm not currently able to find problematic spots, though that doesn't mean we don't still need to consider whether this is valid.

Before: http://localhost:9966/debug/fog.html#15.06/-44.66578/167.90699/-53.6/84

After:

[karimnaaji]

Thinking about this more, I'm a bit concerned about going with this approach:

• Implicitly using sky-blend as a height fog control may prevent us from hosting a dedicated height fog system as they could hardly co-exist and leads to ambiguity. If you could achieve a similar look with the use of sky-blend to approximate this effect, how do you control actual elevation-based height fog: Are they mutually exclusive? Which one overrules the other?
• What happens to symbols going higher than this blend factor? Should they be shown/clipped?
• Height fog may have use cases beyond pitch > 65 degrees. For example, I could imagine it being lightly used (with an opacity control) on non-pitched views to allow for better depth perception of top-down terrain.
• How does haze affect fragments over the range of sky-blend? Should it also dissipate as height increases? e.g. in this sort of situation:

• Should the sky blend still affect the terrain when no sky is available?

sky-blend-2.mov

Due to this ambiguity, I think height fog would really deserve more thoughts and not be something tightly coupled with distance fog in any way (even with a minor approximation like here).

Although it's true that we may have a discrepancy between foreground/background, I still consider this acceptable as far fog ranges would not immediately show this type of issue (and very close-up fog should be considered an edge case). It might be best to leave this open-ended to not restrain the possibilities of a dedicated system.

[rreusser]

That makes sense, though it's too bad since it seems moderately visible at high pitch+high zoom. I think map designers would be well advised to either favor haze or significantly increase sky-blend at high zoom (and, once possible, at high pitch).

Tall mountains near sea level seem to be the worst, e.g.: http://localhost:9966/debug/fog.html#15.92/-44.665341/167.914518/-43/85

[rreusser]

After working with this and trying out height fog a bit, I don't think I agree that it would conflict with dedicated height fog, and I think the visibility of this artifact is actually pretty high even with low amounts of fog. Height fog seems significantly different in its mechanics, so that I don't see it being a simple addition which suddenly falls in conflict with existing fog. The number one argument in my opinion though is that I don't think we should skip a small fix for a high-visibility artifact due to the possibility that it might conflict with a feature (though I don't think it would) we don't currently have any intent of implementing, and which we could trivially disable if height fog addressed it instead.

Here is the image at the top again, with fog range [5, 15], which is quite minimal. It's definitely the worst close to sea level.

Here's the same region zoomed out, to illustrate that it's quite a minimal amount of fog:

Regarding the specific points:

Implicitly using sky-blend as a height fog control may prevent us from hosting a dedicated height fog system as they could hardly co-exist and leads to ambiguity. If you could achieve a similar look with the use of sky-blend to approximate this effect, how do you control actual elevation-based height fog: Are they mutually exclusive? Which one overrules the other?

I don't see the ambiguity since if height fog is active and addressed it in its own way, then presumably we would simply disable this fix. I'd also reiterate that I don't think we will implement height fog on any reasonable timeline due to the challenges in estimating the local baseline altitude. I think the sky-blend layer is in a similar situation in the sense that if height fog obviates the need for it, then we'd have to come up with a reasonable solution like layering it under height fog.

What happens to symbols going higher than this blend factor? Should they be shown/clipped?

For a start, I would fade symbols with the strictly-distance-based fog. I don't see a particular reason why symbol fading needs to exactly match fog, though we could certainly try either approach with minimal effort.

Height fog may have use cases beyond pitch > 65 degrees. For example, I could imagine it being lightly used (with an opacity control) on non-pitched views to allow for better depth perception of top-down terrain.

I agree, though I don't think that's related to this fix.

How does haze affect fragments over the range of sky-blend? Should it also dissipate as height increases? e.g. in this sort of situation

I would apply haze just the same. In my experimentation, it looks reasonable and is physically justifiable. To the best of my understanding, haze is the result of light-molecule interactions which presumably vary with air density, so that Mount Everest would still only maybe show a 50% variation in haze from sea level, which is almost certainly negligible compared to other liberties taken with our atmospheric model.

[arindam1993]

With regards to symbols and fog with this, it shouldn't be much of an issue as long as the CPU side fog code can account for sample points height + the fog-sky blend factor.

And regarding this being conflicting with future height fog implementation, honestly we can just rename fog-skt-blend to fog-height with this change, its a much more simper name to understand and in the future we can unlock a larger range for fog-height to allow for below horizon fog heights as well.

[arindam1993]

Need account for this in CPU side code as well.

[rreusser]

I think either direction is defensible, but yeah, I agree, @arindam1993. I've updated the CPU side code to include this.

[karimnaaji]

Thanks for giving it another look. A few more questions:

• Does sky-blend still make sense as a name? It was originally meant to be a horizon-based value, to clarify more on the meaning should it be named differently to better reflect this latest change? elevation-blend, height-blend, horizon-blend? Better naming would also resolve one question I've previously mentioned, as it removes the implicit dependency:

Should the sky blend still affect the terrain when no sky is available?

If we go ahead, I think we should also update the documentation to be more clear about the elevation detail, as I don't think we're mentioning that yet.

• Should we leave 0 as a minimal bound? After testing, 0 seems a bit aggressive visually, using 0.05 as a minimum bound seems to prevent that potential horizon band (basically only allowing a minimum smoothing effect on top of terrain).

[rreusser]

Does sky-blend still make sense as a name?

I wouldn't call it elevation-blend or height-blend since it has no actual dependence on elevation or height, but I think horizon-blend is a pretty good name. 👍

Should the sky blend still affect the terrain when no sky is available?

I think so, yes. You can always set sky/horizon-blend = 1.0 (the max?) Given a fovy of 36 degrees, I think the maximum angle you can see in the sky is something like 31 degrees, so that the blending equation looks like this for sky-blend=1.0:

The point being, you can more or less disable the effect when sky is off by just setting sky-blend to 1.0. For reference, here's fog in what should be perfectly whiteout conditions, with sky-blend set to 1.0. We could always allow sky-blend to go up to 2 or 3.

• Should we leave 0 as a minimal bound?

0.05 seems alright. If you really want no sky-blend you can set it to a transparent color, right?

[karimnaaji]

Thanks for following up on that, the few things we discussed to follow up after this PR:

• Update docs to reflect the new elevation detail introduced by this change
• Better naming of sky-blend to reflect this change (not tied anymore to sky only)
• Revise default minimum bound to prevent eventual harsh horizontal band (we could address this one in a note in the documentation for very low values, or prevent them altogether)

Addressed in latest changes.

[rreusser]

Here is horizon-blend = 0.02:

At low zoom, it seems reasonable to allow a pretty sharp transition, so I'd maybe hesitate to disallow small values. I think best is to simply have zero disable the effect on terrain, and to explain the risks of very small values in the docs.