Symbol visibility above the horizon.

[prozessor13]

Hello,

I implemented a horizon logic, because otherwise in heavy tilted maps you see very far to the poles. This is done via the farZ clipping plane, but this effetcs only baselaers, symbols will render ontop and so do not know anything about the horizon/farZ. Because 3D has a depth-buffer and all symbols are cheched against this depth-buffer in 3D all is working as expected, but in 2D there is no depth-buffer and so symbol will render below horizon. There are some ways to fix this:

1. remove the horizion in 2D, but then, if you switch to 3D you see jumping the horizon.
2. implement the depthbuffer in 2D as well.
3. check 2D symbol-visibility in CPU

my attempt would be to implement version 2, but this will be the first place where the 3D code will effect the 2D code. What should i do?

[HarelM]

I think that option 2 feels better. If you want to make sure you are not "ruining" anything writing the test up front and then implementing this would prevent things from breaking I believe.
I have the server returning points on the map to be displayed (not tiles but rather geojson according to the visible area indicated by north east and south west coordinates) so I would probably need a way to ask the map about the "visible/relevant area" or something similar when doing 3D or even doing 2D with maxPitch > 60.
Implementing this logic I think can help in the implementation of this feature, wouldn't it?
Not sure though...

[prozessor13]

Yes this is the same usecase than to calculate the maplibregl.Marker visibility, which is documented in a separate issue. When i switch to framebuffer i will create a separate method to check visibility and fix the marker-issue as well. Should i create a separate pull-request for this?

[HarelM]

Different PR would be great.

[HarelM]

Referenced issue from above comment: #1134.

[HarelM]

This was addressed with #1188