Support polygononal landscapes

[alex-w]

According to report https://astronomy.ru/forum/index.php/topic,21983.msg5205015.html#msg5205015 Stellarium do not render landscape properly

Expected Behaviour

Support polygonal landscapes compatible with CdC

Actual Behaviour

Current implementatyion of support polygonal landscapes is not compatible with CdC

U.zip

[gzotti]

Can you circumvent your extreme example by not assigning the zenith but 89.9 degrees of elevation? And maybe adding more intermediate points? The idea behind a polygonal horizon line is a landscape that consists of mountains, not cutting out windows.

[alex-w]

I tried this probable solution but has no successful results and this is very sad :-/

[gzotti]

A polygon list like this works:

0 0
0.5 0
1 89.5
90 89.5
179 89.5
179.5 0
180 0
180.5 0
181 89.9
270 89.9
359 89.9
359.5 0

I cannot say why a narrower gap has issues.

[gzotti]

What is the purpose of this weird thing, BTW?

[alex-w]

The original report (translated):

Help please - I can not load the polygonal landscape. I would like to make sure that only the necessary sector is shown, the rest was sketched in the background. This landscape is in the file "observation_sector.txt". And he is drawn in Ciel, but not in Stellarium. There is some problem when drawing near azimuth 180: the landscape in the "t.txt" file is drawn normally, but not in the "t1.txt" file anymore.

observation_sector.txt in CdC looks like on screenshot

Of course this file is not drawn in Stellarium :(

[axd1967]

with some tweaking it is possible:

by further fine tuning the altitudes it should be possible to attain the desired effect

sometimes I have a subjective feeling that there is some kind of memory effect - as if not all objects are correctly refreshed.

some more logging inside the landscape drawing routines might be useful, maybe the logic decides to skip some vertices.

it looks like the absence of 090 is maybe a culprit:

maybe not only integer values must be avoided, but maybe there needs to be at least one value per 90-degree sector.

0 89 also works:

[gzotti]

The idea behind a polygonal horizon line is a landscape that consists of mountains, not cutting out windows.

This implies many points in every quadrant. "Simply" understand SphericalRegion with all details to figure out what has to be done to cut out windows.

[axd1967]

This implies many points in every quadrant. "Simply" understand SphericalRegion with all details to figure out what has to be done to cut out windows.

I beg to differ: you can't expect an average user to "understand SphericalRegion" (even if a large proportion of users probably are at an academic level). Can't we translate this to "user speak"?

So, populating each quadrant might be a requirement; and this can even be enforced by the software emitting a warning if this condition is not met. If this is the case, I'm not sure if this is highlighted in the User Manual.

[axd1967]

and requiring at least one point per quadrant - if that would be the case - is odd and an obvious shortcoming, but we are aware that the landscape plotting code is far from trivial so we will have to live with this until enough understanding of the code has been acquired.

[gzotti]

I suggest YOU, not the average user, to make your hands dirty and understand SphericalRegion and work out a solution if you really need one. I repeat, the intended use is to create a landscape horizon of a location where the zenith is usually free of obstacles and some hills or houses are plotted. Of course this implies one value every few degrees at least, and by this, in every quadrant.

[axd1967]

hello @gzotti ...

I don't need a solution... I'm just trying to help whoever created the issue, help the community understand the issue, find workarounds. I'm trying to express that this is not an easy solution, I'm not criticising anyone...

in this case, my suggested workaround should at least help the user that created that landscape to go forward, and on the road we learn things.

[axd1967]

Same issue (0.20.3 as well as master) with following data: (the "80" values are attempts to make this landscape work, but even that doesn't work)

000 80
045 80
090 80

125 8

135 80
180 80

186 6
195 12
196 3
206 5
209 2
222 11
236 0
275 19
293 1

315 80
330 80

this is a frustrating experience, because there is no apparent reason why this shouldn't work

[axd1967]

there might be a bug that leads to parts of the drawn landscape to be clipped by the library Qt routines that try to draw the final polygon.

[axd1967]

done some debugging, it looks like this piece of code is giving headaches:

https://github.com/Stellarium/stellarium/blob/5a27f254a8fcd64a2497f4e2114b29640743ba08/src/core/modules/Landscape.cpp#L242-L252

by just skipping this piece (just as a hack...), I get a better result (horizon has been fiddled a bit meanwhile):

as far as I could see, skipping this piece of code also works for the existing landscapes, but I might be mistaken.

it looks like negative altitudes have an impact on the guts of the spherical geometry routines.

[axd1967]

and requiring at least one point per quadrant - if that would be the case - is odd and an obvious shortcoming, but we are aware that the landscape plotting code is far from trivial so we will have to live with this until enough understanding of the code has been acquired.

I suspect that the result of this "requirement" is that the zenith is almost always included in most "normal" landscapes (landscapes )

kind of workaround

reversing the list of horizon points prevents triggering this test but then the user must show the polygon line only

I added a single point to my original file (from https://github.com/Stellarium/stellarium/issues/1397#issuecomment-750904794) and now the normal horizon plotting works again.

043 10 #  -> this seems to make the difference (quadrant 1)

125 08.0 # 
186 06.0 # 
195 12.0 #
196 03.0 # 
206 05.0 # 
209 02.5 # 
222 11.0 # 
236 00.5 # 

275 19.0 # 
293 01.0 # 

[gzotti]

Skipping the zenith test brings back earlier problems. A landscape horizon usually has a free zenith, and a covered nadir. Not both. There are technical reasons deeply buried in the guts of used classes which required enforcing this incredibly restrictive behaviour which tremendously inhibits usability.

Cutting windows into a dome is NOT the application of a polygonal LANDSCAPE usually computed from 2.5D digital elevation models. Use a Spherical landscape and PAINT transparent windows into the texture as a WORKING SOLUTION.

[axd1967]

@gzotti if inclusion of the zenith is required for now (0a95d93324390e4b559a716b796ea4dccb7a1938), wouldn't it good to add at least a warning in the logfile? this problem is difficult to diagnose/visualise but easy to detect by the software.

I've added this in a PR: https://github.com/Stellarium/stellarium/compare/master...axd1967:contrib/issue/1397/landscape/polygon-bug?expand=1