True Volumetric Lights (Now Open Source)

Thanks for answering

Unfortunately these errors prevent everything from working, I see no volumetric lights in the scene.
I don't need volumetric lights in my projects now, but was curious to give it a try and compare it with other solutions. I will update to 5.3.4 when possible.

Has anybody tested this package on non-DX11 gpus? Does it use DX11 specific features?

Thanks for your time.

 

It doesn't use DX11 specific features. At least not yet. It could work on DX9 hw. I just automatically target DX11 to make my life easier. Anyway, I changed shader target for all shaders to 4.0. That should theoretically work on DX10 class hw. I have no way to test though.

 

@Michal_ Sorry to bother you on the weekend, but I have attached Volumetric Light to my Directional Light (only light in the scene), and the Volumetric Light Renderer to my camera and put the provided "spot" texture in the slot.

Upon pressing play, I am greeted with the editor pausing, and 3 different errors, which all seem related to the buffers (?).

Code (CSharp):

1. Dimensions of color surface does not match dimensions of depth surface

Code (CSharp):

1. depthSurface == NULL || rcolorZero->backBuffer == depthSurface->backBuffer

Code (CSharp):

1. Dimensions of color surface does not match dimensions of depth surface
2. UnityEditor.DockArea:OnGUI()

 

A very popular error indeed. It has been discussed here many times already. It looks like a Unity and/or driver bug. Anyway, I really don't want to see it again so I made a "fix". It is not really a fix, it could decrease performance in some cases but at least that annoying message is gone. It affects full resolution rendering only.

 

I reckon this stuff will get more attention if you start a thread in WIP or Asset Store forum, perhaps when you've added some of the things you talked about in informal 'roadmap' that makes it a fuller atmospheric system?

 

After seeing Uncharted 4 through I saw that this kind of effect was absolutely essential in setting atmosphere and definitely deserves some attention

 

I suppose WIP forum would be a better fit. I'm just not sure I want more attention
Anyway, it doesn't look like I can move a thread. I would have to start a new one. I'll consider doing it with the next update.

 

This is amazing. Thank you so much @Michal_ . Since this is a gift I am not pressuring you but wondering when 5.4 officially comes out are you going to update it for it. I am using 5.3.4 but played with it in 5.4 beta 12 and the height fog and builds do not work. 5.4 is a beta though so no use building for it till the official release.

 

Support for 5.4 is planned but I won't be wasting my time with beta release. I still have nightmares from 5.0 beta to be honest...

 

Cool. That is what I was saying. Wait till the official launch in June. 5.3.4 builds do not work with the cinematic effects so I am looking forward to the official 5.4 when I can make a working build with everything working.

 

The issue is command buffers don't work on point lights in 5.4 betas. there was a regression. I've already submitted a bug to unity and its been fixed. Should be coming out in the next beta.

 

Hi,
First off this asset is amazing!
But i do have a question and i was hoping you guys could give me a bit more insight on how this is working exactly.


In the image above i am using a spot light to simulate a flashlight, bu as you can see on the edge on the left there are some "rings?" it looks like it is getting pixelated of something similar, i am not sure to be honest.

On the image below are the setting i am using:


I am looking forward to getting more insight on how all of this is working!

Regards

 

I guess what you see is color banding.

According to Unity's HDR documentation, one benefit of HDR would be "Reduction of banding in low frequency lighting areas". If you don't use HDR yet, you could give it a try. Additionally, I'd check if switching a few textures from compressed to uncompressed provides better results. Maybe you use some compressed lookup textures in your lighting calculations or so, that would benefit from RGBA rather than DXT.

Otherwise there is also a paper available that explains how Playdead workarounds color banding in their games:
Banding in Games: A Noisy Rant
But implementing their technique does not seem like something that can be done so easily.

 

Thank you for your comment, this is very helpfull!

I am using HDR, Deferred and Linear Color space.
So i will have a look at the links you posted and the textures.

Regards

 

Yep, @Peter77 is right, that's color banding. You usually use noise and/or dithering to fight it. If you're not a graphics programmer, then the easiest way how to reduce it is to add some noise. I believe there is a noise post-process effect in Unity standard image effects. It will obviously impact image quality but the noise doesn't have to be strong. Just add a little noise to break the pattern.

 

Thanks for the information.
I added very little to just break the pattern and it works like a charm.

And again many thanks for this asset, it is truly amazing.

Regards

 

Cool. But yeah I don't want to encourage you to do something you aren't comfortable with, if you don't want that much attention or support hassles then I'm not going to complain if you just stick with this thread.

In the grand scheme of things I guess we are now closer to finding out what the strengths and limitations of the volumetric fog/area lights stuff that Unity have made for the Adam demo is like, and this may have some bearing on how 'mainstream' your solution becomes over time.

 

Thanks for your great work.
For seeing this lights effects we should play game to see how it looks is there anyway to see result when game is not played too?

 

Yeah, I still see this more as a educational project than a production ready asset. Something people can learn from, extend it and something I can use for further experiments. I find storing light scattering in 3d texture (as Unity will) a more general/flexible solution. Actually, rewriting this to use the same tech as Unity wouldn't be very difficult. The techniques are pretty similar. But Unity will hopefully give us something more polished...

There is currently no way how to see the result in scene view when the game isn't running. A Unity limitation. There are some changes in 5.4 that let you apply image effects to scene view camera but I'm afraid it won't be good enough. I'll investigate it when 5.4 releases.

 

For example sunshine! it isn't good as your lights but we can see effect without running the game.
Anyway you done a great job and great favor to Unity.

 

Yes that all makes great sense. I'm also interested in how well theirs is integrated with the area lights technique they've developed. I was looking at some posts on Unity & Robert Cupisz's twitter feed from the last month or so and it seems this is their area light technique:

https://twitter.com/unity3d/status/733213642984988672

https://eheitzresearch.wordpress.com/415-2/

 

Have played with this a little more and noticed a major performance drop when this effect is applied to a rotating directional light. Is this a unfixable thing or something wrong?

 

are you sure you dont have enlighten turned on. If so it recalculates all the light bounces and can get really expensive. this shouldnt be linked to his volumetric lighting.

 

Sorry. You are right. Sick of Enlighten.

 

i dont get it why should enlighten interfere with the volume light integration? enlighten is doing its own thing right?
or do you mean the enlighten performance in general?

 

enlighten doesn't interface with the volumetric lighting. The user was wrongly attributing the slowdown that enlighten has when rotating the light.

 

Just saw this thread yesterday... looks mighty interesting! Waiting for the Unity solution promised to be revelead at Unite Europe, as I rather would have an officially sanction solution. But if that turns out to be disappointing (and lets be honest, many official Unity solutions do), I will give this system a try in a month or so.

Some questions though:

If Enlighten needs to be switched off, what to do for (faked) GI? Is his system calculating bounced lighting too? Is it at least calculating faked GI to feed to standard shaders? Do I need to take care of that myself?

In the images taken by users it looks like there is some ambient lighting going on still. How is this set up without Enlighten?
(sorry, just came back to Unity 5 after 6 months of trying out UE4, so the new Unity 5 features are still quite alien to me)


If I can get rid of enlighten and still get usable ambient lighting (even if faked or not as accurate), I will do a happy dance of joy. Even after the short while I have been struggling with the system I am sick and tired of it.

 

I never said it needs to be switched off, This user was wrongly attributing the slow down that enlighten has. You can have this effect on at the same time.

Edit: To clarify

When you use a directional light with unity while enlighten is turned on. There are two parts. One part is a real time shadow casting light that this raymarch technique uses. (so only direct sunlight is used in the volumetric pass)

The second part is enlighten which calculates the bounced lighting. if the directional light is rotated then enlighten needs to recalculate the bounces. hence the slow down.

You can use both the volumetric effect and enlighten at the same time, but the volumetric effect only ray marches the direct lighting.

 

Yes, as @Lexie said you can use it with enlighten or any other lighting model Unity supports. The volumetric fog effect is simply added on top of existing scene light.

 

Time for quick update. I admit I didn't touch this project for about a month now but it isn't dead. I finally found some time to work on it this week. I experimented with atmospheric scattering. It is far from being finished but I think it looks gorgeous so I'll show you anyway. Atmosphere from outer space to sea level. Again try to ignore poor video quality.

 

Ah, that makes sense. Yeah, I had the feeling enlighten could be quite expensive... yet with the controls provided by the RenderSettings, and by cutting back the update cycle (maybe only once per second), one could get fully dynamic Realtime GI while not completly spamming the CPU with Enlighten load, right? Just a question of optimization.

I see that some thirdparty assets (like time of day) give you the controls to to time the update frequency for ambient lighting. So I GUESS this is possible (could still be that enlighten in the background does calculate bounces for the dynamic lights, just not updates the ambient lighting in the end, IDK).


Thanks for clearing things up. I am excited to try this system in my project when I find time. One of the most interesting thirdparty assets to surface in quite a while.

 

Don't forget about supporting multiple volumetrics per light if possible! (I tried to hack your code to do it but I could never get two independent renderings of the effect)

Also while I'm thinking about it... would there be an easy way to make the color of the volumetric effect independent from the light? It'd make sense to make the user have to check an "Override color with" box and the a color selector.

Imagine if a user combined my feature requests... you could have a white light that emits 3 separate volumetric primary colors rays... a prism effect. It would be absolutely ridiculously cool.

 

Right.. You wanted to render the effect second time to simulate the sun. I completely forgot about it. Thankfully it is not very difficult to do. In fact, that's how I fake the sun in the atmospheric scattering video. Changing the color independently of the light is also easy to do. I want to focus on the atmospheric scattering now but I'll show you how to do it over the weekend. (PM me if I don't )

 

It turned out I made some changes month ago and forgot about it. There are minor shader optimizations and better dithering (8x8 kernel instead of 4x4). It is now on GitHub. There is also temporal filter but it is not ready yet.

@Dreamaster, if you download latest version, then you can do the following to render your sun.
VolumetricLight.cs - duplicate MieG parameter and optionally add color parameters

Code (CSharp):

1. // define parameters
2. [Range(0.0f, 0.999f)]
3. public float MieG = 0.1f;
4. [Range(0.0f, 0.999f)]
5. public float MieG2 = 0.1f;
6. public Color Color1;
7. public Color Color2;
8. ...
9.  
10. // send params to shader
11. _material.SetVector("_MieG", new Vector4(1 - (MieG * MieG), 1 + (MieG * MieG), 2 * MieG, 1.0f / (4.0f * Mathf.PI)));
12. _material.SetVector("_MieG2", new Vector4(1 - (MieG2 * MieG2), 1 + (MieG2 * MieG2), 2 * MieG2, 1.0f / (4.0f * Mathf.PI)));
13. _material.SetColor("_Color1", Color1);
14. _material.SetColor("_Color2", Color2);
15. ...

VolumetricLight.shader - apply mie phase function multiple times

Code (CSharp):

1.  
2. // define variables
3. float4 _MieG2;
4. float4 _Color1;
5. float4 _Color2;
6.  
7. // replace this --------------------------
8. #if defined (DIRECTIONAL) || defined (DIRECTIONAL_COOKIE)
9. // apply phase function for dir light
10. vlight *= MieScattering(cosAngle, _MieG);
11. #endif
12. // apply light's color
13. vlight *= _LightColor;
14.  
15. // with this -------------------------------
16. #if defined (DIRECTIONAL) || defined (DIRECTIONAL_COOKIE)
17. // dir light - apply phase function multiple times with different colors
18. vlight = vlight * MieScattering(cosAngle, _MieG) * _Color1 + vlight * MieScattering(cosAngle, _MieG2) * _Color2;
19. #else
20. // apply light's color for spot and point lights
21. vlight *= _LightColor;
22. #endif

Not sure if it will compile. I didn't try it. Feel free to contact me about it.

 

OH MAH GAH BECKY....
THANK ... YOU.... SIR...

 

Now we're cooking with gas!

Code (CSharp):

1.  
2.  if (Color1.r == 0f && Color1.g == 0f && Color1.b == 0f)
3.         { //black selected, then auto pass the light's color
4.  
5.             _material.SetColor("_Color1", _light.color);
6.         }
7.         else
8.         {
9.             _material.SetColor("_Color1", Color1);
10.         }
11.         if (Color2.r == 0f && Color2.g == 0f && Color2.b == 0f)
12.         { //black selected, then auto pass the light's color
13.             _material.SetColor("_Color2", _light.color);
14.         }
15.         else
16.         {
17.             _material.SetColor("_Color2", Color2);
18.         }
19.  

 

One more screenshot because I really want people to understand what we've just done here. This shot has two MieG settings, one close to 1, and the other much lower... Color1 is the color of the directional light, but Color2 was set to bright red. Since Michal's code is multiplying the colors together it creates a "fading" effect as the MieG1's effect begins to "lose" to MieG2's color as the rays fall towards the earth. The artistic possibilities are almost unlimited as you're free to make things that could never happen in real life if you wish. (For example in the screenshot I took above the Colors of the rays make a purple "sun" but the actual light color is pure white... so you get a purple sun, pink rays and white highlights on the mountains. Magic... this is just &*(&ing magic folks. Thanks again Michal!

 

You're very welcome. It sure looks great!

 

@Michal_ I was comparing the results of my volumetric lighting to yours and I noticed that your not grabbing the linear color from the light source. So the lights color is getting applied in gamma space while all your render textures are in linear space. Just add .linear when you grab the lights color.

 

Look great!But the fps is very low,can optimized ?

 

Right. I made two assumptions and both were wrong. First, I thought I'm setting the color to the material as color and not as vector. Apparently not. And related to that, I thought that every material property that is set as a color will be automatically converted to the right color space by Unity. It turned out only color properties that are explicitly stated in shader's property block are automatically converted. Thanks @Lexie. I guess I'll make it work in both spaces while I'm at it even though using gamma space makes little sense to me...

 

It is an expensive effect by nature. There is room for improvement but that is not my interest at the moment. I'll wait for Unity's solution before I invest more time into this. It should be around the corner and it should theoretically be better than this. I'll continue working on atmospheric scattering for now.
With that being said, you can trade quality for performance by changing rendering resolution (in VolumetricLightRenderer) or by reducing sample count per light. Out of curiosity, what graphics card are you using?

 

Michal is there anything you can think of why maybe your lights wouldn't show up in a compiled build of the game?

 

Add all the shaders into "Always included shaders" in graphics settings. Or something like that, I don't remember how exactly it is called.

 

SHAZAM!!! That was it, thanks!
So for right now... these 4 folders and their files, plus adding the those 3 shaders in the graphics settings (all as shown in the screenshot) are all you need to get these lights going in your project.

 

Tried it in my current project.... dude, this effect is sweet!

Expensive performance wise, but sweet. Makes dusk / dawn pop even in an isometric view. Makes the night come alive as soon as window lights go on.
If the effect wouldn't be so expensive per light enabled with it, it would be a must for all projects targetting high end PC Hardware. If only it would be screenspace and not per-light, but I guess this isn't going to work... is it?


Tried it on directional-, spot- and point lights. All worked without any problem. Two thumbs up.

Now, I noticed two things:
1) When I first added the volumetric scripts to my lights, I would get weird black-ish artefacts when starting my scene in the editor game view, and when turning the view around. I since played around with the light settings, especially brought the day length up from 1 minute (set so low for testing purposes) to five minutes (still to low for the game, but enough to enjoy that dawn a little bit longer).... after that, the artefacts are gone.
Maybe something with the light being moved too fast? The artefacts, when stopping turning the view at that moment, looked like part of the screen was in shadow... like a diagonal half of it.
2) Somehow I struggle with controlling the "length" of the rays with spotlights.... I have some window lights I am trying to get a subtle ray effect from, but the rays are either almost not there (noise and other settings turned down), or emit very long rays (All settings up)... played around with all the settings, couldn't find out what combination lets me get shorter, more subtle rays.
Any ideas?

 

Love your effect, this is what I have, however I really wish the performance would be better though.

 

Performance could be further improved but I want to see Unity's solution first. Chances are nobody will care for this asset in a month.

You can improve performance by lowering resolution and sample count. Keep sample count as low as possible. Only a few samples are usually enough for lights without shadows and something like 10-16 for shadow casting lights. It kind of depends on your scene though. You could try to lower sample count and/or disable shadows based on distance.

@gian-reto alig
Yeah it has to be computed per light.
1. I've seen something like it recently. I think there is a bug in directional light rendering.
2. This effect uses the same attenuation as the light itself. Length of the rays is controlled by light's range.

 

1. Funny enough, it only happens right at startup anymore. I am not sure what I changed, but now the problem is almost gone save the first second of the game.

2. Ah, makes sense. Might need to tune this then, the spotlight migt have a way to high range.


On the performance, I was thinking about mixing this solution with a mesh based lightray solution... "non-important lights", the ones with either very faint lightbeams or only visible in the distance would only get mesh lightbeam. Important lights would get mesh lightbeams that would then fade into the full volumetric solution by fading out the meshes and activating and fading in the volumetric light script (I guess this is possible) based on distance to the camera. The directional light would always use the volumetric light.

That would make sure CPU cycles are not lost on less important lights, while still giving the illusion that everything is volumetric.
Given these lightbeams can be optimized like all meshes (combining multiples, maybe even using instancing coming 5.4), it should be a cheaper way to render the lightbeams.

But yeah, lets see what Unity itself has come up with. Given it is meant for a cinematic usecase, probably performance still is not that great though. You might be surprised that your solution still is the better one (nothing against Unity, but given past expierience, I will not get my hopes up until I see the final results... )

 

Where did they say they were working on their own solution? I couldn't find anything on the forum.