Splitting the graphics engine

[10110111]

I'm looking for ways to split the graphics engine, so that we could improve image quality, still retaining support for legacy hardware.

#3156 showed that even as basic change as addition of support for sRGB-aware textures and framebuffers doesn't work at least for Raspberry Pi, and ANGLE with GLES2 doesn't support this well enough too. But even this change is quite intrusive for many modules. So I suppose I'll have to split the graphics engine into two modes: high-graphics and legacy. What I'm not sure of is how this should be done. Some ways are as follows.

• Split some classes into two implementation files and conditionally compile ones or the others depending on the chosen mode, leaving Qt5-based builds with the legacy engine, while putting all the improvements into Qt6-based ones. In this case we'll basically freeze all the graphics in Qt5-based builds (removing support for ShowMySky there), improving whatever else that remains, and only fixing some serious problems there that might appear. The Qt6-based builds would only contain the high-graphics engine, without any fallbacks.
• Make a split in two separate high-graphics and legacy binaries, but independent on Qt version. Not sure if this would make much sense, since Qt5 support remains specifically for legacy hardware.
• Make dozens of inline conditionals throughout the code that depend on some highGraphicsMode flag that's set dynamically, based on OpenGL capabilities and command line. Some files like Landscape.cpp or StelPainter.cpp will have especially large amount of such checks. Scenery3D might later also need this. This would make maintenance much harder.

What do you think? Any other way you can suggest?

[gzotti]

Hmm, what are your long-term plans? Why a new graphics engine? Do you want to go Vulcan? More shader programs? For what? Asteroid belt simulation? Planet atmospheres? 50.000 satellites in earth orbit?

Most users now are (I think) happy with the current appearance, there is just still a significant number of bugs or usability issues. (ObservingLists, TelescopeControl, ... Text output seems to slow down the system. Any insight on #3003?) What currently looks bad is the balance new skylight vs. Milky Way. The sky brightness seems higher than what the older model delivered, or maybe you are counting more data points, and therefore visibility of Milky Way&ZL are reduced. My quick balancing for 1.0 was not sufficient here.

Of course, software evolves, and at some point also newer hardware like HDR-aware screens will be widely available. Then we will need something new, yes. Do you want to do something about glare simulation?

I would be OK if we leave Qt5-based builds on all 3 platforms with the OpenGL 2.1/ GLES 2.0 / ANGLE ("legacy") solution (with optional OpenGL3.3 skylight? Or really without, for simplicity?), and if new breaking changes (OpenGL 4.2+? What do you have in mind?) are required do that support only on Qt6. However, I would like to first clear out these know bugs that keep accumulating. Currently users would have to install both versions on a general-use laptop: Qt5-based for field use with a telescope, and Qt6-based for nice views. If I am not forced by some 32-bit ASCOM driver, I usually should not need the Qt5-based build on a reasonably new (2015+?) system, as soon as we have fixed the TC plugin issues on Qt6.

The Qt6 build should however retain the switching option Preetham/ShowMySky, as the latter still needs more resources. There are OpenGL4.2 capable systems which still would deliver smoother operation with the older model, just showing off the "real thing" occasionally is still nice there.

[10110111]

Hmm, what are your long-term plans?

My long-term plan is a fully physically-based rendering (with the ratios of brightnesses of ZL, MW, planets etc. to skylight being correct by definition). This means making a linear-light HDR image in a floating-point FBO that can be:

1. Tonemapped to be shown on the SDR screen,
2. Tonemapped to be shown on HDR screens,
3. Saved as a DNG photo (maybe by extending the Oculars plugin),
4. Manipulated to add glare or other effects.

This will affect all modules that render physical objects, quite extensively.

Do you want to go Vulcan?

No, I don't find any reason to switch Stellarium to Vulkan, only disadvantages.

Asteroid belt simulation? Planet atmospheres?

Planet atmospheres is definitely a must, as well as better planet rings. But first they must be rendered in a physically-sensible way, i.e. in physical units of brightness, which implies the need for HDR.

[gzotti]

Reads like an ambitious PhD project :-) Please make sure to know the literature! Schaefer from the side of astronomy, maybe some atmospheric optics, psychophysics (esp. human mesopic/scotopic vision), light pollution work, Night Rendering (Jensen 2000) or related papers, ...

The nebula images are delivered in a JSON format which was never fully documented (SUG 8.1.3, minResolution/maxBrightness, these will be important to draw the DSO in the right brightness. ). Also things like the moment when stars appear will need careful re-implementation.

Will your idea of Qt6/modern run on OpenGL3.3 or even higher systems?

[10110111]

some atmospheric optics

We have ShowMySky for this. It can compute extinction too. Refraction can in principle be added to it as well.

Schaefer from the side of astronomy

We also have ISS raw photos of airglow, so this is relatively easy to validate.

light pollution work

CalcMySky + light pollution maps. May need extension for non-constant ground glow, still doable.

psychophysics (esp. human mesopic/scotopic vision)

Rapport BIPM-2019/05 "PRINCIPLES GOVERNING PHOTOMETRY" has discussion on this.

Night Rendering

This is the only really hard part here, since it's not actually physics of light reception, but rather psychology of light perception. Jensen 2000 might be a solution, but only as an option for those who like this acid blue in place of gray. I need to find better ways of tone mapping that would look more realistic.

But in any case, a photo-like HDR image is the first stage of this.

Will your idea of Qt6/modern run on OpenGL3.3 or even higher systems?

I think OpenGL 3.3 should suffice for now. It contains all the core support for sRGB textures and floating-point FBO, and this is the main requirement.

[gzotti]

Schaefer is not only for airglow, esp. the appearance of stars and the Milky Way in twilight is important to get right.
For light pollution, I know Garstang's 1990s works, but not the current state.
For the "acid blue", maybe simple brightness-dependent decolorisation helps. (dim blue landscape gets gray, red or yellow lights keep more of their color... A few switches for advanced users could influence strength of effects. And then there is the temporal component, glare into the bright moon, and the landscape appears black for half a minute... ) This was only an example. But indeed, this is about human vision, and Stellarium is mostly about experiencing night views, not about photo planning.

OK, for the next steps, it's OK for me to split the graphics requirements (and indeed also use of ShowMySky) on the Qt5/Qt6 transition. What I want to avoid is a full branch, where the Qt5 line would be left behind. We had the 0.12 series which stayed on Qt4 for several years, where new functionality was left behind, and where Alex had to backport just a few important features or bugfixes. Prefer to use one common master and apply a few #ifdefs, so at least the astronomical data are the same.

EDIT: Of course, develop this in a branch, but with the idea of building releases for Qt5 and Qt6 from a common, merged master.

@alex-w ? @xalioth ?