   Deferred lighting and AA, once again
  I am looking for some advice on how to progress with deferred lighting and especially on how to deal with antialiasing. I know this has been discussed in length on the forums here but I was wondering if someone could put me at ease. I am working on a graphics engine for a large procedural environment where you can zoom right down to the surface of a planet, walk around but then also get into a spaceship and fly into space. The engine supports characters including the interior of spaceships and buildings. Here are a few screenshots to give you an idea of the environment. Recently I have been improving the rendering pipeline, added HDR, Bloom and SSAO. SSAO forced me to start rendering into FBOs, because I cannot get the depth out of the z-buffer. In order to avoid z-fighting with those large distances I have to render the scene using three different frustums for near, medium and far distances. So, I basically have to use an FBO and store the depth in one of the channels. After that I started to move the lighting into screen space as well and I have to say that I was stunned by the effects that could be achieved. I especially like trying to land a shuttle on the dark side of the planet with two headlights illuminating the ground, or approaching a lit up landing strip. Not to mention what you can do inside a spaceship. Long story short, I am hooked to deferred lighting and I will probably not look back. Having said that, I am really unhappy with the lack of hardware antialiasing. So, here are three shots; the one on the left is with hardware AA, the one in the middle come straight from the FBO and the one on the right is your classic edge detection AA. Clearly, the one on the left is the best, and the one on the far right doesn’t produce great results, is expensive and tends to blur things that are not supposed to be antialiased. So, my question is twofold. Does anyone know of upcoming hardware support for proper antialiasing of FBOs. I know there is MSAA, but I haven’t tried it yet. I heard that it takes quite a performance hit and it will AA all of the other attachments as well. Plus, it is apparently not as good. I would be much happier if I knew that there is hardware support for deferred lighting-AA in the pipeline; is it? I can wait a bit.Other than that I am actually thinking of rendering the scene twice. Once the albedo by itself into the back buffer, making use of hardware AA. Then again into MRTs to produce the additional info, i.e. depth, normals, etc… Has anyone actually tried that? I know this may require an extra set of shaders, but then maybe not. As far as I know, gl_FragData[0] ends up in the hardware buffer anyways, if you are running the shader without an FBO. There will be some overhead though to compute the stuff that would normally end up in the other targets. Long story short, I am weighing the benefits of both and as far as I am concerned deferred lighting wins out. But I hate the lack of proper AA. If it comes around in the next generation hardware, then I can wait. I am just curious if ATI and NVIDIA feel that this would be an important feature…. Does anyone have dips on this info?[Edited by - jochenstier on May 7, 2009 12:23:18 AM]
  Have you checked out Wolfgang Engel's idea for a Light pre-pass renderer? (That google search should turn up his blog, and several topics here on GameDev)If I remember correctly, it works well with MSAA.   ;  I just had a look at that link and I think that I get the idea! You still have to render the geometry twice, but nevertheless its an ingenious idea. If I understand right then you only render the normals and depth into one FBO first; i.e. everything you need to accumulate the light sources and do SSAO. After that is done, you use that buffer as a lookup texture(s) in your final rendering pass. I am going to have to think about that a bit more but it all makes sense of first glance. Thx for the link…[Edited by - jochenstier on May 6, 2009 11:11:50 PM];  Or you can always do supersampling (if you don't care about speed of course - otherwise it's a bad idea).   ;  Isn't supersampling where you render the scene into a larger buffer and then downsample? I guess this would be easy enough to try. I could just shrink a screenshot using photoshop. I am curious if this approach would produce better results than the edge-detection-blurring used in the far right image above. I am also worried about the extra memory and bandwidth required to fill the 3 MRTs and then downsample. Has anyone ever tried  prefiltered lines? That looks also promising to me, although I still have to take a closer look. This approach still requires a second geometry pass, but it should be much faster since you only need to rasterize the edges. ;  DX10-level hardware (Nvidia 8000-series and up, ATI 2000-series and up) can do MSAA just fine with multiple render targets.  DX10 also has the ability to read back individual subsamples from MSAA render targets, so that gives you enough to do "proper" MSAA with deferred rendering.  This demo by Humus does that with a few clever optimizations to speed things up.  You should also check out by the section in ShaderX7 about MSAA + Deferred Rendering with DX10.Oh and supersampling will definitely give you better results than edge-blurring...in fact it something like 4x super-sampling will produce better results than 4x MSAA because it will also reduce shader aliasing and texture aliasing.  The problem of course is that it's enormously expensive to double or quadruple your G-Buffer resolution.   ;  Ok, I will take a serious look at MSAA and run some test. Do you know off any examples in OpenGL off the top of your head? I am assuming if DX10 has the ability to read back individual subsamples from MSAA render targets, then so does OpenGL.   ;  have u looked at EXT_framebuffer_multisample (I havent for a couple of years) but I have used it to allow a AA FBO on my at the time geforceFX (so its well supported)   ;Quote:Original post by jochenstierOk, I will take a serious look at MSAA and run some test. Do you know off any examples in OpenGL off the top of your head? I am assuming if DX10 has the ability to read back individual subsamples from MSAA render targets, then so does OpenGL.Sorry, I don't know of anything in OpenGL.  I know Nvidia exposed a lot of stuff via extensions, but I'm not sure if ATI ever did (or if this was part of what was added for OpenGL 3.0).   ;  Yes, on Nvidia with OpenGL you can do MSAA for deferred ligtiing similary as with DX10. It is done with NV_explicit_multisample extension which allows individual subsamples from multisampled renderbuffers.ATI OpenGL driver currently doesn't expose such or similar extension.   