URP deferred

I've spent a few hours changing the lighting model of built-in lighting model, it was hum... interesting.
So I have one request for the URP deferred, to lower the level of hum... interestingness:

make the changing of lighting model EASY

what this means practically:
wrap lambert should be no more than 4 nodes away: ndotl (yep should be a node so we don't have to redo it 20 million times, since it's used all the time), 0.5, mult and add

also, make multi pass composite possible so we can have inverse hull outlines.

 

hi, in which version you managed to use the deferred mode in URP?

 

the lighting model change was done in built-in, URP team is releasing deferred any-time-now™

 

How about the performance? I tried the deferred rendering in URP 9.0 with Unity 2020.2, seems every point light cause 3 extra non-batched draw call(Stencil Volume Pass + Lit Pass + Simple Lit Pass), not a big deal for PC, I did not see any framerate drops inside editor, but it's a little bit scary...so I switch back to forward renderer...

 

So they are implementing deferred as it was 10 years ago, using stencil-based geometry draw calls instead of tiled/froxel compute-based shading. Why? Any GPU that doesn't support compute shaders in 2020 is also very likely not capable of running 10+ referred rendered lights at an acceptable performance.

 

Hope that's only a very basic implementation in 9.0, because I saw tile depth pass in 10.0.

 

That's reassuring. DeferredLights.cs is all about tiled lighting. Also nice to see many #if UNITY_SWITCH around the code, it means the team is actually testing their stuff on device or something. Oh, and seems they are trying to use burst inside SRPs now, so there is hope. For projects starting next year, but still.

 

Nice. I'll take a look at v10

 

how do you install v10?
I get

Spoiler: this error

Z:\__TESTS\Graphics\com.unity.render-pipelines.universal\Editor\ShaderGUI\ParticleGUI.cs(319,106): error CS1061: 'ParticleSystemRenderer' does not contain a definition for 'supportsMeshInstancing' and no accessible extension method 'supportsMeshInstancing' accepting a first argument of type 'ParticleSystemRenderer' could be found (are you missing a using directive or an assembly reference?)

in 2020.1 and 2020.2

 

a18

 

Wait, URP gets a Deferred renderer?

NOOOOOO... all the shaders just get more complicated now, I thought the main idea of URP was it being forward renderers all the way down.

 

They want to replace built-in, and built-in has deferred, so...

 

I tried https://github.com/Unity-Technologies/Graphics/tree/v10.0.0-preview.18 which has urp 14 and https://github.com/Unity-Technologies/Graphics/tree/v10.0.0-preview.14 which has urp 10 < very confusing, needs consolidation to a same preview # even if URP team falls between sub releases.
None work with a18

 

Ok. I thought built-in was split into HDRP and URP, but ok. I think they should make a Deferred variant of URP though.

 

That was the original idea with LWRP and HDRP. But when Unity realized expecting their user base to write their own render pipelines was infeasible, LWRP became URP and its goals changed: it now has to do everything built-in did, plus do it faster, better and scaling all the way from low end mobile to next-gen consoles (this will take a while).

HDRP's role in this scenario is uncertain, since the only features it will have over URP when it's all said and done are volumetric lighting and ray tracing.

 

that's what I'm doing, what's the github url of a repo that works for you in a18?

 

HDRP will still have more features than URP out of the box.
Just count all the different Material types and shaders: Ansitropy, Iridescence, Translucent, Subsurface Scattering, Clear Coat, Hair, Eye, Refraction, Distortion. There is nothing on URP roadmap that indicates these features will come to URP Lit.
In addition, the new Realtime GI may only come for HDRP exclusive because on URP roadmap, Realtime GI is marked as "Under Consideration". Same thing for light proxy volumes.

 

Is funny how Unity 5 is still alive in urp =)) it never changed in 6 versions of unity5 and it will never change for alot more years to come from what i can tell.

 

Yes each module has a different version when I add them from the same repo, and one of the repo I've tried is this one:

I might be doing it wrong so here are the steps:
in package manager click on the +/from disk then open the urp folder and double click on the .json file
do the same thing on the core and the shader graph folders

 

urp v10.0.0-preview 26 is in
where is deferred pipeline asset?

 

yea I'm a bit confused, I thought deferred was promised for 2020.2, has that been changed?

 

I can ask the team to get a definitive answer for you @Anisoft, I hope this helps!

 

Yeah thanks that'd be great to find out.

I've been modifying the standard pipeline for my own needs but I feel being able to use deferred in urp would help make some things a bit easier, especially with some custom lighting stuff that HDRP doesn't easily support (it has has a lot of features I dont exactly need)

 

Hi @Shaunyowns ,

any answer from your team on promised deferred rendering for 2020.2 ?

thx

 

I wouldn't rush them, pressure to perform's on the team.

 

anything new about the Deferred Renderer ??

 

So what exactly does this say about its release?

 

Any news about URP deferred?

 

No, better stick with old built-in graphics if you can!

 

I thought URP was getting volumetric light .. right ?

 

It is marked as planned on the roadmap.

 

Somewhere between 2021 and the heat death of the universe.

 

So what about deferred renderer? Is it coming anywhere soon?

Why Unity team always has such problems in communicating? They literally almost never follow any discussion.

 

Any updates here, or estimates? 8 lights is not enough

It 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.

 

There should be more options between a hard 8 lights limit and full blown deferred rendering.

 

Right. I get down from 132 FPS (2 lights) to 128 FPS (8 lights) in my scene.
I have plenty of space for more lights.
The limit should be entirely up to us.

 

Keep in mind that 8 light limit is not per scene, but per object. If your objects are not too big and each is lit by 8 or less lights at any single moment than you can totally use more lights in your scene.
Also, light limit in forward rendering is not some (totally) arbitrary number, each additional light adds instructions to lit shaders.

 

There are different ways to render lights in forward rendering which don't involve bloating the shaders. We could have at least the option to multipass (so 8 lights per pass), but there is also tiled forward lighting and clustered forward lighting, which can actually outperform deferred depending on the scene and target hardware. For something called "universal", it should have more options.

 

Sure, but that's including terrain as an object. It is a problem for me. 16 would probably be enough, but 8 is ridiculous.

 

The per-object lighting is terrible for large objects like terrain because it doesn't matter if the lights are large or small: every visible pixel of the terrain will calculate all visible lights, regardless if said pixel is outside their radius because the entire system was designed to be friendly to GLES 2.0 mobile GPUs by avoiding more complex features like branching and SBOs.

The problem is that devices which only support GLES 2.0 are often too slow to handle more than one per pixel light anyway, so you have a system that runs sub-optimally on every platform.

 

Any updates please? I'm more than happy to use an unstable version.

 

8 light per object? Are we back to the PS2 era?

 

Unreal engine light limit Unreal engine has a hard limit of 4...

I hope with the new URP deferred renderer and the new urp debuger there will be an option to detected overlapping lights. We go through a lot of effort to make sure we have no more than two real time non moving lights (directional and some other light - generally spot light ) and one real time moving lights affect any given object in the scene at a time.

Aside from that the urp forward render combined with point light shadows is actually pretty fast. It will be interesting to compare performance between the forward and deferred.

 

That's for stationary lights, which are the Unreal equivalent of Unity's mixed mode lights (shadows are baked, but the light itself isn't). And that's not per object, it's per pixel, so you can have hundreds affecting the same object as long as no more than four overlap at once. Finally, excess lights revert to dynamic shadows, they don't just stop rendering altogether like on URP.

The URP lights behave more like old fixed function OpenGL lights.

 

Still no word on this?