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

[Jean-Baptiste Silvy]

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