Allow opacity setting for ground_color in polygonal landscapes #3214
Comments
|
Thanks for adding your first issue to Stellarium. If you have questions, please do not hesitate to contact us. |
|
Hello @ac4lt! Thank you for suggesting this feature. |
|
Due to issues with the underlying polygonal mesh tessellation this is unfortunately not possible. I tried it in ~ 2014... |
|
That's a shame about the inability to do opacity. It would make things a lot simpler for the. user. Regarding the spherical landscape PNG, perhaps I'm doing something wrong there. Can you point me at a proper procedure for constructing one from the text based horizon file? |
|
You can start with a 3600x1800 pixel transparent texture and draw the horizon line in 1/10 degree steps. It may be possible to write a program to do that, but I have not done that so far. |
|
This should be possible to implement if we switch polygonal landscapes to fragment-shader-based rendering, similar to the other types. A problem that would appear is aliasing of the horizon line, which is currently solved by multisampling. |
|
I'm considering ways to implement polygonal landscape via shader, and now I got a question: is the 2048-point (or 16384-point on better GPUs) limit for the horizon line sufficient? I remember @gzotti was against imposing such a limit on old-style landscapes. Is it also critical for polygonal ones? If it's critical, what about a 8192-point limit instead of 2048 (the case when we'd use RGBA components of a 1D texture to fit more points)? |
|
Hm, the point about the polygonal type is the vectorial description, which theoretically has no limits on angular resolution. I am in these days discussing hi-res horizons. If we must introduce a limit, I would opt for resolution finer than 1 arcminute. Arcsecond resolution would mean 360x60x60=1 296 000, that may be overkill, but the arcminute resolution is 360x60=21600. This, or some value not too far away like 16384, is what I would see as minimum requirement for hi-res, as it is the resolution of the unaided eye. Consider zooming into that horizon polygon to see a planet appear. We always say, earth atmosphere will not act as simulated by Stellarium when it comes to arcsecond details on the horizon, but I would dislike to see a jaggy sampled line in this case. Do I understand you would create a texture on the fly filled with semitransparent color to render the polygon? This may be a way for landscapes described with transparency if there is no other solution. But it's hardware dependent. Weak GLES2 systems may have 2048 only (or is 4096 the specified limit?) Most users can probably live with 8192px with the hand-guessed polygons I have seen in screenshots out there. But some need the higher precision the vector description can give. |
No, my idea was to pass a texture containing horizon altitude for each given azimuth. The shader would then check whether current fragment is higher or lower than the horizon, and then either render fill color, or emit transparent fragment (or discard it). This approach will naturally give a vectorized horizon line, because between the texture samples we'll get an interpolated altitude—but there'll be a limit on the frequency of direction switches of this line. |
|
Ah, clever! I have seen manually created horizon lines with tens of values in irregular steps, and use software that creates regular 1/10 degree steps (3600 values). We never specified a theoretical limit for the polygon length, so it could be more (it's a SphericalCap). And .. uh .. it is possible to have undercuts, e.g. tree trunks topped by crowns! So, for a single azimuth, there may be 3 (or more, 5/7/...) altitude values per azimuth! |
And does it still work as intended — the horizon line, the filling? |
|
There is an example in the Geneva landscape, at azimuth 218-220. |
|
Ah, when I first saw it, I thought it was a glitch. Well, this complicates the task considerably. Is having such semi-holes in the landscape very important? |
|
From what I have seen out there, yes, people are doing such silhouettes. The idea of this LS type is letting users draw masks which cover houses, balconies, trees, etc. which are in the way of observing. The polygon line is planned to be used to define, when available, "visible" or "invisible" for objects w.r.t. the visible horizon. (Else, texture alpha is used.) Ultimately, to compute RTS times in the real landscape (using the last (morning) / first (evening) time the object goes behind the polygon. |
alex-w
added
the
state: published
|
Hello @ac4lt! Please check the fresh version (development snapshot) of Stellarium: |
alex-w
removed
the
state: published
|
Hello @ac4lt! Please check the latest stable version of Stellarium: |
Is your feature request related to a problem? Please describe.
I have a polygonal custom horizon for my location but I want the stars to show through the "ground". This is helpful for astrophotography planning purposes.
Describe the solution you'd like
I'd like either a four number on ground_color for the opacity that would look like this:
ground_color = .145,.29,.243,.5
where that ".5" at the end is the opacity of the "ground" or an additional parameter
ground_opacity = 0.5
that would make the ground 50% transparent in this case. Opacity of 1 is fully opaque and opacity of 0 is fully transparent.
Describe alternatives you've considered
I've tried taking the data for my custom horizon and turning it into a png for a spherical landscape but the vertices don't line up with the polygonal horizon file reliably. Some match but some are off.
Additional context
Some of us want the "ground" display only for context purposes. We still want to see the stars that are there but to use color and transparency to show what is visible vs what is not.
The text was updated successfully, but these errors were encountered: