Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

LWRP render bug and spotlight intensity

Discussion in 'General Graphics' started by Nicksaccount, Dec 21, 2018.

  1. Nicksaccount

    Nicksaccount

    Joined:
    Jan 10, 2013
    Posts:
    24
    Hi,

    I've been playing with the LightWeight Render Pipeline in 2018.3.0f2 and found a couple of things that look like bugs (well, one I'm sure is a bug and the other is perhaps a "feature").

    This is my original scene. It has a simple shader on both objects with a directional light and a spot light with default values apart from an intensity set to 6.

    normal_spot_light_6_small.png

    I then tried to migrate to LWRP using a "Lightweight Render Pipeline / Lit" material (the settings of which are in lwrp_shadow_bug.png) and found I had to increase the intensity of the spot light from 6 to 90 to get something that looked similar:

    lwrp_spot_light_90_small.png

    The "Lightweight Render Pipeline / Lit" material also seemed to introduce an issue with shadow of the sword.

    This can be perhaps be better seen if I change the Scriptable Render Pipeline back to "None" and then re-texture the floor. In the image below the sword is still "Lightweight Render Pipeline / Lit" (which is why it's pink) and the floor is a normal material. If I change the sword to match the material on the floor then we get the first image where it renders correctly.

    lwrp_shadow_bug_small.png

    My questions are:

    - Why do I need to tweak the spot light to 15 times it's original intensity?
    - How can I fix the bug in the shadow?

    Thanks!

    Nick
     

    Attached Files:

  2. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,329
    Because the built in renderer and the LWRP use different attenuation calculations. The built in renderer uses an arbitrary curve that "looked good", and the LWRP uses a clamped inverse square falloff which is more physically correct.

    If I remember correctly the normal bias setting on spot lights doesn't do anything in the built in renderer, it only works on directional lights. It looks like it does do something in the LWRP. Try setting the normal bias lower on the spotlight.
     
    Nicksaccount likes this.
  3. Nicksaccount

    Nicksaccount

    Joined:
    Jan 10, 2013
    Posts:
    24
    Ah, that explains the intensity then, it was a feature :)

    For the shadow bug, you're right - lowering the normal bias fixed the glitch.

    Thank you, @bgolus!
     
  4. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,329
    The other solution to the normal biasing problem as to not use hard edges in your model, try to only use one smoothing group and then get the hard edges back with a normal map. This only works on geometry with <90 degree edges, so it fails rather spectacularly on things like swords with out some additional finesse... Or a few hard edges.
     
  5. amisner2k

    amisner2k

    Joined:
    Jan 9, 2017
    Posts:
    43
    Hey @bgolus - In regards to the falloff used by the LWRP, I just ran up against an issue myself and was wondering if you had any insight: I have a point light in my scene with the intensity set to 200 and range set to 100.

    I have a simple built-in Unity sphere as a test model using the default LWRP/Lit material and it appears bright enough for my tastes at around 5 to 20 units away from the light. At about 80 units away, it is barely lit (to the point of being not even noticeably lit) which is what I would expect given the InverseSquare falloff LWRP seems to use.

    My aim is to increase the range at which my model appears comfortably lit by the point light, so I increased the range of the point light. Going from 100 to 1000 raised the brightness by I'm guessing about 10%. I would have expected a bit more than that given a 10x increase but ok maybe that's expected from an inverse squared falloff...however what I most certainly did not expect was going from 1000 to 10000 resulting in absolutely no brightness increase. I have the ambient light set to a dark color value to ensure it's not just somehow being washed out by that.

    It would appear that the LWRP has some sort of range cap internally for positional lights. No amount over 1000 on the range property of a point light has any appreciable effect as far as I can tell.

    Do you have any ideas? I'm using 2019.1.0f2. Was wondering if you could confirm this or explain what's going on.

    Thank you for your help and thank you for having the Never Ending Story snail as your profile pic.
     
  6. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,329
    An inverse square falloff means at 100 units, the brightness is 0.01% of the original light. With an intensity of 200, that’s a linear brightness of 0.02, or an 8bit sRGB of 39. Still decently visible. Unity uses the range as a clamp on the attenuation, starting at 80% of the light’s range. So with a range of 100 units, at 80 units the light will start to fade from the unmodified inverse square brightness of 0.0156% to 0% by multiplying the attenuation by either a linear fade or a square fade. Increasing the range to 1000 means the fade doesn’t start until 800 units.

    But at 800 units the inverse square is 0.000156%. 1000 units would be 0.0001%, but that doesn’t really matter since at 800 units the linear brightness is 0.0003125, or very nearly an sRGB of 0. In fact, past 812 units a brightness of 200 will be zero (assuming no HDR post processing). So the fade to black by 1000 units isn’t going to make much difference since it already got there on it’s own, and increasing the range further won’t make any difference either.

    If you want a non directional light to have an effective range over 800 units, you’re going to need a much brighter light.

    Don’t worry, it’s a racing snail!
     
    amisner2k likes this.
  7. amisner2k

    amisner2k

    Joined:
    Jan 9, 2017
    Posts:
    43
    Thanks good sir. Your explanation makes sense. I appreciate you taking the time to do the math and lay it all out there like you did.

    This was what I was afraid of. This fact means that my entities are completely blown out when they're too close to my light (which makes sense physically). I'm going to need to get more creative with what I'm trying to accomplish.

    It would be nice if we could simply set/override the attenuation type of a light from the Light component inspector itself. I created a thread here (https://forum.unity.com/threads/abi...enuation-falloff-from-light-component.670657/) hopefully the Unity devs see it and hopefully it's possible to implement.
     
  8. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,329
    For deferred or baked lighting, it’s relatively trivial to support different attenuation types (or, for deferred, write custom lights types). For forward rendering like the LWRP it’s a bit harder as every attenuation type you add potentially makes the shader more expensive regardless of what attenuation you select. If you want a different attenuation for all lights, you might want to look at modifying the SRP itself (or at least the Lighting.hlsl file).
     
    amisner2k likes this.