Celestia Forums

Here's a video of some work I've been doing on using precomputed atmospheric scattering textures to produce much more realistic renderings of planets with atmospheres:

http://www.youtube.com/watch?v=vSNgxvshR6o

Note that there's no cloud layer texture in the video; the planet surface is hidden by atmosphere and nothing else.

The approach is similar to that used in the scattersim utility in the Celestia tools folder except that the rendering is performed on the GPU. Clever parameterizations are required to pack all the required tables into reasonably sized 3D textures for OpenGL. Some of the improvements over the techniques in scattersim were suggested in a paper by Eric Bruneton and Fabrice Neyret:

http://www-ljk.imag.fr/Publications/Bas ... rticle.pdf

As Fridger mentioned, the current implementation of atmospheric scattering in Celestia is simplified in order to run in real-time. Celestia's approximations unfortunately don't work very well with optically dense atmospheres like those of Titan and Venus. A workaround is to calculate most of the scattering integrals ahead of time and store the results in large 3D textures (about 1MB per atmosphere). So, you trade some flexibility for greatly improved rendering quality.

--Chris

Chris,

looks like a good start. But what does one see on a flight through that type of atmosphere, possibly down towards a landing site?? I am first of all thinking of Titan's atmosphere, of course, which is exciting and challenging at the same time...

I'll study that paper you quoted. Thanks!

F.

t00fri wrote:Chris,

looks like a good start. But what does one see on a flight through that type of atmosphere, possibly down towards a landing site?? I am first of all thinking of Titan's atmosphere, of course, which is exciting and challenging at the same time...

I'll post another video showing a surface-to-space transition. It looks good except that the ground is quite dark, which is what you'd expect if Titan's atmosphere is attenuating 95% (or more?) of the direct sunlight.

Here are a couple images of Earth using the same scattering code with different coefficients and scale heights. The base texture is the Blue Marble May texture. The Rayleigh scattering coefficients are computed from the index of refraction of air and the molecular density at ground level. I've used realistic values for a temperature of 15C. Unlike with the Titan movie, there's been no fiddling with parameters to get an image that looks right. Physically correct values simply produce the right image.




--Chris

I agree, the consistent determination of the coefficients from known physical data is a VERY nice feature. Also your Earth images look pretty interesting.

Since the colors of the BMNG surface texture are reduced to ZERO atmosphere (see paper), the good overall result above looks really encouraging: the Mie scattering of light in the atmosphere just produces the right kind of color corrections.

F.

An image of the Titan-like atmosphere:



Mars:
The horizon is probably too bright. I'm having a hard time finding information on the properties of Mars's atmosphere (such as the phase function of the atmospheric dust), so parameters I'm using are the result of trial and error rather than being physically derived.
http://www.youtube.com/watch?v=fRzopzZRKA0


Venus is tricky...

--Chris

Chris,

how about a physics-observable-related determination of the parameters responsible for backlit Titan rendering, e.g. like mine here (with Kraken Mare)?



The parameters responsible for the backlit atmosphere rendering (colors, transparency, vertical extension, density profile...) are not so easy to "dial" by trial and error, actually.

How about some patch for more effective studies?

F.

I now read (and understood) the above paper on Precomputed Atmosphere Scattering. Moreover I studied the many videos, source codes etc on Eric Bruneton's Website

http://evasion.inrialpes.fr/~Eric.Bruneton/

All this is really interesting stuff. I'll certainly devote more time to this atmosphere approach and to the many related projects on that site.

To make real progress for Celestia (or Celestia.Sci ), forming a respective small "taskforce" dev team that explores the vast possibilities more explicitly, would be phantastic... But unfortunately I can't see many in our community with the appropriate physics AND coding backgrounds...

F.

PS: How about moving this advanced atmosphere talk to a proper location!?

t00fri wrote:PS: How about moving this advanced atmosphere talk to a proper location!?

Done!

As for a patch, I'm working on it... The videos were generated with a standalone program, not Celestia. Fortunately, the shader to apply scattering isn't that complicated. Generating the scattering tables is more effort than using them. And there were a lot of numerical issues to work out, mostly balancing numerical precision with storage requirements and choosing the right parameterization for scattering and transmittance table indexes.

Note that my scattering table generator does not currently support multiple scattering. It also ignores the angle between the viewer and sun; this is deliberate, as this enhancement requires using a 4D table that is at least eight times larger than 3 parameter scattering table.

--Chris

This looks pretty good, definitely nice to see this kind of feature. How does this interact with HDR techniques?

ajtribick wrote:This looks pretty good, definitely nice to see this kind of feature. How does this interact with HDR techniques?

Realistic scattering definitely benefits from HDR. Asymmetric scattering phase functions produce a large range of values. Without some careful mapping to 8-bit framebuffer values, you can easily end up with scenes that are too dark or overexposed. The images and videos that I've posted are not using HDR, and you can see where there are overbright areas near the horizon.

--Chris

This screenshot shows how specular highlights are affected by outscattering. Rayleigh scattering preferentially scatters short wavelengths so sunlight arriving at an oblique angle appears noticeable redder.



--Chris

chris wrote:This screenshot shows how specular highlights are affected by outscattering. Rayleigh scattering preferentially scatters short wavelengths so sunlight arriving at an oblique angle appears noticeable redder.

sunrise-glint.png

--Chris

Nice!

Note that my scattering table generator does not currently support multiple scattering. It also ignores the angle between the viewer and sun; this is deliberate, as this enhancement requires using a 4D table that is at least eight times larger than 3 parameter scattering table.

Well, ignoring multiple scattering is fine for daylight, but NOT for sunrise/sunset, since then the sunlight traverses much more atmosphere than during the day.

Since I have only VERY limited knowledge at this time about what is contained in your present test code, and notably what is still missing compared to the paper, it would be great if we could find some methodical improvement here. Either I start hacking my own testbench together from the given sources etc or we use your code as a starting point along with some more concise description of the physical contents?

Also which shader language should we adopt? I don't mind really. For my entirely new (colored) galaxy code for Celesta.Sci, I practiced quite a bit with the old ARB assembly (ARBvp1.0), but using GLSL would be more handy and matching what the INRIA people used...

The first thing I did quickly so far was to port Eric Bruneton's PrecomputedAtmosphere code to my Linux desktop environment, which required a few different/additional includes and the appropriate libs.

F.

t00fri wrote:

Note that my scattering table generator does not currently support multiple scattering. It also ignores the angle between the viewer and sun; this is deliberate, as this enhancement requires using a 4D table that is at least eight times larger than 3 parameter scattering table.

Well, ignoring multiple scattering is fine for daylight, but NOT for sunrise/sunset, since then the sunlight traverses much more atmosphere than during the day.

Yes. The single scattering limitation is only temporary. Note that there is no change to the program displaying the planet is necessary in order to incorporate multiple scattering. It's just the tables that have to change.

Since I have only VERY limited knowledge at this time about what is contained in your present test code, and notably what is still missing compared to the paper, it would be great if we could find some methodical improvement here. Either I start hacking my own testbench together from the given sources etc or we use your code as a starting point along with some more concise description of the physical contents?

I'm working to get the code for the scattering and transmittance tables into shape for sharing and also on creating a patch for Celestia that will allow loading and using the tables. It will take a couple more days.

Also which shader language should we adopt? I don't mind really. For my entirely new (colored) galaxy code for Celesta.Sci, I practiced quite a bit with the old ARB assembly (ARBvp1.0), but using GLSL would be more handy and matching what the INRIA people used...

GLSL without question. Celestia uses GLSL exclusively in it's OpenGL 2.0 path, and GLSL is much easier to write than the shaded assembly. I don't think there's any advantage to the assembly style code at this point.

In case you happen to be using older hardware... My code uses half precision (16-bit) floats for the scattering table, as does Bruneton's. I'm not sure that this will work on pre-dx10 GPUs--while these older GPUs supported half float textures, I don't think they work in 3D textures. 8-bit per component textures mostly work, but they do exhibit some banding artifacts.

--Chris



--Chris

Nice images Chris... I'm particularly interested in this feature.

chris wrote:Yes. The single scattering limitation is only temporary. Note that there is no change to the program displaying the planet is necessary in order to incorporate multiple scattering. It's just the tables that have to change.

Wouldn't it be methodically preferrable to start from the best possible Mie rendering (<=> paper, 4D table,...) and then successively implement further approximations to improve on speed? This way one could first judge explicitly, how the best quality rendering with Bruneton's method looks like and how slow/fast it would be.

Incidentally, when I wrote various research papers related to the Mie series many years ago, its partially poor convergence was already well-known.

The worst problem actually was the oscillatory behaviour, when many terms are involved in the usual Legendre polynomial expansion of the Mie sum. Mathematically, the recipe for a dramatic convergence improvement (depending on wavelength and droplet size!), consists in specific resummation techniques that are also more suitable for approximations (e.g. saddle point integration <=> geometrical optics rays...) . The resummation I (and other authors) explored in particular was the so-called Sommerfeld-Watson transform that has actually many further useful applications.

Generically, the SW-transform first replaces the infinite Mie sum by a complex contour integral based on the calculus of residues (Cauchy theorem):

with this contour in the complex lambda plane:

So far, this is an EXACT relation. However, the main point is that it is MUCH easier to derive various accurate approximations from such type of (NON-oscillatory) )integral representations compared to the original discrete Mie sum.

In a second step, one deforms the above closed contour appropriately, to pick up the dominant (resummed) contribution, once more including a (different) sum of residues. The remainder is a small "background" integral (with contour parallel to the imaginary lambda axis) that can be usually neglected!! The leading term even includes subtle diffractive effects near the shadow boundaries etc. Notably, one has quantitative control on the regime where this resummation is highly economical. Of course in the simple Rayleigh regime (where I ~ 1 + cos(theta)^2 just involves TWO lowest order Legendre polynomials P_l(cos(theta)) ), all this is surely not necessary.

Probably, you can easily google some more info about that technique in the web if you have never heard of it before.

I'm working to get the code for the scattering and transmittance tables into shape for sharing and also on creating a patch for Celestia that will allow loading and using the tables. It will take a couple more days.

OK, then I'll wait for your patch.

In case you happen to be using older hardware...
...

Yes, I indeed encountered some runtime problems after loading Bruneton's various .glsl shader files...I can always work remotely on my office machine that has a at least a 9300 nvidia card.

Fridger

t00fri wrote:Chris,
how about a physics-observable-related determination of the parameters responsible for backlit Titan rendering, e.g. like mine here (with Kraken Mare)?

I corrected a bug while cleaning up the code. Now, backlit Titan is looking OK:



This is with the Henyey-Greenstein phase function, g=0.6.

--Chris

Now that is impressive.

chris wrote:

t00fri wrote:Chris,
how about a physics-observable-related determination of the parameters responsible for backlit Titan rendering, e.g. like mine here (with Kraken Mare)?

I corrected a bug while cleaning up the code. Now, backlit Titan is looking OK:

titan-ring.png

This is with the Henyey-Greenstein phase function, g=0.6.

--Chris

I wonder why the color is so yellow/orange in your new backlit display?

Here is the imaging "data" that I used for tuning before this new atmosphere stuff started: The image below was reconstructed from 3 R,G,B - filtered CICLOPS raw images by our old Celestian Matt McIrvin:



The somewhat purple color is pretty well reproduced by my Mie parameters (see above)

Fridger

Beautiful colours there Fridger.

Perhaps for those of you who are not following the technical details of our atmosphere discussion, here are some great videos by Eric Bruneton, whose atmosphere work is underlying our present discussions:

Real-time planet rendering II
------------------------------------
http://www.google.com/url?sa=t&source=v ... MdXmjNYVvA

Real-time planet rendering
------------------------------------
http://www.google.com/url?sa=t&source=v ... 9CJQbv-WYQ

Real-time planet rendering III
------------------------------------

http://www.google.com/url?sa=t&source=v ... kIkOSXlQiQ

Real-time ocean rendering and lighting
----------------------------------------------------
http://www.google.com/url?url=http://ww ... m_ZJZns4Ng

Real-time planet rendering IV (ocean)
----------------------------------------------------------
http://www.google.com/url?sa=t&source=v ... OJXqRP8XFw

Real-time planet rendering IV (Editing)
----------------------------------------------------------
http://www.google.com/url?sa=t&source=v ... QOVALyOmHQ


And last not least, a MOST beautiful video: Rendez-vous with Rama
3D animation of a spacecraft freely inspired from the book "Rendez-vous with Rama" from Arthur C. Clarke. Switch on your sound!

++++++++++++++++++++++++++++++++++
Rama
======
http://www.google.com/url?sa=t&source=v ... xhfwQxxpkw
+++++++++++++++++++++++++++++++++++
Enjoy,
Fridger