-
-
Notifications
You must be signed in to change notification settings - Fork 809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Splitting the graphics engine #3318
Comments
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. |
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:
This will affect all modules that render physical objects, quite extensively.
No, I don't find any reason to switch Stellarium to Vulkan, only disadvantages.
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. |
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? |
We have ShowMySky for this. It can compute extinction too. Refraction can in principle be added to it as well.
We also have ISS raw photos of airglow, so this is relatively easy to validate.
CalcMySky + light pollution maps. May need extension for non-constant ground glow, still doable.
Rapport BIPM-2019/05 "PRINCIPLES GOVERNING PHOTOMETRY" has discussion on this.
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.
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. |
Schaefer is not only for airglow, esp. the appearance of stars and the Milky Way in twilight is important to get right. 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 EDIT: Of course, develop this in a branch, but with the idea of building releases for Qt5 and Qt6 from a common, merged master. |
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.
highGraphicsMode
flag that's set dynamically, based on OpenGL capabilities and command line. Some files likeLandscape.cpp
orStelPainter.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?
The text was updated successfully, but these errors were encountered: