Geometry and Compute Shaders

Also, which atmospheric scattering model are you using?

I’d definitely be interested in your compute shader work! I’ve got a volumetric fog shader I wrote that I’d love to Port to jme. It’s just not high on my list at the moment.

1 Like

Thank you, yes contribution is welcome. You can also mention some small changes here if you’d like.

Hmm, are you sure about this?

Lines 707-709 contain:

float extinCoeff = ExtinctionFactor*density;
float T = exp(-extinCoeff*add);
vec3 Light = Sunlight(p)*(phase*(1.0-exp(-extinCoeff*add*2.0)));

Here T is beer lambert(out scattering) and 1.0-exp(-extinCoeff*add*2.0) is in scattering.

1 Like

Ah ok. I guess it would be better to explain what I’m trying to do. The clouds in seven sky look good, but I’m trying to get more accurate looking in-scattering. Around 16:25 there is a slide of before and after the in-scattering probably function is applied. The after slide is what I am looking to achieve.

I will post a snippet of code when I have time later, but to summarize, I left your light integration alone and added a routine to apply a different in-scattering probability function and then interpolated between the two values. This isn’t the best way to do it, but it gave me pretty close to the results I expected, (minus the sort issues @pspeed noted).

Maybe there is already a way to achieve the look I am hoping for in sevenSky, but it wasn’t immediately obvious to me. There is a good deal commented out in the shader.

1 Like

I see, thanks. Yes, to customize the look it definitely useful to fiddle with the shader, etc. You can also try different values for phase function etc. Also remember that by default max 16 samples are used, which I think are generally enough, you can try increase them and see if you spot a difference.

Finally, even if you completely change the shader/Clouds file, and get a nice look you can still contribute to SevenSky, in which case, we would make a copy of the shader and possibly Clouds to include clouds with different look., user can choose either then.

1 Like

I didn’t make any changes anywhere but the shader. This is nowhere near complete or anything, but it shows the guts of the in-scatter probability function. Here is the WIP shader.

You can also comment out the LIGHTING VOLUME TEST part at line 824 and add this line if you see that weird sorting issue too.

I.rgb = mix(LightVolume.rgb, I.rgb, .1);
I.rgb += I.a*I0 ;
I.a *= T;
1 Like

It appears to me after reading the thread that the “sorting” issue occurred after you removed the matrix invert line.

Thank you for the info. I might play with that later. : )

1 Like

No, it was there since dreamwagon’s very first image.

Looks like cloud tops:

Looks like cloud tops:

1 Like

So I FINALLY got my hold on GPU Pro 7 from the university library and I kind of been going down the rabbit hole with the volumetric clouds. I had that ‘ah-ha’ moment regarding cloud shaping, and the examples I found online that referenced zero dawn are starting to make more sense.

One thing that was not immediately obvious was the noise texture used to form the base cloud shape. They used a special 3d texture with perlin worley in the R channel, and worley noise in the GBA channels at increasing octaves. Here is something similar I came up with in photoshop. I use the DDS exporter plugin and it seems to create the volume texture I need.


The first step in the density calculation using this texture:

float density(vec3 pos) {

vec4 lowFreqNoises = textureLod(m_CloudShapeNoise, pos.xzy *.000001 , 0).rgba;
//Build FBM out of the noises
float fbm = (lowFreqNoises.g * 0.625) + (lowFreqNoises.b * 0.25) + (lowFreqNoises.a * 0.125);

float d = Remap(lowFreqNoises.r, -(1.0 -fbm), 1.0, 0.0, 1.0);

Likewise the secondary detail map used to erode the cloud shape is also created in a similar way.
At this point I have completely wandered away from working on the cloud lighting model and am focused on building realistic looking coverage. Here is a shot of one layer of stratus clouds. I don’t think these have the sorting issue. Would you agree @pspeed?

Side question: any opinions regarding using a full screen quad vs a dome? I see that @The_Leo used a full screen quad. Was this decision just for optimization and using a less complex geometry, or were there other reasons you decided on a quad?

I am hoping in the next couple months this will morph into something really useful for the community. Also, should I move this into a new thread? I kind of hijacked this one. We’re pretty far away from the compute shader topic at this point :rofl:


Since volumetric clouds are ‘ray-traced’ full-screen quad accomplishes that.
Generally you use dome shape/box if you have, eg skybox image, but here the sky is generated on the fly.

PS: in the above photo the clouds look like they don’t have much volume. If you’d like to increase cloud coverage, change the Cloud.Coverage variable ([0,1] 0 or 1 represents full coverage), also set a custom Clouds.Weather_Map for even more control. (See Section 5.3 in documentation about Weather Maps).
In short: Weathermap’s Red channel represents cloud density, Green, Blue channel, represent cloud height.


Although I am using seven sky for the setup on the CPU side, I am completely rewriting the cloud fragment shader. I am planning it a little differently to follow the slides.

Weather texture:
R - Coverage
G - Precip chance (as % 0-1)
B - Cloud type ( Used in density height gradient) - I think this is the same as seven sky

I didn’t realize that was documented, thank you! I had to figure it out by testing the shader and drawing contents of test weather map on a quad :sweat_smile:

1 Like

Yes, there is no sorting issue but there is no shading either. So it’s impossible to tell, really.

It’s the shading being on the wrong sides and/or ahead of the things in front of them that was causing the issue before.

I don’t know how I missed the PDF in the project, but wow, that is super helpful!
Curious how much performance you gained by using a lookup table for cloud path?

Haven’t done tests in numbers, but if you check SkyLutGenerator.cloudPath that amount of code would have to be executed for each fragment without the lookup table, which would be rather expensive.

I did a very basic test in SevenSky by moving the calcForSphere function to the frag shader, and there was a drop of about 7 fps. The cloudPath LUT is indeed VERY important! I am going to have to borrow that part :smiley:

I started clean in a new project and have made some decent progress (below). It still looks too much like noise IMO but it is getting close. Also, the sky shader I am using at the moment is very slow. The clouds alone render over 100fps and I am using 32 samples, although I have not started on the lighting samples yet. I should have something really nice in another week or so.


I wonder how the performance will look with lighting samples included.

Btw, there’s also a way to ‘fake’ the lighting. Or maybe use yet another LUT in some way. I’ll probably look into these two once I’ll get back to work on sky.

Also another nice feature of the lib that would be nice would be the ability to bake a sky into skybox. That way even very expensive sky effects could be rendered or pre-rendered. Would be useful for games which do not require animated clouds/day-night cycle etc.


That looks really nice already.


this already looks nice, like was said, but you are right, performance could be better.

I’m going to remove the atmospheric scattering shader I’m currently using since it is cutting the fps in half. I’m very curious about the lighting samples too.

LUT for the lighting is likely doable. There’s probably a tricky way to do it with 3d texture. I’ll have to think about it too.

Pre-rendered skybox texturing is a great idea! I made a fighting game a long way back that would have been a great use case for a randomly generated static sky box.