Add dynamic screen space error

[baothientran]

This accommodates https://github.com/CesiumGS/cesium-native/pull/466

[cesium-concierge]

Thanks for the pull request @baothientran!

• :heavy_check_mark: Signed CLA found.
• :grey_question: CHANGES.md was not updated.
  • If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

• [ ] Cesium for Unreal Samples works.

[kring]

@baothientran this is really interesting! The reduction in tiles for horizon views near the ground is quite impressive. And in some cases it actually does a better job of preserving detail. For example, here's a horizon view with dynamic SSE enabled and default settings. Notice the small peak at the horizon near the middle-right of the screen.

Now here's the same scene with dynamic SSE disabled:

Huh.. where'd the peak go? Apparently, it got fog culled. Not great. But even less great is that second screenshot with the missing peak rendered 145 tiles, while your improved algorithm only rendered 81. That's very impressive.

Here's a zoomed out view showing which tiles were selected, with dynamic SSE (81 tiles rendered):

And with the original, non-dynamic algorithm (145 tiles rendered):

The new algorithm is switching to bigger, less detailed tiles much more aggressively, but it also is pushing the horizon out much further.

Of course, if you look closely, you can see the loss of detail at medium zoom distances.

It's more obvious in the above gif because Bing has an imagery discontinuity here.

Also, because the dynamic SSE is only activated when the camera descends below a certain height, it's possible to observe weird discontinuities where moving the camera downward (and thus closer to the globe) causes the globe to become less detailed:

So I think this is super promising, but we need to be a bit more rigorous about it. Especially considering that there are so many user-tweakable settings here. It's going to be very hard to explain to users how to set them, and settings that work great in one part of the globe may work very poorly in others. Perhaps we need some basic knowledge of terrain heights over the globe so that we can use that as an input to the algorithm? CesiumJS does similar things elsewhere (but not for tile selection, AFAIK).

[baothientran]

yeah I agree we should have a better way to estimate those settings automatically, so that it works reliably for the whole earth and make it easier for user. I will check on CesiumJS to see if we can calculate the estimation

[javagl]

So I think this is super promising, but we need to be a bit more rigorous about it. Especially considering that there are so many user-tweakable settings here. It's going to be very hard to explain to users how to set them, ...

The number of settings/parameters depends on the exact approach that is implemented. The computation right now is implemented as

double sse = frustum.computeScreenSpaceError(tile.getGeometricError(), distance);
if (_options.enableDynamicScreenSpaceError) {
    // some complex computation, hightly specific for the approach,
    // depending on 7 user-tweakable parameters and many aspects
    // of what is currently visible on the screen...
    sse = ...;
}

where indeed quite a few paramters come into play.

---

Regardless of the implementation, it all boils down to a single bit being 0 or 1 (render or don't render). So it could be written as

boolean skipDueToSse = sseCuller.compute(....);

Usually (but not necessarily!) this is based on comparing the SSE with the "maximum SSE". So the default implementation of the SseCuller#compute function could be

boolean compute(....) {
    double sse = sseComputer.compute(tile, distance, ...);
    return sse < maxSse;
}

with SseComputer being a single-virtual-function class. One could argue about the exact inputs, but one could be open-minded about that. In any case, it would open room for further experiments, including approaches with fewer user-tweakable parameters.

---

Back when I opened https://github.com/CesiumGS/cesium-native/issues/342 , I actually played around with one implementation like that, using sse = geometricError / pow(distance, someExponent) as the actual function. (That's just one of many possible SseComputer implementations that could be switched transparently, without affecting any other part of the code).

Some screenshots are attached.

The fist one (scene A) shows one scene where I varied the Distance Exponent ( lower right) in the range [0.25, 2.0], and chose the Maximum Screen Space Error so that roughly the same number of tiles are rendered. In the second one (scene B), I did the same with fewer steps.

This this had really just been very basic experiments, because there was no explicit "goal" here. The question about the "goal" could be:

• Should there be fewer tiles rendered for the same SSE ?
• Should the SSE be smaller for the same number of rendered tiles?
• (+ probably many other "axes" to explore....)
• ...
• (abstractly: ) How to actually quantify "visual quality"?

CesiumUnreal distance exponent.zip