4 ms·

FXAA is neat, but the idea of using pixel-based edge detection on games is, IMO, a bit silly. Why not use detect edges on the depth buffer? You'll much more e

by daeken 15y ago

FXAA is neat, but the idea of using pixel-based edge detection on games is, IMO, a bit silly. Why not use detect edges on the depth buffer? You'll much more easily see the contrast and you will be far, far less likely to blur your textures. I might have to whip up a quick WebGL demo of this.

hormis 15y ago
FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z. Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. Deferred shading based renderers often duplicate the z-value also into a texture. Deferred rendering can render large number of dynamic, unshadowed lights very efficiently. It can be used as approximate global illumination technique.
- daeken 15y ago
  > FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers. > Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z. If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge. > Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer. > Deferred rendering can render large number of dynamic, unshadowed lights very efficiently. It can be used as approximate global illumination technique. Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer.
  - hormis 15y ago
    > Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers. FXAA is acceptable for the other techniques as well. However, MSAA is, in my opinion, a better technique as it uses supersampling at the edges and is already hardware assisted. FXAA's strength is that it is less expensive than MSAA memory and bandwidth wise. Both are a premium in deferred shading as you are using a 4x RBGA16 texture render target or something close to it :) > If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge. The question is can you get reliable edge detection with less number of texture look-ups on the z-buffer versus the RBG based edge detection? > As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer. Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format. > Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb147221%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb14... > All render target surfaces used together must have the same bit depth but can be of different formats, unless the D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS cap is set. As you can see, the bit depth restriction means that you would end up with 2x bandwidth usage with the z based edge detector, especially on the older hardware where you do not have the bandwidth to spare. It would be a different case if you can sample the hardware z-buffer.
    - maximilianburke 15y ago
      > Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format. This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target. See "Reading the Depth-Stencil Buffer as a Texture" on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205074(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb20...
- exDM69 15y ago
  >> FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z. Why do you say that FXAA is only relevant to deferred rendering? If you have a deferred rendering setup, you'll have the depth buffer and the normal buffer (a floating point texture with normal vectors) available. These can be used to do edge detection for silhouette edges and non-silhouette sharp edges. I don't know the details of modern anti aliasing techniques, but I'd guess that you can get the best edge detection using a combination of the color, depth and normal buffer. Whether you want to do this for anti aliasing is a different issue, a simple RGB edge detect may yield better results. >> Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. Deferred shading based renderers often duplicate the z-value also into a texture. This doesn't make any sense. The depth buffer may be internally stored in a compressed proprietary format, but it's still available to the programmer as a regular buffer or texture. You have plenty of ways to access the depth buffer for reading. The depth buffer can be rendered into a texture (either as floating point or regular 24 bit integer), which can be read back in a shader. You can do regular lookups where you get back the depth value or a shadow lookup with percentage closer filtering. The depth values can also be read back from the buffers (using glReadPixels in OpenGL) to be analyzed on the CPU (not feasible for anything realtime) or saved to disk or whatever.
- Too 15y ago
  When doing cel-shading you usually render a pass that stores the depth and normal values of each pixel into a texture. Thus you have your own z-buffer and access to the normals. If either the difference of the normal or the z-value is over a certain threshold you add some black color to the pixel to make the edge look thicker.
Geee 15y ago
The algorithm analyses the contrast from the luminance of the pixels and does more than just edge detection. There's more in the paper that I don't understand with a quick look. Screen space edge detection (RGB or Z) + low-pass filtering is not a new idea at all, maybe FXAA is just the first that can make it work well.
- lusr 15y ago
  FXAA smooths out stuff way too much for my liking (look at the character highlights and the detail on the horse): http://www.geforce.com/Active/en_US/shared/images/guides/the-elder-scrolls-v-skyrim-tweak-guide/Skyrim-AA-FXAA-Off-8xAA.png http://www.geforce.com/Active/en_US/shared/images/guides/the... http://www.geforce.com/Active/en_US/shared/images/guides/the-elder-scrolls-v-skyrim-tweak-guide/Skyrim-AA-FXAA-On-AA-Off.png http://www.geforce.com/Active/en_US/shared/images/guides/the... I know very little about this stuff but wouldn't using the depth buffer in addition to the current algorithm make it possible not to smooth over details like this?
forrestthewoods 15y ago
It's extremely fast, looks great, and is very easy to add. If you can produce something better games will immediately use it instead. Good luck.

by daeken 15y ago

hormis 15y ago

FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z. Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. Deferred shading based renderers often duplicate the z-value also into a texture. Deferred rendering can render large number of dynamic, unshadowed lights very efficiently. It can be used as approximate global illumination technique.

daeken 15y ago
> FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers. > Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z. If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge. > Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer. > Deferred rendering can render large number of dynamic, unshadowed lights very efficiently. It can be used as approximate global illumination technique. Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer.
- hormis 15y ago
  > Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers. FXAA is acceptable for the other techniques as well. However, MSAA is, in my opinion, a better technique as it uses supersampling at the edges and is already hardware assisted. FXAA's strength is that it is less expensive than MSAA memory and bandwidth wise. Both are a premium in deferred shading as you are using a 4x RBGA16 texture render target or something close to it :) > If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge. The question is can you get reliable edge detection with less number of texture look-ups on the z-buffer versus the RBG based edge detection? > As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer. Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format. > Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb147221%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb14... > All render target surfaces used together must have the same bit depth but can be of different formats, unless the D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS cap is set. As you can see, the bit depth restriction means that you would end up with 2x bandwidth usage with the z based edge detector, especially on the older hardware where you do not have the bandwidth to spare. It would be a different case if you can sample the hardware z-buffer.
  - maximilianburke 15y ago
    > Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format. This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target. See "Reading the Depth-Stencil Buffer as a Texture" on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205074(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb20...
exDM69 15y ago
>> FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z. Why do you say that FXAA is only relevant to deferred rendering? If you have a deferred rendering setup, you'll have the depth buffer and the normal buffer (a floating point texture with normal vectors) available. These can be used to do edge detection for silhouette edges and non-silhouette sharp edges. I don't know the details of modern anti aliasing techniques, but I'd guess that you can get the best edge detection using a combination of the color, depth and normal buffer. Whether you want to do this for anti aliasing is a different issue, a simple RGB edge detect may yield better results. >> Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. Deferred shading based renderers often duplicate the z-value also into a texture. This doesn't make any sense. The depth buffer may be internally stored in a compressed proprietary format, but it's still available to the programmer as a regular buffer or texture. You have plenty of ways to access the depth buffer for reading. The depth buffer can be rendered into a texture (either as floating point or regular 24 bit integer), which can be read back in a shader. You can do regular lookups where you get back the depth value or a shadow lookup with percentage closer filtering. The depth values can also be read back from the buffers (using glReadPixels in OpenGL) to be analyzed on the CPU (not feasible for anything realtime) or saved to disk or whatever.
Too 15y ago
When doing cel-shading you usually render a pass that stores the depth and normal values of each pixel into a texture. Thus you have your own z-buffer and access to the normals. If either the difference of the normal or the z-value is over a certain threshold you add some black color to the pixel to make the edge look thicker.

Geee 15y ago

The algorithm analyses the contrast from the luminance of the pixels and does more than just edge detection. There's more in the paper that I don't understand with a quick look. Screen space edge detection (RGB or Z) + low-pass filtering is not a new idea at all, maybe FXAA is just the first that can make it work well.

lusr 15y ago
FXAA smooths out stuff way too much for my liking (look at the character highlights and the detail on the horse): http://www.geforce.com/Active/en_US/shared/images/guides/the-elder-scrolls-v-skyrim-tweak-guide/Skyrim-AA-FXAA-Off-8xAA.png http://www.geforce.com/Active/en_US/shared/images/guides/the... http://www.geforce.com/Active/en_US/shared/images/guides/the-elder-scrolls-v-skyrim-tweak-guide/Skyrim-AA-FXAA-On-AA-Off.png http://www.geforce.com/Active/en_US/shared/images/guides/the... I know very little about this stuff but wouldn't using the depth buffer in addition to the current algorithm make it possible not to smooth over details like this?

forrestthewoods 15y ago

It's extremely fast, looks great, and is very easy to add. If you can produce something better games will immediately use it instead. Good luck.