Memory leak and saturated memory usage for high values of frustrum

[gpaar]

trafficstars

On larger (e.g. Jezero HiRise data sets), frustrum settings higher than ~30 lead to extensively growing memory usage which seems to saturate at about 33 GBytes. The process stalls and/or crashes at this point. Seemingly, LoDs are not properly handled and a much larger portion is attempted to load than necessary for the given FoV. Still present in 4.21.0-Prerelease3

[haraldsteinlechner]

related to this one, https://github.com/pro3d-space/PRo3D/issues/485, the current state is. i tweaked the bounding box based lod heuristics to work better with those scenarios but in general, those ortho-style cameras need a different approach altogether. The problem is that, just based on the bounding boxes, all opcs intersecting the view frustum needs to be loaded - and those are maaaany, depending how far away one is looking at. This can't be improved easily. We simply need more information in the lod which is not here yet. The best approach is to use sample rays to guide the lod. This is not that much effor but it needs still-sit-down time.