The light turns off and on (or flickering) at different angles

[jaunty marsh]

Hey guys, I have a problem. Do you know how to solve it? I heard that it's because of the additional URP lighting settings, which limit the number of light sources to 8 per mesh. Btw, my URP doesn't have a Forward+ rendering path

[narrow willow]

Is Deferred path an option? Do you have more than 8 additional light sources (in addition to a main direciton light if there is one)? In the video there doesn't seem to be that many. Apart from choosing different rendering paths, you can consider making the lights have less range (so they would affect less meshes) and splitting the meshes into smaller parts so every light wouldn't be hitting the same huge mesh

If there are a ton of lights, you should consider something like the deferred path but it has a lot of limitations too so it isn't nearly always viable solution (which is the main reason for the forward+ renderer which is a good middleground)

[jaunty marsh]

Just chaned renderer path for forward +, everything working nice

@narrow willow can you tell me what's the different between Forward and Forward+ rendering path?

[narrow willow]

The difference between those as far as I know is just the way they store the lighting data. Forward simply passes all the nearby light data to every single object when they are rendered. In the shader that list of lights is then iterated to find the total effect of the lights. That is fine when there are few lights, but becomes really slow if there are a lot of lights affecting a single mesh, even if there wasn't many lights lighting a single pixel, the shader must iterate over all the lights. I don't remember how exactly forward+ works but I think it stores the light data in some sort of screen space spatial data structure that allows all meshes to access the lighting data that is relevant to a certain pixel from the same structure. Forward+ probably has more base cost (slower with low light count), but the cost is more dependant on the lights per pixel rather than lights affecting a single mesh so a lot of small lights can be rendered efficiently

I think forward+ splits the screen into small tiles and marks which lights affect each tile (based on the depth buffer I assume). I assume forward+ works only on opaque geometry meaning transparent objects would fall back to the regular forward rendering but I'm not sure about that, I would need to check the impelementation details

Each processed pixel/fragment would only need to iterate over the lights stored for the tile the pixel is part of and not the list of lights affecting the whole mesh most of which are likely out of range for the given pixel

@jaunty marsh As an example, this whole red area probably shouldn't receive any light, but in forward rendering, since all of lets say 8 lights are hitting the wall mesh each of those pixels would have a for loop running through 8 lights. In forward+ the whole screen (not just the rectangle that I drew for demonstration) would be divided to small tiles shown in green where all of those tiles would have 0 lights linked to them. Each pixel/fragment falling to any of those tiles would iterate over the list of 0 lights which would obviously be much faster than going over all the nearby lights.

Although great in principle, figuring which lights affect each tile isn't trivial and increases the base cost. There's also the deferred renderer which works totally different but is also bit limited in many ways

[native halo]

In a nutshell forward has light limits per object, and has to render the mesh again for each light that reaches it
Forward+ splits the meshes into screen tiles so light limit is not only per object, and generally much higher also

[narrow willow]

I don't think it splits the meshes literally at least. Just stores the light data per screen space tile right?

Oh, and I do believe URP simply does for loop (in shader code) to iterate over the lights even in regular forward. BiRP used to render the mesh once per light which meant there was no limit for how many times you could do that (if I had to guess, the need for hard coded light count limit would have something to do with the SRP batcher or optimization in general). Not that this makes much of a difference either

[native halo]

I don't know exactly
Seems like just a technical distinction
At least it doesn't come up in typical use

[native halo]

That makes sense
So shader complexity increases in URP along with light limit, but you might not save performance by having less lights per object?
(Unless SRP batcher juggles shader variants with different light loops or something)

[narrow willow]

Having less lights should be cheaper. There's no need to unroll the for loop since all the fragments of the same mesh have the same amount of iterations. You can have true loops in shader code, it just may not be very fast if fragments in the same wavefront have different iteration counts

At least I assume it is just a regular for loop. The point about SRP batcher is not so much about the for loop having the same iteration count (which would likely be unrolled making less iterations not a thing), but the way the data must be sent to each draw call

I'm probably not doing great job explaining this

Just trying to say that you can make a loop like this in shader code and it will only run lightCount times:

for (int i = 0; i < lightCount; i++)
{
    lighting += calculateLighting(lightArray[i]);
}```

Passing the lightArray to the shader in some form is why some upper limit is likely there. If I remember correctly, you can only use fixed size arrays and buffers (which can change in size by reallocation) in HLSL. The SRP batcher also probably wants to know the size of the material data in advance since it uses some sort of large buffer to store all the data.

The BiRP way of rendering the mesh once per light does only require sending the data of one light at a time

[jaunty marsh]

I have neuron activation, lol

[jaunty marsh]

Thanks for the explanation buddy!)

[narrow willow]

No problem. Feel free to ask if there is anything unclear (which is likely after that ramble)

[jaunty marsh]

Interesting 🤔

thanks for tip)

[narrow willow]

I probably made some assumption about your knowledge on graphics programming. If shaders as a concept for example are totally new to you, that is probably bit much to digest. In short, forward and forward+ just process lights totally different. Forward is cheaper for few lights and forward+ is especially effective on large amount of relatively small light sources (a lot of large, almost global light sources is tough ask regardless of the render path)

[jaunty marsh]

I don't think it was difficult for me to understand what you said before haha, but thanks anyway)

Guys, check this out

I made several light effects

1. Static - just simple light
2. Flickering light
3. Pulse effect
4. Strobe effect
5. Emergency effect
6. Fire effect
7. Candle effect (It's a little hard to see, but it's there)
8. Scanner effect
9. Alarm effect

It can also be very conveniently customized thanks to the NaughtyAttributes asset