Board index FlightGear Development Effects and shaders

Revisiting clouds

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Revisiting clouds

Postby Icecode GL » Wed Sep 12, 2018 6:38 pm

I've been playing with the code and I've come up with some interesting results, but I'm stuck and I can't seem to figure out what's wrong.

I'm trying to get the world space direction of the ray that comes out of the camera for each pixel. Everything looked ok at first but then I noticed everything is rotated, i.e. the Z axis doesn't point up, the X axis doesn't point right etc.

Image
Here I'm looking up but the center of the screen isn't completely blue (the direction of the ray coming out of the center pixel should be [0,0,1]).

Image
Here is how it's supposed to look like, but I'm looking at a 45º degree angle in both the Z and X axis.

Code: Select all
void main()
{
    vec2 rayNDS = (gl_FragCoord.xy / fg_BufferSize) * 2.0 - 1.0;
    vec4 rayCS = vec4(rayNDS, -1.0, 1.0);
    vec4 rayVS = fg_ProjectionMatrixInverse * rayCS;
    rayVS = vec4(rayVS.xy, -1.0, 0.0);
    vec3 rayWS = normalize(fg_ViewMatrixInverse * rayVS).xyz;
    gl_FragColor = vec4(rayWS, 1.0);
}
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Icecode GL » Wed Sep 12, 2018 8:02 pm

Just discovered another interesting "feature": if I change the location to lat 0 and lon 0, looking up shows the X axis. I guess FG's world position matches the cartesian coordinates on a sphere, i.e. it's not relative to the ground. Now how do I transform these directions to be relative to the ground...

EDIT: Alright, it works now. No need to transform them if you account for the spherical coordinates.
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Thu Sep 13, 2018 4:37 am

I guess FG's world position matches the cartesian coordinates on a sphere, i.e. it's not relative to the ground.


Yep - world coordinates are co-rotating with the sphere and have z poleward and x (I guess?) towards the 0 meridian. I use them for some coarse-grained noise on the terrain (which has to be 3d noise then for that reason), but they're not good for scales < 10 m or so, the floating point precision screws things horribly on some cards.
Thorsten
 
Posts: 9909
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby Dave B » Sun Sep 16, 2018 12:07 am

While not able to assist programmatically. As promised, mentioned would try some Blender experiments. This is to try and help supply a larger range of 2D textures made from 3D clouds for the current billboard implementation, until shader ray marched 3D cloud code is ready.

- Blender viewport test renders (slower render times due to using older laptop)

First, tried modeling and shading clouds, then made improvements after watching couple of Blender online tutorials, finally made modifications allowing variable displacement mapping. This method allows easily created varied cloud shapes

Image

Second, tried growing clouds using heavily modified default physics smoke simulation (plus added force fields). While harder to control, results are more vapor like.

Image

Few benefits compared with using photographs for textures, (if required) clouds can be re-rendered with light from any direction allowing a wider range of 2D texture use. While above examples have simulated sky and blackbody setting for the sun, it's easy to render with neutral colours and transparent backgrounds, saving post-processing time.

Please consider the above work in progress, feel there's still quite some way to go, thank you!
Dave B
 
Posts: 12
Joined: Fri May 18, 2018 3:19 pm

Re: Revisiting clouds

Postby Icecode GL » Mon Sep 17, 2018 11:46 am

After some experimenting I think I've got a base to work on:

Image

The result looks bad mainly because:

  • The light direction is wrong, it's hardcoded into the shader. I need to find a way to pass the sun direction to fullscreen passes.
  • The clouds don't fade with the horizon, they just stop drawing to save some computation time.
  • Ambient and direct lighting colors are wrong, they don't use ALS equations, just a fixed ambient and direct light color.
  • Some finetunning to the noises is still required to get the best looking cloud shapes.

Framerates are bad as well because the ray marcher currently runs 256 samples per pixel every frame. Temporal upsampling and some dithering/blurring can help A LOT with that. For that we'd need to pass the previous frame and the previous frame's projection matrix to the shader, which is possible although it'd require changes to the Compositor.

The clouds also draw on top of any geometry, we'd need to read the depth buffer to avoid that.
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Icecode GL » Mon Sep 17, 2018 1:46 pm

Here are some pics with fake ambient values:

Image
Image
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Mon Sep 17, 2018 2:15 pm

Framerates are bad as well because the ray marcher currently runs 256 samples per pixel every frame.


What equation are you running - did you stick with my code, or change to something else?

And how able are we to insert a specific cloud into a specific location (conceptually I mean, not right now)?
Thorsten
 
Posts: 9909
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby Icecode GL » Mon Sep 17, 2018 2:29 pm

What equation are you running - did you stick with my code, or change to something else?


It's basically what you are doing but with a few tweaks from the previous links.
It uses an analytical integration of Beer–Lambert’s law to calculate transmittance and two superimposed HenyeyGreenstein phase functions to calculate the scattering.
Volumetric shadowing is also done the same way, stepping a ray from the sample to the sun.

On the modelling side it's also a lot like yours, except that instead of superimposing Perlin noises only, it uses Worley noises like in the previous links.

And how able are we to insert a specific cloud into a specific location (conceptually I mean, not right now)?


Cloud coverage is controlled by a noise function (or a texture if you want). You can use a texture and paint the distribution you want, but I think a noise function is a better way to represent coverage.

Here is how it is calculated:
Code: Select all
    float coverage =
        Noise3D(pos, 10000.0) * 0.625 +
        Noise3D(pos, 5000.0) * 0.500 +
        Noise3D(pos, 2500.0) * 0.125;
    coverage = smoothstep(0.6, 1.0, coverage);
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Mon Sep 17, 2018 2:55 pm

Yeah, the thing is, ultimately we need clouds at specific places (think cap clouds indicating thermals). We need different cloud types in different parts of the sky (think fronts). We need to displace part of the layer vertically (think Cu development in mountains). We need to let the terrain drive cloud development (think Cu development over water vs. land).

These are all important cues for a pilot, and I guess somewhere there is the difference between rendering a plausible cloud layer and having a flightsim-capable weather engine...

So I'm not expecting any of this to work any time soon - but at least conceptually we need a way to get there eventually. Otherwise it has to be 'boxed' like in my implementation and only each box is loaded...
Thorsten
 
Posts: 9909
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby Icecode GL » Mon Sep 17, 2018 3:06 pm

Yeah, the thing is, ultimately we need clouds at specific places (think cap clouds indicating thermals). We need different cloud types in different parts of the sky (think fronts). We need to displace part of the layer vertically (think Cu development in mountains). We need to let the terrain drive cloud development (think Cu development over water vs. land).


All of that is possible here, but you must have a different mindset when dealing with the problem. You can't place clouds individually now, the sky is a continuous medium.
Clouds types can be obtained by modulating the coverage by a height signal, where cumulus clouds are the tallest and stratus are the thinnest.
Displacing vertically is as simple as placing the cloud layer X altitude over the terrain below it.
Terrain driving cloud development could be another function where the independent variable is the terrain type below (maybe 1.0 is land and 0.0 is water). Just by multiplying the coverage by this value you can get clouds over land but not over water.

I might even dare to say this is a better approach to local weather. Instead of letting the weather engine calculate all the individual cloud positions, it just calculates some specific data for the current weather and lets the shader do the rest.
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Richard » Mon Sep 17, 2018 3:24 pm

Icecode GL wrote in Mon Sep 17, 2018 3:06 pm:I might even dare to say this is a better approach to local weather. Instead of letting the weather engine calculate all the individual cloud positions, it just calculates some specific data for the current weather and lets the shader do the rest.


Except of course that we need this modeled in the simulation host so we have the aerodynamic effects in the atmosphere modeled and exported into the fdm.
Richard
 
Posts: 609
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Revisiting clouds

Postby Thorsten » Mon Sep 17, 2018 4:52 pm

All of that is possible here, but you must have a different mindset when dealing with the problem. You can't place clouds individually now, the sky is a continuous medium.


We're going to have to if we want to keep having weather rather than a cloud layer. As Richard says, we need to define the weather outside the renderer. Precipitation needs to go under the cap cloud, up and downwash under the appropriate cloud types, turbulence to where strong convection is. And so on.

Some guiding field for the noise is perhaps needed that can be fed with position data. Positions to 'seed' cloud development in the noise field somehow. To be efficient, we can't do checks against 1000 positions, so this probably needs some kind of octree lookup to do just a few range checks. Then a way to insert position data into this vector and remove it again.

Displacing vertically is as simple as placing the cloud layer X altitude over the terrain below it.


Except the mountain displaces a single cloud, not the whole layer... I've struggled for a few months with halfway realistic cloud placement in mountain regions, it's not a simple problem at all.

Just by multiplying the coverage by this value you can get clouds over land but not over water.


Which requires to know cloud type (only convective clouds follow that pattern) and having a continuous function of the terrain type that is accessible to the shader.

I might even dare to say this is a better approach to local weather. Instead of letting the weather engine calculate all the individual cloud positions, it just calculates some specific data for the current weather and lets the shader do the rest.


I wish weather were that simple... :mrgreen: You need a hell lot of heuristics to get close to a real-world gliding experience in mountains - I really would not want to evaluate that per frame...
Thorsten
 
Posts: 9909
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby Icecode GL » Mon Sep 17, 2018 5:19 pm

We're going to have to if we want to keep having weather rather than a cloud layer. As Richard says, we need to define the weather outside the renderer. Precipitation needs to go under the cap cloud, up and downwash under the appropriate cloud types, turbulence to where strong convection is. And so on.


Nothing I've said contradicts that...

I wish weather were that simple... :mrgreen: You need a hell lot of heuristics to get close to a real-world gliding experience in mountains - I really would not want to evaluate that per frame...


You can create a weather texture on the CPU and pass it to the Compositor rather trivially... I think you are judging the approach by what you think it can do instead of what it can actually do.

I'm not saying weather is simple (I never did), but everything you have said so far can be reimplemented. Once you have access to the code you'll be able to better judge if you can do everything you want to do using this technique.
Icecode GL
 
Posts: 464
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Revisiting clouds

Postby Thorsten » Mon Sep 17, 2018 5:25 pm

I think you are judging the approach by what you think it can do instead of what it can actually do.


No, not at all - there's no judgement involved, I'm just trying to get us to think of some important stuff early on so that we take the right steps now and don't end up looking back like 'we should rather have...'

Please don't get me wrong here, I don't want to be discouraging in any way.
Thorsten
 
Posts: 9909
Joined: Mon Nov 02, 2009 8:33 am

Re: Revisiting clouds

Postby erik » Mon Sep 17, 2018 8:22 pm

Richard wrote in Mon Sep 17, 2018 3:24 pm:
Icecode GL wrote in Mon Sep 17, 2018 3:06 pm:I might even dare to say this is a better approach to local weather. Instead of letting the weather engine calculate all the individual cloud positions, it just calculates some specific data for the current weather and lets the shader do the rest.


Except of course that we need this modeled in the simulation host so we have the aerodynamic effects in the atmosphere modeled and exported into the fdm.

Not only that, you want to find the same cloud at the same location in a multi-monitor setup as well as in a networked environment. Otherwise anomalies will show.

Erik
erik
 
Posts: 1503
Joined: Thu Nov 01, 2007 1:41 pm

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 4 guests