Volumetric Light Beam - Volumetric Lighting solution compatible with Mobile, VR and WebGL

Thanks for your support! Stay tune on this thread

 

The 1.35 update has been released. It features full support of Sorting Layers and Order in Layer properties. Tweaking theses new properties allow to adjust how the Volumetric Light Beams are rendered with 2D Sprites. Dust Particles rendering is also adjusted according to the same properties.

 

The 1.36 update has been released:
- Add new "Gradient Color" feature. For the Color property, you can now choose between "Flat" (single/plain) and "Gradient" color.


- Merge "Inside Alpha" and "Outside Alpha" properties into one unique "Alpha" property.

Hope you'll like it

 

I a running into a problem- I want the volumetric light not to change at all when you go inside it, I want it to look the same as on the outside. But as soon as the camera begins to enter, the volumetric light slowly fades and becomes weaker. How can I have the very same intensity inside and outside of the beam? I tried using camera blending, it just softens the blending, thats it. Any fix for this?

 

Hi,

There are several things to take into account when the camera goes inside the beam:

- If you are looking at the light source while entering the beam, the problem you are talking about is not supposed to happen: maybe try to increase the "Glare Frontal" property to get a stronger beam in this case.

- If you are not looking at the light source, it's more complicated. The way I designed it is: the less you are facing the light source, the weaker the beam gets. That's simply because it looks really weird to see the beam if you are not looking at the light source at all: it's like you get dazzled but you don't get why. And in this case, the camera is probably looking at some objects in your scene lighted by the light, so it will look good. The only case in which it could look a bit strange is when you are entering a light beam which doesn't enlighten anything in the scenery. I am aware of this behavior, but it's a trade-off.

Note that it's basically impossible to compare this case with the real life, since when you are inside a light beam, your head will create a shadow: so you won't really see a light beam if you look in the same direction than the light.

However, I will try to add a new property to control this behavior in the next big update (the complete rewrite of the plugin that I am teasing for weeks, including box shapes and cookie texture).

Hope it makes more sense now.
Thanks

 

Hi, what If I showed you a video of what I am experiencing? Or showed you through Skype? It would be better (to me) through Skype, but if you cannot I'll make a video of it. EndiHaxhi is my skype username, and it has a picture of a deer with a bazooka.
I tried glare options, even turned all the way up, but still to no avail.

 

Please send me a video of the issue you are experimenting by email: techsaladunity@gmail.com
I'll see what I can do!
Thanks

 

Hi Beam Geometry is created on the TransparentFX layer. Can this be set to something else (does it make things not render properly?) and if it's ok, what's the best way to do this?

Thanks, as always

[Edit]

or better still, can the BeamGeometry be assigned to a Tag?

(the problem I have is that it's picking up bullet hole decals)

 

Hi there!
The layer on which the beam geometry is created can be changed in the config: http://saladgamer.com/vlb-doc/config/
For the tags you cannot, but I could add the feature quite easily.
Please let me know if changing the layer is enough or if you also need the tags.
Thanks

 

Thanks for the super prompt reply. I thought I'd previously seen that config file, and somehow couldn't find it again!

Adding a custom tag would be super useful. Much more flexible to have both options. I'm pretty sure my bullet hole decal (or some other form of triggering) is going to be a common issue with a few people.

 

Understood! I will add the tags in the config. I'll let you know.
Thanks for the suggestion

 

The 1.37 update has been released, featuring the Tag property in the Config to change the tag applied to beam GameObjects: http://saladgamer.com/vlb-doc/config/#tag

 

Can I use this as out door god ray?

 

Hi,
I honestly wouldn't recommend it, since it doesn't support directional lights, nor dynamic light scattering. This asset is more designed to simulate indoor volumetric spotlights.
For outdoor god rays, I would suggest you to look for another asset/solution.
Thanks.

 

There are some open source things that can do this fine. Or u can use sun shafts which is a better effect. Unity has them built in, they are free. Look at standard assets- effects-sun shafts.

 

@techsalad Is there a way to reduce the number of draw calls or to have some sort of occlusion or distance culling? Don't seem to have access to LOD culling or otherwise for the drawn mesh

 

Hi thanks for your message.
- Regarding the drawcalls, I don't think it's really possible to reduce them with the current version of the shader, since it's a 2 pass shaders and it's not to batch multi-pass shaders in Unity.
- The beams are rendered using standard meshes, which are already automatically culled by the static culling system in Unity.
- However doing a distance culling is a very good idea. I will investigate the idea. Thanks for the suggestion.

 

Any recommendations for using these with deferred rendering since they have transparency? Does making them small (ie only 1 meter or less from the light) improve performance? I looked through a lot of the documentation and I'm just trying to get everything as optimized as possible.

 

There are no specific recommendations regarding deferred rendering.

About more general performance best practice, I could suggest:
- making the beams smaller will improve the performance for sure: the smaller they are, the more chance to be culled off they will.
- disable the 3D Noise texture when possible
- do not use the Dust Particles feature (since they create actual particles, it can be performance heavy)

If you want to investigate distance culling on your side and try to make something to fit your particular need, I could suggest you to check the VolumetricDustParticles.cs script which perform some culling for the particles. Basically:
- attach a custom script to your light beam
- in Update(), compute the distance between the camera and the beam. Depending on this distance, you could:
- disable the 3D Noise (if enabled)
- smoothly fade out the beam
- completely hide the beam (by disabling the VLB.VolumetricLightBeam component)

By the way, do you actually encounter performance issues when using the plugin? How many beams do you render in your scene? On which platform do you run your project?

Thanks

 

On 2015 mac and a mid range PC. I had started by putting on every spotlight in my scene (medium sized building, probably around 100 to 150 baked lights) to test and am scaling back. My draw calls at a distance went from around 600-700 to 1200. I'm not using dust particles on any and using 3d noise on select ones. I'll be working on some stuff to cull entire rooms of objects or just these when no cameras in the scene are within distance (there are occasionally multiple cameras).

 

Thanks for the feedback. This is strange if you have so many drawcalls. Each beam should not generate more than 2 drawcalls (one foreach pass).
I'll let you know if I find some optimization.

 

I really needed this. Is there any way to manually set the inside/outside values in the latest version?

To clarify, I basically don't want anything to render if I'm inside the beam. When I'm inside, it lights up the entire scene which i don't want.

 

Oh sorry about that! I really thought if was not useful to anyone.
If you want I can restore it, and send you a version ASAP. If you are interested, please send me an email at techsaladunity@gmail.com
Sorry for the inconvenience.

 

Sent you an e-mail with examples. Thanks for the quick reply.

 

Hi, just wanted to see when you think you may be able to provide a version with that fix.

Thanks again for the prompt reply and help.

 

Should be able tomorrow. But I haven't received any email from you. Have you sent me one?

 

Yeah, I sent it yesterday to the email you listed above. I'll go ahead and send another.

 

Second e-mail sent with the pictures and description of my issue.

 

@techsalad Fixed my issue super fast! Thank you! This is a fantastic asset!

 

Glad to help Thank you very much!

 

Just added to the wish list. The support from the dev alone means a lot, it's really rare to see something like this. Will definitely get it in a few days.
I just have a couple of thoughts passing by; First off, the light cookie support is amazing, considering the way this is done. It's just that I feel it can be a bit too sharp (the yellow one from the video specifically caught my attention), as, y'know, light scatters all around the place in real life. I think a toggle with a simple blur pass to the shader can help alleviate this and make it more subtle.
And second, can I use the volume as just a mask for a particle system? Like in less dense mediums where it's just the dust particles wavering around.
Great stuff anyway.

 

Hi! Thank you very much for your interest.

I really appreciate your feedback regarding the rendering of the cookie effect. But just to be clear: the cookie texture feature is still not released on the asset store. I have been teasing it for months now, but it's still not out yet. But it will one day

About your question about the particles, no I don't think you can do that. I am not aware of anything like that in the Unity Particle System.

Thanks

 

I don't think you got me. I meant 'mask' as in the dust particle feature that's already in the package but without the light beam cone shining with it (thus being just a mask that's culling all of the particles).

 

Oh ok I understand! So yes it would be possible. I will definitely investigate it once the cookie feature will be released.

 

Hi there,

I'm quite interested by this asset, especially since the rectangular-shaped beams and cookies showcase.

I'll definitively take it on the next update.

 

Thanks for your interest. To be very clear, the rectangular-shaped beams and cookie features are still not released. I will make sure to announce it on this thread when it will be available

 

The 1.40 version of the plugin has been released. Still no "box shaped" nor "cookie" feature, but still pretty cool: this release is focused on compatibility to make sure the plugin runs as well as possible on low-end mobile platforms.

I tested the plugin on dozen of mobile devices. This new update fixes visual artifacts and issues about the gradient color feature that could appear on devices using OpenGL ES 2.0. I wrote a custom QA tests system to deeply stress-test each features of the plugin and prevent any future regression. I will try to write a post about it since I am pretty happy with the solution I came up with, and I think it could help other developers.

I added some useful information about Unity versions and target platforms in the documentation to be very clear about what's compatible and what's not.

 

I picked this up yesterday because I thought it looked nice, and would save me some time.

I have a little bit of initial feedback though. You are doing way too much in the fragment shader. It compiles to about 163 instructions which is probably fine for PC, but I am targeting Oculus Go (at 72 FPS) where that is really too heavy.

Luckily, it looks like there is a lot of low-hanging fruit to optimize. In particular, I noticed you are calculating the camera object space position in the fragment shader which, if you are close to a lightbeam, is a full matrix multiplication for millions of pixels that should only need to be done once per frame per object. There seems to be a lot of other geometric calculations (distance, etc.) that should be shifted to the vertex where linear interpolation isn't going to hurt your results at all. Your texture coordinates in particular should be shifted to the vertex because then the texture data can be pre-fetched (just drop the frac). You have a ton of spare interpolators even on ES2 where these kinds of optimizations are usually more important.

It's pretty easy to alter so I shifted pretty much everything to the vertex except for the clip(), the depth blending, the noise texture fetch, and the Unity fog. With that it is only 9 frag instructions with the other 170-ish done in the vertex. I added a "divisions" property in your light beam component to let me customize the lengthwise tessellation of the the cone geometry and it seems like a 32 x 32 cone does a pretty decent job. You need more for the really long or large cones, obviously, but even with that bit of extra geometry it's a pretty substantial savings for the GPU.

Some code moved to the vertex will introduce a bit of visual degradation so it would be nice to have a toggle to enable those optimizations. But it would be nice to have them.

I also let the noise intensity go up to 2 which let me design a patchier type of lightbeam so you might want to consider that as well (lerping past 0 or1 works fine).

Just a quick screenshot to show you what 9 fragment instructions looks like (1088 vertices):


Other than that I am pretty happy with it and the way it looks. I am probably going to keep customizing my version of the shader and remove some of the fluff I don't need to keep it as lightweight as possible, but hopefully that will help you optimize your base shader a bit for future releases. These light beams are a really nice touch to finish off certain scenes.

 

Hi!
Thanks a lot for your useful and detailed feedback. It's very nice of you to share that. I will definitely take your suggestions and experiments into account.
Regarding the cone lengthwise tesselation that you had to introduce because you moved a lot of computation from the fragment to the vertex shader right: without it, the result is really bad?
Thanks again

 

Would be cool if your optimisations are added to the package, would love to use them too.

 

Here is a slightly larger shot to show the artefacts with a few different levels of tessellation. I am just changing the parameters to the GenerateConeZ_Radius() function call.

They become more apparent with the multi-colored beam and when you go close to or inside the beams, but it would be fairly straight-forward to auto-generate a couple LODs to boost the quality when you are very close. For mobile, it would also be nice to be able to batch lightbeams. Simply merge multiple beam geometries into one mesh and control them all with a single VolumetricLightBeam component.

I can send you my version of the shaders. It's pretty straightforward to shift the functions around--I did it all this morning--but the slightly trickier part is figuring out exactly what can move there without any noticeable loss of quality on a PC. Working on mobile VR, I pretty much want to shift everything I can to the vertex, tweak the tessellation, and learn to live with a few interpolation artefacts. On PC, you can afford to have a lower tolerance for error.

It would be nice to have a per-lightbeam toggle even on PC to save performance on less important background lights.

 

Thanks for the info. Sure feel free to send me the optimised shader to techsaladunity@gmail.com. Glad you could have done that quite quickly without wasting too much time.

Like mentioned in a previous post, I have an internal QA tests framework, so I could easily run it with different shader variations on all supported platforms to see how it goes. I will also see how I could expose these optimisations nicely in the editor.

Your idea about merging multiple beam geometries into 1 big buffer is interesting. Some thoughts about it:
- I guess I would have to use a MaterialPropertyBlock to specify the proper matrix to each "portion" (beam) of the big buffer. So if I need to use a MaterialPropertyBlock, I could set other shader properties per "portion", such as the current beam properties (length, color...), which means you could have beams with different shapes, color, etc... merged into 1 buffer (without having to control them all with a single VolumetricLightBeam). The only issue I see is about shaders variants: since some features such as 3D Noise or color gradient swap the shader variant, all the beams merged together would have to use the same shader variant.
- This could be quite tricky to expose in the editor. I want the user to only batch beams which are located close to each other. Because merging multiple beams will "kill" the occlusion (you see 1 beam = you have to render them all), so merging too many beams together could actually be worth than doing nothing.
- The best would have be to do nothing and to rely on the build-in dynamic batching, by the plugin uses a 2-passes, so I cannot use this feature

Thanks

 

Yeah, using a property block per lightbeam would be great, and just only bake lightbeams with the same shader features enabled. The use case I am thinking of is having a room with holes int he ceiling or something and I might want to have a few dozen little lightbeams shining through for effect, but I can't afford that many different objects each with its own little vertex buffer.

I think some documentation and maybe a UI warning about occlusion when batching would be fine. I think it's better to trust the user to some extent, and allow them to make sensible groupings of which objects to batch. They are going to know the specifics of their scene best.

Dynamic batching is pretty limited because the overhead makes it only useful for pretty small meshes anyway. But you could probably remove that second pass by baking the outsideBeam variable into one of the texture coordinate components and then double up the geometry for the inside. A bit of extra memory, but it might be worth it to get rid of the extra pass. GPUs are pretty fantastic at chewing through buffers; it's the state changes that slow them down.

Static batching should actually help automatically, but I usually prefer to manually batch things so I know they are being combined in a sensible way.

Some things to think about anyway. I know making design decisions for the general case can always be difficult. I have the advantage of optimizing for a specific type of level geometry on a specific type of device so that makes things easier

 

Thanks. I am investigating all these ideas. Like you mentioned, I probably won't be able to optimize the shader as much as you did because I have to keep it general enough for most users. But I will do my best to offer several levels of quality/optimization and expose that in a comprehensive way in the editor.

 

I am using the current version of this package and I cant get the effect to show when inside the beam, I tried with many previous version also but never worked for me, not sure what I am doing wrong here...

Below you can see two screenshots one outside and one inside.

This is a VR project and it doesn't work in scene view which I think uses the forward renderer or in the game I use the deferred rendering path.

 

Hi and thanks for your message.
To be sure to understand your issue, what result would you expect in the 2nd screenshot ? Would you expect the foreground (the entrance of your "bunker") to appear brighter?
Thanks.

 

I would expect the same effect on the inside so same kind of fog like effect inside the beam.

 

Ok thanks for the feedback. I'll see if I can improve the rendering in this particular case. I'll let you know.
Thanks.

 

Hi @techsalad , I am looking for a very similar effect but the opposite. Let me explain, I would like to create a volumetric cone but not of light but darkness if that makes sense. So essentially imagine a lit scene but a particular area needs to be made darker or more shadowy. Is it possible to create dark light beams? I really like the way the beams naturally blend into the scene without looking like an obvious cone, I am wondering if this will still work for dark lights.

 

Hi! I wouldn't have anticipated this use case, but it's an interesting suggestion!
So it's not possible to achieve this kind of effect with the current version. But I guess it would only require some changes on the blending mode. I can investigate this solution and send you some screenshots if it works. I'll let you know.
Thanks!