lights and deferred vs forward

as far as i understand, one of the benefits of deferred rendering is an unlimited amount of point lights at very low cost. But that is about the only reason I want to use it. so magic effects etc will have little cheap point light effects.

Is there an option that would be as performant in forward rendering, for lots of lights. I dont even necessarily want them casting shadow. I was looking to stay with URP, (mostly for shadergraph), but if i have to have performance issues for wanting lots of lights....

 

Technically yes. Forward Clustered Shading is a way to have a lot of lights
in forward rendering with similar (or better) performance than deferred rendering. It happens to be what the HDRP uses for anything forward rendered. It also requires modern GPUs (aka not mobile) and significantly increases the complexity of your rendering systems. Since the URP is supposed to be able to run on “anything”, it doesn’t use that.

However the URP should be getting a deferred rendering path in the near future.

 

You can probably accumulate light in an array of SH using 3d texture, if you feel adventurous, point light SH have known analytical formula.

 

I am now leaning towards HDRP. All I really need from either is shadergraph, but once I really compared the two, URP currently looks underpowered, and a ton of things said "not in development" which the manual said would not be implemented any time soon. HDRP can still be fast if tweaked right, maybe even faster depending on what I am looking for. Lots of point lights was one of them. Also I just found out about compute shaders, which was nice, since it was a thing I had been considering without knowing its name, once I considered the possibilities after learning to procedurally generate my own meshes. URP does not implement them, yet.

I only found out what SH was a week ago, and already forgot, so I am not feeling that adventurous.

Please remind me, as "SH" can be hard to search. I know I was in the arena of shaders and compute shaders when I read about it. Wait, I think it was a tutorial.

 

I mean if you're using the SRPs just because you want a node based shader editor, maybe stick with the built in deferred rendering path and buy ASE (Amplify Shader Editor). It's more powerful than Unity's own Shader Graph, which is still missing a ton of features. And if you do decide to switch over to one of the SRPs, ASE supports those too.

Compared to the URP using forward rendering, sure, HDRP might be faster. Compared to the built-in deferred pipeline? Maybe, but unlikely. The HDRP will be prettier looking though.

Correction: The URP doesn't use compute shaders, and is intentionally avoiding using them. But there's nothing stopping you from using compute shaders with the URP. The only catch is if you're doing any kind of custom instancing or mesh generation then you can't use Shader Graph, but I believe that's the case for the HDRP too?

SH refers to Spherical Harmonics. It's what Unity currently uses for ambient lighting on dynamic objects. It's a very inexpensive way of storing and evaluating the incoming light at a specific point in space. Basically if you can get away with pretending a point light is a directional light on an object, then an SH works great. If you need to handle multiple lights on a large object, like a big flat floor that's a single mesh, then SH doesn't really help here. Technically Unity also has the light probe proxy volume which stores light probe data in multiple 3D textures which allows it to work better on larger objects, but it still won't really reproduce the affect of dynamic lights moving across an object in any kind of believable way, plus I believe it only works on static light probe data? It's basically a 3D light map. Some AAAA games use something like it for all baked lighting rather than using light maps.

Basically, I don't think it's that useful. About the only use case I can think of is if you're doing a space shooter with lots of small ships & rocks flying around lit by laser beams / rocket trails. i.e.: Something without a ground plane or large objects to light.

 

So that is what Amplify is. Heard it mentioned, figured it was an outside editor like Substance Painter.
My big fear is Unity will eventually deprecate the standard pipeline in favor of the URP. But since Amplify works across all three, i will definitely look into it. Although... ...I am not nearly as intimidated by the idea of writing my own shaders like I was a year ago.

thanks the the SH explanation. One of the big problems has been the per object light limitation, because my terrain is just one mesh, so if I want multiple lights, the lights beyond the limit flicker out.

 

Oh, they absolutely will... 5+ years from now. They only just removed the legacy particle system, the one that shipped with Unity in 2005(!), at end of 2018. I think you've got some time.

Yep. It's why I wanted to comment on it before you spent too much time considering it. SH based lighting is super powerful, which is why it's been the mainstay of dynamic lighting since the PS2 era. But there's a reason why it wasn't until the Xbox 360 / PS3 era that "local lights" became a common thing.

 

Regarding this discussion at the top of this forum on URP with limited point lights or going with SRP or HDRP to remedy this. I'm building a virtual world game which allows users to instance mesh, lights etc in world at runtime and got caught in two minds what to do. My strategy is to build my scenes with HDRP and keep things shader limited to probably an ocean and lit/unlit shader for now. Since i produce my own scene descriptor for the world its a matter of two aspects for me. 1. Setup a URP environment lighting 2. Instance URP lit/unlit materials with smart downgrade alternatives to replace the HDRP materials. Obviously alot of visual quality can be lost doing this but you can still maintain a halve decent render with URP for an open world level environment. In summary my approach is to simply support URP when it finally gets a robust deferred renderer. Maybe there are some workflows you guys could see such an approach useful, but since i'm rendering procedural from a descriptor at runtime my requirements best suit this style of evolution.

 

I am doing lots of procedural as well. My terrain is a custom mesh with custom shader.

I have found that cheap forward point lights work much faster than the deferred. In fact, it seems like the forward (dshadowless) point lights are cheaper and almost free, but the deferred lag down my game quickly.

I don't know why, but my experience with them is almost the opposite of what I expected from bgolus's answer.

Perhaps it is because I am using GPU instanced trees.

I only discovered this a few weeks ago, and it has perplexed me, and even made me think of going back to URP, because HDRP is a confusing mess. I've been using it for about a year now, and it is still perplexing to say the least. URP seemed simpler.

 

I’m confused, HDRP only uses forward rendering if you force it on for the project & camera, or for any transparent shaders with are always forward rendered.

Disabling shadows on a light doesn’t make it use forward rendering if you’re using deferred, it just disables shadows. And shadows are super duper expensive for point lights.

 

I had shadows off for the point lights either way. I was just mentioning shadows for the other guy.

I turned off deferred lighting, and turned on forward, and the lights performed way better. After the deferred did not perform well, I switched to forward, it worked well, so then I re-read the manual, and it said Forward's point lights are really, really cheap.

I seem to remember something about deferred not working well for models taking up a large part of the camera view, so perhaps using them for terrain is not the best idea, but that is opposite what you wrote.
Either way, I actually only recently got into the massive amounts of lights stage, and deferred just crapped out after only about 300 lights, so I switched to forward, and even with 2000 moving lights, there really was no extra render cost in profile.

I thought maybe it had something to do with my terrain shader using both vertex and fragment shading, so I turned off the vertex part (was not doing much anyway), and it had no impact on deferred lights not working to well. (I still have not turned the vertex part back on).

Of course, the "problem' with forward is the lights blink on and off at random when moving the camera. I may experiment with writing my own "light LOD" script, as I wish the lights would act like LOD's, or have an option too, instead of flicking out on what I would assume to be some kind of as-created list index.