From: "Daniel Phillips" <[EMAIL PROTECTED]> Sent: Tuesday, March 08, 2005 03:23 > 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.
That's right. I thought the topic was antialiasing and wanted to note that for 2d drawing, FSAA is not as suitable as smooth lines/polygons. > > > > 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. No, it is a standard, though optional, feature of OpenGL since 1.3 IIRC. > 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. I'm not sure what the exact difference between supersampling and multisampling is, but OpenGL multisampling does store the samples is a special multisampling buffer---if it were to only store coverage values it would lose the information needed to do full-scene antialiasing. I may be wrong, but I think it is possible to implement OpenGL multisampling using supersampling... > 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. That's too bad, since these are nice features. But I kno next to nothing about hardware and how hard it would be to implement. Antialiased lines certainly are not that complicated though. > > 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. I don't think it is that easy to achieve and that the quality will be as good as hardware implemented Gupta-Sproull line-drawing, nor as fast. > 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. You could implement it in software by rendering to a larger buffer and downsampling, right? There is quite some hardware around that doesn't support FSAA (and may even support smooth lines). --ms _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
