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:
https://imgur.com/OnGAJmK.png
Looks like cloud tops:
https://imgur.com/rmzeDUH.png
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 
4 Likes
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.
3 Likes
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 
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 
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.
8 Likes
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.
3 Likes
That looks really nice already.
2 Likes
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.