[Scilab-Dev] SEP #16: anti-aliasing

[Sylvestre Ledru]

Pretty cool work!

Yep, I have just a short comment, could you detail a bit more how you
managed to produce these results ? (ie the code and the procedure you
used).

Thx!
Sylvestre

Le mardi 21 avril 2009 à 18:05 +0200, Jean-Baptiste Silvy a écrit :
> I have updated the SEP with some benchmarks.
> 
> All questions and comments are highly welcomed.
> 
> Jean-Baptiste
> 
> Jean-Baptiste Silvy a écrit : 
> > I enclose the current SEP version, for people who don't have a git
> > version on their computers.
> > 
> > Jean-Baptiste
> > 
> > Jean-Baptiste Silvy a écrit : 
> > > Hello,
> > > 
> > > Thanks for your remarks.
> > > 
> > > François Vogel a écrit :
> > >   
> > > > Hi,
> > > > 
> > > > Having AA activation control in Scilab sounds like a very good idea.
> > > > 
> > > > Some comments from my side:
> > > > 
> > > > - I think you should state explicitly that you are talking about
> > > > hardware AA, and you are not implementing oversampling and filtering
> > > > of the figures at the Scilab software level. You are merely using the
> > > > AA feature of the graphics board. Thus AA levels will depend on the
> > > > capability of the graphics board the user has. This may sound obvious
> > > > to you, but stating it clearly will not hurt.
> > > > 
> > > > - You will have to check for graphics board capabilities when setting
> > > > the AA level requested by the user. For instance the hardware
> > > > configuration I'm running right now only has 2x, 4x and 6x but not 8x.
> > > > Warnings should be written in the console when the user requested
> > > > level of AA is not available from the hardware, and proper fallback be
> > > > used.
> > > > 
> > > >     
> > > 
> > > Actually, in the master branch I tested two ways of doing antialiasing,
> > > the first one being multisampling. However, as you noticed, it might not
> > > be available on every hardware configurations or not with all quality
> > > settings. Knowing this, I also tested a fall back mode, by using the
> > > accumulation buffer[1]. This is a slower way, since the scene must be
> > > rendered as many time as the quality setting (so 4x, is almost twice
> > > slower than 2x). However, this will run on all configurations since
> > > accumulation buffers are part of OpenGL 1.0 specifications.
> > > 
> > > Practically, for now in the master branch, I test whether hardware
> > > multisampling can be enable at the requested quality. If not I fall back
> > > to the second technique.
> > > 
> > > I haven't run benchmarks yet to see the difference between the two
> > > approaches in term of speed.
> > > However, on my computers (2 and 3 years old), anti-aliasing can be
> > > activated in standard plots and graphics is still usable even with the
> > > accumulation buffers.
> > > 
> > >   
> > > > - In SEP#16 you say:
> > > > "A property “anti_aliasing” will be added to figure handles. This
> > > > property value can be one of the following: “off”, “2x”, “4x”, “8x”,
> > > > “16x”. If the property is set to “off”, anti-aliasing is disabled.
> > > > Otherwise, the value stands for the anti-aliasing quality.
> > > > An other approach would be to have only two or three possible values,
> > > > more understandable by the user. The value could be chosen between
> > > > “off” or “on” (actually setting quality to “4x”) or between “off”,
> > > > “performance” (quality “4x”) and “quality” (quality “8x”).
> > > > "
> > > > 
> > > > I'm strongly in favor of the first option. If a user has enough
> > > > knowledge in graphics to know what is anti-aliasing (and especially
> > > > FSAA) and to use this feature, then this user must also know how this
> > > > works (oversampling 4x == 4 sub-pixels and so on) and that this
> > > > feature can be adjusted to different levels.
> > > > Naming the AA levels "quality" or performance" or whatever would just
> > > > add to the confusion. Everybody calls this 2x, 4x, 8x etc, why would
> > > > Scilab have its own different names?
> > > > The tradeoff between AA level and graphics performance is real but
> > > > should be reminded in the help page for the new property (help figure?).
> > > > 
> > > >     
> > > 
> > > That's my idea too. In the windows Nvidia control panel, they use the
> > > same terms also.
> > > 
> > > 
> > >   
> > > > - FSAA (multisampling) has no effect on texture aliasing. What about
> > > > providing access to anisotropic filtering at the same time? Textures
> > > > in 3D views would look better (hem... I can't remember: is it possible
> > > > to apply textures on a mesh at all in Scilab? Right now I'm not sure
> > > > anymore)
> > > > 
> > > >     
> > > 
> > > Yes Scilab 5 uses textures., though this is quite hidden. They
> > > successfully replaces triangle cutting when applying color
> > > interpolation. More texture will be used in Scilab when will add a way
> > > to display images.
> > > 
> > > You're right, I did not know but multisampling does not work with
> > > textures. It works well with accumulation buffers though.
> > > In this case, I could enable linear filetring on textures to give some
> > > kind of anti_aliasing also, but the result would be even more smoothed.
> > > However, what your mentioning here is aliasing when texels are smaller
> > > than a pixel wide. In this case, you're right anisotropic filtering is nice.
> > > However, for now I don't think it is really needed in Scilab. When using
> > > color interpolation, user normally use quite "continuous" colormaps (in
> > > the color space), so it's not really a problem if the result is a bit
> > > blurry.
> > > 
> > > However, we should keep that in mind for when we will want to apply
> > > various textures in Scilab such as images.
> > > 
> > > Thanks again for your remarks. It highlights me the need for benchmarks
> > > and screenshots in the SEP for the different options argued above.
> > > 
> > > Jean-Baptiste
> > > 
> > > [1]
> > > http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node63.html
> > > 
> > >   
> > 
>