Problem with antialiased points and lines
Author
I have a simple OpenGL program that renders antialiased points and lines, and have found that it doesn't work correctly on some computers. Specifically, if antialiasing is enabled for both points and lines, the lines will sometimes render incorrectly or not render at all (the points are fine).
I've tried this on a number of different computers, and all the computers on which this behavior occurs have GeForce2's and are running OS X. The computers on which the app works correctly have other types of cards installed (Intel, ATI, GeForce3) and are running OS X, Linux, or Windows.
I know different cards have different characteristics when it comes to antialiasing, but it seems odd that enabling antialiasing would cause lines not to be rendered at all.
Are there any known issues with enabling both point and line antialiasing simultaneously when using a GeForce2? I've been Googling, but haven't come across anything conclusive.
Hello,
I don't know if this can be of any help, but it is important to remember that antialiased lines and points are a form of transparent primitive. This requires blending to be enabled so that the incoming pixel fragment will be combined with the value already in the framebuffer, depending on the alpha value. As with all transparent primitives, antialiased lines and points should not be drawn until all opaque objects have been drawn first. Depth buffer testing should remain enabled, but depth buffer updating should be disabled using glDepthMask(GL_FALSE).
If your not setting the correct blending modes, different drivers will have different default values that may cause the lines not to be rendered at all or in an incorrect manner.
Don't know if this is the cause of your troubles else just ignore me,
Jeroen
I don't know if this can be of any help, but it is important to remember that antialiased lines and points are a form of transparent primitive. This requires blending to be enabled so that the incoming pixel fragment will be combined with the value already in the framebuffer, depending on the alpha value. As with all transparent primitives, antialiased lines and points should not be drawn until all opaque objects have been drawn first. Depth buffer testing should remain enabled, but depth buffer updating should be disabled using glDepthMask(GL_FALSE).
If your not setting the correct blending modes, different drivers will have different default values that may cause the lines not to be rendered at all or in an incorrect manner.
Don't know if this is the cause of your troubles else just ignore me,
Jeroen
Author
Quote:Original post by godmodderThanks for your reply.
Hello,
I don't know if this can be of any help, but it is important to remember that antialiased lines and points are a form of transparent primitive. This requires blending to be enabled so that the incoming pixel fragment will be combined with the value already in the framebuffer, depending on the alpha value. As with all transparent primitives, antialiased lines and points should not be drawn until all opaque objects have been drawn first. Depth buffer testing should remain enabled, but depth buffer updating should be disabled using glDepthMask(GL_FALSE).
If your not setting the correct blending modes, different drivers will have different default values that may cause the lines not to be rendered at all or in an incorrect manner.
Don't know if this is the cause of your troubles else just ignore me,
Jeroen
I'm pretty sure I have everything set up correctly, but maybe I'm doing something stupid. I've narrowed down the problem to the following simple program:
#include "SDL.h"#include "SDL_opengl.h"int main(int argc, char *argv[]){ SDL_Init(SDL_INIT_VIDEO); SDL_SetVideoMode(640, 480, 0, SDL_OPENGL); glMatrixMode(GL_PROJECTION); glOrtho(0., 640., 0., 480., -1., 1.); glPointSize(4.f); glEnable(GL_LINE_SMOOTH); glEnable(GL_POINT_SMOOTH); glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); glEnable(GL_DEPTH_TEST); glDepthMask(GL_FALSE); bool quit = false; while (!quit) { SDL_Event event; while (SDL_PollEvent(&event)) { if (event.type == SDL_QUIT || (event.type == SDL_KEYDOWN && event.key.keysym.sym == SDLK_ESCAPE)) { quit = true; } } glClear(GL_COLOR_BUFFER_BIT); glPushMatrix(); glBegin(GL_LINES); glVertex2f(0.f,0.f); glVertex2f(640.f,480.f); glEnd(); glBegin(GL_POINTS); glVertex2f(200.f,100.f); glEnd(); glPopMatrix(); SDL_GL_SwapBuffers(); } SDL_Quit(); return 0;}The matrix push/pop obviously doesn't do anything functional, but it seems to have an affect on how the bug manifests (with the push/pop the line doesn't render at all, and without the push/pop it's partially rendered).
Maybe I'm making an incorrect assumption about default states, as you suggest.
Can anyone spot anything wrong with my example program? Am I missing something obvious?
Hi,
I pasted the code into my own engine and it worked perfectly. Maybe it has something to do with your projection perhaps and the fact you're only passing glVertex2f() instead of glVertex3f()? For instance, why are you setting you're nearplane to -1.0f? Apart from that, I couldn't find anything strange at all.
Jeroen
I pasted the code into my own engine and it worked perfectly. Maybe it has something to do with your projection perhaps and the fact you're only passing glVertex2f() instead of glVertex3f()? For instance, why are you setting you're nearplane to -1.0f? Apart from that, I couldn't find anything strange at all.
Jeroen
Author
Quote:Original post by godmodderThanks for trying it out. The near and far plane distances are arbitrary, more or less, but I believe they mimic the behavior of gluOrtho2D (which simply calls glOrtho() with near and far values of -1 and 1, respectively).
I pasted the code into my own engine and it worked perfectly. Maybe it has something to do with your projection perhaps and the fact you're only passing glVertex2f() instead of glVertex3f()? For instance, why are you setting you're nearplane to -1.0f? Apart from that, I couldn't find anything strange at all.
As for glVertex2f(), I think it's functionally equivalent to calling glVertex3f() with a z value of 0. I did try using glVertex3f(), along with some different near and far values, but didn't notice any change.
If I could trouble you with one more question, what graphics card were you using when you ran the example?
Quote:
As for glVertex2f(), I think it's functionally equivalent to calling glVertex3f() with a z value of 0.
I just double-checked the OGL spec - you're right.
Hello,
I tried your code on a Geforce 7800GS AGP8x. Do you get your problem only on Geforce 2's? That's really strange. Have you installed the latest drivers for those cards too? Maybe it's just a bug in the OS X drivers after all, because the code is supposed to work flawlessly.
Jeroen
I tried your code on a Geforce 7800GS AGP8x. Do you get your problem only on Geforce 2's? That's really strange. Have you installed the latest drivers for those cards too? Maybe it's just a bug in the OS X drivers after all, because the code is supposed to work flawlessly.
Jeroen
Author
Quote:Original post by godmodderYeah, the bug only occurs on GeForce 2's. I'm not sure if it's specific to OS X or not because I don't have a Linux or Windows machine that has a GeForce 2 installed.
I tried your code on a Geforce 7800GS AGP8x. Do you get your problem only on Geforce 2's? That's really strange. Have you installed the latest drivers for those cards too? Maybe it's just a bug in the OS X drivers after all, because the code is supposed to work flawlessly.
As for drivers, I think Software Update takes care of that automatically, but I could be wrong. I Googled for nVidia OS X driver updates, but didn't find anything that looked relevant. All the computers in question are running 10.4.9, and I'm almost certain the GeForce 2 cards came with them, so I'd be surprised if the drivers weren't up to date.
But perhaps, as you say, there's a bug in the OS X drivers that's never been addressed.
Thanks for the help so far - any other tips or suggestions are welcome.
Hi jyk, what if you just AA the points or the lines one at a time does this work then? If so, than what apple computers is this running on? PPC or Intel? Cocoa/Carbon?
Edit Oops I just seen you are using SDL thats Cocoa, IIRC this was stated before
With regards to FSAA not working, try adding NSOpenGLPFASampleAlpha followed by 1 in that that list. (in case it's confused about what kind of anti-aliasing to use when not specified on the Intel Macs.
Edit Oops I just seen you are using SDL thats Cocoa, IIRC this was stated before
With regards to FSAA not working, try adding NSOpenGLPFASampleAlpha followed by 1 in that that list. (in case it's confused about what kind of anti-aliasing to use when not specified on the Intel Macs.
Author
Quote:Original post by MARS_999All the computers are PPC.
Hi jyk, what if you just AA the points or the lines one at a time does this work then? If so, than what apple computers is this running on? PPC or Intel? Cocoa/Carbon?
If only point or line antialiasing is enabled, then both primitives are rendered correctly; the bug only manifests when antialiasing is enabled for both primitive types at the same time.
There are other strange things as well. If the point is rendered before the line, rather than after, both the point and line are rendered. Also, commenting out the calls to glPushMatrix() and glPopMatrix() causes the line to render correctly, which is very odd given that the matrix push/pop should have no effect in this particular case.
Very peculiar :-|
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement