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

[Jean-Baptiste Silvy]

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
>>
>>   
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090421/20de67bc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SEP_16_anti_aliasing.odt
Type: application/vnd.oasis.opendocument.text
Size: 111871 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090421/20de67bc/attachment.odt>