Clipping horizon
A clipping appeared on the floor, certainly caused by the far camera
https://github.com/user-attachments/assets/cdececda-23e3-4ec4-8c3f-358c0837c21d
Hi! This is intended behavior since #2049. If the visual impression isn't satisfactory, or the far-clipping is too obvious, everything is still configurable: a factor controlling the limit of the horizon (View.farFactor), the color of the fog, the color of the sky...
The default value of the far factor should be changed to ensure that all potentially visible data are displayed. In your opinion, what should this value be so that the display looks similar to what it was before the PR #2049 ?
Being able to see exactly up to the horizon would not correspond to a fixed value of farFactor. If we wanted to ensure that all possibly visible data is displayed, we would need to determine that value based on a worst case, e.g. we're 1 m above sea level. In that case farFactor would need to be around 3600.
We could improve the horizon distance by using the optical horizon formula.
Comparison between the master (left) and new formula (right), there is not elevation layer. In this camera position the farFactor cannot correct the camera.far
But with this formula there's a issue : some mountains could be visible after the horizon. A fix could be to calculate the camera frustum containing all visible tiles
Image illustrating that an observer can see a point further away than the horizon line
Calculating the correct horizon distance was actually one of my earlier implementation of the issue, but it was decided to use a method that didn´t show all the theoretically visible area, precisely to limit the number of rendered tiles, and to use fog to hide the border of those tiles.
A GIS data viewer should not hide data by default. The idea would be to disable it by default, or to ensure an accurate calculation of the FAR. The idea is remove unuseful tiles and not remove visible tiles
Furthermore, the gain of limit the number of rendered tiles is low