Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    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.

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

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

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

    9 vote(s)
    5.2%
  1. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    So Unity has the Deferred Lighting rendering path. For Unity 5.0 right now we're somewhat sweeping it under the rug, and want to direct people to use new "deferred shading" rendering path.

    Advantages of new deferred shading:
    • More information in the g-buffer, so things like physically based rendering are possible.
    • Which means it works with new fancy Standard shader in 5.0.
    • One pass over geometry (compared to two passes for light prepass).
    Advantages of the old one (light prepass) deferred lighting:
    • Can work on more platforms - does not require multiple render targets. In practice this means most mobiles could in theory run it, and same for Xbox 360 (we don't have MRT implemented on 360 right now).
    • Can use less video memory bandwidth than full deferred shading.
    Now, the question: should we keep the old deferred lighting path working, or just flat-out remove it?

    Based on some data we have, it doesn't look like many people are using deferred to begin with. Mobile games pretty much never use it; and on PC/consoles about 10% of game builds use it (from editor analytics). If most of these would upgrade to new deferred shading in Unity 5.0, then not much point in keeping the old one around.

    Update: looks like we're keeping deferred lighting in Unity 5.0.
     
    Last edited: Nov 29, 2014
  2. TutiBueno2

    TutiBueno2

    Joined:
    Oct 16, 2012
    Posts:
    3
    I just loved Deferred Lighting since the first day you guys released it. However it has that annoying issue which is when you use more than one camera with different depths.
     
  3. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    So we'd be looking at Forward + 'Deferred Shading' as default..? What happens to realtime shadows from multiple light sources?

    Not sure I really understand the implications of 'Deferred shading' in place of Deferred rendering.
     
  4. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    No. The default (in 4.x) is Forward; the default in 5.0 will very likely stay Forward.
    I don't see how that's relevant, really. You can have that in Forward, Deferred Lighting or Deferred Shading.

    "Deferred Lighting" (4.x way, aka "light prepass") and "Deferred Shading" (5.0 way, aka "MRT g-buffer") are just two of the many ways to do deferred rendering. I'm asking, whether anyone needs two ways to be present in Unity 5.0, or just one (deferred shading) is enough.
     
  5. Chman

    Chman

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    721
    I use the current Deferred Lighting rendering path for only two reasons :
    • Multi camera setup + HDR. It doesn't work properly with the Forward rendering path and the only workaround I could find has a big hit on memory usage. See this topic.
    • For some reason, the depth map quality (for depth-based post processing effects) is better with Deferred than with Forward.
    Honestly, if I could switch back to the forward rendering path I would do it in a heartbeat. It's faster on low-end computers, less memory hungry and allows more freedom when it comes to shaders and custom lighting models.

    So I guess my answer would be : if the first issue could be resolved, I would switch back to Forward (and thus you could dump the old Deferred, as far as I'm concerned). If not... I would probably switch to the new Deferred path, forget about low end hardware and suffer in silence.
     
    haskellf2 likes this.
  6. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    Maybe I'm missing something here but if there's no Deferred Rendering mode then we would always be using Forward Rendering, right?
     
  7. julian-moschuering

    julian-moschuering

    Joined:
    Apr 15, 2014
    Posts:
    529
    Supporting two modes will just make Unity bigger and the eg the Asset Store less compatible. I think Unity 5 is a good point to drop or refactor features.

    So I guess deferred shading mainly adds the diffuse color to the g-buffer + changes for PBR?
    The main problem I see for using MRT's for colors and geometry information is, that alpha blending, at least in DX9, may make problems. Eg adding an alpha blended decal to the g-buffer may not support modifying speculars or normals easily and requires multiple draw calls with different write masks.

    Still I rather put some time into converting to the new method rather than having a cluttered unity.
     
    landon912 and hippocoder like this.
  8. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Would deferred shading allow us to add our own GBuffers into the pipeline?

    Either way, I'm in favour of deferred shading. Just curious.
     
  9. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Yes you are missing something :) Unity 4.x has Deferred Lighting. Unity 5.0 adds new Deferred Shading, so now it has two "deferred" ways. The question is, does it need two. See advantages of either of these in my original post.
     
  10. pahe

    pahe

    Joined:
    May 10, 2011
    Posts:
    543
    As Aras mentioned, there will be Deferred Rendering. The question is if we need the old 4.x way AND the new 5.x way, right?

    Tl:dr
    Drop the old one!

    From my point of view, supporting both version is more complicated. You have bugs, fixes,... for both versions, so way not concentrate to one version. If I understand right, the biggest benefit of keeping the old version is that it runs on the older platforms. I think the older projects may have to stay with 4.x then. I wouldn't like to see the progress in technology be slowed down by older platforms.
     
  11. Guillaume-Swing

    Guillaume-Swing

    Joined:
    Nov 29, 2012
    Posts:
    5
    Our opinion regarding our project is biased since we are implementing our custom G-buffer to make some 2D lighting.

    But I agree with Julian, if you can drop old not so used features, it will make Unity 5 more consistent and easy to maintain!

    So yes, drop as much things as you can when it still time!
     
    landon912 and hippocoder like this.
  12. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    Doh I see now.. I was misunderstanding the rendering path options... In that case toss it! See if I care! Burn it with fire!
     
  13. aubergine

    aubergine

    Joined:
    Sep 12, 2009
    Posts:
    2,878
    I think this kind of "Shall we ditch this feature and add this new feature" questions from "you" are very useless.
    After all, you know how things work inside unity and im sure you want to make it fastest and supporting most platforms while keeping up with rival game engines.

    Considering unity 5 is a brand new product, you should just do whatever you see fit and stop teasing us.

    Just dont forget to include very clear and fine documentation along!!
     
  14. AngryAnt

    AngryAnt

    Keyboard Operator

    Joined:
    Oct 25, 2005
    Posts:
    3,045
    Yea what is this madness about including the community? STAPPIT! ;)

    Kidding aside, perhaps you could provide a more detailed description of which platforms supporting deferred lighting, will not support deferred shading? With a layer of realism perhaps - IE "this would be able to run it, but wouldn't make much sense".
     
  15. aubergine

    aubergine

    Joined:
    Sep 12, 2009
    Posts:
    2,878
    For starters, i dont even know what "Deferred Shading" means according to Aras. How can i have any opinion on that?

    As community, we want cryengine capabilities with the simplicity of Unity editor/c# aand a great documentation along with it aaaaaaand for free. Need to ask more? :p
     
  16. jvo3dc

    jvo3dc

    Joined:
    Oct 11, 2013
    Posts:
    1,520
    That is a good question. I've made my own deferred rendering path before and at that time I also ended up with a full deferred solution with material properties like roughness stored in the MRT. So, I'm liking the physically based shading direction.

    The old light prepass rendering has a less advanced BRDF than the new deferred rendering. So it's not very useful for high end platforms anymore. At the same time, the low end (mobile) platforms often don't have the power (and the design) to do light prepass rendering. So in that light, I'd say, remove it.

    I can however imagine that newer mobile platforms will at some point be able to do light prepass rendering. I haven't tested it, but I'm guessing that the new nvidia shield with its classically designed tegra GPU can handle light prepass rendering quite nicely. And while the BRDF might be less impressive than fully deferred, the increase in light sources can still open new possibilities. So in that light I can imagine that light prepass rendering can be worthy step in between forward and fully deferred.

    So I guess the question really is, how much extra effort does it take to keep the old light prepass path in there? I don't see myself using it in the near future if a full deferred option is available, but who knows what the future brings.
     
  17. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,106
    Drop old one :)
     
  18. DaveHoskins

    DaveHoskins

    Joined:
    Sep 9, 2013
    Posts:
    190
    Yes, drop it.
    And please draw the z-buffer in the same deferred pass instead of drawing it separately, which is a serious waste of GPU cycles.
     
  19. Giometric

    Giometric

    Joined:
    Dec 20, 2011
    Posts:
    170
    I'm inclined toward the "Yes, remove it since I'd rather switch to the new method anyway" option, but I do have a question regarding mobile platforms in particular. I haven't tried to use Unity's current deferred method on mobile myself, but your initial post makes it sound like it's not exactly practical anyway, even though technically they can do it. In a little while, when most mobiles are fast enough to do the current method, how far of a jump in needed power is it before they can also do the new method well?

    In other words, once mobiles in general have gotten to the point that doing deffered shading/rendering is feasible, is the old method so much faster than the new method that it could make the difference between being able to use it or not on a lot of devices for a long time, or is the new method going to be close enough of a jump that using the new way from the get-go will be safe enough?

    Obviously, given enough time that will happen anyway. But if there was, say, a year or two where performance of most mobile devices was good enough to do the old method, but not the new one (again, in general), then it might be worth keeping it around, since otherwise that's a couple extra years that using deferred is totally unfeasible. (and maybe that doesn't matter too much anyway, since as you said most people aren't using deferred on mobile)

    I imagine that won't happen, that mobiles are increasing in power fast enough that it'll be at most months where that gap exists, but you guys have all the performance metric info, so you're in a better position to make those kinds of predictions. Either way, still leaning towards removal, largely to prevent confusion for users and so you guys can put more time into fixes/improvements for the new pipeline.
     
  20. rjevans

    rjevans

    Joined:
    Sep 24, 2010
    Posts:
    24
    I'd also like to know the answer to this - we're currently using this to customize lighting in our game
     
  21. Phantomx

    Phantomx

    Joined:
    Oct 30, 2012
    Posts:
    202
  22. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    But... we already do that, and always have? (except when that doesn't work due to driver issues, IIRC Radeon GPUs on Macs).
     
  23. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    @Aras, please make decisions for current and next gen, not old gen. Let's be honest, if one will develop for old hardware nobody gives a crap about, that hardware is probably too slow for Unity 5 features... and they can use 4x :)

    So yes... make positive changes providing that you document them and make it faster to render! Being able to define own buffers in future would be interesting also.

    Do you want Unity to always play catch up, or will Unity 5 be what everyone really wants - to be for now and the future, able to compete easily against UE4. You can't do that if all your work is spent on maintaining legacy deferred that not many people understand anyway ;)
     
  24. AngryAnt

    AngryAnt

    Keyboard Operator

    Joined:
    Oct 25, 2005
    Posts:
    3,045
    Then how about researching it rather than making a fuss in here about how asking the community for feedback is bad?

    We do? I must have missed that vote.
     
  25. Sir-Irk

    Sir-Irk

    Joined:
    Jan 16, 2014
    Posts:
    1
    I'm curious if the new Deferred Shading can use hardware MSAA instead of just image effect based AA. Lack of MSAA is the number one thing that makes the current Deferred Lighting unappealing to me. I'd readily use it if a better solution for anti-aliasing could be worked out. I know that deferred rendering brings technical problems when using hardware AA. However, I don't know if there have been solutions to the problem which is why I'm curious. I don't feel I know enough about the +/- of your Deferred Shading vs Deferred Lighting to give a valuable vote in the poll.
     
    Last edited: Oct 23, 2014
  26. aubergine

    aubergine

    Joined:
    Sep 12, 2009
    Posts:
    2,878
    I belong to community and i shared what i think. If you wont respect my idea, why ask for it in the first place?

    EDIT: On the other hand, you are an ex-unity worker and still a part of the staff as moderator. So, unity should respect my idea slightly more than yours.
     
  27. duke

    duke

    Joined:
    Jan 10, 2007
    Posts:
    763
    Yes, remove it. If people want to use the legacy system because it's an old project then they can stick to 4.

    Also, some of the responses here are astounding - it's not an opportunity to throw barely related questions at aras, or ask what deferred rendering is. Do some research yourself and then answer the question!
     
  28. Phantomx

    Phantomx

    Joined:
    Oct 30, 2012
    Posts:
    202
    So if I get it right you won't be able to create your own lighting model in deferred? Physically based shading is nice for realistic stuff, but not really what we want for a stylized game. Not being able to customize your lighting model in deferred is a deal breaker for us.
     
  29. aubergine

    aubergine

    Joined:
    Sep 12, 2009
    Posts:
    2,878
    I suppose that is directed at me, so here is your answers:
    *I did not ask an unrelated question to aras or anyone else, i just expressed my opinion on the usefullness of the initial thread. This thread is summarized as "we are ditching the Light prepass. Just so you know."

    *I know what general "deferred rendering" is and i can assume i know slightly better than you do. I just dont know how they will do the integration on unity. If you read carefully(by paying attention to punctuation), you could have seen. If, it would have been answered; it would be on your benefit as well.

    Aaanyways!
     
  30. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Why not? Write your own shaders that write whatever you want to the g-buffer, override the lighting pass shader to do whatever you want with lights & the g-buffer information - done.
     
  31. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    The thread summary is more like "does anyone here really need it still?". If people voice valid reasons why they need it - then we keep it.
     
    shkar-noori likes this.
  32. Phantomx

    Phantomx

    Joined:
    Oct 30, 2012
    Posts:
    202
    OK I get it, works with me then!
     
  33. Reanimate_L

    Reanimate_L

    Joined:
    Oct 10, 2009
    Posts:
    2,788
    drop it....
     
  34. Deleted User

    Deleted User

    Guest

    Aye drop it.

    For anyone who cares:

    DS = Need fat G-Bugger, single pass per light, requires more memory.
    LPPDR = Needs to render geometry twice, single pass per mesh, works better with DX9 in conjunction with MSAA. If anyone still cares about DX9?

    Materials on both have ups and downs and quite limited, meh!.

    P.S I agree with everything Hippo says.
     
    Last edited by a moderator: Oct 24, 2014
  35. varfare

    varfare

    Joined:
    Feb 12, 2013
    Posts:
    227
    Drop it. Forward/vertex lit is fine for mobile which are not capable of running current deferred (most of them). If anybody would want old method could still switch to 4.x. If the old deferred will stay inside U5 I assume that it will cause some problems- keeping documentation up to date for both renderers, bugfixing old renderer & new, people will call for improvements for old deferred... It could turn out to be unity developer's hell ;)

    I am currently working on second Unity game based on deferred renderer and I can't see any pros of leaving old deferred inside U5.
     
  36. shkar-noori

    shkar-noori

    Joined:
    Jun 10, 2013
    Posts:
    833
    Drop it, and please bring a better AA solution.
     
  37. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    666
    The old method is no where near as good as the new one, so drop it.
     
  38. DaveHoskins

    DaveHoskins

    Joined:
    Sep 9, 2013
    Posts:
    190
    Hmm, from my experiments with my own vertex movement, I also had to make a separate shader for the depth buffer pass so they would match the rendering. Which tells me the vertex data is passed more than once. This is on Windows 7 with Direct X.
     
  39. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    6,899
    hi there,

    first, it sounds convincing to just remove "old, unused" stuff.
    but thinking about where you find most unity games right now (on mobile or as a webplayer – there are not so many aaa titles around as far as i know) things might look a bit different:

    deferred lighting doesn’t play a role as far as mobile is concerned right now – which might change in the nearby future as others have said.
    and if it comes to webplayers and casual games i would not expect people having the latest and hottest hardware.
    not to think about webgl (if deferred lighting is or might be supported on this platform at all).

    so having e.g. indoor scenes with heavy use of point and spot lights might become a nightmare for some gamers:
    either due to forward lighting (slow by design under these circumstances) or deferred shading (slow due to the band width consumption and their hardware).

    for theres reasons i am not quite sure how this would really fit into unity’s strategy.

    btw.: any chance to get translucency or sss into the current deferred shader of unity 5?

    lars
     
    GoGoGadget and shkar-noori like this.
  40. Deleted User

    Deleted User

    Guest

    Not sure what you're getting at there? At the moment in Unity 5.0 there is two deferred renderers. Aras is asking is we have any need for light pre-pass.. Forward rendering isn't going anywhere..

    No point in trying to keep both of them running..
     
  41. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    1. old deferred is too slow for any mid-level mobile phone

    2. MRT means you do not have to calc all the verts again, multiple times. The proposal means deferred is potentially fast enough for mid level phones (which support MRT), where current deferred is not. Which means it would actually be quicker to execute. Only really old crap doesn't support MRT.

    3. For slow/old devices you can use forward rendering.

    4. MRT is potentially a lot more optimisations than just prepass lighting, for instance you could use it for AO and a number of other physically based setups, which makes Unity a true PBR renderer.

    So your comments indicate to me you aren't really understanding the proposal, forgive me if I am wrong. With this proposal, mobiles potentially would be able to use it with a lower res to save on excessive fill. K1 gpu and UE4 demonstrate the viability of the approach quite well with the rivalry demo.
     
  42. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    6,899
    forgiven!
    but i was not talking about next gen mobile devices but rather old pc/mac/linux and xbox360 hardware which might not benefit from deferred shading due to its demands as far as bandwidth is concerned (unity 5’s g-buffer is more fat than the one crytek uses in ryse if i remember correctly). you could go with forward on those but that comes with some drawbacks under certain circumstances which i have described in my previous post.

    if that is not relevant to the market (aras mentioned only 10% of the game builts using legacy deferred (which might be caused by the fact that deferred is pro only however)) and unity’s strategy i would call for dropping deferred lighting too: less is more.

    lars
     
    hippocoder likes this.
  43. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I see yeah! I mean I thought 'this guy works on Lux, I must be wrong!' but I just didn't understand you clearly :)

    Is it possible that a gbuffer-lite can be used to create a compromise? After all, perhaps some extra lights is all people want.
     
  44. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    6,899
    if the device supports mrt a g-buffer "lite" would be a solution of course.
    although i am not sure where to save some bytes if this would be the final buffer layout:

    • G-buffer layout
    • RT0: diffuse color (rgb)
    • RT1: specular color (rgb), smoothness (a)
    • RT2: world normal (rgb; 10.2)
    • RT3: emission/light buffer; FP16 when HDR
    • Z-buffer: depth
     
  45. Aieth

    Aieth

    Joined:
    Apr 13, 2013
    Posts:
    805
    The only reason one would ever want to use light prepass over full on deferred shading is either bandwidth or limits in available memory. In a modern computer none of those are an issue. The only platforms possibly affected by dropping LPP would be the old consoles and mobile units. I can't imagine many people are going to be using Unity 5 to develop for last gen consoles. I mean, who is going to be starting development for the previous generation now?
    So the only real reason to keep LPP around would be mobile units. So the question should really be how many are actually using deferred lighting for their mobile games? I admit I know very little of the mobile market, but my intuition tells me most games are forward shaded. And out of the few games that are deferred shaded, I would think are doing it to push the boundaries. And that in general means a team of experienced graphics developers, people likely to be writing their own rendering engine. So LPP for mobile units falls into a greyzone, too slow for the majority and not enough control for those who would use it.

    So, in conclusion, I think it would be a safe bet to drop LPP. It made sense during the previous generation but it has played its part, at least for now. I can see it becoming relevant in a few years when mobile units catch up though, so perhaps put it on the backburner now and reintroduce it later as "Mobile Optimized Deferred"?
     
    Deleted User and shkar-noori like this.
  46. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Well we're not actually worried at all. Our current game is already ps4/vita so obviously it runs very well on those. It's not due for launch for another year or so, therefore by the time we do tackle the next title and finish it, we'll be around 2-3 years from now, so that's going to be considerably less ps3 or 360 active paying customers. At this point everyone will have upped the bar visually.

    If you're even considering a mobile port, then it's probably forward rendering people need.
     
  47. jvo3dc

    jvo3dc

    Joined:
    Oct 11, 2013
    Posts:
    1,520
    Switching RT3 to FP16 would mean switching all targets to FP16.

    This is a bit off topic, but once you start doing physically based shading, you don't really need a specular color. All non-metallic materials basically reflect white. Metallic materials approximately reflect colored diffuse when perpendicular and white when parallel. (This is an approximation, but a much better one than a fixed specular color.)

    Light emission is not usually affected by the amount of incoming light, so it doesn't need to be stored in the deferred buffer. I do like to store ambient lighting from light maps in the deferred buffer. If ambient lighting is available the effect of the SSAO pass can be greatly reduced for a better visual result. Where it is unavailable, SSAO can fill in the blanks.

    Whole different discussion, I know, but I usually use this G-buffer layout:
    • RT0: 8888: Diffuse (RGB), Smoothness (A)
    • RT1: 8888: Lighting (RGB), Reflection type (A)
    • RT2: 16.16: Normal (RG)
    • Z-buffer: Depth
    Light emission is added between the main pass and blend passes. Reflection type contains both the intensity and the type. (Nothing to fresnel to full to metallic fresnel to nothing.)
     
  48. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    No, why?

    So that's the "metallic workflow" you're talking about (have a single color which is diffuse or specular based on "metalness"; have a single channel metalness texture; and have a single channel "reflectivity for non-metals" texture that can handle F0 variation in non-metals). The "specular workflow", which is what we have in 5.0 out of the box now, is a pure superset of that - it can handle more non-pure materials, and more "non realistic/stylized" materials.

    We're still considering what to do with metallic vs. specular workflows, and if we should provide both out of the box somehow.

    It needs to be stored somewhere though, while rendering the objects :)
     
  49. vivi90

    vivi90

    Joined:
    Jul 28, 2010
    Posts:
    78
    I vote for dropping the light prepass path. If someone in the future makes the informed decision that he absolutely needs light prepass, he is usually informed enough to implement it himself. And I imagine it's quite annoying for some Asset Store sellers too to make "awesome shader package xyz" compatible with every single rendering path...:eek:

    Slightly offtopic, sorry: The current U5 GBuffer is quite "fat" at the moment. Of course, things get shoved around and it's most likely not final yet. But does somebody know of a way to measure the current real bandwidth usage of a gpu? The internet tells me nothin'bout it...
    I ask because I have a little side project with a custom minimal gbuffer and I want to make some comparisons for myself.
    The layout is "very" compressed and minimal in order to save bandwidth:
    • 24+8bit: ZBuffer ; Stencil Buffer
    • 8888: Albedo YCoCg interleaved compressed (RG); Metalness(B); AmbientOcclusion(A)
    • 8888: Normal_view.XY stereographic projection(RG); Roughness(B); MaterialIndex (A)
     
  50. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Where would emission, lightmaps, reflection probes & ambient go in your g-buffer?