Antialiasing in gl_window class

[adon...@gmail.com]

Dear FLTK team,

There is no way to implement antialiasing functions on polygon-based OpenGL drawings in the FLTK 1.3.X series in order to get better scenes? I have not tried ti use GLUT, I would like just using the gl_window class instead.

[Bill Spitzak]

It should be possible to turn on fsaa (full screen anti-aliasing) which just draws everything using 4x (or more) pixels and then averages them together. This seems to be the solution most people use now. There are also anti-aliased lines that work pretty well. Anti-aliased polygon fills never worked very well as they did not figure out how to remove the seam between two triangles.

On Tue, Jun 1, 2021 at 6:41 PM adon...@gmail.com <adon...@gmail.com> wrote:

Dear FLTK team,

There is no way to implement antialiasing functions on polygon-based OpenGL drawings in the FLTK 1.3.X series in order to get better scenes? I have not tried ti use GLUT, I would like just using the gl_window class instead.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/fe320ffb-f547-4e80-ab3d-d7d2fe18db05n%40googlegroups.com.

[Ian MacArthur]

On 2 Jun 2021, at 02:25, adonis192 wrote:
>
> Dear FLTK team,
>
> There is no way to implement antialiasing functions on polygon-based OpenGL drawings in the FLTK 1.3.X series in order to get better scenes? I have not tried ti use GLUT, I would like just using the gl_window class instead.

This is more a GL question than a fltk one, really, I guess. Once you have your GL context in fltk, say in a Fl_Gl_Window, then what you draw in there is pretty much up to you.

As Bill says, FSAA is probably the way to go; basically create your frame buffer in some MSAA mode and then render your scene pretty much as normal and let the buffer take care of the AA for you...

I’d guess you can probably do that with a texture created in GL_TEXTURE_2D_MULTISAMPLE mode or something, but looking back at my own code, that last time I did this it looks like I just used GL_TEXTURE_2D but then set up the framebuffer with

glRenderbufferStorageMultisampleEXT(GL_RENDERBUFFER, 4, GL_RGBA8, imageWidth, imageHeight);

And that seems to have pretty much worked (the code in question dates back to 2013, I do not recall anything about why I did things the way I did...) and the program runs fine, seems to be smooth and swift, and the image is definitely AA.

That said, to get any more advanced capabilities out of an Fl_Gl_Window you will probably need some sort of GL extension wrangler to support that (I use GLEW) as the host platforms oftentimes do not expose any GL API beyond 1.3 or some such by default (though possibly the later OSX/macOS versions do support GL3 or such without any messing about.)

There’s a few samples in the fltk “examples" folder (that I think Manolo did) that deliberately try to use GL3 API just to see it work (OpenGL3-glut-test.cxx and OpenGL3test.cxx) so you can try building them and see how you get on. On this old Mac they seem to Just Work, and report the GL API level as:
GL_VERSION=4.1 ATI-1.68.25
Shading Language Version=4.10

FWIW, on Win10 with mingw I *always* have to use GLEW to get advanced GL API’s, but I have no clue what the MS VS tools will do.

[Greg Ercolano]

On 6/2/21 1:27 PM, Ian MacArthur wrote:

This is more a GL question than a fltk one, really, I guess. Once you have your GL context in fltk, say in a Fl_Gl_Window, then what you draw in there is pretty much up to you.

As Bill says, FSAA is probably the way to go; basically create your frame buffer in some MSAA mode and then render your scene pretty much as normal and let the buffer take care of the AA for you...

    I've found opengl features in general are very machine specific.

    For instance my linux machine's OpenGL can't seem to do AA at all, even for
    simple line drawing. But on the mac it's much better.

    For instance to get the cube example to render wire frames with antialiasing,
    I added these to the cube_box::draw() !valid() section:

    glEnable(GL_BLEND);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
    glEnable(GL_LINE_SMOOTH);
    glHint(GL_LINE_SMOOTH_HINT, GL_NICEST);

    ..here's the before and after:

    Despite I couldn't grab the cube at the same position + size between runs,
    you can see the jaggies clearly in the left image, and less so in the right.

    Here's a blowup of the above two images at 3x scale (using no interpolation) to see the details:

 

I wasn't able to get the flat polygon rendering to work, probably because of the reasons Bill mentioned,
and I wasn't sure how to enable full screen anti-aliasing; that seems to be a feature of the window,
and I'm not sure how to control that. I'm also not familiar with the "new" opengl stuff yet.

[Ian MacArthur]

On Thursday, 3 June 2021 at 04:49:34 UTC+1 erco wrote:

    I've found opengl features in general are very machine specific.

    For instance my linux machine's OpenGL can't seem to do AA at all, even for
    simple line drawing. But on the mac it's much better.

FWIW, it seems to me that on  my Ubuntu laptop the GL behaviour is different whether I access it "directly" or via GLEW, with the GLEW version being "better". That *might* also be a factor for your test?

<random_tangent>

As an aside, I find GLEW a bit odd, in that it is distributed as a library, but in fact if you look at the source it is basically just one header file and one source file... so you can just include the header file (in place of the usual GL header) and link the source file into your code and it Just Works. (I often do it this way on Windows, since the stock mingw lib that the GLEW configure script builds doesn't static link properly, a fact they seem to know but not be bothered by... I have also done it this way on Linux, on occasion, simply because it was in my Makefile like that...)

-- 

Ian