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

[Jean-Baptiste Silvy]

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/20090220/74bf2cc3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SEP_16_anti_aliasing.pdf
Type: application/pdf
Size: 371414 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090220/74bf2cc3/attachment.pdf>