Under review

Odd lerp results caused by lighting input

Justin Pierce 3 years ago • updated by Joachim Holmér (Developer) 3 years ago 10

Value A is 0.5 in both instances.  T is 0 in both instances, so it's my understanding that the output should be A (0.5).  This correctly happens when I have a simple color plugged into B, but it seems to go awry when I plug lighting data into B instead.  The preview in the Lerp node looks correct, but you can see the output is different.  

I think this is a bug unless I'm misunderstanding how Lerp works.  
Under review
This is expected, because you've probably misunderstood how the custom lighting input works :)

Custom lighting is rendered additively *per light source*.
Two directional lights * 0.5 = 1, hence it's white.

If you want it to become gray instead of being lit, with the Lerper slider:

Your solution does work, but I guess I'm still confused about how the output could be affected by what's plugged into B if T is set to 0 (100% A).  
That's a good question. It may be that there's something with the light nodes, that makes things multi-pass instead of single-pass, causing more light to hit it
Unfortunately your emission solution doesn't work for what I'm actually trying to do (not pictured in graphs).  I want to use the light attenuation as a lerp value (to control the strength of a softened fresnel effect) and I can't pass that into the emission channel (LightAtten * LightColorAlpha is always 0 if plugged into emission).  

Try to do it all in the custom lighting channel and I bump back into this behavior -- haven't found a way to normalize it.  

(only difference is that I swapped the 0 and 1 values)

Is this correct behavior?  Left is what I'd expect, but on right I'd expect it to go dark to light (opposite of left).  

If I swap out the LightAtten * LightColorAlpha setup with a slider, it can go dark as I'd expect, so it feels like a bug to me.  

edit: If I take the right side setup and change 1 to 0.5, this is the behavior: http://gfycat.com/ExcellentPartialIndigobunting

I'm confused heh.  
It's hard to do that, because light attenuation is still per-light source. Keep in mind that light attenuation only makes thing darker, and that you're currently only reading the alpha channel of the light color
So in reference to that last image, that's the expected behavior?  I'm still confused as to what's going on.  The behavior is the same with one light and multiple lights, and I'm just pulling the alpha of the light to keep things simple for now (swapping the alpha for the rgb doesn't fix it)

On the left side, the light attenuation setup provides a smooth transition from 1 to 0 as you move away from the light source.  When I have that plugged in to lerp between 0 and 1, it works as expected.  

But when I plug the (assumed) identical values from LightAtten into a lerp between 1 and 0, it's as if the light attenuation changes and I no longer get a smooth transition.  Why does changing A and B of the lerp node seem to change the values that LightAtten * LightColor provides it?  

The values being fed into the lerp's T should be the same -- the light is the same and the nodes feeding lighting data are the same.  A T value of 0.5 should output 0.5 in both setups (and it does if I use a slider instead of the LightAtten setup), but it doesn't here.  Why not? 
Alright, so, here's how forward rendering works:

First, it renders a base pass, with all the things that are only supposed to be added once, and it also renders one directional light source.
Secondly, *for each light source affecting this object*, it runs a forward add pass, which is rendered *additively* to the mesh.

I would guess you have a directional light pushing pure white into the second example, and the rest of the light sources don't affect it, because it's overshooting 1 in value
Just one point light in both examples.  Everything is the same except I swapped the Lerp's A and B values.  
Looks like light attenuation is the problem - it seems to output 1, even when there is no directional light at all, which is a bit of a problem. You can solve this by using the A channel of the light position node, which is 1 when point lights are currently being rendered, and 0 while a directional light is rendered: