More pages: 1
2
Geometry Buffer Anti-Aliasing
Monday, July 18, 2011 | Permalink
There is a new demo up demonstrating another anti-aliasing technique called GBAA (Geometry Buffer Anti-Aliasing). Like GPAA it uses actual geometry information, but stores it in a fullscreen buffer. This should scale better with dense geometry and additionally allows alpha-tested edges to be anti-aliased.
Tisten
Monday, July 18, 2011
Always nice with demos which works with DX10.0.
Your precompiled executable works just fine but when I compile it myself all egdes get a bright wireframe from the GBAA pass. Might be a gamma error or something, I haven't debugged it.
Humus
Tuesday, July 19, 2011
You have the latest Framework3? Not that I can think of anything in particular that would cause that.
Tisten
Tuesday, July 19, 2011
Ah, I did not see that you had updated it. It really was gamma which caused the problem and getting the new framework solved it.
sqrt[-1]
Thursday, July 21, 2011
Awesome demo again! - This has me wondering if it would be possible to update the way you do the alpha tested edges in a more generic fashion.
eg. similar to what you did with your old demo where you did selective multisampling based on the highlight, if you could detect the distance to where an AA edge should be - perhaps process the "specular mask" in a similar way?
I dunno - just rambling.
Mat
Thursday, July 28, 2011
Humus,
in term of performance, wich one does better in a same scene? I guess GBAA would be better because of the single pass geometry but I guess the technique itself can be slower.
btw, keep up the good work man! :P
Humus
Saturday, July 30, 2011
Well, GBAA has a fullscreen resolve pass that GPAA doesn't have. So with a trivial scene GPAA is bound to have better performance. As geometric density increases though GBAA should turn out faster.
Hans
Friday, August 5, 2011
While both of your demos are impressive, you can only smooth rugged edges using any form of post processing. I find "blinking pixels" as more annoying form of aliasing (ie. when you have black fence and bright background, at some distance fence width will be smaller than pixel resulting in quite random black fence pixels being drawn)
In case of alpha-tested textures (or shader discarded pixels in general) you can always revert to alpha-blending (with all its burden) but solving this for sub-pixel triangles would require some custom rasterizer (or geometry shader black magic?). Any thoughts on this subject?
(That alpha blended edge anti-aliasing from voodoo2 would come in handy
)
Humus
Monday, August 22, 2011
Well, shader aliasing is a whole different set of problem. Yes, it is often at least as distracting as edge jaggies. A complete antialiasing solution needs to address both, but unless you are able to encode some additional information in the buffer I think shader aliasing is near impossible to solve as a post-process. I think that's better handled in the affected shader itself. Edge jaggies are possible to deal with in a post-step though, as have been demonstrated here and elsewhere.
As for alpha-test, the long-term solution is to switch to some form of OIT technique and blend properly.
More pages: 1
2
