<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I enclose the current SEP version, for people who don't have a git
version on their computers.<br>
<br>
Jean-Baptiste<br>
<br>
Jean-Baptiste Silvy a écrit :
<blockquote cite="mid:499EC731.2050902@scilab.org" type="cite">
<pre wrap="">Hello,
Thanks for your remarks.
François Vogel a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">- 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?).
</pre>
</blockquote>
<pre wrap=""><!---->
That's my idea too. In the windows Nvidia control panel, they use the
same terms also.
</pre>
<blockquote type="cite">
<pre wrap="">- 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)
</pre>
</blockquote>
<pre wrap=""><!---->
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]
<a class="moz-txt-link-freetext" href="http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node63.html">http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node63.html</a>
</pre>
</blockquote>
<br>
</body>
</html>