Hello. I am trying to make particle system that will be reflecting and lighting the plane, but unfortunately it hits universal rp max object lights limit. I need like 50 lights on the object at the same time, but i dont know how to make it higher than 8 (i tried typing it in, but it just drops down to 8). I will be glad of any help, but if there is no solution, I’ll just remove universal RP. I don’t really like it anyway.
You can get unlimited lights with built-in deferred rendering, but the built-in forward rendering is probably going to have the same limit. You still have to worry about performance, though, and I would think that 50 real-time point lights is going to be impractical, no matter what.
I don’t know much about the SRPs, but with the built-in renderer, you can achieve the same look in that last screen grab using emissive materials+ HDR+ Bloom+ screen space reflection. No lights required.
Real-time lights have a big performance impact, so you should always use them very judiciously.
The URP is hard limited to 8 lights. There’s no way to do more with the way its lighting system works.
The built in deferred or the HDRP are the only realistic options if you want more than 8 lights on a single object. Unity’s built in forward rendering path can technically support a near unlimited number of lights, but it comes with an extreme performance penalty for rendering of those objects. The URP is likely faster at doing 8 lights than the built in forward renderer is at doing 4. The concept of deferred rendering is explicitly designed to allow for multiple lights. It is what it exists to handle.
Unity’s built in deferred rendering still doesn’t do a great job of this though, and will start to slow down more than it should using built in lights. People have written custom light systems for the built in deferred renderer that can do hundreds, if not thousands, with minimal performance impact, but Unity’s rendering systems cap out around 20-30 before performance becomes noticeably slower.
In contrast the HDRP should be able to handle millions of lights.
A big caveat is screen space reflections don’t work well when reflecting small or transparent objects. It might catch some of those particles, if they’re made opaque and larger, but the rest will just disappear too. So, yes, you could get something similar to the example posted, but that example was to show what they didn’t want.
I believe URP is going to get Deferred Rendering very soon, and when that occurs that will definitely remedy this issue. I saw that the deferred rendering branch got merged over a month ago. So, it seems to me that, it will most likely come out by the 2020.2 cycle (Although, don’t quote me on this). Could be worth the wait, if you don’t get the effect you desire with the other solution.
Is there any particular reason for limiting it to 8 and hard limiting at all? Why not 16 or 32?
I get down from 132 FPS (2 lights) to 128 FPS (8 lights) in my scene. It seems that I have plenty of space for more lights. I’d gladly sacrifice 30 fps just to get 8 more lights.
Deferred is in progress according to the URP Roadmap, as well as the point light shadows which already works in 2021 beta, but I do not know how to enable Deferred Renderer. There must be a way. Any ideas?
I have responded to these questions in the following thread:
Reposting here for visibility:
We have a forward+ renderer in progress, which is adding a novel form of light tiling to our existing forward renderer. This will allow you to go well beyond the 8 light per object limit with the forward renderer without the inherent limitations of deferred rendering (deferred renderers do not support msaa and we also need to fallback to the forward renderer for transparent complex lit materials): https://portal.productboard.com/unity/1-unity-graphics/c/261-forward-renderer-support
The reason there is currently an 8 light limit per object is because of performance considerations. Ideally, light data should fit entirely into constant buffers, because they are consistently fast universally across all platforms, whereas structured buffers are a lot slower on a lot of platforms. Without tiled/clustered lighting, there is a per object classification for the forward renderer, as we need to loop over all lights over all objects O(num_objects*num_lights), but with forward+, the performance will only be relative to the number of visible lights within each tile.
We are considering making the light limit configurable, but this would require us to use the slow structured buffer path, which will potentially keep your games from being able to run on lower tier hardware. We are making URP as fast as possible across all hardware, but every new feature requested adds complexity to the existing renderer, so we are working very closely with all hardware vendors to define a universal fast path.
The documentation for deferred is in progress. There will documentation for forward+ considerations as well when the feature lands.
There is a presentation on URP’s deferred renderer from Arm’s Moving Mobile Graphics at Siggraph last year:
Is there a way or plan to remove the limit only in Scene View? Perhaps someone made a tool to not draw lights outside the camera frustrum. Aside from the Forward+ that mentioned @nigelw_unity.
We want to work the lighting across the entire level so of course more than 8 lights are projected at the same time. When you hit play we are making sure that only the maximum of 8 are displayed at all moments.
Many people said to break the level into a bunch of tiny scenes but that workflow it’s quite tedious and slow, requires a bunch of rework of the entire game and we don’t really benefit from any gains other than this limitation of URP.
If we also want to bake all Reflection Probes in the scene we need to do it in a Room by Room basis because otherwise only 8 of ??? lights get into the probes.
Has anyone found a way around this? I want to bake a bunch of lights into my environment that has been baked into one object for optimization, so the 8 light limit applies, and baking only 8 lights at a time is def a non-starter
EDIT: Was able to figure a way around it by changing the URP _Renderer to Deferred instead of Forward, baking the lights, then changing it back to Forward to keep the MSAA and all the other fun stuff
)