Atmospheric scattering, with terrain shader preview

[Thorsten]

I've tinkered a bit with the shader in order to see if I could improve the behaviour for lower visibility such that not so much black and yellow stuff becomes visible. My basic idea was to basically keep the color found at the horizon also below. I haven't really succeeded with that so far, but I think I have addressed another problem that has been bugging me - the white-out at the horizon when the physics says the light is white, but the eye wouldn't actually perceive it as such.

By inserting

Code: Select all

vec3 white = vec3(1.0,1.0,1.0);

float scale = dot(normalize(white),normalize(color));
color = (1.0 - (0.6 * scale * scale)) * color;


into the fragment shader (such that skydome.frag now reads)

Code: Select all

#version 120
 
// Atmospheric scattering shader for flightgear
// Written by Lauri Peltonen (Zan)
// Implementation of O'Neil's algorithm
 
varying vec3 rayleigh;
varying vec3 mie;
varying vec3 eye;
 
float miePhase(in float cosTheta, in float g)
{
  float g2 = g*g;
  float a = 1.5 * (1.0 - g2);
  float b = (2.0 + g2);
  float c = 1.0 + cosTheta*cosTheta;
  float d = pow(1.0 + g2 - 2.0 * g * cosTheta, 0.6667);
 
  return (a*c) / (b*d);
}
 
float rayleighPhase(in float cosTheta)
{
  //return 1.5 * (1.0 + cosTheta*cosTheta);
  return 1.5 * (2.0 + 0.5*cosTheta*cosTheta);
}
 
 
 
void main()
{
  float cosTheta = dot(normalize(eye), gl_LightSource[0].position.xyz);
 
  vec3 color = rayleigh * rayleighPhase(cosTheta);
  color += mie * miePhase(cosTheta, -0.8);

  vec3 white = vec3(1.0,1.0,1.0);

  float scale = dot(normalize(white),normalize(color));
  color = (1.0 - (0.6 * scale * scale)) * color;


  gl_FragColor = vec4(color, 1.0);
  gl_FragDepth = 0.1;
}


I found I could get a behaviour which to me looks, with the right parameter settings of rayleigh, mie and density, much more natural than what the default shader produces. I'm still working on the horizon problem...

[Zan]

Thorsten,

the black is caused by all light scattering away when light travels "through earth". It might be not realistic, but the model is not supposed to render that correctly, only the parts of dome that are actually visible.

If you want to change the behaviour, look at the outscatterscale function in skydome.vert. The function takes cosine of view angle as a parameter (view angle 0 means up, 90 or pi is towards horizon) and returns amount of light scattered when looking from ground to sky.

I plotted the function, it is a exponential function, and as you can see, when looking downwards, the scattering amount is huge. Also, the function is fitted only on angles 0...95 or 100 iirc, so any values above that are wrong.


You could just clamp this value to something like 1e8, but then again you get errors, since the model takes always at least two values from this function (one from the viewpoint, and one from the sample point) and substracts them from eachother.

Maybe there could be a clamp somewhere to prevent the values from going too high... but the main problem is that the model is not designed to render "through the earth" lighting.

Zan

Edit: I forgot to say, in skydome.vert, you can find scattering coefficients for mie and rayleigh, for each RGB channels separately. I don't think those are exposed anywhere else. Modifying them might give you much nicer colors than the current ones. Lines 34 & 35 (e.g. vec3 rayleighK = rK * vec3(5.602, 7.222, 19.644); ). Just modify those numbers a bit and you should see difference in how the different light colors get scattered. Also changing the sunIntensity migh be worth trying out.

[Thorsten]

It might be not realistic, but the model is not supposed to render that correctly, only the parts of dome that are actually visible.

Well, yes, just that is the problem I'm trying to address, that if you have any bare LOD distance of less than 150 km, the terrain isn't actually drawn so far out and the parts of the skydome which should not be visible are there for anyone to see.

By restricting the costheta range in outscatter I have now succeeded to turn the yellow-black into a brilliant white (inscatter is all still there). Looks better at terrain edges than black, but since the terrain edges are drawn in a dirty white, I'm trying to come up with a color filter in the fragment shader which turns overexposed brilliant white into the same dirty hue, so while this may not be seemless, it'll probably be way more subtle than white terrain edges contrasting with a black skydome. Unfortunately all filters I've tested so far screw something else up... but maybe I should stop tinkering, sit down, take pen and paper and simply calculate it thoroughly... (not so much fun though).

But thanks for the hints - that has saved some work.

[Thorsten]

Okay, some progress (or not - decide yourself).

This is the original shader at 10.000 ft with 16 km visibility.



The problem is - that low visibility allows you to see 'through the Earth' where the shader doesn't produce correct results. So I'm going to fix this by brute force and will get the shader to display something else instead.

First change: I insert

Code: Select all

  if (costheta < -0.12) costheta = -0.12 - 4.0* (costheta+0.12) ;

into outscatterscale(in float costheta) inside skydome.vert

This dynamically removes the extinction from all rays which pass through the unphysical region (i.e. through Earth), so only the inscatter remains and I get a brilliant white drawn instead.



A bit more plausible than yellow-black, but not really good either.



So next I insert an exposure filter into main() in skydome.frag

Code: Select all

color = color/(1.0 - exp(-5.0 * length(color)));


which tames the white-out a bit (note the more blurred horizon line)



This is still too brilliant, so finally I insert a grey filter after the exposure filter

Code: Select all

 if (color.x > 0.6) color.x = 0.6 + 0.3* log(color.x/0.6);
  if (color.y > 0.6) color.y = 0.6 + 0.3* log(color.y/0.6);
  if (color.z > 0.6) color.z = 0.6 + 0.3* log(color.z/0.6);


and this gets me here



This is actually the worst contrast, looking against the sun where the terrain is drawn brighter it looks even better. And of course the terrain edge isn't going anywhere unless you increase visibility, in which case it moves more towards the horizon - but I assume it's more fun to fly over whitish stuff and pretend it's haze and clouds rather than over black stuff.

At higher altitude, you need progressively more visibility to hide a still persistant 'hole' in the skydome - 50 km visibility at 52.000 ft works nicely though. Also, the prescription is stable for a larger range of Rayleigh and Mie values, although it does have issues at sunrise and sunset. You don't really lose out so much, there was a problem in the first place, now it looks better in many cases, still bad in some.

So, not a proper solution, but maybe some sort of fix for the worst issues.

[i4dnf]

Just a thought, how about mixing the end result with gl_Fog.color, just for the region near the horizon?, that should get you closer to where the terrain ends up in terms of colour.

[Zan]

Just a thought, how about mixing the end result with gl_Fog.color, just for the region near the horizon?, that should get you closer to where the terrain ends up in terms of colour.

That's something I thought too, using for example:

Code: Select all

vec4 endcolor = mix(scattercolor, gl_Fog.color, smoothstep(0.1, 0.0, costheta));

that would/should start the fade at around 80 degrees and past 90 degrees gives fog color.. Might work, or might give awfull results. Worth a try I guess.

Zan

[Thorsten]

Problem seems to be that the terrain isn't really all to fogged out at the edges... the actual terrain color is still partially in there, so I'm not sure this will remove so much of the contrast - but worth a try...

[Thorsten]

Problem is that gl_Fog.color is black... so if you mix 100% of that in below the horizon, you're back to the black hole. But mixing some of it works not so bad. During daytime, using the Local Weather altitude model of visibility, for a particular range of parameter settings I have now something that is seamless and not so bad. At dusk or dawn, the colors don't look so well with the terrain.

Basically, the shader is appropriate for a clear day with visibility on the ground in excess of 35 km or so, then the altitude increase of visibility will fix the rest and push the horizon out far enough. In principle, visibility high up would always meet the criterion, but then one has to switch the skydome shader from default to scattering on the way up and it isn't seamless any more For a closed cloud layer, I could pull it of while flying during the cloud, but in 4/8 I don't know what to do.

My weather-research F-16 on the ground.



Note that the horizon is a bit darkened because I mix gl_FOg.color in - actually just at the horizon line, it blends smoothly under most conditions which can be seen from about 5000 ft. But we'll go higher to see the flaws.

At about airliner cruise altitude of 34.000 ft.



At this altitude, the horizon line is rather well visible, but then there's greyish haze beyond it, and with some Cirrus clouds in the vicinity it doesn;t look too bad.

In ballistic flight at 63.000 ft:



The increased high-altitude visibility pushes out the horizon so that the overall impression isn't changed (the actual visibility range is actually much more than at 34.000 ft) there's a haze band beyond the horizon line, you can see where the terrain ends, but it's actually not that bad. And it's seamless all the way up to here from the ground.

Same scene from external view:



Again, looks sort of semi-plausible. Actually, I would like to look it like this given the altitude



but that doesn't work on the ground, it's gives way too dark skies. I guess the physics reason is that the density distribution of scatterers in nature usually isn't just exponential in altitude, so that's where a weather-dependent atmosphere model would come in.

Technically it corresponds to a dynamical re-adjustment of rayleigh and mie with increasing visibility range, which could easily enough be done in Local Weather.

The question (especially to Lauri) is - should we proceed like this? It'd require to accept that shader parameters are set from Nasal and no longer runtime controllable from the menu, and to change the current shaders against my version where some tinkering is done to fix the region below the horizon (which all probably can be coded much more elegantly and efficiently, I don't really know any GLSL, I'm just picking it up as I go along...).

Then, when you enable the skydome shader and Local Weather is running, it would assume control of the shader parameters and set them to whatever it thinks is appropriate given the visibility (and it'd look silly for low visibility...). If you want your work to end up that way, I can proceed with integration, otherwise I'll just drop it from here.

I'd love to have a consistent shader for terrain and skydome for arbitrary density distributions and visibilities, but I guess that's a long term project...

[adrian]

Thorsten, you're an absolute guru when it comes to FG visuals, your screenshots always are the best IMO

Do you happen to know Falcon4 and its offsprings? I wonder how the FG F16 would be like with such a cockpit and systems modelled... That would be the day

[Thorsten]

Thorsten, you're an absolute guru when it comes to FG visuals, your screenshots always are the best IMO

Thanks... I guess that got me access to the Flightgear main page with the task to generate some PR-suitable material there...

Do you happen to know Falcon4 and its offsprings? I wonder how the FG F16 would be like with such a cockpit and systems modelled... That would be the day

Yes, I always liked Falcon 4 - there's nothing quite like flying for 30 minutes into your target area to suddenly see the threat indicator light up like a christmas tree and go down in flames three seconds later... Clearly not an arcade game.

Most about the Falcon 4 cockpit was radar management though... that's not exactly up the Flightgear alley, very few people are interested in developing detailed tracking and weapons delivery procedures, and there's no one doing a simulated battlefield like Falcon 4 had. I would enjoy somewhat more support for military aviation - it always struck me how tiny a tank looks from the air, and I like the Nellis Bombing Range AI scenario with the A-10, because it requires quite some skill to hit anything.

As far as flight characteristics go, the Flightgear F-16 is quite sophisticated, and I like flying it quite a lot. A bit more systems to play with - say as in the F-14b or the A-10 - would be nice though...

[kyokoyama]

I've never really completely understood what's being discussed in this thread, and every time I try, my understanding seems to get worse and worse...

But if I'm understanding the little parts I am able to comprehend right, then I have an idea. -But first, could I see if my understanding is right, in plain English?

It seems that your scattering values and rayleigh factor and whatnot are what determines how the sky looks, right?
However, it looks like the values that are modified all cause some sort of flaw in the sky, depending on the altitude.
(For example, the green skies in the version shipped with FG2.4, or the dark horizon in Thorsten's recent post)

If these are all issues of altitude, isn't it simply possible to slowly adjust these factors and values depending on the camera and aircraft's altitude?

I'm guessing that's how the black "sky" in space is also produced, but can't the same also be done for lower altitudes?

-I'm sorry if this was a stupid question, but I'd greatly appreciate an explanation that the rest of us can understand. Thank you!

[Thorsten]

It seems that your scattering values and rayleigh factor and whatnot are what determines how the sky looks, right?

Yes.

However, it looks like the values that are modified all cause some sort of flaw in the sky, depending on the altitude.
(For example, the green skies in the version shipped with FG2.4, or the dark horizon in Thorsten's recent post)

No. The problem is that you can use the same setup that determines how the sky above looks to determine how the sky below you would look if there were no terrain. The answer you get is nonsense, because there is no physics solution to how the atmosphere looks below the surface, but it still paints the skydome. Which wouldn't be a problem if there would be terrain displayed all the way out to the horizon, because then you'd never see that part of the skydome, but that's not what the Flightgear terrain engine does - that leaves gaps in the terrain and allows you to see the nonsense region. As you go to higher and higher altitude, at constant visibility the region where there is no terrain visible just keeps growing, that's why high altitude is way more problematic.

The recent part of this thread deals with an ad hoc fix which paints the unphysical region in a more plausible manner.

If these are all issues of altitude, isn't it simply possible to slowly adjust these factors and values depending on the camera and aircraft's altitude?

This is not a fix to the problem of stuff looking outright wrong, but to the different problem that a single setting for the shader parameters either produces too dark a sky at ground level or too bright a sky at high altitude when compared with real life experience. I believe the shader is actually correct if the haze distribution in the atmosphere follows a certain exponential density distribution - the problem seems to be that nature doesn't. In order to fix that, I am actually proposing what you ask.

I'm guessing that's how the black "sky" in space is also produced, but can't the same also be done for lower altitudes?

Yes and no. A code assuming up front that you have on average much less than a single scattering for a light ray in the atmosphere can't handle low visibility where you have much more than one and the physics is different. So the shader in its present form is and will be limited to visibility above a certain number (probably around 30 km, about the atmosphere thickness scale). It can't produce a correct scene for 1000 m visibility conditions (in rain, for instance) for any setting of parameters.

[kyokoyama]

Ohhh... alright. That makes a whole lot more sense.
Thank you!

I mean, many of the pictures have shown that your shaders work either in low altitude (like this one)...


...or high altitudes, like this.



I think that approach will (theoretically) work well -but first, I guess I should learn my Nasal and XML before coming back and formally making a comment.

Thanks again!

PS: Whoa, you work at Duke!?

[Zan]

Problem is that gl_Fog.color is black...

Ouch. Yeah, now that you mention it, I think the skydome is rendered in completely different place than the terrain, so the fog parameters might not be set up. Damn.

BUT! This just came up to my ming. The original vertex colors, that are used in the non shader version, are available in gl_FrontColor in the vertex shader. Might be possible to use the scattering shader above the horison, and below the cpu calculated old values.

One thing to note though is that one of the main effects of this shader is the sunrise/sunset effect near the horison. I'd feel bad to take that away by blending to some constant color...

Technically it corresponds to a dynamical re-adjustment of rayleigh and mie with increasing visibility range, which could easily enough be done in Local Weather.

This is something I though should happen. I always thought that the coefficients would be calculated depending on the METAR, and the sky would then reflect the real weather, no manual editing of parameters needed. They were only exposed for easier testing of the shader.

The question (especially to Lauri) is - should we proceed like this?

Sure, go ahead if you feel like it. The power of GIT comes from the fact that we can always see the original version and the changes, and revert them if necessary. If you feel like you could improve the shader with nasal or anything, just do it.

Then, when you enable the skydome shader and Local Weather is running, it would assume control of the shader parameters and set them to whatever it thinks is appropriate given the visibility (and it'd look silly for low visibility...). If you want your work to end up that way, I can proceed with integration, otherwise I'll just drop it from here.

I'm not sure if you're talking only about weather conditions, or also changing the parameters depending on altitude etc. I think the former is the correct way, and the latter is not. Though the current model does not work really well for anything but clear skies, so maybe the model should be improved.

I'd like to see a model which would simulate clear sky, fog, rain and smoke for example, to allow for very different looking skies with just few parameters which are easily figured from METAR. And the same model should be applied to both terrain and sky, and it would give consistent and good looking results... I guess this model with added support for low visibility (and maybe layered fog?) would be a good start. And one issue is the tile visibility range...

I'd love to have a consistent shader for terrain and skydome for arbitrary density distributions and visibilities, but I guess that's a long term project...

Yeah...

Zan

P.S. take a look of this Outerra post http://outerra.blogspot.com/2011/07/fog-and-dust.html, which shows some screenshots of how they handle low visibility. It looks pretty much the same as what I got with this shader applied to terrain. Any ideas on that one?

[planetacancun]

Hey guys this is what we have to see up above. I wanted to share