About Me

Hi. I'm Josh Ols. Lead Graphics Developer for RUST LTD.


View Joshua Ols's profile on LinkedIn

« I'm not dead | Main | Deferred shading (again?) »

Neo Renderer

So I made the big anouncement of going deferred again. The question now is, what implementation should I use to meet the needs of my project? Having mulled over this one for about a week, I have decided that deferred lighting will once again be my solution.



In my prior work, I favored a minimalist g-buffer in order to cut back on storage as much as possible, and make it feasible to add hardware MSAA on SM 4.0 hardware. Now, I am much less concerned with those goals, and would prefer to favor better precision for better visuals and more flexibility.

Buffers [SM 3.0]:

  • G-Buffer

    • 1x fp16

    • [Normals (packed), Specular power, Linear eye depth]

  • Light-Buffer (SM 3.0)

    • 1x fp16

    • [Diffuse lighting (RGB), Specular intensity]

  • Post-Buffer

    • 1x fp16

    • [Lit scene (RGB), 0.0]

At a minimum, I need to be able to accomodate normals, specular power, and depth to get decent Phong lighting. If I went with MRT, I would have had to use a 1-2 channel float buffer for the depth, which would break compatibility with OpenGL. So, I decided it would be better to pack my normals, and shove all the data in an RGBA16F buffer. This arrangement ensures that all the data can easily be accessed for both lighting and post-processing.


Buffers [SM 4.0]:

  • G-Buffer

    • 1x fp10

    • [Normals (packed), Specular power]

  • Light-Buffer (SM 3.0)

    • 2x fp10

    • [Diffuse lighting (RGB)], [Specular lighting (RGB)]

  • Post-Buffer

    • 1x fp10

    • [Lit scene (RGB)]

Here you see a more reduced version of my buffer setup, which takes advantage of SM 4.0 capabilities (depth buffer sampling, fp10 textures). This setup would allow me to justify the cost of storing separate colored diffuse and specular lighting. Granted, I will be forced to be use MRT, since no hardware supports a 6-channel texture format. However, hardware that can support this combination of features makes the overhead a moot point.


Final Thoughts:

If my assumptions are correct, this setup will produce much better visuals while being more efficient than my prior deferred lighting renderer. It will also be a good excuse for me to explore the possibilites of tinkering with the contents of the light buffer(s) for different effects. Though I think I will leave that for another day. ;)

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (4)

A possible modification for SM3.0 path: turns out that on quite a lot of DX9 hardware, you can access actual depth buffer as a texture (INTZ/RAWZ/DF16/DF24 hacks). See here: http://aras-p.info/texts/D3D9GPUHacks.html

The same can be done in OpenGL, by just binding both color and depth buffers as textures.

This way you'd save one channel out of your rendertarget setup, which might or might not be beneficial.
March 14, 2010 | Unregistered CommenterAras Pranckevičius
Have you considered the light-indexed deferred rendering approach? If so, what put you off it?
March 15, 2010 | Unregistered Commenteranon
Actually, I frequent your blog, so I already knew about the D3D hacks. I actually started by reading your normal packing article. Currently, I am trying to avoid using vendor-specific tricks to handle core functionality in my renderer. So I would prefer to use them for non-essential things, to maximize code portability.

Just have to see how things go.

I have used Deferred Lighting before, and have become sufficiently comfortable with it that I think it will meet most of my needs. Plus, I really don't like the implications of Light-Indexed Deferred Lighting. Sure, it allows you to have plenty of lights in view, but it still carries almost all of the limitations of forward rendering.

The shader combinatorial problem will be as bad as single pass lighting, maybe even a little worse. It still has to handle combining the number and types of lights influencing each pixel. It also has to handle shadow and texture projection, which will obviously be limited since it has to be single pass. Finally, adding new light types is more difficult now, since you also have to modify the light data look-up tables as well as all the shading code.

It was these limitations that made me want to go deferred, and get as far away from forward rendering as I could. So that is why I will not be using Light-Indexed Deferred Lighting any time soon.
March 16, 2010 | Unregistered Commentern00body
In need of a business partner for a start up company. DirectX and C# involved.
Give me an email if interested.
April 4, 2010 | Unregistered CommenterCJ

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.