On Monday 07 March 2005 18:23, Martijn Sipkema wrote: > On Mon, 2005-03-07 at 00:45 -0500, Daniel Phillips wrote: > > That is a pretty good illustration of algorithms based on blending > > into a partially constructed image don't work very well. None of > > the three algorithms I described do this. > > For 2d antialiasing you can use front-to-back drawing using smooth > polygons, i.e. alpha values that represent coverage, and use > GL_SRC_ALPHA_SATURATE/GL_ONE for the src/dst blending functions.
But that is not FSAA, which is the current topic. FSAA has to be independent of rendering order. > > > The simple 2x2 supersampling approach does not have this problem, > > > but how does this work for multisampling? > > > > The color value for each subsample is stored separately and only > > mixed with other subsamples in final scanout. > > Multisampling is the standard OpenGL way---apart from using a > multipass algorithm using the accumulation buffer---of handling > antialiasing for the general 3d case. Multisampling is an extension, not a standard feature of OpenGL. Multisampling is a lot more complicated to implement than supersampling, particularly if it is to follow the letter of the specification: http://oss.sgi.com/projects/ogl-sample/registry/ARB/multisample.txt This is simply out of reach for an initial design. One of the nice things about FSAA is that a 3D card can implement it entirely transparently to the graphics API. It does not have to be exposed via OpenGL in order to be useful. That was the way it worked through a number of card generations, since only supersampling was available for the same reasons that only supersampling is practical for us: limited number of gates. In fact, some of the current cards do not implement multisampling strictly as specified in the link above - they do not compute coverage values, but instead provide several full framebuffers for the subsamples. As I read the specification above, these cards do not implement ARB_multisample as defined, yet that does not seem to worry anyone. My guess is: current OpenGL implementations will honor MULTISAMPLE_ARB by enabling FSAA, and try to honor SAMPLE_BUFFERS_ARB by selecting a FSAA setting that seems to match, and otherwise, will do things their own way. Please correct me if I've misinterpreted this, otherwise I think that is the way we should do things. > > > The reason I'm asking is that I'm wondering whether we can't > > > cheat, and do something that gives somewhat better results than > > > 2x2 antialiasing. > > > > If you find a way, be sure to shout! > > For 2d drawing the OpenGL smooth polygons will give much better > results. I meant, a way to implement FSAA. By the way, it is a practical certainty that we will not be able to implement GL_SMOOTH or GL_LINE_SMOOTH in hardware in the initial design. These will have to be implemented using alpha polygons, just like any other early generation 3D card. > 2x2 may be quite acceptable for realtime 3d graphics, but not good > enough for (high quality) 2d drawing, e.g. vector graphics for SVG > rendering. Very high quality results are possible for 2D vector graphics using RGBA textured or Gouraud shaded polygons, and this can be transparent to the 2D graphics program. FSAA provides an important capability that is well within our reach to implement and can't be emulated in any practical way. It is not meant for drawing a 2D desktop. In this, we are no different from any other 3D card. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
