Search Unity

  1. Unity 2020.1 has been released.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

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

Discussion in 'Shaders' started by Aras, Oct 21, 2014.

?

Should we remove old (light prepass) deferred lighting for Unity 5.0?

  1. Yes! I'm using forward rendering anyway.

    25 vote(s)
    14.9%
  2. Yes! I will switch to new deferred shading anyway.

    96 vote(s)
    57.1%
  3. No! I need the light prepass one, because.

    38 vote(s)
    22.6%
  4. I have no idea what you're talking about.

    9 vote(s)
    5.4%
  1. jvo3dc

    jvo3dc

    Joined:
    Oct 11, 2013
    Posts:
    1,445
    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.
     
  2. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,608
    Most DX9-level GPUs also support mixed-bit-width render targets just fine (D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS).

    There are some that can't (I forget which ones right now - but they either aren't popular; or their performance is so that you really don't want HDR or deferred there).
     
  3. pigzlz

    pigzlz

    Joined:
    Jul 28, 2010
    Posts:
    78
    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".o_O
    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..
     
    Last edited: Oct 29, 2014
  4. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,422
    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?
     
  5. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,608
    We haven't written much documentation yet (on todo list...), but current g-buffer layout is as follows:

    ARGB32: Diffuse color (RGB), unused (A).
    ARGB32: Specular color (RGB), roughness (A).
    ARGB2101010: World space normals (RGB), unused (A).
    ARGBHalf (when HDR) or ARGB32 (non-HDR): Emission, lightmaps, ambient and lighting accumulation.
    Depth+Stencil buffer: well, depth and stencil.

    So that comes out at 160 bits/pixel (non-HDR) or 192 bits/pixel (HDR).

    On my todo list to make the g-buffer layout configurable, but haven't done that yet.
     
    Charkes and Reanimate_L like this.
  6. brn

    brn

    Joined:
    Feb 8, 2011
    Posts:
    318
    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 :)
     
    hippocoder, pigzlz and shkar-noori like this.
  7. jvo3dc

    jvo3dc

    Joined:
    Oct 11, 2013
    Posts:
    1,445
    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.
     
  8. the_motionblur

    the_motionblur

    Joined:
    Mar 4, 2008
    Posts:
    1,737
    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". :D
     
  9. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,422
    So we cannot modified the buffer for now?
     
  10. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,608
    Not yet.
     
  11. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    5,775
    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
     
  12. Marco-Sperling

    Marco-Sperling

    Joined:
    Mar 5, 2012
    Posts:
    597
    I second larsbertram1's proposal. Having translucency/sss/thickness somehow stored inside the gbuffer and used by the lighting equation would be nice.
     
  13. GoGoGadget

    GoGoGadget

    Joined:
    Sep 23, 2013
    Posts:
    716
    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).
     
    Last edited: Nov 27, 2014
  14. FranckS

    FranckS

    Joined:
    Jan 14, 2014
    Posts:
    29
    I'd say drop the old deferred. Forward is fine for less powerful platforms anyways.
     
    Last edited: Nov 26, 2014
    Charkes and shkar-noori like this.
  15. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    5,775
    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
     
  16. Charkes

    Charkes

    Joined:
    Apr 17, 2013
    Posts:
    228
    I'll love that !
     
  17. cakeslice

    cakeslice

    Joined:
    Oct 18, 2014
    Posts:
    186
  18. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,608
    Update on current thinking: looks like deferred lighting (aka light prepass) will stay in 5.0. Reasons being lower-end hardware that can't do MRT efficiently (mobiles, Xbox360); some flexibility allowed by deferred lighting; and simply the fact that no one here has time to remove it (it's harder than it looks! a lot of documentation needs to be updated, etc. :))
     
  19. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,727
    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...
     
  20. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,608
    Apparently some people use it.

    Correct. i.e. final 5.0 is likely to have what current betas have: both new deferred shading, and legacy deferred lighting.
     
  21. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,727
    Oh well, more work for you guys either way. It's appreciated by your users :)
     
  22. cakeslice

    cakeslice

    Joined:
    Oct 18, 2014
    Posts:
    186
    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!
     
    Last edited: Dec 1, 2014
  23. shkar-noori

    shkar-noori

    Joined:
    Jun 10, 2013
    Posts:
    833
    Get rid of Light Pre-Pass please. the more junk around the harder the codebase will be to maintain.
     
  24. WGermany

    WGermany

    Joined:
    Jun 27, 2013
    Posts:
    78
    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.
     
  25. GixG17

    GixG17

    Joined:
    Aug 18, 2013
    Posts:
    99
    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.
     
    GoGoGadget likes this.
  26. GGeff

    GGeff

    Joined:
    Nov 11, 2014
    Posts:
    40
    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.
     
    Last edited: Dec 9, 2014
    hippocoder likes this.
  27. imtrobin

    imtrobin

    Joined:
    Nov 30, 2009
    Posts:
    1,548
    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.
     
  28. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    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.
     
  29. CFprime

    CFprime

    Joined:
    Feb 6, 2015
    Posts:
    27
    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.
     
  30. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    But the new method is faster, the old one is terrible for mobiles by comparison.
     
  31. CFprime

    CFprime

    Joined:
    Feb 6, 2015
    Posts:
    27
    That hasn't been my experience, but I'll do some stress testing between the two.
     
unityunity