Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 03 July 2013 - 07:47 PM

If I download the FXAA 3.9 shader and integrate it in my pipeline, will it help beyond allowing me to avoid blurring HUD/text elements?

There's a lot of options to the FXAA shader that you can tweak yourself.
Also, if you don't actually integrate it into your pipeline, then it's not actually in your game. It's pretty unkind to your users to say "to make my game look best, go into your nVidia driver panel (sorry ATI/intel users) and enable these hacks".

I have a lot of objects in my scene with long, straight edges -- particularly buildings and chain link fences, but also some vehicles as well -- with which FXAA seems to work particularly poorly. At a distance, these objects create wild, shimmering jaggies that are very distracting. Will downloading the shader actually improve this? Here are a couple examples:

In those example pictures, there's a lot of "information" missing -- e.g. lines that have pixels missing from them, so they've become dashed lines rather than solid lines.
Post-processing AA techniques (like FXAA) will not be able to repair these lines.
MSAA / super-sampling techniques will mitigate this issue, making the threshold for a solid line turning into a dashed line smaller.
Another solution is to fix the data going in to the renderer -- if you've got tiny bits of geometry that are going to end up being thinner than a pixel, they should be replaced with some kind of low-LOD version of themselves.  e.g. if those fences were drawn with as a textured plane with alpha blending, you'd get soft anti-aliased lines by default, even with no anti-aliasing technique used.

Edit: On the other hand, isn't it somewhat expensive the loop through a runtime-determined number of lights inside a fragment shader?

On D3D9-era GPUs, yes, the branch instructions are quite costly. They'll also compile the loop to something like:
for( int i=0; i!=255; ++i ) { if( i >= g_lightCount ) break; ..... }
On more modern cards, branching is less costly. The biggest worry is when nearby pixels take different branches (e.g. one pixel wants to loop through 8 lights, but it's neighbour wants to loop through 32 lights) -- but most of these Forward+-ish techniques mitigate this issue by clustering/tiling pixels together, so that neighbouring pixels are likely to use the same loop counters and data.

#1Hodgman

Posted 03 July 2013 - 07:44 PM


t I have a lot of objects in my scene with long, straight edges -- particularly buildings and chain link fences, but also some vehicles as well -- with which FXAA seems to work particularly poorly. At a distance, these objects create wild, shimmering jaggies that are very distracting. Will downloading the shader actually improve this? Here are a couple examples:
In those example pictures, there's a lot of "information" missing -- e.g. lines that have pixels missing from them, so they've become dashed lines rather than solid lines.

Post-processing AA techniques (like FXAA) will not be able to repair these lines.

MSAA / super-sampling techniques will mitigate this issue, making the threshold for a solid line turning into a dashed line smaller.

Another solution is to fix the data going in to the renderer -- if you've got tiny bits of geometry that are going to end up being thinner than a pixel, they should be replaced with some kind of low-LOD version of themselves.  e.g. if those fences were drawn with as a textured plane with alpha blending, you'd get soft anti-aliased lines by default, even with no anti-aliasing technique used.


Edit: On the other hand, isn't it somewhat expensive the loop through a runtime-determined number of lights inside a fragment shader?
On D3D9-era GPUs, yes, the branch instructions are quite costly. They'll also compile the loop to something like for( int i=0; i!=255; ++i ) { if( i >= g_lightCount ) break; ..... }

On more modern cards, branching is less costly. The biggest worry is when nearby pixels take different branches (e.g. one pixel wants to loop through 8 lights, but it's neighbour wants to loop through 32 lights) -- but most of these Forward+-ish techniques mitigate this issue by clustering/tiling pixels together, so that neighbouring pixels are likely to use the same loop counters and data.


PARTNERS