[Released] kode80 Volumetric Clouds (Ver 1.1.0)

This looks like a Unity bug regarding calling Graphics.DrawMesh() from OnPreCull() when you have their Advanced Water in your scene. I'm assuming you're on Windows because on OSX it hard crashes Unity every time. If I comment out the DrawMesh() call from my OnPreCull delegate, no crash.

I've submitted a bug report (the 2nd this week for OnPreCull issues) and am currently looking into a workaround.

 

Alrighty, I've fixed this issue along with a few other related bugs. kode80 Clouds 1.1.1 is available now from the usual link: http://kode80.com/downloads/assets/kode80Clouds.unitypackage

If you already have 1.1.0 installed, you can of course just use (Window/kode80/Check for Asset Updates) to grab the latest version.

Let me know how you get on, my apologies for this issue.

 

Thanks, I will. And it is no problem... The package has just been released, we were expecting issues like that for the next weeks. Will look into it later today, been a crazy day this morning.

 

Just tested V 1.2.1 and the clouds are rendering with water too! Great fix.

 

This is really cool stuff and just what I need for my game, but...
I can't seem to get the kind of performance shown in your vids. The demo scene sits at around 50 FPS and that is even with the terrain turned off. Is this to be expected or what's going on?
My specs are: Intel Core i5-4670 3,40 GHz. 8 GB ram. AMD Radeon HD 7850.

Btw. Profiler says the GFX.WaitForPresent takes 19 ms, and that is with Vsync ON and OFF.

I have another question as well. My game takes place above the clouds, so I'm wondering if its possible to flip the clouds so you look down on them instead of up (without using fancy camera tricks preferably). ex.

 

Excellent, glad that fixed it. I know that with the large number of platforms/hardware/3rd party assets, there's always likely to be some conflicts, but I'd still rather limit these issues as much as possible for you guys. Thanks for understanding.

 

For your card, at the default settings, that sounds about right. This is definitely not a light effect. With that said, there are 2 major optimizations that are disabled in the current version that I'm going to be fixing and reenabling in the next major update, which should give you a significant framerate boost for free.

There are also a lot of properties you can tweak to increase performance if your target hardware needs the help.

• Lower "Max Iterations", this is the maximum number of raycast steps taken per pixel. Lower numbers will give you a huge performance boost. The side effect of this is you'll start to notice more 'slices' in the final render, you can fix this by playing with the "Sample Scalar" property. Lowering the "Sample Scalar" property will cause each 'slice' to have a lower alpha, essentially hiding the lower iteration count by blending together.
• Make sure "Sub Pixel Size" is set to at least "2x2", this is the number of frames it takes for the full resolution render to converge. 2x2 means that each 'block' of the final image is 2x2 pixels, i.e. 4 pixels, i.e. the per frame resolution is actually 1/2 of whatever you have it set to in the properties. Over 4 frames it will render these lower resolution versions, using temporal reprojection to fill in the gaps. If you have slow moving clouds in your game (as clouds generally are) then you may be able to bump this up to 4x4, doing so will net you a huge saving as now it's only rendering 1/4 the resolution per frame. The reason I mention the speed your clouds are moving is this has a much bigger impact on how obvious the temporal reprojection step is - it works great for camera rotations, but if your clouds are animating super quickly you may start to notice a dithering pattern.
• Unless you need a fixed resolution (for VR for example), make sure the "Render Size" is set to "Camera Dimensions" and "Downsample" is set to 2. If you have really soft clouds you may be able to downsample even further.
• Try lowering "LOD Distance", there are 2 sample qualities used in the main shader and you can control how far from the camera the lower quality samples start to be used. Try running your game and slowly lowering this property, lower equals faster so you'll want it as low as is acceptable for your game.
• Raise the "Horizon Level" property as high as is acceptable for your game. This is the height of the horizon, any clouds below this will not be rendered. So for example, if your game takes place in a courtyard, with four walls obscuring the camera's view of the horizon, then you can raise the horizon level to just below what's visible above the walls and you will gain a huge performance boost since you are no longer rendering clouds that can't be seen.
• You can also use the above approach even if the player can see straight to the horizon by playing with the "Horizon Start Fade" and "Horizon Start Fade Alpha" properties - these control the smooth fading of the horizon, so if you set the "Horizon Level" to a higher value, you can then smoothly fade it so it blends into the background rather than abruptly stopping. Due to the atmosphere, clouds on the horizon take a lot of samples so if you don't have the performance to spare it's definitely worth just raising the "Horizon Level" a bit.
• Finally, it's worth pointing out that 'empty space' is cheaper to render than 'clouds' so if you have tried everything above and still need a little bit extra performance, you can try removing some of the clouds via the coverage editor. Obviously this is the last step you ever want to take, but it's worth mentioning.

I'm going to be putting together in an in-depth tutorial video over the next week that will demonstrate all of the properties, what they do, how to achieve certain looks and all of the performance tweaks I've mentioned above.

If you have any other questions about how things work/what properties do what etc. be sure to ask either on here, via DM or email (ben AT kode80).

Regarding placing the clouds below the camera rather than above. I've had a few people request this, as well as moving through the clouds. Both of these are on the roadmap, but will take some time to implement robustly. Having the camera above instead of below is fairly easy to implement though, so I may just add that into the next update.

 

Thank you for the elaborate response. I hope these soon-to-be-enabled optimizations will make a difference. I'll try adjusting the sliders some more till then.

 

By the way, related to the coverage map editing. On which version on unity did you tested it? On 5.3.4 it seems to work pretty odd, throws a lot of errors around in the console and there is no text on the buttons. Of course, coverage maps can be edited in a outside environment but it would be nicer if we could do it properly in Unity.

Would you require a screenshot or something? Thanks!

(sorry that I have to keep coming with bugs )

 

Wow, sorry to hear that. The Coverage Editor is a huge part of the asset, I want it to be as easy as possible to customize your clouds in your scene, so I definitely don't want you to have to manually create the textures due to it not working.

I'm away from my main computer right now, but I'm pretty sure that's on 5.3.4. This machine has 5.3.0.f4, and I've tested on several earlier versions (5.2.4 etc.) due to breaking changes Unity has made between minor versions.

I'll be back at my main machine shortly and will confirm.

 

Ok, I'm back at my main machine. I am running 5.3.4 (5.3.4p1 to be precise) and can confirm the Coverage Editor works fine. 2 things:

1) could you send me the errors you're getting, most important is the first error listed in the console, but all errors would be useful.

2) can you confirm that you installed a fresh copy of kode80 Clouds? As mentioned in the earlier update, Unity's package installer is really bad if files are moved/deleted. It won't delete files that have been removed from a package, and if files have been moved it will in fact update them in the old location. If you haven't done this, could you try deleting the /kode80 folder from your assets folder and then installing the latest version of kode80 Clouds and see if that fixes it?

 

Sorry, was away too. Will check everything again with a clean install, and if the problem persists I will contact you then with further details + screenshots and log errors so that everything is clear. I really hope it's Unity's package fault .

 

I tested again and the problem was related to the fact that I did not let the package in it's default 'kode80' folder. I had to move it somewhere else to keep the project clean. You had some hardcoded image retrieval but it was a minor issue and fixed it.

As for image editing it works great now, but it is not an artist's dream .

Speaking of which, another issue seems to have emerged, attached a screenshot. The clouds overlap the 'TreeCreator' billboard trees in the distance. I noticed your previous post related to that but I said that I won't go into that, with your fix but better let you fix it when you have the time so that I don't ruin something else .

By the way, the shadow casting is awesome, it looks like in the Uncharted 4's Madagascar level. Great feature.

 

Ok glad you got to the bottom of it. I'll remove the hardcoded GUI image paths in the next update so this isn't an issue.

Improving the general UX of the coverage editor is high on the list. There are a number of additional features I want to add and tweaks to existing ones to make it as pleasant to use as possible. If you have any suggestions of things you'd like or general improvements in the editor, please let me know!

Yep, the damn transparency ordering - I ran into this over the weekend and have fixed it in my local copy. It seems that Unity splits transparency into groups based on depth. In the last update I moved the render queue for the cloud blending pass and that fixed overlap with most transparencies, but it seems beyond a certain depth they're still an issue. If you open up CloudBlender.shader and CloudBlenderEditor.shader and change:
"Queue" = "Transparency"
to:
"Queue" = "Transparency-1"
This seems to fix it for all cases I've tried personally. Let me know if this works for you.

The only reason this pass needs transparency at all is so you can blend the clouds with a pre-existing skybox (I actually have a version that doesn't do HW blending, instead blending with the sky in the shader and rendering the result opaque to a skydome mesh). So it's just a case of getting the Unity queue right to beat these draw order issues. "Transparency-1" should do the trick, since it ensures it will be drawn before any transparencies but after all opaques.

Glad to hear you like the ground shadows, that screenshot looks nice!

 

I was thinking that there might be a way to opt out of processing pixels which won't be drawn. I assumed you might be doing this but you mentioned that its a good plan to adjust horizon and other parts to optimise if they'd be unseen behind high walls which got me thinking about opaque passes in general.

 

The clouds themselves are rendered to a RenderTexture, outside of the scene, so depth testing won't have any benefit during the actual cloud rendering pass. The transparency overlap issue mentioned above is a separate pass, literally just blending a worldspace fullscreen quad with the scene, to display the cloud's output RenderTexture.

The reason the clouds are always rendered, rather than doing depth testing, is (somewhat counter intuitively) for performance. A big part of the performance win is due to the temporal reprojection, this allows each frame to be rendered at a very low resolution, and then several frames (depending on the "Sub Pixel Size" setting) combined together to give the full resolution render. For this to work, the previous frame has to be reprojected using the current frame's camera matrices. If depth testing is performed, to cull cloud pixels, then you potentially end up with gaps around the edges where geometry 'existed' in the previous frame. The short of it is, you get ghosting from previous frames.

In the end, the temporal reprojection provides a much greater performance boost than that which you would get from depth testing.

Now, there are several ways around this, and they are all things I'm either looking into or already have experimental versions of locally, but for now the quality/performance ratio is better by just rendering the full frame. As mentioned earlier, there are a number of big optimizations on the cards, so performance will only get better! On a related note, I was working on something over the weekend that'll provide a big boost, using SDFs to drastically cut down on the raycast step.

 

Hello! Changed the queue from Transparency to Transparency-101 since I think billboards are at queue -100 and it works. Setting the queue at -1 doesn't work. Thanks for the help!

Gogo SDF's! It's only a few math integrals .

 

That's useful to know about the billboards, I'll take a look at that.

Yup, using distance fields for the purpose I have in mind in the cloud's shader would be practically free and should offer a huge performance boost across empty patches of sky. The only performance hit I can see is generating the DF itself and that can mostly happen offline. For runtime coverage map updates, as long as what you're adding already has a precomputed DF (the brushes in the editor for example) then you can skip recomputing the whole DF by simply doing a min() with old/new DF values.

In related news, today I went back to reexamine depth testing in the raycast pass and think I've come up with a solution to the issue that was preventing using depth testing with reprojection. This means a huge performance boost when clouds are occluded by scene geometry. So far it's looking really promising, and all signs point to it being in the next update.

I also got cloud reflections working yesterday. Updates a realtime cubemap which can be passed to any shader that accepts a cubemap and ReflectionProbes (via the customBakedTexture property). Still requires some polishing (no pun intended), but looking good.

 

This is the kind of obsessive mad science I love to see.

 

Just posted a quick vine demonstrating my fix for depth testing with temporal reproduction. For those interested, it does a super low resolution depth pass, turns it into a binary mask and then erodes the edges. This allows for some buffer space around the edges of occluding geometry, which fixes all ghosting caused by depth skipped pixels in previous frame.

TLDR; cloud pixels will no longer be rendered when occluded by scene geometry. (Vine was recorded on 3yr old MBP)

https://twitter.com/kode80/status/725377617877159936

 

I just gotta say, this is fascinating especially because it looks so good. It's truly eye candy.
Most of all, kudos to you for continuing to take it even further.

 

So I guess you're really aiming to put truesky out of business

 

Thank you so much, this has been/continues to be a ton of work, so I really appreciate it.

 

Not at all. I just want to make my clouds as good as they can be.

 

Hello! I'm just looking for volumetric clouds for my project and would like to know - whether it is planned the possibility of flight camera through the clouds? And if so - when approximately?

 

This is something that I'm definitely going to be looking into. I can't give you a firm date since it's going to take some experimentation, and there are other things that will take precedence in the near term. But I should know more within the next month and will continue to post WIP shots/video of dev as and when I have something interesting to share.

 

A nice scene, with your clouds and Tenkoku (and playway water).


https://drive.google.com/file/d/0B4-J2ITfmqYNOFk3QWpLRk5sVDQ/view?usp=sharing

 

Looks great really nice colors, I'd love to see it in motion!

 

I like how easy it is to just add another layer. The performance is great, and I think the clouds are beautiful.
I'll see if I can post something nice sometime this week

 

How the hell have I managed to miss this until now?!

 

I don't know, but I'm glad you found it - that shot's beautiful!

 

Thought you may want to take a look at this:

http://reset-game.net/?p=752

 

I completely forgot about this game. Their clouds & atmospherics look gorgeous!

 

Hey did you added those optimizations related to not rendering each pixel of the cloud?

Been a little off-topic for a little time.

 

I am beating myself up for missing this awesome asset. Now it seems that the clouds does not reflect on water. Is there a way to fix it?

 

Not in the main branch yet as there are a number of other things I'm adding for the next major release, but you can check out the DepthTest branch. https://github.com/kode80/kode80CloudsUnity3D/tree/DepthTest

 

Not in the current release. I do have reflections working locally, but I'm working on some optimizations specific to reflections that'll need to be in place before they're ready for a full release.

 

Is there a ETA on the water reflections?

 

Hey, just tested your awesome asset on HTC vive.
With gtx 1070 i got something between 45 and 90 fps.
45 when i've been looking up
and 90 when only around a half of the screen area was taken by clouds.
Downsampling was set to 2.

But may be there is a way to increase fps without increasing downsampling?

 

Is it being rendered twice, I think @kode80 mentioned it didn't really need to be.

 

Hm. Is there a workaround? As I understood by default they are rendered without stereo nonw

 

bug report:
In the depth test branch I am getting the pink error

Notice the pink triangle on the top of the screen

The pink triangle gets smaller by smaller subpixel size but still remain visible

This was not observed in the standard version, however standard version are roughly 200-300% more expensive performance wise.

 

Would it be possible for the cloud shadows to be added as a cookie to the directional light? This would enable the shadows to be visible regardless of shadow draw distance.

 

2 things to check:

• Make sure "Sub Pixel Size" is set to at least 2x2
• If you're working in the Vive, make sure that "Render Size" is set to "Fixed Dimensions" and "Fixed Width/Height" is manually set to the render dimensions you want (i.e. half the Vive's resolution). The reason for this is that Unity VR camera's report the game view dimensions, not the HMD's resolution. So what may be happening is you're rendering to a much bigger resolution than needed for decent quality in the HMD.

Let me know if this helps. (I'm also working on several optimizations that will be in the next release)

 

The pink pixels you are seeing is a debug marker I'm using to visually show where the occlusion testing is failing. I'll add an option to disable that so that you can use the depth branch while it's in development without having those glaring pink pixels.

 

My first approach at ground shadows was to use a cookie, however I couldn’t quite get it to look right. The current approach does a screen space raycast from the current point to the virtual skydome so that it can accurately detect cloud occlusion, which it then writes to the shadow buffer. Unfortunately, by writing to the shadow buffer it automatically get’s clipped based on the shadow distance setting. Doing it this way is important though as it means that any dynamic lights in the scene will affect cloud shadows correctly.

I do intend to revisit ground shadows once I've finished optimizations/bug fixes.

 

@kode80

Wouldn't it just work by instantiating a mesh with the cloud distribution texture and rendering the red and blue channel additively from the light position into a render texture. A kind of silly way to do it, but I don't see why it wouldn't work.

 

The main problem with this/using a cookie is it assumes the clouds are on a flat plane, they're not. The clouds exist in a slab of atmosphere curving up and over the camera from the horizon. So for accurate looking ground shadows you need to take this curvature into account.

The current approach is fairly cheap (it's just a ray/atmosphere intersection test based on frag position and light direction to lookup the correct spot in the coverage map) and gives the most accurate ground shadows for all light directions. There is no reason it can't work for the entire scene other than rendering to Unity's shadow buffer seems to cut out everything beyond the shadow distance, but this is something I'm sure I can work around.

 

By the way, can't remember where I've read this (in a post from a unity engineer) but isn't this the reason that we have shadow cascades for? I've just tried in a big scene a 1500 shadow view distance and it only eats up 2-3 extra MS (of course that is a lot in some cases I really don't know about your project). Of course I've modified the shadow cascades so that we have the only the fourth cascade is rendering at 1400 meters +.

Would you like to try that out too while we wait for kode's future possible fix?

 

@Assembler-Maze

That makes sense. A cookie approach would still be faster, but I kind of forgot you can tweak individual cascades in Unity. Thank you very much.