It is currently Tue, 19-09-17, 13:22 GMT

All times are UTC




Post new topic Reply to topic  [ 96 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
 Post subject:
PostPosted: Fri, 16-11-07, 23:45 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
t00fri wrote:
OK here it is. Same parameters as previous titan image, except RayleighScaleHeight = 100.0 instead of = 0, previously.



OK. That's a less subtle version the same LUT bug you saw before. It's visible in pixels where:
1. The viewer is inside the atmosphere
2. The line of the view ray doesn't intersect the planet

Without the -l option, I get this:

Image

I'm working on a fix.

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 17-11-07, 2:12 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
I added support for wide-angle cameras so that you can view the effects of scattering across the entire sky. Use -f or --fisheye to get two wide angle views--one at mid-day, one at sunset--instead of the usual four views.

Image

The horizontal field of view in each image is 180 degrees.

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 17-11-07, 9:26 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4495
Location: Hamburg, Germany
chris wrote:
I added support for wide-angle cameras so that you can view the effects of scattering across the entire sky. Use -f or --fisheye to get two wide angle views--one at mid-day, one at sunset--instead of the usual four views.

Image

The horizontal field of view in each image is 180 degrees.

--Chris


Nice, i.e. VERY useful! Chris, could you confirm the definitions of the 4 default images in out.png?

Please note, that in your code the bottom and top images seem to be interchanged! (a libpng effect? Kind of known to me)

So actually, with the incident light direction being along the z-axis, in your out.png image, I conclude
  • botleft is the outer atmosphere as seen from space (3*radius distance) with 20 degs between light source and camera. (low phase)
  • botright is the outer atmosphere as seen from space (3*radius distance) with 110 degs between light source and camera. (high phase). 180 degrees might be even more useful e.g. Titan. So one should take the high phase angle as an external parameter.
  • topleft is the close illuminated atmospheric view (1.2 * radius) with medium phase angle
  • topright is the surface color as appearing due to skylight (given the initial groundcolor = 0.5,0.5,0.5 (gray))


Did you fix the LUT, meanwhile?

I am presently comparing your code with the paper by Nishita et al. and Cornette&Shanks (Appl. Optics).

Why didn't you use the improved Henyey-Greenstein(HG) function including Cornette's corrections for Mie scattering? You apparently took the original HG phase function.
Code:
double phaseHenyeyGreenstein(double cosTheta, double g)
{
    return (1.0 - g * g) / pow(1.0 + g * g - 2.0 * g * cosTheta, 1.5);
}


Unlike the original HG phase function, the good thing about the CS-corrected version is that for g=0 one recovers exactly the Rayleigh phase function. That is however necessary, when the size parameter, a = 2*PI*r/ lambda is significantly
less than one and where r is the particle radius. After all, Mie scattering is the more general framework that must reproduce Rayleigh scattering as a limiting case for a<<1.

I actually have that latter CornetteShamks paper in Applied Optics (it costs money). I modified your code to include the CS-improved phase function. It doesn't take much longer.

I think in the Mie-backscattering strength something is wrong. If I take exactly 180 degs between source and camera, there is very little backscatter independent of the MieAsymmetry parameter! This might be connected with your uncorrected HG-Phasefunction?

I also wonder whether one might better introduce more physical parameters to describe atmospheric scattering, like (using Nishita's nomenclature now)

for molecular scattering (Rayleigh):
----------------------------------------
  • (effective) index of refraction of air n,
  • the molecular density parameter of (standard) atmosphere N_s,
    of course one may directy take 4*Pi8k/lambda^4, but using the individual parameters may be not so bad in various case...
  • the actual (molecular) atmosphere heights instead of the Rayleigh scale height
    The latter can usually be looked up in or estimated from planetary databases.
  • the wavelength lambda of incident light along with parametrizing explicitly the Rayleight 1/lambda^4 constraint into the corresponding RGB colors, etc.
    I think we should stick to a 1/lambda^4 Rayleigh constraint in RGB as long as possible.

for aerosol scattering (Mie)
-------------------------------
  • ...
  • The quantity u -> g(u) determining the asymmetry factor g, u=0.5..1.0
    Is the sign convention of your asymmetry factor in scattersim the same as in Celestia??
  • The actual aerosol atmosphere height


A possibly tricky issue might be the accuracy of the numerical integration of the optical depth. The trapezoidal rule with varying intervals ~ log(rho) might well be satisfactory often but not always. I know from my own experience long ago that due to the exponential variation of the atmospheric density care is necessary. Did you test the accuracies explicitly in your code?? I noted though that you allow for using different numbers of integration steps in the command line.

One quantitative way of checking the similarity of out1.png and out2.png calculated with different step numbers is to compare the two images with the VERY useful tool

'nvimgdiff out1.png out2.png'

identical images give 0, while else appropriate error measures are printed.
from NVIDIA's new texture tools

F.


Last edited by t00fri on Sat, 17-11-07, 16:20 GMT, edited 7 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat, 17-11-07, 11:00 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4495
Location: Hamburg, Germany
Here are a lot of atmospheric data & atmospheric models for Earth and Titan

http://www.markelowitz.com/titan.htm

F.

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 17-11-07, 17:22 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
t00fri wrote:
Please note, that in your code the bottom and top images seem to be interchanged! (a libpng effect? Kind of known to me)


Yes, it's a libpng issue. I'll fix that so the code makes a bit more sense.

Quote:
Did you fix the LUT, meanwhile?


Not yet--I've actually been working on the inscattering LUT, which is what the GLSL shader would eventually use. I'm going see what happens when I switch from an extinction LUT to an optical depth LUT; linear interpolation artifacts are the only thing I can think of that could be causing the problems I'm seeing. Also, I notice that the Schafhitzel paper uses optical depth instead of extinction as well.

Quote:
I am presently comparing your code with the paper by Nishita et al. and Cornette&Shanks (Appl. Optics).

Why didn't you use the improved Henyey-Greenstein(HG) function including Cornette's corrections for Mie scattering? You apparently took the original HG phase function.
Code:
double phaseHenyeyGreenstein(double cosTheta, double g)
{
    return (1.0 - g * g) / pow(1.0 + g * g - 2.0 * g * cosTheta, 1.5);
}



Since the shader must execute quickly, I was anticipating using the Schlick approximation to the original HG phase function. The phase function could be encoded in a 1D texture, but that adds some complexity, since Celestia would have to generate a new texture for each value of g used. Regardless of all that, we should support Schlick, the original HG, and the CS-corrected version of HG in scattersim so that we can compare differences between them. If the visual differences ends up being minimal, we can take the simple approach (Schlick) in Celestia.

Quote:
Unlike the original HG phase function, the good thing about the CS-corrected version is that for g=0 one recovers exactly the Rayleigh phase function. That is however necessary, when the size parameter, a = 2*PI*r/ lambda is significantly
less than one and where r is the particle radius. After all, Mie scattering is the more general framework that must reproduce Rayleigh scattering as a limiting case for a<<1.

I actually have that latter CornetteShamks paper in Applied Optics (it costs money). I modified your code to include the CS-improved phase function. It doesn't take much longer.


Good. Please check in this change, and I'll add a new cfg file parameter to select the phase function.

Quote:
I think in the Mie-backscattering strength something is wrong. If I take exactly 180 degs between source and camera, there is very little backscatter independent of the MieAsymmetry parameter! This might be connected with your uncorrected HG-Phasefunction?


Yes, something is fishy there I agree . . . I'm looking into it.

Quote:
I also wonder whether one might better introduce more physical parameters to describe atmospheric scattering, like (using Nishita's nomenclature now)

for molecular scattering (Rayleigh):
----------------------------------------
  • (effective) index of refraction of air n,
  • the molecular density parameter of (standard) atmosphere N_s,
    of course one may directy take 4*Pi8k/lambda^4, but using the individual parameters may be not so bad in various case...
  • the actual (molecular) atmosphere heights instead of the Rayleigh scale height
    The latter can usually be looked up in or estimated from planetary databases.
  • the wavelength lambda of incident light along with parametrizing explicitly the Rayleight 1/lambda^4 constraint into the corresponding RGB colors, etc.
    I think we should stick to a 1/lambda^4 Rayleigh constraint in RGB as long as possible.


Yes, we should make it easy to create an atmopshere by setting these physical parameters. However, for experimentation, I still want it to be possible to set the derived quantities directly, i.e. the attenuation coefficients due to outscattering and absorption. Especially in Celestia, I don't believe that we should enforce the 1/lambda^4 constraint, in order to allow some flexibility in atmosphere modeling.

Quote:
for aerosol scattering (Mie)
-------------------------------
  • ...
  • The quantity u -> g(u) determining the asymmetry factor g, u=0.5..1.0
    Is the sign convention of your asymmetry factor in scattersim the same as in Celestia??
  • The actual aerosol atmosphere height


Sure . . . although, if we specify an aerosol atmosphere height, how does the density vary with h? Which brings to mind another possibility: rather than simply using exp(-h / H0) for density, we could use a lookup table from some standard atmosphere model. I'm not sure that it's worth the effort given the other simplifications in scattersim (e.g. no multiple scattering), but it might be interesting. For my part, I'm going to focus on getting this all working on the GPU.

Quote:
A possibly tricky issue might be the accuracy of the numerical integration of the optical depth. The trapezoidal rule with varying intervals ~ log(rho) might well be satisfactory often but not always. I know from my own experience long ago that due to the exponential variation of the atmospheric density care is necessary. Did you test the accuracies explicitly in your code?? I noted though that you allow for using different numbers of integration steps in the command line.


The only accuracy tests I performed were visual ones: how do things look with 10 vs 20 integration steps, etc. Since the ultimate aim is producing an image, this seemed adequate, though it would be nice to quantify the the differences.

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 17-11-07, 21:08 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4495
Location: Hamburg, Germany
Chris,

returning from a good weekend dinner, I have just committed my changes, including a much improved titan2.cfg parameter set. It doesn't look all that bad, including backward scattering. You best use a diff tool to find out my changes, where I have also increased the large phase angle from 110 to 160 degrees, to be able to examine better the backward halo for Titan. This angle should best become a command line parameter.. I did not delete your original HG phase function. The new one is called 'phaseHenyeyGreenstein_CS'. I made it the default for now. I added also a routine mu2g() that converts mu= <cosTheta> to g, which is needed for 'phaseHenyeyGreenstein_CS'. It will only be called once. There are some explanatory comments in the new routines.

As to the backward asymmetry, I found the solution. The backward fraction INCREASES with decreasing MieAsymmetry g. There are lots of respective plots in the nice Cornette-Shanks paper in Applied Optics.

-F.

Image


Last edited by t00fri on Sun, 18-11-07, 17:56 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat, 17-11-07, 22:01 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4495
Location: Hamburg, Germany
Here are some of my Maple calculations, clarifying the meaning of the MieAsymmetry parameter <cosTheta> in the HG phase function and its improvement by Cornette-Shanks (CS)

http://www.celestialmatters.org/users/t ... s2/out.pdf

Bye Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 19-11-07, 18:55 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
I've committed an update to scattersim that allows easy switching of the phase function via a cfg file parameter. The parameter is MiePhaseFunction and its value may be one of:

HenyeyGreenstein_CS
HenyeyGreenstein
Schlick

(default is HenyeyGreenstein_CS)

The Schlick phase function is an approximation to HG that is currently used in Celestia. It's more practical to implement in a shader than HG or HG_CS, though faster hardware can deal with the more complex phase functions. And a lookup table lets us get away with with anything we want, with the cost of some added code complexity.

I didn't observe any difference between phase functions with titan2.cfg and the default view set. I don't doubt that differences would be visible at other views or with different parameter sets.


Top
 Profile  
 
 Post subject:
PostPosted: Mon, 19-11-07, 21:01 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4495
Location: Hamburg, Germany
Chris,

very well!

I have compiled the new update, looked at the code and am playing a bit. I think it makes sense to use the CS-improved phase function in scattersim and then to try and pin down possibly VISIBLE differences to the more economical approximations. I certainly can see differences via the 'nvimgdiff' tool.

One IMPORTANT issue is the size of the BACKWARD intensity peak. As you can see from the plots of the CS paper (or my Maple file) , the backward Mie intensity varies significantly among the different phase functions. Since the backward halo is a most conspicuous signature for TITAN, I consider this issue very important.

Let me know what you want to focus on with the new HDR switch?? -e 2.0 seems a good start. Any config where the HDR effects are dramatic?

Another field where the scattersim code can bring deeper insight is a more detailed understanding of the Mars sunset pattern vs the daylight sky pattern. As a reminder:

Image

while

Image

These are very good photographic images and the drastically different sky is not easy to simulate. Certainly not in Celestia 1.5.0CVS. Also note the shape of the blue region ABOVE the setting sun! The transition to that orange daylight sky seems pretty hard as well.

All this looks pretty interesting and challenging ;-)

Bye Fridger

PS: compare with what I get in Celestia 1.5.0CVS. The blue is below the brown! NOT ABOVE the setting Sun.

Image


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 10-04-08, 10:19 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4495
Location: Hamburg, Germany
Hi,

let me return to some very impressive fast calculations of atmospheric effects by Yoshinori Dobashi, Tsuyoshi Yamamoto, Tomoyuki Nishita.

Here is their algorithm of how to render efficiently lightnings taking into account scattering effects due to clouds and atmospheric particles.

http://nis-lab.is.s.u-tokyo.ac.jp/~nis/ ... htning.pdf

most impressive, the following animation:

Imagine you are landing on the surface of Venus ... ;-)

Amazing Thunderstorm Simulation mpeg (3Mb)
Image

Another interesting discussion based on Display of the Earth taking into account atmospheric scattering by Tomoyuki Nishita et.al.,
is here:

A Display Method of the Sky Color on GeForce FX hardware

...and this one

Real Time Rendering of Atmospheric Scattering Effects for Flight Simulators

Enjoy,
F.


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 02-09-08, 1:28 GMT 
Offline
User avatar

Joined: Sat, 13-10-07, 18:18 GMT
Posts: 373
Just a quick note to warn others about the potential for problems when using the Mie parameters within an existing
planet definition...

I had a really nice Mars Cloud texture go BLOOEY! after I applied the Mie settings which were suggested
for Mars. I started noticing a rather marked and very severe artifact in Mars' atmosphere after I added the Mie Parameters
to the Mars cloud texture package I have listed on my home page.

After I played with the these parameters a bit, I discovered that the use of the MieScaleHeight element
was causing this severe artifact to be developed while viewing the atmosphere of Mars.

When I simply removed only this part of the Mie definition, the artifact disappeared. Now, you all know that I am no genius, so
I may have simply used a value which was incompatible with the others defined in my add-on.

At any rate, I just thought I'd post this message as a warning in case someone else runs into this problem.
The artifact created was a rather extreme set of zigzagged cloud textures which completely ruined an
otherwise fairly beautiful atmospheric rendition on Mars.

Thanks and Just FYI... Brain-Dead


Last edited by BobHegwood on Tue, 02-09-08, 18:56 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue, 02-09-08, 7:43 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2726
Location: France, South, not far from Montpellier
Perhaps it's a bug so if you give the guilty Mie setting and a screenshot, it could help to see if there is a solution or not to your problem...


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 02-09-08, 13:55 GMT 
Offline
User avatar

Joined: Sat, 13-10-07, 18:18 GMT
Posts: 373
ElChristou wrote:
Perhaps it's a bug so if you give the guilty Mie setting and a screenshot, it could help to see if there is a solution or not to your problem...

Okay, here's the deal as illustrated below...

First, the error occurs when the MieScaleHeight parameter is set to 20 or below:
Image

This is Mars when the MieScaleHeight parameter is set to 30:
Image

And this is Mars displayed with the MieScaleHeight directive removed entirely from the SSC:
Image

Also, if I increase the MieScaleHeight parameter above 30, the atmosphere expands outward from the
planet until it is entirely dissociated from the planet. In other words, see the image below with
MieScaleHeight: set to 220:
Image

Just for information here...
So exactly how does one determine the appropriate settings for the Mie parameters?


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 02-09-08, 14:03 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2726
Location: France, South, not far from Montpellier
Indeed that's odd... For the scattering parameters, I think only Fridger or Chris (L.) can explain you but it also depends on how you want your atmosphere to react.
Perhaps you should post this as a bug report at Shatters...


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 03-09-08, 10:52 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 991
Location: NE PA, USA
It looks like the mesh for the cloudmap is interfering with the mesh for the atmosphere. You can probably lower your CloudHeight if you want to keep MieScaleHeight at 20.
cartrite


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 96 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group