Unity 3 Feature Preview – Deferred Rendering

September 9, 2010 in Technology

After a bit of radio silence we’re back with another Unity 3 feature preview.

In this short video Will Goldstone shows some of the benefits of the new deferred rendering path in Unity 3.0 such as being able to have dozens of lights on screen at the same time without a performance hit as well as using advanced image effects that utilize the same depth and normal textures as deferred rendering.

[vimeo clip_id="14832454" width="640" height="360"]

 

And stayed tuned for the Occlusion Culling video… we promise it’s almost ready ;)

Comments (20)

Subscribe to comments
  1. Termin8

    December 15, 2010 at 4:12 am / 

    Hello!

    Are all these object covered with emissive materials or just light sources added to each of them?

    Thank you!

    Best regards,
    Alexander

  2. Tal S

    September 20, 2010 at 4:13 am / 

    I pee ma pants

  3. Francis Humphries

    September 14, 2010 at 6:27 pm / 

    WHAT! Pro only? That is just damn great :/. I was really looking forward to unity 3 aswell. Oh well, I guess that’s where you make the money.

  4. Nathali Abbortini

    September 12, 2010 at 11:19 pm / 

    Oh wow,this is al great.
    But uuuuhhh,the Umbra Occlusion demo was supposed to be finished soon ?

  5. Aras Pranckevičius

    September 12, 2010 at 11:14 am / 

    @Dave: if deferred rendering is not supported, it will fallback to forward shader based rendering. If shaders are not supported, it will fallback to fixed function per-vertex lit rendering path.

    @edvinas: yeah, anti-aliasing and deferred rendering techniques do not easily mix together. Like Ethan said, we are providing an edge-blur postprocessing effect to somewhat help with this. It’s not proper anti-aliasing, but helps to hide jagged edges.

    @Nick:
    1) yes, shadows still cost a lot, primarily because shadow casters need to be rendered. So yeah, the cost of rendering into the shadow map is very similar to forward rendering. The cost of applying the shadow map (rendering the receivers) is much cheaper in deferred rendering though; it happens in screen space just like for non-shadowed lights.

    2) It’s “deferred lighting” aka “light pre-pass”. Usually there’s one color target (world space normals in RGB, specular exponent in A), and depth is just fetched from the native depth buffer. On platforms/GPUs that don’t support reading depth buffer as a texture, depth is contained in another render target. So yeah, the G-buffer is really small, but does not have any fancy data like motion vectors.

    3) It depends. Post-processing based edge blurring is not “real” anti-aliasing (it does not have access to sub-pixel data), i.e. it does not look as good as real anti-aliasing. Cost of native GPU anti-aliasing (multi-sampling) is mostly larger video memory requirements, and then all triangle edges cost more, proportionally to the anti-aliasing level.

  6. Nick

    September 12, 2010 at 9:02 am / 

    Couple of questions:

    1) We are talking about lights without shadows, right? I’m guessing it’s impossible to calculate shadows only from the normals you get from the G-Buffer. So lights with shadows will have more or less the same performance hit as previous unity versions? (not that having that many lights, even without shadows, isn’t amazing)

    2) What does the gbuffer in your deferred rendering implementation contain? I’m assuming normals and depth at the very least (which is why the dof becomes so much cheaper), but how about more exotic buffers such as screen-space 2d motion vectors, which would make motion blur cheaper and also look great?

    3) About the EdgeBlurEffectNormals, am I right to assume that it’s somewhat faster than traditional antialiasing? It won’t be as accurate of course but it should be easier to calculate, right?

  7. Ethan Vosburgh

    September 12, 2010 at 2:07 am / 

    @edvinas – there are image effects that can be used to blur the edges of meshes at certain levels of differentiation in the depth buffer. There is is actually an image effect included in the “Image Effects” standard assets package that does this called “EdgeBlurEffectNormals”.

  8. edvinas

    September 12, 2010 at 12:23 am / 

    Quick question… Will the anti-aliasing work with deferred rendering? Or will there be any other alternative to have the anti-aliasing effect with deferred rendering?
    Because at the moment it looks really lame without the anti-aliasing on Unity 3 beta7, when compared to simple forward lighting and anti-aliasing on…

    Thanks

  9. Dave

    September 11, 2010 at 9:55 pm / 

    What happens if you set the player to deferred rendering and it’s run with a card that doesn’t support it? Does it fall back to forward rendering?

  10. Jozsef Trencsenyi

    September 11, 2010 at 12:14 pm / 

    WHERE IS THE Occlusion Culling video?! :D

  11. Aras Pranckevičius

    September 10, 2010 at 8:40 pm / 

    @Vectrex: dynamic batching transforms small (in vertex count) objects that share all other parameters (material, lighting set etc.) on the CPU, and draws them in one draw call. It has no relation to physics; only for rendering. Unity iPhone 1.7 had this, and with 3.0 it’s coming to all platforms.

    @Rich: yeah, it does have some overhead. Basically, if you only use one or two lights, forward rendering might be faster. Also, deferred requires certain level of hardware support (e.g. Shader Model 3.0), and on lower GPUs it just won’t work.

  12. Michael brockwell

    September 10, 2010 at 7:19 pm / 

    sweet update guys!!

  13. Rich Hudson

    September 10, 2010 at 6:05 pm / 

    My question then is when/why would you ever using forward lighting, since deferred is less CPU/GPU intensive. Or does it have an initially large hit, and is only better after a certain number of lights are added?

  14. Dwair

    September 10, 2010 at 5:17 pm / 

    Now I’m feeling really proud of being a pro user.

    I’ve always tried to limit the number of dynamic lights to a minimum, but I think with this I’ll be able to make some interesting light moods in my games!

    A cool feature indeed!

  15. Vectrex

    September 10, 2010 at 4:01 pm / 

    Hmm I spy ‘dynamic batching’? Instancing? Splitting/merging of sleeping physics objects? Instancing would be a big performance boost in our case (lots of identical moving objects)

  16. Aras Pranckevičius

    September 10, 2010 at 12:10 pm / 

    @Francis: Deferred Lighting will be Pro only.

  17. Francis Humphries

    September 10, 2010 at 11:41 am / 

    Nice, this is exactly what my project needs! Will this be in both indie and pro?
    Also, nice editor- i love that dark theme :). Does thios mean the editor will be customizable (in a visual sense)?
    Otherwise, amazing. Absolutely amazing!

  18. Tom Higgins

    September 9, 2010 at 8:34 pm / 

    @marty: Deferred rendering will not be supported for use in iOS/Android applications as the devices just aren’t robust enough for it.

    @tino: No, you’ll still need to include that at the top of every script to enable it. And our core iOS implementation and support isn’t changing drastically from the current experience and the examples and demos will behave the same. If you have more questions about all this then please redirect those to the forums and leave comments here to be focused on Unity 3.0′s deferred rendering features. Thanks!

  19. tino

    September 9, 2010 at 8:01 pm / 

    Nice.
    i have question regarding Unity iphone, is #pragma strict enabled by default for unity 3 or you have to enable it manually ? Also I haven’t found much information about iphone implementation in unity 3, how will project and example demos behave ?
    thx.

  20. marty

    September 9, 2010 at 7:42 pm / 

    Should those of us authoring for mobile devices and thus using only one light (if that) turn on deferred lighting – or is it no big deal without multiple scene lights?

Comments are closed.