URP - Limited number of pixel lights, why ?

Hello,

I am making shooter similar to doom/quake/unreal tournament and I just decided to add point light to my projectiles just to make it prettier. And as expected, I reached the limit of 8 pixel lights very fast.



If you look at Unreal Tournament (game from 1999), then you can see that projectiles were emiting light. And since its multiplayer game, there could be hundreds of those lights and the game had no problems at all.




Now, over 20 years later I am limited by 8 real time lights which I really don't understand as my knowledge about rendering is very basic.

So could someone please explain to me why is that ? Maybe these are not actual lights but just some kind of a "fake" lights since it has to be very performant ?? But since it actually enlightens dark areas I am very confused..

I am using URP with forward rendering and I would love to achieve similar effect without being limited to 8 lights.

Thank you very much for answers.

 

In URP's defense UT wasn't doing PBR and I think I remember it mostly used vertex lighting instead of pixel lights. However, you are totally right about the light limit being too low. They should at least make that configurable for the forward renderer.

That said I don't think the light limit will really change anytime soon unless their deferred renderer doesn't share that limitation. For the forward renderer to scale well they would need to do something like tiled forward or cluster shading instead of the brute force loop they do at this point. I also don't recall URP being able to mix vertex and pixel lighting either like built-in can do once you have too many pixel lights. So at this point if the deferred renderer can't get around this then I don't think you can do anything about it with vanilla URP.

 

That is such a tease! Cant wait to experiment

 

thank you guys.. so I'll be looking forward to deferred renderer. Hopefuly its very close to release

 

Hi @Jonas-Mortensen - I've upgraded my 2021.1 project to URP 12 from Master.
I tried to create a new Deferred Renderer Data to assign to a URP Asset's Renderer List, but when I click Create->Rendering->Universal Rendering Pipeline-> it only lists Forward Renderer. Is that because there's no such thing as Deferred Renderer Data and we're just supposed to use Forward Renderer Data asset? If I just switch to Deferred Lighting in that I get warnings in the URP Asset about both OpenGLES2 and OpenGLES3 not being supported. Does this mean WebGL isn't capable of it? Which Graphics APIs are supported (or will be)? Thanks !

 

We just recently finished our own version of a cluster shading forward renderer in URP and I can say it has been invaluable to have. We don't have to worry about old devices so I think the work was much simpler but this is something you guys should have in the near future. I look forward to it!

 

Awesome!

Curious will you guys do a forum/blog/documentation post going into details about the deferred, forward+, and original URP forward?

 

Cool - thanks

 

To enable deferred renderer in project, after adding packages to local package folder, you need to add Scripting Define Symble "ENABLE_RENDERING_PATH_UI" in project settings player. After that rendering mode will appear in Forward Renderer Data's UI, and there you go.

 

It's now available to select - thanks! I'll see if I can get the unlimited-ish point lights feature running in my project this weekend for a glance at compatibility/performance implications. I might have to wait on Forward+ but it's worth a look either way. WebGL 2.0 is currently my baseline platform and I haven't heard back yet from @nigeljw_unity

 

great news on Forward+ that's really beneficial for stylized projects that can't rely on the deferred gbuffer but want more lights.
Is there a specific branch on the graphics github or is it still early compared to Deferred?

 

Did you get the unlimited point lights to work? I did choose the deferred option but it actually did not change anything. Did you follow a specific step that I missed? It still just turns on 8 lights a time.

 

It's not compatible with WebGL.. I got as far into trying as seeing the warnings.

I didn't actually realize this was the reason I could pick up to 8 lights now though, just figured that was a recent change I hadn't noticed

 

I am not using WebGL. Does the function for you work without?

 

I just confirmed it's working in Windows 10:



Instructions..
- create new URP template project (I'm using 2021.2.0a9)
- in Hierarchy, delete everything except "Main Camera" and "Post-process Volume"
- add the ENABLE_RENDERING_PATH_UI thing noted above
- change Lighting to Deferred (select ForwardRenderer in Project window)
- create a new 3d object->plane
- drag the 'Ground_Mat' material from Project window onto it
- add the DeferredPointLightsTest component to it
- enter play mode
- during play mode, select the Plane with the component, then in the Inspector,
- drag/change the number of lights and animation shape

DeferredPointLightsTest.cs

Code (CSharp):

1. // @polemical, Unity Forum
2. using UnityEngine;
3. public class DeferredPointLightsTest : MonoBehaviour
4. {
5.   public float animationShape = 1;
6.   public int numberOfLights = 50;
7.   private int prevNumberOfLights = 0;
8.   public Vector3 offset = new Vector3(-5, 0.2f, 0);
9.   public Vector3 spread = new Vector3(10, 0, 0);
10.  
11.   private GameObject[] instances;
12.  
13.   private Vector3[] instanceOrigins;
14.   private void Start()
15.   {
16.     Regenerate();
17.     prevNumberOfLights = numberOfLights;
18.   }
19.   private void Regenerate()
20.   {
21.     Clear();
22.     numberOfLights = Mathf.Clamp(numberOfLights, 1, 50);
23.     Vector3 instanceStep = spread / numberOfLights;
24.     Vector3 instanceCenterOffset = instanceStep * 0.5f;
25.  
26.     GameObject prefab = new GameObject();
27.     Light light = prefab.AddComponent<Light>();
28.     light.type = LightType.Point;
29.     light.intensity = 1;
30.  
31.     instances = new GameObject[numberOfLights];
32.     instanceOrigins = new Vector3[numberOfLights];
33.     for (int i = 0; i < numberOfLights; i++)
34.     {
35.       instanceOrigins[i] = offset + instanceCenterOffset + (instanceStep * i);
36.       instances[i] = Instantiate(prefab, transform);
37.       instances[i].GetComponent<Light>().color = GetRandomLightColor();
38.       instances[i].transform.localPosition = instanceOrigins[i];
39.       instances[i].name = (i + 1).ToString();
40.     }
41.     prevNumberOfLights = numberOfLights;
42.     Destroy(prefab);
43.   }
44.   private void Update()
45.   {
46.     if (prevNumberOfLights != numberOfLights) Regenerate();
47.     if (instances == null) return;
48.     for (int i = 0; i < instances.Length; i++)
49.     {
50.       instances[i].transform.localPosition = instanceOrigins[i] + new Vector3(
51.         0, 0, Mathf.Sin((Time.time + (i * 100)) * animationShape)
52.       );
53.     }
54.   }
55.   private void Clear()
56.   {
57.     if (instances != null)
58.     {
59.       for (int i = 0; i < instances.Length; i++)
60.       {
61.         Destroy(instances[i]);
62.       }
63.       instances = null;
64.     }
65.   }
66.   private Color GetRandomLightColor()
67.   {
68.     return new Color(
69.       Random.Range(0.5f, 1.0f),
70.       Random.Range(0.5f, 1.0f),
71.       Random.Range(0.5f, 1.0f)
72.     );
73.   }
74.   private void OnDestroy()
75.   {
76.     Clear();
77.   }
78. }

 

I think URP has an 8 lights limit on the number of lights in front of the camera
Why do you need more than 8 lights in front of the camera at the same time durin play mode ?
The lights are generally fixed and use a light shaft and projector for real-time light simulation in other multiplayer players...
The difference between a projector and real light is in casting shadows
The use of too many lights is a sign of weakness in the design

 

Would you mind sharing a way to do this without lights? There's no shadows in it:
https://forum.unity.com/threads/urp-limited-number-of-pixel-lights-why.1048142/#post-6787790

 

Apparently URP does not support projector. "URP is not compatible with the Projector component. URP does not currently include an alternative solution."

 

There is no logical reason to use URP

Built_in pipeline with lowest preset (plus some limitations)= URP

 

This is just the projector solution showcase
For URP you must find compatible projector
The performance is maxed out:
If you want maxed our performance, you must use shaft (flare) textures as bloom effect

 

I'm having the same problem with the maximum amount of ligthing on my scene. I'm developing a top down twin stick shooter in URP, and wanted to put a simple point light on my projectiles. It works perfectly fine on walls / obstacles, but I'm having problems for the ground, which is giant plane, the size of the whole screen. With 4 moving spotlights on the scene and more than 4 projectiles flying around (basically always), some of the lights suddenly turn off, ruining the whole scene. I have the same problem on my UI (again, a single plane), as there are could be more than 8 lights at once (with no shadows). I don't think there would be any performance problems, as the number of vertexes is particularly low (a plane).

I have no prior experience with rendering and lightning. What would you suggest it to be the best approach?
Splitting the plane in multiple objects? Sounds a bit ugly and harder to maintain, and I have no guarantees that there will be less than 8 lights on any place at any given time.
Switching to deferred renderer? I have no idea what the implications would be, especially since it is not yet ufficially released. Can someone explain it to me?

Thanks in advance!

 

game engines are in year 2021 now, not 2006

 

We are talking about the low-end platform / pipeline
No mobile can still render real-time light at high frames
URP is built to apply the same limitations to have safe performance on low-end platforms
Low-end platforms are not built for real-time lighting

 

Is it known, will this Deferred Renderer for URP work on mobile devices so that I'd be able to have a few dynamic lights in my game without it dropping FPS down to the floor?

 

Trying the URP deferred renderer with Unity 2021.1.2f1 and URP 11.0.0 and everything is becoming grey. Anybody else has that too?

 

FYI. If you are relying on the new SSAO render feature the deferred lighting path will currently break that (2021.1.5f1)

 

I successfully turned on deferred in a test version of my project... is there a way to get point lights to allow objects to cast real time shadows on other objects?

 

Hi is this coming to, or compatible with 2020 LTS?

 

Hoping speed wins out, since if people want more, the deferred renderer is still available. But Forward+ with non configurable sounds perfect for real developers who want the fastest performing compromise...

I don't need lots of options, I need lots of speed

 

Oh, I did not know deferred is slower than forward.

 

Deferred is faster than forward if forward has to deal with a lot of lights. But if you have a set amount and want MSAA which is also faster than FXAA and other antialiasing solutions on mobile etc, you would want forward+ a whole lot. VR for example will be considerably better under forward+ if lots of lights are your thing.

 

Thanks for the info! I am on a VR project and I hope this comes to 2021 LTS (URP 10) also.

 

I have similar circumstances. URP has only recently began to step up with VR quality and engineering in Unity, but it seems to be ongoing so I hope the staff will feel encouraged to work on this knowing it's very much appreciated by us here.

 

Is there any approximate ETA for the forward plus renderer? (E.g. can we expect it to release this year?)

 

@nigeljw_unity
1. I noticed that Tiled Deferred (Deferred+) was half-removed (missing TiledDeferred shaders) in later versions of URP. Is there plan to bring it back?

2. Are you guys considering adding an optional GPU version of Forward+/Deferred+ ? Some platforms with low CPU core count are struggling with the current CPU light binning (even with Jobs enabled) and a GPU Compute version could help them.

3. The CPU performance cost of Deferred is much higher than Forward on platforms with low CPU core count. Are you considering adding an optional version of Deferred where Lights are GPU instanced to reduce the number of drawcalls? Instead of using Stencil pass before each light, a shader clip() could do.

Thanks!

 

Hows forward+ stack up against forward for switch etc? At what point does one become better? Thanks for any insights!

 

@nigeljw_unity can you please answer @hippocoder question ?

 

@nigeljw_unity Thanks for getting back! It's good to hear that you are exploring GPU-based solutions. Having multiple options is great for fine-tuning.

Sadly I have already tested the Hybrid Renderer v2 in URP but quickly found the CPU overhead of it to be too much, since our game is already CPU bottlenecked by the Rendering on the target platform.

Not sure I follow this point. Why? The point of using Instancing would be to avoid render state changes, no? AFAIK, drawing multiple lights of the same LightType shouldn't require a render state change between each light draw (we are talking about the solution of instancing and no stencil pass for traditional deferred).

Can you talk a bit more about those other ways? I wonder if there are ideas which we could preemptively implement in our own codebase.

 

Hi there!

@nigeljw_unity, is there any news about forward+ implementation?

 

Hi

In Unity, the Forward rendering can currently have 8 lights per vertex. My question would be whether this number can be increased because I don't see why it makes sense to take the management of this out of the hands of the developers.
Deferred render is forgettable on Oculus, but you could easily have more than 8 lights in the vertex shader, after all, it's not 2001.
If someone asks why so many lamps, my answer is that it would come in handy in a lot of situations.
Is it possible to change this limitation, or will it be possible in the near future?

 

Forward+ has no limits to worry about, that is a tiled approach instead. I would recommend you wait for that, and if it is still insufficient, you should calculate simple lights in the shader (I did 16 lights per object on my old 2011 iPhone project). They can be super simple such as distance + dot product.

 

Thank you for your information!

 

2021.2.2f1 and URP 12.1.1 (I can't upgrade to 2021.2.8f1 because of an outstanding show-stopper bug, but I've tested the results below on that as well as on 2022.1.0b4 / URP 13 and they stand in both cases).

I'm having lights flicking on and off in my project, so I went to investigate the impact of Graphics API and platform. On WIndows, 576 spotlights render just fine over a terrain object (with some minor artefacts in edit mode). On Linux Vulkan, 576 spotlights render with the same artefacts in edit and play mode. On Linux OpenGL, it looks limited to 8 lights per object (small terrain square) and perhaps 32 lights in all.

Yet the documentation says that I can expect a limit of 256 lights per camera and 8 per object. The page on the deferred renderer does not talk about any changes to that, such as allowing unlimited lights, which appears to be the case here, except for OpenGL. I still get a 'lights per object' slider in Linux Vulkan, and it appears to do nothing, which adds to my uncertainty.

Is the documentation innacurate or am I understanding it wrong? Is this a reflection of things being in a state of flux right now? If the latter, where is the most current information being posted, please, or do I just have to wing it for now? Linux / Vulkan / URP is a great configuration for me, if I could just pin down these dashed flickering lights...

Thanks!