See what's going on with flipcode!




 


Submitted by , posted on 24 November 2004



Image Description, by


This is a series of screenshots of the Deferred Shading Renderer I'm working on. For each row:
  • Two renderings from two close points of view, with a different depth-of-field.
  • A four spots rendering with shadows. A parallax mapping wall. A face with ambient occlusion rendering.
  • An indoor scene rendering, the whole scene has an ambient occlusion map. And another multi-lights scene with soft shadows rendering.
  • About the renderer:
  • Actually Shader Model 3.0 compliant only, there's not much work to do to make it work on the ATI Chips. :)
  • Four Rendering Targets are used, each one has a depth of 32 bits:
  • Albedo, it stores the computed albedo using the graphical object's shader.
  • Z, it stores the 32bits depth of the pixel, that's a shame we can't use the Z-Buffer for that.well.
  • Normal, it stores the X and Y components of the pixel's normal, the Z is computed on the fly.
  • Material settings, actually 8bits components for Specular Intensity, Specular Power, Ambient Occlusion Factor and last one is free.
  • Some random features: Gamma correction, optimized light rendering using projected bounding volumes, HDR (still in progress), Soft or hard shadow mapping on Point/Spot light (direct, being in progress, damn PSM.), NormalMap/Parallax mapping, Ambient Occlusion Mapping, Standard Lambert Lighting (I'll write a new set of custom lights more suitable and faster later), Depth of Field, Projected Textures.

  • About the deferred shading:

    Many people think what is good about Deferred Shading are the early pixel culling and doing the lighting in screen space. Of course, these are good things compared to the standard way when you have to do a first pass to fill the Z-Buffer, and then ideally just one more pass to light everything.

    My point of view is slightly different, I of course like these benefits, but what I enjoy the most about Deferred Shading is the simplicity it enables in many aspects of the real-time rendering.

    You have three separated stages of rendering: the MRTs creation, the lighting, and the post-process/tone-mapping.

    This is so clear, and so.right (similar to broadcast renderers). You can write complex shaders for the albedo computation, different lighting models, and have fun with post-process. Each stage has its own set of HLSL shaders, and it's highly pluggable/scalable (which is a priority for the technology I'm working on). The whole architecture can be strong and stable.

    Concerning the speed of rendering, it relies on pixel power mainly, and we know this is going to improve a lot. You have some effects like Depth-of-Field almost for free (done during tone mapping). Look at the timings on my log page to get a better idea.

    There's a lot more to talk about the architecture of this technique, and its real benefits, but I don't want to make this description too long! (I know, that's already the case! :) )

    Some links:

    My log page with more screenshots:
    http://www.elixys.com/prog/SM3Renderer.html

    Description of the whole development environment:
    http://www.elixys.com/elixys/iriontech/apidetails.html



    [prev]
    Image of the Day Gallery
    www.flipcode.com

    [next]


     


    Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
    Please read our Terms, Conditions, and Privacy information.