Light importance calculation oddities

I am using the Universal Render Pipeline and custom shaders. I was seeing some strange lighting issues and verified they are also behaving the same with the Lit and SimpleLit shaders. My lights are set to Per Vertex and the per object limit is 4.

I have a level full of static geometry and a bunch of static objects. These are all lit by vertex colors and realtime lights are set to ignore these layers. I am trying to light dynamic objects such as doors and players with per vertex lights. In my render settings asset, the main light is disabled and additional lights are set to per vertex.

The issue I am having is that there seems to be some limit or issue affecting which lights are illuminating these objects. For this example, I am using a single door (I have disabled the surrounding area). There are hundreds of lights in the world but these are the 4 closest and I have ramped their intensity up to 300 (it's extreme, I know).

On one side of the door is lit.



On the other, there is no light:


There are several hundred lights in the world but they are all far away and of intensity 1. Interestingly, if I pitch the camera down and other lights in the scene are culled, it does finally light the object:


But the second the camera can see other lights, these two lights aren't rendered.

I don't understand why these 4 lights aren't the lights that are used to light the object. The other lights in the scene are of intensity 1 and are not closer (maybe only 1 other light is within range of the door). It's as if there is some arbitrary max light limit on the whole world. I am at a loss. I understood that it's a maximum of 4 lights per mesh renderer, and these lights are ordered by importance. How is this importance calculated? Is this a limit with the URP? What am I missing?

 

I moved these 4 lights and this object far away from the other lights (just to be sure). Same issue is happening where if other lights are in the camera's frustum, despite them being so far away they can't affect the light on this object, the lights stop illuminating the door.

Happens in both scene and game views.

 

Here's a video of this bug in action:

I disabled the level and all objects and just have a SimpleLit cube. All of the lights (save for two) have a range that does not come close to the cube. But when they enter my camera frustum, they for some reason take precedence over the two very close lights. All intensities are the same, only the range varies.

 

My assumption after a bit more testing is that Unity has a limit on the amount of lights they will consider for the shader. So it's not that another light is being considered more important for this object, but the maximum number of lights has been reached and these two lights have been unlucky and were bumped" and not considered. Does anyone from Unity have any insights? What is the limit?

The frustum will be smaller than it is now so it will be less of an issue, but it's still important to know what's going on behind the scenes. I realize that it's not a very common use case that you'd have a level with hundreds of lights, especially in forward rendered mode, but as other limitations are exposed (max lights per objects), it would be nice to see this as well.

 

Even with a smaller frustum, the issue is still there. I have upgraded to the latest Unity 2019.3.7f1 and URP 7.3.1 with no luck. The issue is also in builds as well, not just in editor.

 

Things I have tried thus far:
1. Custom + Official URP Shaders
2. Light Importance - they are all pixel lights anyway
3. Modifying pixel light count (set to 4) - definitely not this
4. Disabling Metal editor support
5. Enabling/disabling SRP Batcher and Mixed Lighting

Seems like the only way this works is if there are fewer lights in my frustum.

Here are the URP settings:

 

Did more testing and found this does not affect the built in render pipeline, just the URP.

I also tried playing around and set

k_MaxVisibleAdditionalLightsUBO

to 256 in both the

UniversalRenderPipeline.cs

and

Input.hlsl

. No dice.

 

Submitted a bug report. Hopefully it gets resolved.