Assets [WIP] SkyRay - Next-gen dynamic sky & weather for Unity

This is something I've been very excited about, having sunk a lot of time and effort. Today I think it's far enough along that I can start sharing WIPs here and talk about what this is.

​

SkyRay is a next-gen dynamic sky system for Unity. The sky is 100% volumetric, procedural, and totally dynamic. It was painstakingly designed to borrow as much inspiration from real world clouds as possible. Several cloud layers - cumulus, cumulonimbus, and cirrus clouds - work in tandem to provide a convincing sky rendering. At the same time, great care has been taken to ensure that SkyRay has a minimal framecost while looking the best it possibly can.

In addition to cloud rendering, SkyRay features a dynamic weather engine which allows new weather conditions to roll in from the horizon in real time. You can literally watch storms approach from the distance.
Weather events are world-persistent too, so you could theoretically follow a storm through your game world. Additionally, SkyRay allows a configurable climate to be defined which affects the weather patterns. Climate can change throughout the year with the seasons, or even in different areas of your game world for maximum realism and control.

Screenshot of large stormclouds rolling in. Players can watch these events happen in real time.​

The weather over the player is also used to drive a highly configurable set of effects encompassing particle and sound effects, driven by a variety of curves such as moisture, cloud coverage, temperature, etc.

The same storm, now over the player. The weather engine can drive various sound and visual effects, as well as custom scripts.​

SkyRay has been tested and verified 100% compatible with DX11/PC, Vulkan/PC, and WebGL 2.0 / GLES3.0 in both Firefox and Chrome.

SkyRay running in WebGL 2.0 on Chrome (showing debug output)​

 

very nice... when you say volumetric you mean you can fly though clouds ?

 

They're volumetric in that you can fly around underneath them and they appear fully 3D rather than being a flat cloud plane. But, for a number of reasons relating to how they're being rendered and how I'm keeping the frame cost down, you can't fly through them. They're designed to be used like skybox clouds for when you're on the ground.

 

Looks really good! Definitely keeping my eye on this one.

 

Just a little update. Today I just about finished the rewrite of atmospheric scattering. SkyRay features a full time-of-day cycle too, and I want the sky to look just as good as the clouds do!

Previously I had basically reused Unity's skybox code, but now I'm using precomputed atmospheric scattering based on Eric Bruneton's work, known to be one of the better looking methods available. Essentially it prerenders what the sky looks like at different sun angles and times of day directly into a 3D texture which is stored as an asset - then sky rendering can just be sampled with an angle in a shader.

A utility will ship with SkyRay which lets you render these LUTs yourself:

​

It allows you to play with atmosphere/sun color, moon color, atmosphere density, planet radius, etc so you can create physically plausible and/or artistically tweaked alien or fantasy worlds. Of course an earth-based LUT set will ship out of the box.

Additionally, I've changed how I'm doing sun color calculation. You can either have SkyRay calculate sun color automatically using rayleigh scattering, or you can enable a custom sun gradient for full artistic control. You can have SkyRay auto-fill the gradient with rayleigh-based values and then tweak to your heart's content. For example, I captured this dramatic shot which was the result of tweaking the sun gradient:

​

I would also like to point out that already built in is a feature that SkyRay can auto-generate global spherical harmonics lighting for your scene based on rayleigh scattering and on cloud coverage so that no matter the time of day or the weather your lighting looks consistent and plausible.

 

Any movies/gifs of these clouds rolling in?!

And what are your plans for celestial positioning? In other words: are you going for a more realistic approach (i.e. Time of Day), or a simple sun/moon rotation?

 

I'll see if I can get a video together!
Currently the sun is positioned realistically, based on latitude, longitude, and date. The star layer rotates with the sun. The moon is not yet realistically positioned, but I'm looking to change that prior to release.

 

Ermm, when will it be available and price point info would be good to know Dynamic Skies would be cool for my Aircraft Sim I have.

 

When will it be available?
I actually cannot say. I've got a good amount of work ahead of me just for V1, such as getting in all of the features I want v1.0 to have, polishing and cleaning up the existing features so that it's as clean and user friendly as possible, and also documenting everything properly.

Price point?
I'm thinking around $60-$70.

Aircraft / Flight sim?
I know that wasn't a question, but I'd like to point out again as I did in an earlier post - at the moment, you cannot fly through the clouds. They're highly optimized around the case of being on the ground. As long as you're OK with this, then it should be fine. But if you want to be able to fly through the clouds, at least the first version is probably not what you're looking for. Luckily, there are other solutions which do support this - TrueSky, for example (though as far as I'm aware at the moment TrueSky's Unity plugin is still DX11/Windows only).

 

As promised, here's a video of the clouds in action, including footage of that storm front rolling in! Also showing off the cloud shadows feature which allows the cloud layer to modify the screen space shadow mask to add global cloud shadows.

 

Awesome!

 

Looks very nice indeed, what is the CPU cost for the clouds and other effects, and I am guessing this would not work on mobile devices? Finally can you just generate a static sky without animation so a cube map could be rendered for example.

 

You are correct, the GPU cost makes this prohibitively expensive for mobile, and it is geared towards consoles and gaming PCs. The CPU cost is extremely minimal, however (most of the work is on the GPU). There's no support for cubemap rendering at the moment, but it shouldn't be too hard to implement.

 

Spent today getting exponential height fog up and running. Now the AtmosphereFog effect which will ship with SkyRay features a nice height-based falloff you can tweak

 

More, slightly less exciting probably, news.
I've now got realistic moon positions in. So both sun and moon are calculated based on date, latitude, and longitude, accurate to real world positions. BUT!
That's not all. Internally, I've refactored the code so that the codepath for sun and moon are actually one and the same, just with different values. In fact, not just the sun and moon, but any arbitrary celestial body too. You'd have to work out a whole table of values for a custom planet (or just borrow one of our solar system's planets, from http://www.stjarnhimlen.se/comp/ppcomp.html), but it is possible and is capable of taking the earth's rotation, the earth's orbit around the sun, AND that planet's orbit around the sun as well

 

Sounds very interesting, great work. SkyRay looks really great so far!

Can you post some pics of the night lighting, I would like to see SkyRay at night?

 

Sure thing! Here's a few of them. Still haven't implemented phases yet, but I plan to.


The moon just becoming visible at sundown (may tweak this to make moon a little more visible).


After sundown.


Same time but earlier in the month, the moon is higher in the sky.

 

Thank you looks very impressive! I think SkyRay would be perfect for my boat sim project.

 

More progress. Got lightning storms in
Lightning starts at around 2:00 in.

 

Correct me if I'm wrong, but your system doesn't seem to account for haze/fog when displaying the clouds. When it was raining (around 40 seconds into the video), in the distance I could see patches of light clouds. Or is there a way for the user to overcome that?

Also...what do you think it would take to enable clouds that are are "fully" 3D, or what performance impact would it have?

 

Looks great, count me in! With trueSky I have many annoying problems, especially the precipitation does not work for me.

 

A few more quick questions: do you plan to have this control wind zones? What are your plans for the night sky / stars / etc? What sort of time frame are we looking at for release in some form? =)

 

@jc_lvngstn Actually clouds do support fog, integrated with the AtmosphereFog shader. In the video, it's just using the atmospheric fog which turns grey at high cloud coverage values (note the blue tint on the clouds with clearer skies? that's the atmospheric fog). There's also a separate fog density on the AtmosphereFog component for custom fog, which also affects the cloud and the skybox - currently no weather condition increases the fog density automatically but it is an exposed value.

Now, as for fully 3D clouds. The thing about raymarched clouds is that they're right up against the limits of what modern consumer hardware is capable of, especially in the context of a full game which has tons of other things it needs to budget for as well. SkyRay has an interesting optimization that makes it suitable for use on consoles and PCs, in that you get two resolution options - quarter resolution, and 1/8th resolution, which are not directly displayed but instead used to "fill in" the pixels of a half resolution buffer over time (this way, you can render your clouds at 1/8th the screen resolution but it looks as if it was rendered at half resolution, because it uses the 1/8th buffer to partially update the 1/2 buffer, which dramatically cuts down on per-fragment cost as these clouds are very much fillrate bound).

If this is done naively, it results in a high degree of "blurring" as for example the 1/8th buffer takes 16 frames to fully update the 1/2 buffer but by then the clouds have already moved. Actually, it looks vaguely like interlacing artifacts, but on individual pixels instead of whole rows of pixels. The clouds are fairly slow moving, so the artifacts are much less noticeable when the camera is still, but rotating the camera makes the artifacts immediately visible. So, to combat this, SkyRay does a temporal reprojection of the previous frame's result onto the current frame. It can only account for rotation however, as positional correction only really works properly for opaque objects with a depth buffer available.

You can see this in this video of an older WIP of SkyRay, starting at about 1:50 where I show the debug modes.

So the main problem is that when far beneath the clouds this temporal rendering works great, but move the camera right up close to the clouds, or into the clouds, and the artifacts become readily apparent as the difference between one frame and the next is higher. I could make a "direct" rendering mode, which simply renders the low-res buffer directly to the screen, and then add a direct half-res mode which renders the clouds at half-resolution and directly blends them to the screen, but 1/4 and 1/8 res modes would take an instantly noticeable hit to visual quality, with pixels becoming much more visible, and a theoretical direct 1/2 resolution mode would dramatically increase the GPU cost of the clouds.

@mons00n Currently no wind zone control, but shouldn't be too hard. There's a WeatherParameters class which you can stick as a field in any script and has a set of curves for all weather parameters, and an Evaluate method you can call which returns a 0-1 value of all of those curves multiplied together for the current weather conditions. It makes it quite simple to add new scripts which respond to the weather. As an example it took probably around 10 minutes to create the lightning controller script. So I'll add a wind zone script as well!

As for night sky and stars, right now (and it will probably stay this way at least for V1) the stars are just a cubemap of the Milky Way assigned to the stars layer of the skybox material. The star layer is rotated with the sun rotation.

As for a release schedule I have historically been quite terrible about those sorts of estimates. All I can say is I hope to have this release ready soon. At this point I'm going to be looking at laying out a roadmap for all of the features which are a must-have for V1, and then doing a polish pass on the code I already have so everything's as clean and easy to read and use as possible. Then there's documentation, and then marketing. So I've got my work cut out for me but I'm trying to get this ready as quickly as I can!

 

Thanks for the response! Looking forward to the progress.

The sun should rotate at a different rate than the stars no? Granted they will appear similar, but the sun should be in a different portion of the sky roughly every month.

 

I'll take a look. Oddly info about calculating star positions seems to be harder than finding info about calculating planet positions. Ideally I can just find a way to plug it directly into the same celestial body calculations I've already got to produce a separate rotation

 

Phobic, thank you for the great explanation
As far as the fog/haze affecting cloud visibility...in the youtoube video you linked, the very first frame shows mountains obscured by fog but the clouds in the distance are clear. Shouldn't they be somewhat obscured also, or is the fog height based?

 

@jc_lvngstn There's a bit of a fudge factor involved here, in that it's precisely the same fog factor affecting both, but just naively applying that fog factor to the clouds looks a bit wrong. It overrides the lighting too much and they look too dark. So the clouds apply a bit of overbrightening of lit spots on top of the fog (only atmospheric fog mind you, not custom fog). This looks great during the day but maybe a bit too bright if the scene looks like it should be fogged. I did try reducing this during overcast but there's some annoying transitional periods there that look even worse (bits that *shouldn't* be fogged but are). I can see about trying to strike a balance there, though it should be noted that custom fog does not exhibit the same issue.

@mons00n So I think I've got proper star rotations in. In doing so I actually ended up exposing an issue in my celestial body calculations, so thanks for bringing it up
Issue was that altitude and azimuth tell you an object's position in the sky, but not what its "up" vector should be. Constructing a quaternion from just those two values produces an odd wobble over the course of the day. The solution turned out to be storing a "celestial object" that sits directly above the north pole and acts like an up reference. This fixes the moon as well, which would subtly rotate in the sky over the duration of the night, but now is more stable! (actually, fun fact, I store the stars as a celestial object as well - an object that "orbits" the earth 1.0 AU away except it never actually moves in its orbit, so the equations boil down to essentially calculating the earth's rotation and tilt).

Also, in case it's useful, I have included inline documentation for all of the parameters that define a CelestialObject. It's actually not that hard to construct even an entire fantasy solar system with just a bit of thinking and a scratchpad handy. Mostly all of the parameters just define the parameters of orbit - like distance from sun, angular distance over time, eccentricity of orbit (how elliptical or circular is it, like an aspect ratio), etc.

 

Moon phases are in!



Fun fact, all I did was properly transform a normal map and then do a dot product with sun direction. Aside from eclipse events, this still turns out to be relatively accurate to real-world lunar cycles (double checked going several months from now in simulation with online lunar calendars).

Also fun fact: This would theoretically work with custom planets in the sky too (actually I might think about a system for defining custom planets to be rendered)

 

Beautiful! The clouds are really amazing!

I have a few comments/questions if you don't mind:

• Can multiple storms converge on each-other?

• Do storms gain or lose intensity?

• Are you able to add custom weather effects, like sandstorms, hail, etc...?

• It would be really cool if you could see lightning in the distance as a storm is approaching. I think it would really add more depth to a scene.

• In my opinion, the more I can easily customize the better.
  • It would be great if you were able to add different planets and or moons.

Keep up the great work!

 

Thank you! I've worked very hard on them

- I'll answer the first two questions at the same time. Storms don't converge, nor do they gain or lose intensity. The weather is essentially the product of a set of layered simplex noise generators which all move with the same user-definable cloud scroll value. So, as it is, you cannot have two storms scroll in from different directions nor can you have, say, two storms which grow to intersect with each other. That said, weather within a single storm can and does change over time, so for a single storm you can see rain increase or decrease in intensity, as well as chance/frequency of lighting strikes if you use the LightingController component.
I can take a look at doing something like this post-V1 however.

- To sort of answer your question, right now all of the weather effects (and other sounds) are separate particle systems and audio sources (plus a separate LightingController script for the lightning shown) which use a WeatherParameters object that contains animation curves for moisture, cloud cover, temperature, and sun height. The value of each curve is evaluated and then combined (right now just multiplied, thinking about integrating StagPoint.Eval so you can type a custom javascript expression directly into the inspector), and used for emission rate, audio source volume, lightning strike chance/frequency, etc. You can draw from the built-in scripts to come up with custom components for stuff like hail, or for custom events like sandstorms you could use a custom perlin noise based solution (in fact you might combine a similar approach to hail as well, intersecting the results of custom perlin noise with rainclouds, moisture, and temperature factors).
In any case, the weather system is designed to be modular and easy to access for custom scripts.

- Lightning in the distance is a bit hard. Right now it just evalutes weather values directly overhead for CPU-side stuff. I might have it evaluate weather conditions over a low-resolution grid on the CPU, which should improve average cloud cover estimates as well as perhaps allowing it to better determine where lightning can be positioned in the sky, for example.

- I think it'd be nice as well. I'll have to give it some thought on how I want to approach it. Right now it'd have to be done through code, as custom planet orbits have to be defined in a subclass of CelestialBody using property getters. Also would either have to impose a somewhat low max limit of planets, or use maybe a TextureArray of planet images (which imposes the limitation that planet textures all have to have the same format and dimensions).

 

Looks really good, I've been looking for a beautiful weather solution for a while. Let me know if you need a beta tester
For me the most important feature is the mini map showing cloud density around the player, such enabling you to have different weather around the world. How much control do we have to modify that?

 

Actually that isn't quite a feature per-se, it was just a debug display I had while working out the weather system. The weather is a shader-based blit to texture which currently encompasses a 32km^2 area centered around the camera (the size is configurable, but is mostly just meant to encompass the visible sky around the player). The weathermap texture wouldn't visually scale very well to a larger world.
I've been giving the weather around the world idea some thought though. Technically, it's already possible as long as you know where in the world the player is and can work out a set of climate parameters for that location (the idea being climate doesn't usually change so drastically that you can't just apply a single set of climate parameters to the whole sky and then just change those parameters with position). I may try and make it even easier to do this, however. I think I will include a Lerp function which interpolates between two ClimateInfo structs. Might also include some kind of "climate grid" system as a post-v1 release, which lets you stuff climate parameters into a grid representing your world and then query that grid using a sort of bilinear filtering (like an image, except each "pixel" is a ClimateInfo rather than a color) to produce interpolated climate at the player's position in the world.

 

If you can map it into some sort of 2d data array for us to populate that would make me very happy.

 

Another question I had was networking; are there specific variables that can be net-synced so that multiple clients will observe the same weather patterns, cloud cover, etc? TOD did this nicely for time & cloud cover by just synchronizing the time Ticks, and CloudUV (vector2). Lighting was a bit trickier but I simply RPC'd a random seed to the client which resulted in identical lightning bolts on all clients.

 

Actually, yes. The weather system was designed as a continuous function of time, position, and climate. Fed in the same player position, weather sim time (which is exposed as a public variable), and climate info, it will produce the same weather. Also means if you had a single player game, you could just save the weather sim time as part of your game save and when you reload the save the weather will return right where it was.
Lightning, yeah that's a little trickier. I can take a look at making it possible to sync with some sort of seed value combined with time. Another possibility is to sync lightning strikes with individual RPCs.

 

Yea I found that individual RPCs with seeds was the easiest way to make lighting synchronized across all clients with this asset.

 

Ah, I think I see what you're saying. If the idea behind the RNG is that a random int is generated and then used as the seed for the next random query, theoretically you could even just send the current seed to clients and then just sync individual lightning strikes as RPCs, as each strike causes the client to use the current seed to generate a new seed value and so each client should continue to end up with the same seed.

EDIT
Alright, it's supported. Ended up implementing a custom Xorshift-based PRNG so I could change the seed at any time unlike System.Random and also without affecting Unity's random. Now you can set the initial seed in the inspector for the LightningController, and at any time you can query or change the current seed value via LightningController.CurrentSeed.

 

The issue with this is that clients joining the game after numbers have been generated will be out of sync. So the server assigns a seed and invokes a lightning strike via RPC and the first random number will be generated. Client B then joins the game and gets the seed; on the next lightning RPC client B will generate the first value, while client A will generate the second value resulting in different results.

btw how are things going?! Haven't had any updates in a while =)

 

This is gorgeous, cannot wait to try.

 

So I've been a bit quiet because I was involved in a game jam recently (the RemakeJam)! I didn't get to implement almost any of the major features I wanted (you had to pick one of your first games ever released, and mine were all too big in scope to properly do in the week allowed), but it was fun anyway.

But anyway, it's back to work on SkyRay. I've got a new requested feature up and running, and that's exporting skyboxes! You can export either non-HDR skyboxes (it exports them as PNG images set to import as cubemaps), or as HDR (exports as a compressed EXR image instead of PNG). It automatically uses SkyRay's highest possibly quality settings when rendering a cubemap as well.



Additionally, I'm looking into the possibility of reflection probe integration. It's a bit of a challenge, because SkyRay is implemented as a post effect and also because reflection probe rendering is difficult to customize, but I'd love to be able to properly support reflection probes anyway.

 

@PhobicGunner : your asset looks very interesting !
Can you show us some pictures illustrating the difference between a cumulus, a stratus and a cirrus ? I think that's what is currently missing from lots of cloud assets on the market. Raymarching is often done against "generic" perlin noise texture, and that doesn't take into account the various shapes of the different kind of clouds.

 

So, SkyRay does not model stratus clouds for one. It does, however, model cumulus, cumulonimbus, and cirrus clouds. The approach I'm taking for this closely follows that of Horizon: Zero Dawn as it's based on similar methods.

The cirrus layer is just part of the skybox as it's flat enough that raymarching is overkill, and that uses a scrolling ridged fractal texture modified against itself to produce the sharp and wispy shapes mostly meant for providing some extra subtle visual interest to the sky:



Then, the cumulus and culumonimbus clouds are raymarched. They both actually use the same noise in order to save on performance and memory as having them separately sample the noise textures separately proved to be detrimental to performance. Just like in HZD, the noise texture itself is a highly tweaked combination of Perlin noise plus layered worley noise (inverted voronoi pits). The worley noise is used to add what the HZD docs refer to as a "packed cauliflower" shape, which looks better than just pure perlin which tends to produce amorphous wispy blobs rather than distinct cloud shapes.
The height density ramps provide the main distinction between the two (their densities being defined in two separate channels of a weather texture). So cumulus clouds are much smaller, lower, and more frequent:



Whereas cumulonimbus clouds are much taller, denser, and generally larger/wider:

 

@PhobicRunner : thanks for the explanation !
When you export as HDR texture, what's the color value of the clouds ?
We have a project where when compare a realtime rendering against some precalculated engine.
One idea was to export the skybox from Unity and use it inside the offline renderer. It's possible only if the skybox itself (and the sun) have proper values, as well as the clouds. I know that your asset is dedicated to clouds only, so we will use something else for the sky.

 

Forgive me, but I'm not quite sure if I understand the question.
What you see in that screenshot with the cubemap window is precisely what it renders out, skybox and all. If you select HDR, it will render whatever you have in the scene (currently, excluding objects but I think I will add the option to render scene objects too) in linear non-sRGB color to an EXR file. Do you mean what color the clouds would be if they had no self-shadowing? Even that depends on the height of the sun in the sky (since this also includes Eric Bruneton's scattering methods and a full day night cycle system), used to select a sun color from a precomputed gradient. If you pick a latitude/longitude and time of day that puts the sun at direct center top of the sky, then the clouds are lit by a pure white light. I'm also not sure what you mean by proper values, if you could clarify I may be able to answer whether or not it's already supported or if I need to add support for a new use case.

I guess it's a little difficult to answer what the cloud color is since this isn't *just* focused on clouds. Clouds are a large part of it, but it also is designed around having a full day/night cycle, sky scattering, and weather engine too. And a lot of these things go together (for example, the atmospheric scattering also plays a role in the color of the clouds, as it contributes color to the parts of the cloud that are in shadow, as well as distant clouds).

 

Got realtime reflection probes working today



I had to implement a totally custom rendering solution for reflection probes in order to do this, including figuring out how to reimplement Unity's GPU cubemap convolution.
The way it works is you attach a RenderSkyProbe component to your main camera, the same one with the AtmosphereClouds script. This script exposes a single static cubemap which contains just the sky and clouds.
Then, to each reflection probe in your scene, you attach a CustomRenderProbe script. This script completely takes over rendering of the reflection probe, supplying its own cubemap. Each of these makes use of the sky cubemap rendered by the RenderSkyProbe script so that the sky cubemap is only ever rendered once per frame no matter how many probes you have (and even then you can enable only one cubemap face per frame - will also probably expose an update frequency option so you get control over how often it updates).

 

Hi PhobicGunner
Any news ? would love to see some progress
this looks amazing

 

I am looking forward using this for the project I'm working on. Please let us know when the release date! I'm eager to buy it atm!

 

So today I sat down and implemented some climate controller example scripts. Remember, all of the weather effects I'm providing with SkyRay are sort of examples more than final production scripts - they absolutely *can* be used in production if they serve your purpose, but they're designed to be totally separate scripts small enough that you can easily take a look and use the concepts to create your own scripts to react to the same weather values - for example, by creating a snow accumulation script that keeps track of snow that has fallen or melted by responding to temperature and moisture parameters.

So in addition to those, I'm also providing a SeasonClimateController script. Currently, this lets you set climate parameters for the coldest part of the year and the warmest part of the year, as well as create a curve for the transition between the two, and it will interpolate between those two settings and provide the resulting climate data to the weather generator component. This allows you to change your weather over the course of the year, but additionally this relies on a new function which lets you interpolate between two climates in a single function call:

Code (csharp):

1.  
2. Climate c = Climate.Lerp( climateA, climateB, interpT );
3.  

Additionally, I'm also providing a currently unused function but could help someone nonetheless, a function for bilinearly interpolating climate values:

Code (csharp):

1.  
2. Climate c = Climate.BilinearInterpolate( climate00, climate01, climate10, climate11, new Vector2( 0.5, 0.5 ) );
3.  

This interpolates four climate values arranged in a grid as top left, top right, bottom left, bottom right, using a 2D vector of 0.0 - 1.0 interpolation factors. It interpolates on the horizontal and vertical axes in much the same way bilinear texture sampling works. This could be used, as an example, to implement some sort of world grid climate, where you grab the four climate cells around the player's position in your world and then perform bilinear interpolation to get the climate at the player's precise location, so that you could vary climate in your world with a simple grid of values.

As far as release date...
There's so many other extras I would love to work on, but sooner or later this thing has to be released. As it stands, my current plan is to get the documentation and script API worked out, put together the materials for the asset store, and submit sooner rather than later. It's already a relatively well featured system as it stands right now. There's definitely more I can do with this, but I can always get it submitted and then continue to provide all of the extras I'm eager to work on as free updates post-release.
This includes things like prototyping an actual grid system like I was just referring to so people can just use a drop-in script for it, as well as other visual effects like I would love to get volumetric lighting implemented and directly integrated with the clouds so you can see godrays filtered through cloud cover (I think it would look spectacular!), plus stuff like implementing a system where precipitation effects don't clip through world geometry so if you're underneath an overhang or something, there's no rain clipping through it (I have an idea for a way I could implement this efficiently). I don't think these are making it into a V1 but almost certainly post-release.

 

Would be great to see SkyRay goes live.

 

You've gone dark! Come back! =)