Implementing a new atmosphere model

[10110111]

Moving discussion started in #623 here.

looking forward to seeing this side-to-side with my timelapse photos!

Are they published anywhere? Would be interesting to compare the model with real-world photos.

You could allow many user tweaks as well (with a reset to useful defaults!).

This has an issue. Namely, the precomputation stage is quite resource-hungry: on my nVidia GeForce GTX 750Ti it takes several tens of seconds to precompute the necessary textures, yielding 128MiB main texture when I set up constants for a decent resolution (otherwise deep twilight is blocky in azimuth and jumpy in time, see this animation; if you don't notice jumpiness, try watching it in a lower speed).

Moreover, until I added a couple of glFinish calls in my fork of PAS (branch "stellarium"), precomputation made my X11 session unusable (frozen mouse cursor etc.), and sometimes locked up X server indefinitely. Also, sometimes the results were garbage (e.g. missing red channel — I suppose this is due to some nvidia driver bugs, but might be races in the implementation).

Also, since a decent-resolution main texture is at least 128MiB, precomputation stage takes multiple times that amount of VRAM, so this looks unfriendly to mobile devices.

So, I'm not sure if we really want the user to have an option to change parameters from within Stellarium GUI.

But please make it switchable (old/new) in the config dialog.

Well, if you insist, OK. Currently my WIP atmosphere branch of Stellarium simply hacks into class Atmosphere.

And if the new model allows (no time to go into details), think of conditions on other planets (Mars?).

This might well be possible, but for each new planed we need its own profile of atmospheric density, scattering&absorption cross-sections, Mie scattering phase functions (based on a sensible particle size distribution) etc.. With this data we can indeed try to precompute corresponding textures (maybe increasing number of orders of scattering).

[10110111]

OK, I've found the reason for abrupt color changes I got from your raw files (see my answer in the link above). With this fixed, chromaticity of a small rectangle near the horizon changes almost continuously. I've made a new animation. There still remains the orange patch moving from horizon towards zenith right before the Sun rises. I'm not sure what it is, but my hypothesis is that this is very thin uniform (cirrostratus?) clouds being highlighted by the Sun.

[gzotti]

you mean different gammas? Possible. Unfortunately the video is too fast for me to clearly see what you mean. Today Win10 brought a nice login image that shows "ocean twilight".
https://www.bing.com/images/search?view=detailV2&ccid=NSlS78GQ&id=2DE533EEF06C4D4D43EA147BEA0842513BE3CFF9&thid=OIP.NSlS78GQatDb1a3tzwBeIwHaE8&mediaurl=https%3a%2f%2fwherewouldyougo.com%2fwp-content%2fuploads%2f2017%2f10%2fUmhlanga-pier-Durban-South-Africa.jpg&exph=600&expw=900&q=Umhlanga%2c+KwaZulu-Natal%2c+S%c3%bcdafrika&simid=608052636362998465&selectedIndex=47&ajaxhist=0

[10110111]

you mean different gammas?

No, different color temperature coefficients saved in the RAW file.

[alex-w]

Any news for new model?

[10110111]

I'm slowly progressing forward. What I'm currently developing is the approximation for solar eclipse. It's much harder to calculate due to broken cylindrical symmetry of the system (the symmetry would only be preserved for eclipse in subsolar point, which is quite rare; e.g. July 1991 or June 2132), so needs some care to do well.

[gzotti]

Great to read. I can provide a movie of the horizon with the black "shadow wall" approaching from 2017-08-21 if that helps. And maybe some fisheye shots from 2006-03.

[10110111]

If you have all-sky photos with the shadow bands, this would definitely help validation. Currently I can only compare with home-grown Monte Carlo scattering simulator:

But if the horizon movie is all you have, that can also be useful.

[gzotti]

Looks interesting, however there seem to be two darkest areas along the horizon (?). OK, I will dig out the pictures tomorrow.

[10110111]

however there seem to be two darkest areas along the horizon

Yes, the Sun here is 10° above the horizon, so the shadow band goes from roughly the solar azimuth (bottom) to antisolar (top).

[gzotti]

Alright, look here. https://1drv.ms/f/s!AuJ_d8wlPcFpikv-9oamV7bB5p3g

The fisheye shots were intended to create a HDR series. However, the tethered system crashed just during totality, so there is only one usable totality shot (series). I had an ND filter in the fisheye lens, not sure whether this caused the two "solar companions". Venus is visible in the lower right of the sun.

The movie has been taken with a Canon PowerShot G15 during the 2017 eclipse near Rexburg, Idaho, USA. It gives a pretty good record of the appearance of the shadow on the horizon and ground.

Please confirm when you have downloaded.

[10110111]

Thanks, I've downloaded these.

the tethered system crashed just during totality

Sad. Reminds me of the story by an eclipse watcher in Antarctica, who says:

The anti-solar shadow was huge and black all the way to the horizon, I wish I could have gotten a picture of that (the camera died due to cold).

Now, regarding this:

I had an ND filter in the fisheye lens, not sure whether this caused the two "solar companions".

I wonder how you even managed to cover the whole 180° FOV with a filter. Was it an internal one? Anyway, I suppose that not only the two "companions" were added by it, but also the radial lines, right? In any case, this doesn't seem to be a halo :)

Venus is visible in the lower right of the sun.

Interesting, wouldn't've noticed it, especially among the noise.

It gives a pretty good record of the appearance of the shadow on the horizon and ground.

Indeed, a good view of the shadow. I didn't think it would be so dark above the horizon, to about 1 or 2 degrees. My simulations currently fail to reproduce this. I suspect this might be due to clouds, which I don't take into account at all.

[gzotti]

Sad. Reminds me of the story by an eclipse watcher in Antarctica, who says:

The anti-solar shadow was huge and black all the way to the horizon, I wish I could have gotten a picture of that (the camera died due to cold).

Maybe it was too hot in my case (Sahara?) I was not able to identify the real cause.

Now, regarding this:

I had an ND filter in the fisheye lens, not sure whether this caused the two "solar companions".

I wonder how you even managed to cover the whole 180° FOV with a filter. Was it an internal one?

Yes, "inside". There was a cel filter holder. Therefore I also could not take it off...

Anyway, I suppose that not only the two "companions" were added by it, but also the radial lines, right? In any case, this doesn't seem to be a halo :)

No halo. Of course, all these radial lines are probably caused by this filter (with an HDR scene these burnt-out parts should be neglected.)

Venus is visible in the lower right of the sun.

Interesting, wouldn't've noticed it, especially among the noise.

It gives a pretty good record of the appearance of the shadow on the horizon and ground.

Indeed, a good view of the shadow. I didn't think it would be so dark above the horizon, to about 1 or 2 degrees. My simulations currently fail to reproduce this. I suspect this might be due to clouds, which I don't take into account at all.

Observe the development in the movie. Quite likely the effect of "approaching black wall" is also caused by dust which is densest just above the ground. And it should be only one dark zone, approaching or vanishing. The totality series in Libya was at the beginning of totality, so that the shadow was not yet centered on us. it approached from the lower edge, so that is darker. I still don't understand your two darkest spots.

[10110111]

See this photo. Imagine yourself in the center of this shadow. You'll see two dark directions: the solar and anti-solar ones.

[gzotti]

Ah, thanks. I had not considered such low sun.

[gzotti]

https://1drv.ms/f/s!AuJ_d8wlPcFpil6dBJGLXhE5nr6W contains my 3 shots from 2008. This time no filter, and no partial phase series or attempts towards HDR. Please again see GPS info in the EXIF for location and time.

[10110111]

Thanks. Here the asymmetry of the horizon luminance with respect to the solar/antisolar azimuth is quite apparent. It's an interesting effect: this lets us see that the Moon disk is shifted a bit from the center of the Sun disk — to the darker side. And then checking in Stellarium with the date, time and position confirms it. It's one of the problems for precomputation of the eclipsed atmosphere: position of the Moon WRT the Sun is two more degrees of freedom which would make the Bruneton's 4D texture become 6D.

I suppose you don't have a raw version of these? And, BTW, the previous set of images didn't contain any GPS info, although they seem to have been taken by the same model of camera. Is it something you added manually into these JPGs?

[gzotti]

Phew, 6D sounds immense. I think most users will be more than happy with a circular or single-asymmetric solution else based on the Bruneton model.

I should have the CR2, somewhere. In those days I archived them separately on DVD-RAM...

After 2008, I used GeoSetter to add GPS info recorded with a GPS logger. (This failed a month ago, but now there are smartphone apps for that...) GeoSetter uses ExifTool to write metadata into the CR2.

[ghost]

Ah, thanks. I had not considered such low sun.

i want new atmosphere on stellarium web

[gzotti]

@ferreiradantas6 consider https://github.com/Stellarium/stellarium/wiki/FAQ#why-dont-you-implement as answer. This project is made by very few people in their spare time. I would very much like to see the new model myself somewhere within a year or so, but you cannot force this. Please stop flooding this thread. And consider Ruslan's answer about heavy textures as very likely. Come back next year for a recheck.

[ghost]

i want new atmosphere on stellarium web

[gzotti]

Stop trolling! This is not even the place to suggest anything in Stellarium Web. We have understood you want it. I also want it. Everybody who has seen it likely wants it. Stop wasting our time with your whining.

[WAUthethird]

@gzotti Report the guy.

[ghost]

i want new atmosphere on stellarium web please build to me on stellarium web i m working

[gzotti]

@gzotti Report the guy.

Yes, I also saw no other way. Not reported but we have silence for 30 days.

[ghost]

i want new model of atmosphere please stellarium build to me on stellarium web this new atmosphere is beautiful i want

[10110111]

@fereiradantas8 please can you stop flooding this issue? Or I think someone will lose their patience and finally report you.

[xalioth]

Hi 10110111,

I also read the excellent code from PAS, and the rendering is just incredible, not only for atmosphere colors but also for clean multi-band extinction computation etc.. I was investigating how to make this work in Stellarium Web and indeed the pre-computation time (or large file loading) is really nasty.

I saw in the test code that the author implemented a lazy CPU version of the data, which is then computed on the fly & on demand instead of pre-computed. It could be an option to use such a lazy CPU version instead of GPU fragment shader version. Especially if we stick to the current basic grid with only a few points computed.

What do you think?

Fabien

[10110111]

Current progress in making the full version with precomputation can be seen in this repo. At this point, the largest part—precomputor of non-eclipsed textures—is completed. Remaining steps include writing actual rendering code and adding support for eclipses, as well as several minor points. Their status is tracked in the README of the above linked repo.

[10110111]

Status update:

• The generator of textures and shaders has been renamed to CalcMySky;
• There is now a previewer utility, called ShowMySky, that can visualize the output of the generator (currently only displays in equirectangular projection);
• Single-scattered eclipse can now be rendered by the previewer. Multiple scattering and zero-order scattering are planned.

[Atque]

@10110111 Would it be possible to link light pollution of the new model to SQM readings? So that 22.00 mag/arcsec² would correspond to a perfectly dark sky, 21.00 mag/arcsec² would be Bortle 5, and so on? The light pollution currently used in Stellarium is not physical, as far as I know.

[10110111]

Would it be possible to link light pollution of the new model to SQM readings? So that 22.00 mag/arcsec² would correspond to a perfectly dark sky, 21.00 mag/arcsec² would be Bortle 5, and so on? The light pollution currently used in Stellarium is not physical, as far as I know.

The new model will use avarage ground luminance (in cd/m²) as input, because it's a natural quantity for the calculations.

Note that luminance of light-polluted sky does depend on elevation above horizon, so if we use a single value for sky luminance as input, we need to know from what direction it was obtained. It might be from zenith, or maybe average over the whole sky dome. Knowing this, we can just fit the ground luminance to get corresponding result.

[ghost]

Seria possível vincular a poluição luminosa do novo modelo às leituras SQM? Então, 22,00 mag / arcsec² corresponderia a um céu perfeitamente escuro, 21,00 mag / arcsec² seria Bortle 5 e assim por diante? A poluição luminosa usada atualmente no Stellarium não é física, pelo que eu sei.

O novo modelo usará como entrada a luminância média do solo (em cd / m²), por ser uma quantidade natural para os cálculos.

Observe que a luminância do céu poluído pela luz depende da elevação acima do horizonte, portanto, se usarmos um único valor para a luminância do céu como entrada, precisamos saber de qual direção ela foi obtida. Pode ser do zênite ou talvez da média em toda a cúpula do céu. Sabendo disso, podemos apenas ajustar a luminância do solo para obter o resultado correspondente.

Status update:

• The generator of textures and shaders has been renamed to CalcMySky;
• There is now a previewer utility, called ShowMySky, that can visualize the output of the generator (currently only displays in equirectangular projection);
• Single-scattered eclipse can now be rendered by the previewer. Multiple scattering and zero-order scattering are planned.

teach me how it implement it

[gzotti]

@10110111 I am very sorry the tone mapping issue took so long. We now have both options, and the old sky model is user accessible for experiments. New GUI elements allow tweaking Skylight and tone mapping. I hope your work can be integrated in this new infrastructure.

[10110111]

I want to understand how it's done

All the relevant explanation is here.

[gzotti]

(This is our well-known Brazilian troll.)

[10110111]

Status update:

• Support for eclipses is finished. There are 4 modes of quality, highest two of them (modes 2 and 3) are more realistic but very demanding on the GPU: ~1 FPS on GeForce GTX 750Ti, ~4.5 FPS on GTX 1050. Lowest (mode 0) is just like the non-eclipsed case but with lower brightness (similar to how Preetham model does it). Mode 1 uses precomputed double scattering textures at ~13 FPS on GTX 750Ti.
• Light pollution, although I thought it to be completed, appears to look too unrealistic: I calculated it using a model where the whole Earth's surface glows, and this gives too much luminance near the horizon. This will have to be redone, taking into account a finite city size.
• One can check it out from my showmysky branch.
• I changed AppVeyor and GitHub CI scripts to be able to build Stellarium using ShowMySky library, which works fine at least on Windows. An artifact to download can be found here. (Note that artifacts are stored for 1 month only on AppVeyor.)
• A binary package for CalcMySky (which includes the ShowMySky library) can be found here. You'll need to copy ShowMySky.dll into the installation directory of Stellarium for it to be found.
• After installing, follow the instructions here to generate a set of textures. Then, in the Stellarium interface, navigate to the Atmosphere Details dialog from the View dialog, and choose ShowMySky visual model. There, choose path to data to be the same as you passed to calcmysky when generating. If everything goes well, you should see the new atmosphere.
• Currently there's no failure indication in the GUI. You need to check logs if something fails.

[10110111]

Oh, forgot to say: if you do try my showmysky branch, don't forget to setup the tone reproducer to the correct way of application of gamma. I don't force it in the code yet.

(this is no longer needed in the updated links in the previous message)

[Atque]

@10110111 Could you provide generated textures? I can't get CalcMySky to work, it fails at computing radiation from the ground.

What is the plan? To include a set of textures in the installation of Stellarium, or to let users generate textures using CalcMySky?

[10110111]

The minimal set of uncompressed textures (without precomputed eclipsed double scattering) is 517M in size. The idea was to provide them with Stellarium, possibly as a separate download. But to alter the parameters the users will have to regenerate the textures.

I'll have to think how to provide them for now.

I can't get CalcMySky to work, it fails at computing radiation from the ground.

What error do you get?

[gzotti]

I just ran it. Textures are 1.62GB. We cannot pack this into the distribution. However, the chapter of Stellarium's sky model in the User Guide can of course instruct our users to download and run CalcMySky to create the atmosphere data in their user data directories. Maybe you could also create a plugin from the command-line tool, many users prefer button clicks over command lines. It would help a lot to discuss 2-5 "typical" atmospheres with their constituents. (Lowland dry, humid, mountain, seascape, densely-populated, ...)

I am just playing with ShowMySky.

• Wow, the view is superb!
• Uh, finally I have a reason I would upgrade from my 2fps 960M :-) Can you estimate what is so computationally demanding, would a 3090 perform better, i.e. over 30fps?
• OK, without eclipse shaders framerate is >50fps, that's much better ...

[Atque]

What error do you get?

It says Computing scattering density layers for radiation from the ground... FAILED: Invalid operation. I guess I'm doing something wrong? Using your sample.atmo as input.

[10110111]

@gzotti

Can you estimate what is so computationally demanding,

Computationally demanding mostly is the computation of single scattering for lots of locations to estimate double scattering. This can't be feasibly done in advance, so we have to do it for a very coarse grid of points on the fly. This is why I've implemented mode 1 in Stellarium where this estimation is precomputed only for totality phase of the eclipse for each solar=lunar elevation (and saved to texture; this is the longest part of calcmysky run), and the rest is achieved by interpolation.

would a 3090 perform better, i.e. over 30fps?

GTX 1050 is at 4.5 FPS, so unless 3090 is more than 7× faster than 1050, it wouldn't achieve 30 FPS.

@Atque

No, it doesn't mean you're doing something wrong. Something is going wrong with the interaction of my OpenGL code with your GPU driver. Could you paste the first 4 lines of the output? They give some info about OpenGL. Also, what is your OS?

[Atque]

@10110111 The first 4 lines say Writing parameters to output description file... done OpenGL vendor : ATI Technologies Inc. OpenGL renderer: AMD Radeon RX 5700 XT Working on wavelengths 360, 391.333, 422.667, 454 nm (set 1 of 4):

I'm running Windows 10 64-bit, OpenGL 4.6.

[gzotti]

OK, I can reach one 3090GTX over RemoteDesktop. In eclipse mode, it says 8-12 fps. Else 157 and more. I know, RemoteDesktop may make things worse. But yes, this seems to be a computationally serious task :)

I have not again built your Stellarium branch. Would that mean we can have, on "average" systems, a sky which renders e.g. 1 fps and the rest of Stellarium keeps running at higher rates, or would that limit the final interaction and simulation framerate? At least in the latter case, we need a hotkey action to switch between eclipse and regular mode. (But this is hopefully a tiny issue compared to the work you have done!)

[10110111]

Would that mean we can have, on "average" systems, a sky which renders e.g. 1 fps and the rest of Stellarium keeps running at higher rates, or would that limit the final interaction and simulation framerate?

During an eclipse we'll have 1FPS for all the interactions, including GUI.

But in any case, the default quality mode is set rather low, so that, although less realistic simulation will be done, frame rate will be comparable to non-eclipsed case. Only if the user specifically chooses higher quality will the frame rate drop. If this drop is too large, there always remains the option of pressing ArrowDown key in this dialog to lower this spinbox value.

[10110111]

@Atque

I've posted a small version of the dataset on my Google Drive. It's a 412MiB download, 517MiB extracted. This dataset doesn't include eclipsed double scattering textures, so quality level 1 will be the same as level 0. Higher quality levels 2 and 3 work as usual.

[Atque]

@10110111 Thanks a lot for that link. I get about 3 FPS when rendering multiple scattering during solar eclipses, and my GPU is considered a pretty decent one.

Otherwise the view is absolutely breathtaking. Great work!

[10110111]

I get about 3 FPS when rendering multiple scattering during solar eclipses

Was it via Stellarium or in showmysky previewer?

[Atque]

Was it via Stellarium or in showmysky previewer?

Stellarium, but I get the same framerate in ShowMySky. Disabling multiple scattering in ShowMySky gives an FPS of about 150.

[10110111]

Great, so Stellarium version works for you! That's what I wanted to know :)