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

Like Lars-Steenhoff above I also would like volumetric shadows. It was advertised as Truly Volumetric even inside the beam of light and say it generates "high quality light shafts rays effects". But it doesn't. I think its great as an asset if you want to see volumetric lighting from the outside but I was expecting the true volumetric shadows as the description suggested. Can I get a refund please? Thanks. Iain

 

Hi,
Thank you for your message. I am sorry that you are not satisfied with the asset and ashamed if you felt misled.
Just to explain, I advertise the asset as "truly volumetric" because it generates a real volumetric mesh and you can see the effect even when the camera is located inside the beam. It's "volumetric" unlike some other solutions based a sprites/billboards for example.
But indeed it doesn't generate realtime shadow, that's why I list "partial occlusion" as not supported. But I will try to change the description and to be more clear.
Obviously if the asset is not useful to you I will be happy to grant you a refund. Please send me an email with your invoice ID at techsaladunity@gmail.com
Sorry again.
TS

 

Hi guys,
The 1.51 version of the plugin has been released, featuring the Scriptable Render Pipeline (HDRP and LWRP) support!



It requires some simple configuration, so please make sure to read the documentation about SRP support.
Do not hesitate if you need any help.
Enjoy!
TS

 

Just to let you know that I am aware of some annoying log errors appearing in the latest beta 2018.3.0b1
If you have some volumetric light beams in a prefab, you could see the following error message appearing in the console:

This error is caused by the new prefab workflow introduced in this beta. Note that these error messages don't interfere with the rendering, meaning that your light beams will be properly rendered in your game.
However I am working on a fix to properly support this new workflow, to be released ASAP in a next update.
Meanwhile, please notify me if you encounter any other issue when using the latest beta.
Thanks
TS

 

Hi, I am also looking forward to the Square volumetric light, or has it already been implemented?

 

Hi and thanks for your interest. No this feature is still not implemented but like mentionned in a previous post I have a WIP version. Please send me an email with your invoice id at techsaladunity@gmail.com so I can share it with you.
Thanks .

 

I'm looking at this asset to use it to create light beams for bullet holes. Is it any overhead showing or creating these on the fly? We can pool them and move them to the bullet hole when a new bullet hole is created, but if the player sprays a wall it means maybe 30 holes within a short timespan.

 

is supported inHDRP unity 2018.2.8?

 

Hi and thanks for your interest.

With the current version, without pooling, there will be the overhead of creating a Material per beam (this is how it works currently). But you could simply pool the beams to avoid this overhead.

Please note that I am currently working on GPU instancing optimization, which should be released very soon. With this feature enabled, it will not require 1 beam per beam anymore: 1 material will be enough to render all the beams. So you won't have this overhead even without pooling. In addition, the beams could be batched at runtime, drastically decreasing the drawcalls count.

Hope it helps,
Thanks

 

Hi Dave,
Yes, HDRP (and LWRP) are supported: http://saladgamer.com/vlb-doc/compatibility/#high-definition-pipeline-hdrp
Honestly I haven't tested the Unity 2018.2.8 version specifically. I can try it and I will let you know if everything is fine.

EDIT:
Hi again @Dave4654
So I just tried the plugin with HDRP in Unity 2018.2.8 and it works perfectly fine.

Thanks
TS

 

Ah ok, so that basicly means one set pass call per beam then? That's a bummer. Cool we target VR so minimzing draw calls are super important.

Also I guess oclussion culling etc are used so you don't draw them when culled?

 

It depends on the configuration you choose. You can choose to use a 2-pass or a single-pass shader: http://saladgamer.com/vlb-doc/config/#force-single-pass
With the 2-pass shader, it will be 2 drawcalls per beam.
With the single-pass shader, it will be 1 drawcall per beam.

With the upcoming GPU instancing feature, you will be able to batch "unlimited" beams in 1 single drawcall. More info will come soon. I will announce it on this forum thread once available

And yes the beams are culled off by occlusion culling.

 

I'm trying the LWSRP on Metal for iOS and get one error in the editor:

Metal: Error creating pipeline state (Hidden/VolumetricLightBeam2Pass): Link failed: The type of fragment input user(TEXCOORD0) does not match the type of the corresponding vertex shader output
(null)

Any idea what this can be? Thanks

 

I'll have a look. I'll let you know.
Thanks

 

and maybe i should mention that im using 2018.3 b4

 

Hi, I can't find why my Volumetric Light Beam will automatically changes its render layer/camera.
I have two cameras each has different settings, one watches Layer Default the other watches Layer FX.
While entering playmode, the rendering result will change unless I reset its layer manually.

 

Hi,

It's actually a feature!

In fact there are 2 gameobjects. The master with the VLB component on it (the one on which you tried to change the layer), and a child "beam geometry" geometry which is procedurally generated and is the actual geometry rendered.

The plugin controls on which layer the child gameobjects are generated via the config file: http://saladgamer.com/vlb-doc/config/#layer
So what's happening is that you properly change the layer of the master and its child manually. But once you press play, the child is recomputed with the layer specified in the config.

In short, it's possible to change the layer on which the procedural beams will be generated via the config. But it's currently not possible to have some beams on layer A and some beams on layer B.

But I could definitely develop this feature for you if you need it. What I could do is to make the layer specified in the config optional, so you could keep the entire control on the layers of your beams.
Let me know.
Thanks

 

Thanks for the quick reply. For now, I just need my beams on one correct layer, so the Configuration way is enough.
That will be perfect if we could specify beam's layer individually in the future.

 

Great! Thanks for your feedback.
I will develop the individual layer feature for the next update.
Thanks

 

Hi, we are very happy with the asset, but sadly we have a problem on Android, using the latest Unity. we get this error when the app starts with a black screen:

10-14 17:49:47.940 14882-14903/? E/Unity: IndexOutOfRangeException: Array index is out of range.
at VLB.Config.get_Instance () [0x00000] in <filename unknown>:0
at VLB.Noise3D.LoadIfNeeded () [0x00000] in <filename unknown>:0
at VLB.Noise3D.OnStartUp () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

We can see that the exception happens because the Config asset was not found in the Resources, but unsure how to proceed.

Any help will be appreciated...

 

Hi!
Thank you for notifying this issue. That's really strange. The Config asset is supposed to be included in the builds since it's in a "Resources". I have a few questions to try to pinpoint the problem:
- Go in your Assets/Plugins/VolumetricLightBeam/Resources folder. Do you have a Config.asset file in this folder?
- Does the problem occur only when you export on Android?
- What version of Unity are you using? PC or Mac?
- Do you use any other asset that strip/clean "unused" assets?
(If you prefer you can answer me in a private message)
Many thanks!

 

I'm very happy with the performance and the look of the asset, thank you so far!

Would you consider adding an option to generate the beam geometry at edit time?

I noticed, that the call to GenerateGeometry in Start can take substantially long on low-end hardware (mobile VR). I don't expect any optimizations of the geometry creation routine to remedy such problems, instead I hope for a precompute feature. Ideally, such an option would run as a build process (which is also called before play mode is entered in the editor) and cache as much as possible.

 

Hi,
Thank you very much for your suggestion.
So you would expect this feature to save some loading time on mobile devices?
To be honest I am a bit afraid a feature like this would be complicated to maintain. Maintaining 2 workflow is a PITA. But if you think it would help you I will consider it.
Do you use the "shared mesh" feature on your beams? http://saladgamer.com/vlb-doc/comp-lightbeam/#mesh-type
Because when using the shared mesh, only 1 beam geometry is generated at start-up, and so I think this processing time won't be really significant.
Thanks

 

Yes, I'm already using the feature and I think it is saving some performance. However, I noticed that even when sharing the mesh it is considerably slow during Start on low-end hardware.

Specifically, this is our profiler result:



I have already implemented a quick-fix by removing the HideFlags from the generated geometry and instead serialize all game objects, meshes and references to the scene. This way nothing needs to be instantiated when starting the game. This potentially introduces some side-effects or bugs with the rest of the system, but for now it was working great, which is why I thought this may be a feature others would benefit from.

Thank you for considering this, but it's totally at your discretion whether this is a feature more users would benefit from or too specific.

Edit: Cleared up some confusing information.

 

What do you mean by that?
Thanks!

 

Sorry, I was confusing some other changes I made. I cleared up my post above.

Basically, the call to GenerateGeometry in Start is taking too long on our mobile device, so I moved the mesh generation part entirely into the editor by serializing all meshes and objects with the scene, instead of letting them be created in Start. This may be a very specific optimization to the project I'm working on, but maybe other user would also benefit from such an option.

 

Ok thanks for the clarification, it's really helpful
I am glad if you managed to figure a solution for your project. Like you mentioned, it could be an interested feature for other users. I will definitely consider integrating it as a built-in feature.
Thank you very much for the suggestion and for the details.

 

Thank you very much for notifying me. Glad it works!
Thanks

 

Just in case anyone else is having this problem, I think what really solved the issue was that in the Build setting under "other setting" we added to the Preloaded Assets list the Config.asset file

 

@techsalad
How to remove banding? the cone is still visible no matter how Soft Intersection blending distances that i have set.

 

Hi,
sorry I don't understand what's the problem on the screenshot. The area you are pointing at looks like the floor, which is lighted by the Unity spotlight (not related to the light beam plugin). But maybe I am wrong because I don't really understand where your camera is located. Please provide me more info.
Thanks

 

Please view the screenshot at full resolution, i have taken new screenshot


If you notice for example the red line, you can see in the same position, there is some-kind of white seams bending like intersections for the cone, what i want is to smooth it out so the projected cone intersections on the floor is less visible. If the scene being played, the projected inter-sectioning cone become more visible.

P.S i have already reverted to the vanilla version which come from the asset store.

 

Hi,
Thanks for the clarification.
I don't think the problem is related to the beam plugin.
I tried to place the camera at the same spot than you did in the last screenshot. You can see some "bands" at the location you highlighted even with the Unity light only (with the volumetric beam disabled):


I have to admit than turning the volumetric beam on make the bands a bit more visible, but I think that's only because it makes the area brighter.

Anyway, banding is a very common issue in Unity, specially with lighting. That's because the color range is encoded on 256 values when using regular SDR cameras, which is simply not enough to simulate smooth transitions between dark and bright areas.

The most common way to reduce banding is to use a HDR camera. Just enable HDR on the main camera, and even when re-enabling the volumetric beam, the banding will become barely noticeable.


Hope it helps!
Thanks
TS

 

Hey- I'm having trouble getting VLB to work with LWRP on iOS. I've got the latest version, and I followed the instructions (force single-pass, etc.) but I can't get it to work when built to the phone. It looks fine in the editor, but they don't appear on iOS. No errors in the console. Is anyone else having the same issue? Thanks!

 

Hi,
I just tried on my iOS device but don't manage to reproduce the issue you are mentioning. FYI I tried with Unity 2018.3.0b4 and on iOS 11.2.1 with Metal API. What is the version of Unity / iOS you are using?

It might be related to the issue @Lars-Steenhoff reported. In the folder Plugins\VolumetricLightBeam\Resources\Shaders, open the files VolumetricLightBeam1Pass.shader and VolumetricLightBeam2Pass.shader and remove the line #pragma target 3.0 (1 occurrence in VolumetricLightBeam1Pass and 2 occurrences and VolumetricLightBeam2Pass).

Please let me know if it fixes the issue. If it doesn't, please provide me more info (Unity version, iOS version, Metal or OpenGL API) and the output log when running on iOS.
Many thanks!

 

Hey- thanks for the quick reply! It didn't seem to work, though. I'm using 2018.3.0b5, iOS 12.1, Metal, and no relevant console output. Let me know what you think; thanks for the help!

 

Ok thanks for the information. I will update my devices to the same version to try to reproduce it.
Few more questions:
- Is it an iPhone or another iDevice?
- Have you tried to run your project on the iPhone emulator to see if it works?
Thanks

 

Hey– I did a little more testing and it looks like it's got something to do with the Unity ARKit plugin. When I slim down the scene to just display the light, it works, but when I try to incorporate it with the ARKit plugin, it breaks. Any idea what it could be?

 

Thanks for the info. That's interesting...
No I don't really know why ARkit would prevent the beams from rendering. I never used the ARkit plugin and I actually don't have a device compatible with it. I'll see if I can do something with the simulator.
The only thing I could think of is maybe there is a problem with the depth texture. Could you try to reenable ARkit and to disable the blending with opaque geometry by setting this property of your beam to 0. It will prevent from reading the depth texture: http://saladgamer.com/vlb-doc/comp-lightbeam/#opaque-geometry
Thanks

 

Looks like that was it! Any ideas for how to work around it and keep soft intersections? It helps the look so much! Thanks!

 

Thanks for the feedback. Ok so the problem occurs only with ARKit and soft intersections enabled. That's strange.
I won't assume any possible fixes since I am really not familiar with ARKit. But I am currently updating all my devices (OSX, XCode and iDevice) and trying to get my hand on a ARKit-compatible device to be able to reproduce the issue. I'll let you know.

 

Hi, can this do flickering Lights ?

 

Sure. You just have to disable and enable the VolumetricLightBeam component, or the whole gameobject in a coroutine for example. Let me know if you need help to make the script.
Thanks

 

Hi again,

So I managed to run a test scene with LWRP and the ARKit plugin on an iPhone 7. I force the app to require ARKit to make sure it was enabled.


If I don't put anything special in my scene, it runs without any difference, so I guess it's like ARKit wasn't enabled.

So I dropped a Unity AR Camera Manager in my scene. When I run it on the iPhone, the first frame seems fine and then all the geometry of my scene (not the volumetric light beams) appear grey, like if it was not textured. And I can move the camera by moving the phone, so I assume ARKit is properly enabled in this case.


Obviously I am doing something wrong. If I can't even manage to properly render standard geometry with ARKit enabled, I can't deduce anything about the rendering of the beams.

Could you give me more info about your scene (about the ARKit specific components and objects you added), and how you managed to render LWRP geometry with ARKit enabled? Or maybe could you share a subset of your project to me so I could reproduce the bug more easily?

Many thanks!

 

Hi! This asset is impressive so far, and really useful!
1. Is there a way to fade out the volumetric light relative to the light's intensity?
2. What is the status on volumetric light mesh shaped by cookie?
Thanks!

 

Hi and thanks
1. No there is currently no way to do that, except coding your own script. But it should be pretty easy to do, so I can try to investigate.
2. I still have a WIP version of the feature I could share with you (send me an email so I could send it to you if you want). But I haven't worked on it for a couple of months, since I always have more important features to work on, like improving compatibility each time there a new Unity version
Thanks

 

Can you use the dynamic occlusion with 2d box coliders instead of 3D box coliders?

 

Hi,
Thank your for your message. No this feature only works with 3D colliders for now. But this is a very relevant suggestion and I can definitely investigate to make it work with 2D colliders if it's a feature you need. I'll investigate and I'll let you know.
Thanks