[Official] Dropping Deferred Lighting (Light Pre-Pass) rendering path for Unity 5.0?

Well, ok, it's not that black and white. But the targets all need to be the same size and there are already 3 targets used. (Not taking DirectX 10+ only into account.) So it will get a little tricky to store three 16 bit channels given that the first three targets are 32 bits. It's not impossible, but it's not as simple as "FP16 when HDR".

Yes, you could call it a "metallic workflow". I've seen some BRDF document with a metalness parameter before I think. My take on it is that we mainly do architectural visualisation and (almost) everything we need to show either reflects in the diffuse color or white. So it simply saves room.

With games in mind this might be a bit limited though. I can imagine many game designers are just used to the fact that there is a separate specular color. And I also like the idea of being able to store more realistic metal reflections or for example thin film reflection effects.

In my case emission was rendered additively in forward mode after the deferred pass. Eliminating any precision limitations with the emission intensity. The down side is similar to prepass lighting in that you have to convert the geometry twice. But the advantage is also similar in requiring less storage space in the g-buffer. Of course this design didn't take any realtime GI into account.

 

I am not suggesting that Unity changes it's GBuffer layout. In fact I think it's good that standard Unity 5 will allow materials with 'exotic' parameters which are not achievable with the metalness workflow.
I was mainly asking if someone knows a better way to measure or predict bandwidth usage other than testing different gbuffer layouts on a dozen different gpu configurations...

Good question.
Keep in mind that it's mostly a experiment and very specific to what "I" want and need. I don't think it would be useful for others because it entirely changes how I need to author my models (I use multi tile UVs and Amplyfy Virtual Texture 2 to batch as much as I can and save drawcalls for the gbuffer pass).
And at the moment I need atleast SM4.0 and bitwise operators to decode the YCoCg Albedo back to RGB .
Then I use the material index to pull emission, translucency and F0 from a list of materials during the main lighting pass. Reflections are deferred and also applied in the main lighting pass based on reconstructed world position (I have to limit the number of different reflection probes that are at the screen at the same time).
Lightmaps are not used/needed at the moment, but that may change with Enlighten. That would then be another 32bit, so I would end up at roughly 128bpp. I could live with that.

But hey, inFamous 2 uses 328bits per pixel and it still runs ok-ish. According to their gdc2014 postmortem they store Normals.xy and VertexNormals.xy in a rgba16 target (=64bit per pixel) and even have a rgba8 target (=32bit per pixel) dedicated to "wetness params".
In comparison Unity5 isn't fat at all and I may be overly cautious, but as I said, I simply don't know a better way of measuring bandwidth usage..

 

Speaking of the new deffered shading, what kind of information that exposed and can be accessed in the new buffer, is there any detail about it?

 

Personally I think the proposal to drop the old deferred method for the newer suggestion is a good one.

The extra flexibility in having a complete set of buffers to work with would out way the hardware specific limitations in my opinion. It would also free up developers that want to push in the direction of high end graphics to really extend themselves. Particularly now that other non game specific industries are looking to real time solutions for their own purposes, often without the hardware limitations that games developers cater for.

I think its important and progressive that you are offering a clean start graphics architecture for Unity, while also providing a "bread and butter" forward rendering path. The old deferred system was great for its time, but its increasingly becoming a clumsy middle ground when trying to implement newer concepts.

Also, Aras you seem to be hinting that the new method might be implemented with greater low level accessibility for customisation and fuller documentation..........I drool over such suggestions

 

Ah, I did not know this. I come from a platform where it had to be the same. I figured that was imposed by DirectX.

So right now there are a few unused spots. I can imagine you can set the roughness of the diffuse part and the reflective part separately. The room is there in the first RT. Or is roughness ignored for the diffuse part of the BRDF?

Anyway, this is getting pretty off topic. The previews I've look great. A great step forward for the deferred rendering in Unity.

 

I voted on switching to the new one anyways but it's varying between deferred and forward, anyways. If I'm using deferred I will probably use the new one from now on. So you can chalk one vote flexible on "usng the new deferred" or "using forward anyways".

 

So we cannot modified the buffer for now?

 

hi aras,
it would be really great if we could have translucency or sss stored to the gbuffer and taken into account in the lighting function.
speedtree just using lambert lighting and no culling on leaves is not really what i would expect from a 2014/15 engine.

lars

 

I second larsbertram1's proposal. Having translucency/sss/thickness somehow stored inside the gbuffer and used by the lighting equation would be nice.

 

This x 100. If people want to make games for >10 year old hardware (like a last-gen console) then good on them, but that shouldn't impact any decision made in Unity 5. Unity 4.x is a perfectly fine tool for them to use in that scenario.

I'm currently using Unity 4.x's "deferred" path, but I would drop it in a heartbeat if it meant moving to a 'better' alternative. Also should be noted - unlike Lars or Aieth who are shader wizards (and the main people who should be consulted on this tbh), I couldn't write a diffuse shader if my life depended on it. I'll admit openly that I rely on the fantastic work that Asset Store publishers (like Lars) have produced to make my game look good. By keeping in some outdated rendering path that's barely used in the first place (and has a better alternative in U5), you create a bad situation for Asset Store publishers who will probably have to compromise in order to support these different modes (making an assumption with this point).

Edit: Would be nice to actually see benchmarks on various hardware though, to visualise what kind of a difference new deferred vs LPP makes.

Also, with the hundreds of thousands of Unity users that have no firm grasp on what these modes mean, some users will no doubt be sucked into the "Noob trap" of choosing the old LPP anyway.

A side note, it would be nice if the new deferred didn't have all the little quirks and undocumented bugs in it that the current LPP has (eg. drawing linear rendertextures to screen, nothing drawing if no camera is active, camera depth issues, etc).

 

I'd say drop the old deferred. Forward is fine for less powerful platforms anyways.

 

just as i have said before: we are not talking about > 10 years old hardware.
i woud love to give my current laptop (2009 mac book pro (so it is 5 years old)) to my daughter – but i just keep working on it as it is still capable of doing most of the stuff i have to do. so she will have to cope with may be 7 years old hardware.
expect people playing casual games to have pretty weak hardware and deferred lighting might fit those needs pretty well under certain circumstances: especially as unity is not very much known as aaa game engine, but rather as a game engine that will allow you to address a very wide audience.
personally i am very fine with dropping deferred lighting but i just do not agree with anybody on his thread declaring this rendering pass as totally worthless: just step back and think a while.

lars

 

I'll love that !

 

Please vote NO!

Otherwise a lot of flexibility will be lost and things like screen space decals will be impossible because GI/lightmaps do not take G-Buffer data as input to be drawn, they're drawn when G-Buffer is being drawn:
http://forum.unity3d.com/threads/deferred-decals-not-compatible-with-gi.282782/

 

Uh, deferred on mobile is a thing?
Xbox 360 still developed for by the time Unity 5 is robust enough for release?

So this means we get both right? Or Unity stays with old deferred...

 

Oh well, more work for you guys either way. It's appreciated by your users

 

Actually, I just realized that even with Light Pre Pass this isn't fixed (obviously since it doesn't even have an albedo rendertarget)... the problem is that GI/lightmaps are calculated in the geometry pass... they should be treated as a light and use albedo, etc... as input!

Because of this I say yes, get rid of Light Pre Pass... however I think you guys need to do something about this!

 

Get rid of Light Pre-Pass please. the more junk around the harder the codebase will be to maintain.

 

I accidentally voted for the wrong one, Get rid of it please!

Offtopic:
Also @Aras in conjunction with letting us customize our own G-buffer, can you also allow us to easily sample the shadow map? I wanted to work on volumetric lighting similar to Killzone and Crysis 3 but I cant sample the shadow maps and have to make my own from the looks of it.

I can't do tex2D(_SampleShadow, shadowcoords); in Unity but I can do that with depth, and normals etc.

 

I would gladly ditch the old if it wasn't for the fact that my textures get impossibly dark in the new.


Old


New

Not to mention that, with the new deferred shading, a Windows version of my project end up looking drastically different from what I see on my editor. With textures looking blurry, washed out with barely any normal map information visible.

So, unless I'm doing something completely wrong, I'm going to stick with the old until the new one is debugged.

 

I voted for remove it. As long as mobile developers have a way to switch the rendering path during runtime so they can use deferred for the newer phones as it slowly becomes viable and fallback to forward if needed. Deferred without MRT just feels weird anyways.

 

Since we are on topic, can you separate layers for physics/rendering? Maybe the reason why people don't use deferred because there are more than 4 layers to exclude lighting so in a serious game, we need to layers for physics, like me I'm forced to used forward.

 

You can easily sample the shadow maps, look through the shader source, just take into account there are many different ways you have to do it depending on what the hardware supports.

 

RE: Deferred Lighting and Mobile

I'm very pleased that it was not removed. People mentioned several reasons why people may not already be using Deferred Lighting, and they are all valid, but I believe it is more likely an issue of people not realizing the benefits.

Unless folks are writing your own fragment shaders and setting up their scenes to take advantage of the numerous lights that can be exploited, most game would not see any benefit. Lets be honest there aren't too many people pushing the limits of mobile right now. Not just in the Unity community but anywhere.

However we are at a major transitional point in mobile. The latest devices are fast enough to handle a great deal of fragment shading operations, but only with Deferred Lighting.

Cheers.

 

But the new method is faster, the old one is terrible for mobiles by comparison.

 

That hasn't been my experience, but I'll do some stress testing between the two.