Search Unity

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

Discussion in 'Assets and Asset Store' started by techsalad, Oct 9, 2017.

  1. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    Hi @techsalad I've run into a problem with your latest version (1.61) and GPU Instancing.

    I have a number of streetlights in the scene configured as fairly standard VLBs and they're fine. However I also have half a dozen "window beams" which are VLBs with square beams on the horizontal for showing light coming from windows.

    Everything works as expected when the global render settings are set to Single Pass. However, when I set it to GPU Instancing the square beams switch on and off periodically as you move around the scene.

    Note that this only happens in a build. Running in the editor seems fine. Setting VLB back to Single Pass rendering fixes everything in the build.

    Is there something you can recommend for remedying this?

    Ideally it would be great for all VLBs to be instanced (for performance), however if it's not possible to mix square beams and normal beams with GPU instancing, would it be possible to implement a switch that allows me to specify which VLBs should use instancing or not (rather than just the one global setting)?

    Thanks for your help!
     
  2. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi,

    By square beams, do you mean beams with a 'custom' mesh type set with 4 sides?

    Obviously the fact that the square beams flicker when you export a build is not expected. I will investigate this issue. What version of Unity do you use, and on which target platform do you have the problem?

    About instancing, the limitation is that only beams using the shared mesh type can be instanced/batched, because it's only possible to use GPU Instancing with objects rendering the same mesh: more info here.
    So the way you decide which beams will use GPU instancing is basically which beams use the shared mesh type. If you prefer to use GPU instancing on your square beams, you should configure the global shared mesh as the square beam, and configure all your standard beams with the custom mesh type. But it would be particularly painful to do since it would require to modify each of your beams, and it won't be possible to easily switch which set of beams are batched. So I wouldn't recommend to do that!

    However, a better solution would be to add the possibility to configure multiple shared meshes instead of only one. This way you could have a shared mesh for your standard beams, and another one for your square beams. So all your beams could use the shared mesh type, but then you could choose to use either the 'standard' or the 'square' shared mesh per beam. All the beams using the same shared mesh could be batched together. You could still use beams with 'custom' mesh for very specific geometry if needed, which couldn't be batched with anything else.

    This is just some ideas, and it would probably require quite some work, but this is something possible. Do you think it could help to have a feature like that? Would you be interested?

    Thanks
     
    tntfoz likes this.
  3. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    Hi @techsalad thanks for getting back to me.

    The square windows beams are indeed custom meshes with just 4 sides. All other beams (streetlights) are shared meshes (16 sides, 5 segments).

    My project is using Unity 2018.2.20f1 and the target build is for VR (Windows) on the Oculus Rift, with SPSR enabled.

    Looking more closely at the build I can see some of the streetlights (shared meshes) also disappear on occasion along with the square beams, so it seems to be a more generic problem rather than just the square beams having issues (though they do seem more affected).

    If I create the build again with the VLB render mode set to Single Pass, then there are no longer any problems - it only happens with GPU Instancing set.

    Regarding your suggestions about adding support for multiple shared meshes, I think that's a really good one - especially for mobile platforms as the memory savings would be very beneficial, and the GPU instancing would work for all variations of VLBs in the scene. The big question is whether enough of your users actually use different variations of VLBs in a scene to warrant the time it will cost you to implement.

    In my case, I guess I'm experiencing a problem with the GPU instancing that wouldn't be fixed by the multiple shared meshes anyway?
     
  4. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Thank you for the feedback.
    Indeed the issue you are experiencing is not related to the feature I was exposing. I will investigate and try to fix it in priority.
    Then I will try to estimate the cost of developing this new feature. I'll you know.
    Thanks again for your time.
     
    tntfoz likes this.
  5. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    No problem! Thank you for the great support!

    :)

    Just hope you're able to reproduce the problem easily, rather than it being something specific to my setup.

    Let me know if I can provide any further info.
     
  6. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    I tried to reproduce the issue with the exact same setup: Unity 2018.2.20f1, Windows build, Oculus Rift, Single Pass Stereo Rendering, GPU Instancing. I added around 20 beams with shared mesh, and 20 beams with custom mesh, but wasn't able to reproduce the issue.

    So there is probably something else. Do you think it would be possible to share with me some parts of your project so I could reproduce the issue on my side and investigate further? Please contact me by email: techsaladunity@gmail.com

    By the way I also tried to switch the Stereo Rendering Method to Single Pass Instanced (Preview) instead, and I noticed that the beams don't work (the beams of both eyes seem to rendered to the left eye only). I should also investigate this bug...

    Thanks
     
    tntfoz likes this.
  7. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    Hmm, I'll have to do a lot of chopping and changing to reproduce a scene outside of my project. I'll see what I can do.

    Is there possibly a limit to the number of VLBs that can be instanced in one go? It's possible I have a 100+ being rendered around the player at a given time.

    The disappearing beams seem to occur as you get near to them - is there a state change to the VLB as the camera gets near to its edge that might create a problem with instancing?

    Anyway, I'll have a look at creating an empty scene that recreates the issue although it may take a couple of days for me to get back to you - thanks!
     
  8. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    No, but I will try to add more beams in my test scene.

    Nope.

    I will keep investigating on my side. Thank you very much for your help, it's really appreciated.
     
    tntfoz likes this.
  9. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    I've got a few other components on the camera which might possibly be conflicting so I'll check into this when I dissect my project over the weekend.

    I just assumed it was an issue with VLB as the beams are fine when switched back to Single Pass rendering versus GPU instanced.

    Thanks for your time.
     
  10. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    I am pretty sure it's an issue with the plugin. Whatever you do with it, the beams are never supposed to switch on and off randomly. But it's not possible to test every use-cases possible, and your project is probably using some other scripts or effects I haven't tested the plugin with.

    I tried with more beams (60 with shared mesh + 60 with custom mesh) but still couldn't reproduce the issue.

    Btw I managed to fix the support of Single Pass Instanced Stereo Rendering Mode. I don't think it's related with your issue, but if you are interested I could send a version with the fix to you.

    Thanks.
     
    tntfoz likes this.
  11. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    Funnily enough I didn't enable Single Pass Instanced support in my project because the VLBs didn't work! :D

    So I've no idea what I'm missing by not having tried it yet!

    Unfortunately I still haven't started stripping down my project yet (it's going to be a big job) - so apologies for the delay. Decided to catch a breather this weekend before getting back into the thick of it! :/

    I quick try of your new version would be great thanks - I'll send you an email shortly to give you my address again as it's been a while since our previous exchanges!

    Thanks!
     
  12. Zarkow

    Zarkow

    Joined:
    Jul 27, 2015
    Posts:
    38
    I am currently using Deferred Rendering as I have a lot of dynamic lights (lots of flashlights) and am not sure if I am missing something.

    When I look at the rendering using the Scene -> Miscellaneous -> Render Paths I see that all lights using the Volumetric Light Beam addition comes up as big yellow blobs, indicating that the solution is using Forward Rendering, i.e. is rendered ontop after the full Deferred pass is done, as it is rendering using transparency?

    RenderPaths_VolumetricLightingSolution.png

    Am I misunderstanding something or do I need to set up something for the plugin to fully support Deferred Rendering?
     
  13. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi,
    You are 100% right, the volumetric light beams are rendered using a forward rendering path because they are transparent. This is a known limitation of the deferred rendering technique for all semi-transparent objects like stated in the manual: https://docs.unity3d.com/Manual/RenderTech-DeferredShading.html
    Thanks
     
  14. Zarkow

    Zarkow

    Joined:
    Jul 27, 2015
    Posts:
    38
    Alright, thank you, I just became unsure when the docs said "Supports [..]: Deferred and Forward rendering", with no asterisk or link to Unity doc.
     
  15. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Ok, sorry if it was misleading, I will update the doc to make it more clear.
    Thanks
     
  16. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Volumetric Light Beam 1.62 has been released with bug fixes, optimization and new features:
    • Fix Single Pass Instanced Stereo Rendering Method in VR.
    • Fix beams switching on and off randomly in rare cases with GPU Instancing enabled on standalone builds (special thanks to @tntfoz for your time and your feedback!)
    • Fix Dynamic Occlusion wrongly computed on scaled beams.
    • Add new Consider Triggers property on Dynamic Occlusion to specify if a beam should also be occluded by triggers or not.
    • Improve loading time on exported builds.
    • Editor inspector UI improvements.
     
    tntfoz likes this.
  17. Tom-Goethals

    Tom-Goethals

    Joined:
    Mar 6, 2015
    Posts:
    82
    Hi TechSalad,

    I've been playing with your plugin for a few days now and it looks really great.
    As i'm using the LWRP and noticed some rendering artifacts (right eye showing an offset)

    So I stumbled upon this:
    http://saladgamer.com/vlb-doc/compatibility/#common-steps
    (i've also enabled Opaque texture as @FeedMyData suggested but that doesn't help and makes my transparent textures disappear)

    However when i switch to "SRP 4.0.0 or higher " setting in plugin config nothing is rendered anymore when built to the Oculus Go. Editor and game view inside unity are fine. When i switch back to the built in render pipeline (VLB config) it works again. Tried both "rendering mode single pass" and "single pass instanced".

    I'm using:
    Unity 2018.3.8
    VLB: 1.6.2
    LWRP: 4.10.0
    Linear
    OpenGLES3
    Android > Oculus Go

    Any idea what i'm doing wrong?
     
    Last edited: Mar 18, 2019
  18. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi Tom,
    Regarding your offset rendering artifact, does your project use the "Single Pass" Stereo Mode? Because what you are mentioning reminds me a lot this known issue: http://saladgamer.com/vlb-doc/troubleshooting/#shadow-artifacts-on-mobile-single-pass-vr
    Let me know if this is the case and if switching to Multi-Pass Stereo Mode fixes the issue.
    Thanks
     
  19. Tom-Goethals

    Tom-Goethals

    Joined:
    Mar 6, 2015
    Posts:
    82
    Hi TechSalad,

    Yes it's using Single Pass, LWRP on 2018.3.8 only has that option enabled.
    Does the "SRP 4.0.0" renderer in VLB need multi-pass?
    (off-topic can't for the life of me get the post processing stack to work in combination with LWRP as well, if you have any suggestions.. seems related to the same issue somehow)

    I might have to go with the soft intersections "set to 0" solution.
    (voted on the issue btw.)

    Thanks!
     
  20. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hey Tom,

    Like stated in the documentation, when using LWRP, the config should set as:
    - Render Pipeline: SRP 4.0.0 or higher since you use LWRP 4.10.0.
    - Rendering Mode: Single-Pass or GPU Instancing

    So if you use the workaround on your beams (setting the property Soft Intersections with Opaque Geometry at 0), do you still have the issue happening (no beams rendered) when running on Oculus Go?

    Regarding your question about the Post Processing Stack, indeed it should be related to the same Unity bug (the depth map broken for the right eye). In this case, I am afraid the only working workaround would be to use the Multi-Pass Stereo Rendering Method in the player settings.

    Thanks :)
     
  21. Tom-Goethals

    Tom-Goethals

    Joined:
    Mar 6, 2015
    Posts:
    82
    No, LWRP 4.10.0 renderer in combination with Opaque Geometry at 0 works in Go. Thanks! Hoping for a fix from Unity soon cause it sure looks prettier with some opaque geometry! :)
     
    techsalad likes this.
  22. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Thanks for the feedback! Indeed this Unity bug is a pity :(
     
  23. FreeReignPublishing

    FreeReignPublishing

    Joined:
    Oct 22, 2017
    Posts:
    31
    Hi, is there a way to have the volumetric light beam fade from the start of it.
    I'm using it for a 2d game and there's a hard line from were the light starts.
     
  24. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi,
    Yes it's possible to do that using a gradient: switch the color mode of your beam from flat to gradient. Then in the gradient editor, keep your beam with a flat color (bottom keyframes) but add alpha keyframes (top keyframes) to make the beginning of the beam (left side of the gradient) transparent while keeping the ending opaque.
    image.png

    If you are missing precision, switch to a custom mesh and add more segments to your beam:
    unnamed.png

    Note that both the gradient and the attenuation modulates the beam transparency: this means that even if you let the beam fully opaque through the gradient, its ending will still fade out because of the attenuation. Actually I should probably add a new mode to fully control the beam transparency through the gradient by disabling the attenuation.

    Let me know if it works.
    Thanks
     
  25. FreeReignPublishing

    FreeReignPublishing

    Joined:
    Oct 22, 2017
    Posts:
    31
    the gradient worked thanks!
     
  26. Crabmontage

    Crabmontage

    Joined:
    Feb 28, 2019
    Posts:
    4
    Hey guys i am studying lighting design and tried your plugin. I have noticed one thing which is pretty opposite than in reality. The viewing angle towards camera should amplify light and in the plugin it is exactly opposite. So i was trying to find the function in all the scripts and shaders which is responsible for that with no luck. The closest thing i have stumbled upon it is glare parameter which is making edges of the beam brighter (and in reality that should work while camera is inside of the light beam as well).
    Adding some pictures to explain.
    So i took the long beam example and created four of them facing into different directions in clean scene

    The Glare parameter is set to 1 here and all the beams look pretty evenly bright

    If i decrease the glare to 0 the beams looking towards the camera and opposite of the camera become almost invisible even the alpha haven't changed

    Even if i set alpha to 1 the beams from the side are getting stronger and frontal and back are barely visible.
    So i am trying to find the function in the shader code or in the script which makes this happen. (I have tried each function processing variable alpha to return 1.0f so all the beams would have same intensity, but the effect is still there.)

    The only way to tweak it to took more-less realistic was to increase glare to 1.2 or more to achieve desired effect, but it illuminates the edges of the beam rather middle part, that's why i am trying to deal with alpha variable.



    Any hints or suggestions which function deals with camera to beam normal and makes the beams less bright?
     
  27. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi,
    Thank you for your detailed message.
    If I understand properly, you would like to have more control on how the beam looks like when the camera is facing the beam, or when it looks in the same direction. You are right, the 2 properties offered by the plugin to control this behavior are Glare Frontal and Glare from Behind.

    I had a look to your screenshots, but I am not sure to understand what I am looking at exactly. I did some tests on my side, here is how a beam will look from the side (bottom right) and when facing it directly (top right):
    Screenshot_17.png

    The beam has its Glare frontal property set to the max (1). The result will obviously depends on how far the camera is located, but with these camera positions, this is basically the brightest beam you can get with the current version of the plugin.

    I am sorry if you are not satisfied with the result the plugin can achieve. Since the 2 Glare properties are supposed to be clamped between 0 and 1, I cannot guarantee the result if you try to override them with greater values than expected. However I could investigate the right way to boost the brightness of the beams in these particular cases if you are interested.

    Thanks
    TS
     
  28. Crabmontage

    Crabmontage

    Joined:
    Feb 28, 2019
    Posts:
    4
    Thanks for fast reply,

    I think your plugin is one of the most efficient for game design and well structured code-wise. The thing what I am trying to achieve is just to make something what would reflect the real world results to be used to simulate real lighting.
    So it's more like challenging myself to figure it out ;)

    The case i am talking about is when camera is not inside the light beam, but facing its direction.

    In reality in a foggy situation if you would look towards the light source (parallel), the beam would look brighter comparing to if you would look onto the beam from the side (perpendicular).



    That is simply happening because you are seeing more light concentrated in smaller space, and since light is additive it becomes brighter - while looking towards the beam beam becomes shorter and you see denser light quantity.

    If you look from the side onto the beam, it is longer so the same amount of light energy is distributed over longer area and luminance is comparingly lower.


    So in example we have four beams facing different directions, camera is placed outside the beam. Camera normal towards the beams W and E is perpendicular, while camera normal towards N and S is parallel.

    So if all of the beams would be of the same brightness, the beams N and S should be brightest, and W and E should be less visible.
    [That was the real world scenario]



    Now if we compare to what happens in plugin in unity it is quite opposite.

    Imagine if the glare variable is set to 1 - all the beams will be same brightness
    If the glare value is set to 0 then North and South facing beams will become almost invisible, and West and East facing beams will stay the same brightness.



    Normally i believe should be exactly opposite or at least all the beams should be equal brightness, so i was trying to find what might be causing that.

    Lets imagine that the glare variables do not exist ( set to zero ).
    What could influence the that the beams depending on the camera position become less brighter?
    Maybe some blending mode, maybe some function which is calculating normals (camera normal compared to Light source normal).

    could you point out to some parts of (i guess shader) code i could have closer look into ? :)
     
  29. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    Hi @techsalad would it be possible for you to set the VolumetricLightBeam class as partial so it could be easily extended?

    There are a couple of additions I want to make to the class but don't want to worry about future updates overwriting them.

    To facilitate being able to extend the class I need to move the VolumetricLightBeam asset folder out of Plugins so it doesn't get compiled into the firstpass assembly (or it will conflict with the default csharp assembly when extending).

    Is there a reason why VLB is installed into the Plugins folder in the project?

    Thanks!
     
    Last edited: Apr 3, 2019
  30. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi,
    Sure I can definitely make the class partial. I will include this change in the next update.
    The plugin is located by default under the Assets/Plugins folder because I personally think it's cleaner to do so, and I am pretty sure I read it was considered as a best practice in a guide few years ago. But you can totally move this folder anywhere you want :)
    Thanks
     
    tntfoz likes this.
  31. tntfoz

    tntfoz

    Joined:
    Sep 29, 2016
    Posts:
    95
    Thanks! Leaving assets in the Plugins folder compiles them into a different assembly file to a project's normal classes (they end up in Assembly-CSharp-firstpass.dll instead of Assembly-CSharp.dll) so just wondered if you wanted/needed that by design?

    Personally I like assets in the root of my project's assets folder. I always forget to look in the Plugins and Editor folders when I'm trying to locate asset files (like VLB) for example! No worries though! :)
     
  32. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Thank you very much for the very detailed explanation!

    The way the plugin renders the volumetric lights using cone geometry is obviously not accurate, so it's not easy to apply real life equations directly to the plugin. Most of the computations done in the shaders are the result of a lot of trials and errors to make the beams look fine (at least to me :)) in most situation, after checking how it looked in other games. So I am not really surprised it doesn't give physically accurate results particularly because the beams used for these tests are very unusual: normal users are not supposed to use beams long and narrow like this and so I cannot guarantee decent results with such extreme cases. The plugin is not a physically accurate simulation (and doesn't pretend to be).

    To give you more details, the main plugin shader computes a bunch of "factors" before combining them together. There is one attenuation factor to decrease the beam intensity the further from the light source the pixel is.
    There is one "fresnel" factor to soften the look of the beam around the cone's edges: this property "Side thickness" modulates this factor. The way this factor is computed only looks good when we look at the beam from the side. So when the camera is near the beam axis, I don't use this factor anymore and use another instead which is computed from the glare properties. These 2 factors are lerped according to the camera position to make the transition looks smooth. To be even more specific, the following line does the magic: I lerp the fresnelPow value with the glareFactor value depending on the distance of the camera to the beam's axis:
    Code (CSharp):
    1. fresnelPow = lerp(fresnelPow, min(fresnelPow, glareFactor), factorNearAxisZ);
    Feel free to play the shader code if you want to try to achieve a different result :)

    Thanks
    TS
     
  33. Crabmontage

    Crabmontage

    Joined:
    Feb 28, 2019
    Posts:
    4
    Thanks for pointing it out, it is exactly that direction i am looking for!
    I swapped the fresnelReal and fresnelProjOnTangentPlane in foloat fresnel and it seems to be better now.
    It made beams look the same power when Alpha inside and inside are of same value.

    Code (CSharp):
    1. float fresnel = lerp( fresnelReal, fresnelProjOnTangentPlane, factorNearAxisZ);
    Followingly i have touched the ComputeColor functions part which lerps Alpha (inside) and Alpha (outside)

    Code (CSharp):
    1. half alpha = lerp(alphaInside, alphaOutside, outsideBeam)
    and added to that multiplication by factor of factorNearAxisZ as well as it happens in the fresnel function.

    Code (CSharp):
    1. half4 ComputeColor(float pixDistFromSource, float outsideBeam, float3 vecCamToPixOSN)
    2. {
    3.     float vecCamToPixDotZ = vecCamToPixOSN.z;
    4.     float factorNearAxisZ = abs(vecCamToPixDotZ); // factorNearAxisZ is normalized
    5.  
    6. #if VLB_COLOR_GRADIENT_MATRIX_HIGH || VLB_COLOR_GRADIENT_MATRIX_LOW
    7.     float distanceFadeEnd = VLB_GET_PROP(_DistanceFadeEnd);
    8.     float4x4 colorGradientMatrix = VLB_GET_PROP(_ColorGradientMatrix);
    9.     float distFromSourceNormalized = invLerpClamped(0, distanceFadeEnd, pixDistFromSource);
    10.     half4 color = DecodeGradient(distFromSourceNormalized, colorGradientMatrix);
    11. #else
    12.     half4 color = VLB_GET_PROP(_ColorFlat);
    13. #endif
    14.  
    15.     half alphaInside  = VLB_GET_PROP(_AlphaInside);
    16.     half alphaOutside = VLB_GET_PROP(_AlphaOutside);
    17.     half alpha = lerp(alphaInside, alphaOutside, outsideBeam)*factorNearAxisZ;
    18. #if VLB_ALPHA_AS_BLACK
    19.     color.rgb *= color.a;
    20.     color.rgb *= alpha;
    21. #else
    22.     color.a *= alpha;
    23. #endif
    24.  
    25.     return color;
    26. }
    Now it more-less looks closer to the real world scenario! thanks for the help!



    P.S. it has a bit of small visual bug, but may be i will be able to figure it out in later approaches.
    It happens when i move camera to the right or left, but its not a big issue :)



    There is that darker spot in the center, it has something to do with the segments of cone geometry, ill try to look for some workarounds. :)
     
    Last edited: Apr 8, 2019
    techsalad likes this.
  34. Crabmontage

    Crabmontage

    Joined:
    Feb 28, 2019
    Posts:
    4
    Where vecCamToPixOSN is declared / created?

    and where does outsideBeam (TEXCOORD8) come from ?
     
  35. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    The vecCamToPixOSN variable is computed in the vertex and fragment shader: it means vector "camera to pixel" in object space and normalized:
    Code (CSharp):
    1.     // Vector Camera to current Pixel, in object space and normalized
    2.     float3 vecCamToPixOSN = normalize(o.posObjectSpace.xyz - o.cameraPosObjectSpace);
    The outsideBeam variable comes from the shader:
    - for the 2 pass shader, the 1st pass is drawn with outsideBeam at false and the 2nd pass at true.
    - for the 1 pass shader (single pass & GPU Instancing) this data is baked inside the cone geometry.
     
    Crabmontage likes this.
  36. Royy212

    Royy212

    Joined:
    Aug 1, 2016
    Posts:
    19
    Hi @techsalad, I've updated my Unity to at beta version (2019.1.0f1) and now there's an error with your plugin. I'm not quite exeperienced using delegates do I don't know how to fix it. Here's a link to an image of the error: https://i.imgur.com/ojdSO2S.png

    Could you tell me how to fix this or fix this in an update of the plugin?
     
    Rohirm likes this.
  37. Rohirm

    Rohirm

    Joined:
    Oct 17, 2017
    Posts:
    9
    I managed to fix that by modifying the BeamGeometry.cs and adding:
    using UnityEngine.Rendering;

    And changed:
    void OnBeginCameraRendering(Camera cam)

    to:
    void OnBeginCameraRendering(ScriptableRenderContext context, Camera cam)

    Not sure if still missing something that has to be done with the context, but works :)
     
    techsalad likes this.
  38. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Very sorry for the late answer. The forum didn't send me any notification about your post...
    Apparently unity has changed their API once again. Thank you very much @Rohirm for your fix. I will include it in a next update.
    Thanks!
     
    Last edited: Apr 16, 2019
    Royy212 and Tom-Goethals like this.
  39. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi guys,
    The version 1.64 has been released on the Asset Store! The main new feature of the update is Fade Out:
    See the full changelog here: http://saladgamer.com/vlb-doc/changelog/
    Thanks
    TS
     
    Lars-Steenhoff, AthrunVLokiz and punk like this.
  40. Aaron-Meyers

    Aaron-Meyers

    Joined:
    Dec 8, 2009
    Posts:
    177
    Hey there... love the VLB package. I'm currently using it on an AR project where I am also using the MobileARShadow shader that comes with Unity's ARKit plugin. It basically let's a surface catch shadows without actually drawing anything else.

    Seems like it doesn't really get along with the volumetric light beam though :(

    Wondering if you have any ideas about how to get it to work?

    upload_2019-5-7_12-40-47.png
     
  41. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi,
    Thanks for you message and sorry for this issue.
    In your screenshot, what is the blue-white gradient in the background? Is it actually the beam?
    So if I understand properly, the shader you are using to render the blue plane and the white sphere draws over the beam?
    If this is the problem, a possible way to fix it is to check the render queue your shader is using. Then you can tweak the render queue the volumetric light beams are rendered on via the config: make sure the render queue of the beams is higher than the one used by your shader.
    Let me know if it helps.
    Thanks :)
     
  42. Aaron-Meyers

    Aaron-Meyers

    Joined:
    Dec 8, 2009
    Posts:
    177
    In the screenshot, I have the camera setup to just clear to the blue color. The white is from the volumetric beam. Its just a simple scene I set up to show what's happening. Its just a sphere, a plane with the MobileARShadow shader material and a volumetric light beam.

    I tried some of the different render queue options in the config and none of them seemed to make any difference.

    The source code of the MobileARShadow shader is here: https://github.com/HippoAR/Unity-Te...Examples/Common/Shaders/MobileARShadow.shader

    It looks like it draws on the geometry+1 queue and the VLB is drawing on transparent, so it should already be drawing after, but that MobileARShadow seems like it works in mysterious ways.

    Separate issue, but I also can't get it to work with shadows from spotlights because when I tried adding a ForwardAdd pass to it, it stops being transparent and seems to take on some shading from the spotlight :(
     
  43. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    You are right, with these render queues setup the vlb should be drawn after the plane and sphere.
    Have you tried to add some simple geometry with a transparent material and shader in your scene, to see if the same rendering order issue happens?
    Thanks for the shader source code. I will setup a test scene with it to try to reproduce the issue.
    I'll let you know.
    Thanks
     
  44. Aaron-Meyers

    Aaron-Meyers

    Joined:
    Dec 8, 2009
    Posts:
    177
    Hmm... I only have a couple objects with transparency and they seem to look fine in the scene. Its just with this funky MobileARShadow shader that problems start happening!
     
  45. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Hi again,
    Like promised, I did some experiments. I downloaded the ARKit repository you linked me, and I opened it using Unity 2017.2.0f3 (this repo is made using 2017.1.1).
    I created a test scene to mimic yours: a sphere with default material, a plane with the MobileARShadow shader, a directional light, a camera with a blue sold color background, and a volumetric light beam. Here is how it looks in the editor scene view:
    Screenshot_1.png

    I think I managed to reproduce your issue. If I make the beam intersects with the plane and place the camera far enough, I have this weird rendering which looks like your screenshot:
    Screenshot_18.png

    The problem is that the MobileARShadow shader is writing to the Depth Buffer, but not really to the Frame Buffer (except where the shadow is obviously). So later in the frame rendering, when the volumetric light beam is rendered, it "thinks" that some solid geometry exists where the plane is located because the info stored in the depth buffer looks like so.

    To improve the rendering, you could disable the ZWrite in the MobileARShadow shader. Change the line "ZWrite On" to "ZWrite Off".

    But there is the shadowcaster pass (via the fallback VertexLit shader) which still writes in the depth buffer. So when the Volumetric Light Beam shader tries to blend and soften the beam with the geometry already drawn, it will get the info written in the depth buffer by this shadowcaster pass: it means it will look like the beam is intersecting some plane (which is true in some way...).
    If you don't want this behavior, and make the beam looks like it doesn't intersect the plane, just disable the "Soft intersection with Opaque Geometry" by setting this property to 0.

    Please let me know if it helps.
    Thanks
     
    Last edited: May 9, 2019
    Aaron-Meyers likes this.
  46. Aaron-Meyers

    Aaron-Meyers

    Joined:
    Dec 8, 2009
    Posts:
    177
    Hey thanks for looking into this!!! This is helpful.

    On a totally separate note, I'm finding that if I add the dust particles to the beam, they seem to not get along well with a Timeline that I'm using. When the Timeline is not playing, they are totally normal, but once the Timeline is playing, they appear to be stuck in a short 1 second-ish loop. Any idea what might be going on here?
     
  47. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Glad to hear it helped!

    I'll look into the issue you have with the dust particles and I'll let you know.
    Two questions:
    - What version of Unity are you using?
    - What properties of the beam are you playing with in your timeline?

    Thanks
     
  48. Aaron-Meyers

    Aaron-Meyers

    Joined:
    Dec 8, 2009
    Posts:
    177
    I'm using 2018.3.9... I have a script that is keyframed on the timeline to change the color of the spotlight and vlb color (not directly animating the fields on vlb).
     
  49. Aaron-Meyers

    Aaron-Meyers

    Joined:
    Dec 8, 2009
    Posts:
    177
    ok my apologies... i don't think this has anything to do with your particles in particular! it seems to be a pretty weird Unity bug that only seems to happen when I have nested timelines (which I do in the main scene on this project). Pretty weird... it only starts happening after 5 seconds into the timeline. But I am able to recreate it with another particle system too...
     
  50. techsalad

    techsalad

    Joined:
    Oct 9, 2017
    Posts:
    208
    Thank you very much for your feedback.
    I did some experiments and wasn't able to reproduce it, but I didn't try with nested timelines.
    Sure if it also happens with regular particles, I am not sure I would be able to do something about it.
    Thanks!