From: Rob H. <ri...@as...> - 2001-06-11 12:26:58
|
Hi, For a while I've been having problems with software rendering of triangle strips arranged into rings. The problem is that if the grid is too fine, or the object too distant, or the window too small then parts or all of the strip are invisible. It appears as either a hole in an object where the grid is finest, or as a speckled pattern. Background objects can be seen through the gaps. It seems to depend on the size of the triangles in relation to the pixel size - changing the window size will change the effect even if no changes are made to the object definition. The problem only occurs with software rendering, in 16 or 32 bit colour depth, eg with the make linux target. Using the Glide driver on a Voodoo3 card (make linux-glide) I get the problem in windowed mode, but it goes away in fullscreen mode with no modification to the code. I have tried enabling and disabling depth testing, back face culling, double buffering and dithering and none of these make any difference. A program that produces the problem is attached below. It should produce a white circle with a small hole in the middle. With software rendering a ring of black speckles also appears around the central hole. The size of the ring depends on the window resolution. There may be some crucial setting I've missed or maybe this could be a software rendering bug? Any suggestions would be welcome. I am working in C++ with Redhat Linux 6.2, egcs 1.1.2, Mesa 3.4.2 and XFree86 3.3.6. The machine is a typical Intel PC configuration with a Voodoo3 3000 graphics card. Thanks, Rob Hynes -- Robert I. Hynes Dept. of Physics and Astronomy University of Southampton Hampshire SO17 1BJ, UK E-Mail: ri...@as... Tel: (44) 2380 592112 Fax: (44) 2380 593910 #include <cmath> #include <GL/glut.h> void draw(void) { glClear(GL_COLOR_BUFFER_BIT); glLoadIdentity(); glOrtho(-10.0f, 10.0f, -10.0f, 10.0f, -10.0f, 10.0f); for (int j=0; j < 900 ; j++) { float r1 = (j+101) * 0.01f; float r2 = (j+100) * 0.01f; glBegin(GL_TRIANGLE_STRIP); glColor3f(1.0f, 1.0f, 1.0f); for (int i=0; i <= 1000 ; i++) { float theta = 0.001f * i *3.1415926f * 2.0f; glVertex3f(r1 * sin(theta), r1 * cos(theta), 0); glVertex3f(r2 * sin(theta), r2 * cos(theta), 0); } glEnd(); } } void key(unsigned char k, int x, int y) { if (k == 27) exit(0); } int main(int argc, char** argv) { glutInit(&argc, argv); glutInitDisplayMode(GLUT_RGB); glutInitWindowSize(200, 200); glutCreateWindow("Mesa3d Test"); glClearColor(0.0,0.0,0.0,0.0); glEnable(GL_DITHER); glutDisplayFunc(draw); glutKeyboardFunc(key); glutMainLoop(); return 0; } |
From: Mike G. <mwg...@ze...> - 2001-06-11 19:07:08
|
Rob Hynes wrote: > > Hi, > > For a while I've been having problems with software rendering of triangle > strips arranged into rings. The problem is that if the grid is too fine, > or the object too distant, or the window too small then parts or all of > the strip are invisible. It appears as either a hole in an object where > the grid is finest, or as a speckled pattern. Background objects can be > seen through the gaps. It seems to depend on the size of the triangles in > relation to the pixel size - changing the window size will change the > effect even if no changes are made to the object definition. The problem > only occurs with software rendering, in 16 or 32 bit colour depth, eg with > the make linux target. Using the Glide driver on a Voodoo3 card (make > linux-glide) I get the problem in windowed mode, but it goes away in > fullscreen mode with no modification to the code. I have tried enabling > and disabling depth testing, back face culling, double buffering and > dithering and none of these make any difference. A program that produces > the problem is attached below. It should produce a white circle with a > small hole in the middle. With software rendering a ring of black > speckles also appears around the central hole. The size of the ring > depends on the window resolution. There may be some crucial setting I've > missed or maybe this could be a software rendering bug? Any suggestions > would be welcome. > > I am working in C++ with Redhat Linux 6.2, egcs 1.1.2, Mesa 3.4.2 and > XFree86 3.3.6. The machine is a typical Intel PC configuration with a > Voodoo3 3000 graphics card. > > Thanks, > Rob Hynes > > -- > Robert I. Hynes > Dept. of Physics and Astronomy > University of Southampton > Hampshire SO17 1BJ, UK > E-Mail: ri...@as... > Tel: (44) 2380 592112 > Fax: (44) 2380 593910 > > #include <cmath> > > #include <GL/glut.h> > > void draw(void) > { > glClear(GL_COLOR_BUFFER_BIT); > glLoadIdentity(); > glOrtho(-10.0f, 10.0f, -10.0f, 10.0f, -10.0f, 10.0f); > > for (int j=0; j < 900 ; j++) { > float r1 = (j+101) * 0.01f; > float r2 = (j+100) * 0.01f; > > glBegin(GL_TRIANGLE_STRIP); > glColor3f(1.0f, 1.0f, 1.0f); > > for (int i=0; i <= 1000 ; i++) { > float theta = 0.001f * i *3.1415926f * 2.0f; > > glVertex3f(r1 * sin(theta), r1 * cos(theta), 0); > glVertex3f(r2 * sin(theta), r2 * cos(theta), 0); > } > > glEnd(); > } > } > > void key(unsigned char k, int x, int y) { if (k == 27) exit(0); } > > int main(int argc, char** argv) > { > glutInit(&argc, argv); > glutInitDisplayMode(GLUT_RGB); > glutInitWindowSize(200, 200); > glutCreateWindow("Mesa3d Test"); > > glClearColor(0.0,0.0,0.0,0.0); > > glEnable(GL_DITHER); > > glutDisplayFunc(draw); > glutKeyboardFunc(key); > > glutMainLoop(); > > return 0; > } > > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > http://lists.sourceforge.net/lists/listinfo/mesa3d-users -- Rob-- It may not be the same, but I had similar problems with primitives drawn near a earth sphere. Turning off depth testing didn't change the display, but the problem completely went away when I rebuilt MESA with DEFAULT_SOFTWARE_DEPTH_BITS 31 instead of 16. Edit "config.h" to change the setting. -- BOEING - PHANTOM WORKS <> Michael W. Gilbertson Systems Analysis <> mailto:mic...@bo... Seal Beach, Calif. |
From: Mike G. <mwg...@ze...> - 2001-06-11 19:59:46
|
Mike Gilbertson wrote: > > Rob Hynes wrote: > > > > Hi, > > > > For a while I've been having problems with software rendering of triangle > > strips arranged into rings. The problem is that if the grid is too fine, > > or the object too distant, or the window too small then parts or all of > > the strip are invisible. It appears as either a hole in an object where > > the grid is finest, or as a speckled pattern. Background objects can be > > seen through the gaps. It seems to depend on the size of the triangles in > > relation to the pixel size - changing the window size will change the > > effect even if no changes are made to the object definition. The problem > > only occurs with software rendering, in 16 or 32 bit colour depth, eg with > > the make linux target. Using the Glide driver on a Voodoo3 card (make > > linux-glide) I get the problem in windowed mode, but it goes away in > > fullscreen mode with no modification to the code. I have tried enabling > > and disabling depth testing, back face culling, double buffering and > > dithering and none of these make any difference. A program that produces > > the problem is attached below. It should produce a white circle with a > > small hole in the middle. With software rendering a ring of black > > speckles also appears around the central hole. The size of the ring > > depends on the window resolution. There may be some crucial setting I've > > missed or maybe this could be a software rendering bug? Any suggestions > > would be welcome. > > > > I am working in C++ with Redhat Linux 6.2, egcs 1.1.2, Mesa 3.4.2 and > > XFree86 3.3.6. The machine is a typical Intel PC configuration with a > > Voodoo3 3000 graphics card. > > > > Thanks, > > Rob Hynes > > > > -- > > Robert I. Hynes > > Dept. of Physics and Astronomy > > University of Southampton > > Hampshire SO17 1BJ, UK > > E-Mail: ri...@as... > > Tel: (44) 2380 592112 > > Fax: (44) 2380 593910 > > > > #include <cmath> > > > > #include <GL/glut.h> > > > > void draw(void) > > { > > glClear(GL_COLOR_BUFFER_BIT); > > glLoadIdentity(); > > glOrtho(-10.0f, 10.0f, -10.0f, 10.0f, -10.0f, 10.0f); > > > > for (int j=0; j < 900 ; j++) { > > float r1 = (j+101) * 0.01f; > > float r2 = (j+100) * 0.01f; > > > > glBegin(GL_TRIANGLE_STRIP); > > glColor3f(1.0f, 1.0f, 1.0f); > > > > for (int i=0; i <= 1000 ; i++) { > > float theta = 0.001f * i *3.1415926f * 2.0f; > > > > glVertex3f(r1 * sin(theta), r1 * cos(theta), 0); > > glVertex3f(r2 * sin(theta), r2 * cos(theta), 0); > > } > > > > glEnd(); > > } > > } > > > > void key(unsigned char k, int x, int y) { if (k == 27) exit(0); } > > > > int main(int argc, char** argv) > > { > > glutInit(&argc, argv); > > glutInitDisplayMode(GLUT_RGB); > > glutInitWindowSize(200, 200); > > glutCreateWindow("Mesa3d Test"); > > > > glClearColor(0.0,0.0,0.0,0.0); > > > > glEnable(GL_DITHER); > > > > glutDisplayFunc(draw); > > glutKeyboardFunc(key); > > > > glutMainLoop(); > > > > return 0; > > } > > > > _______________________________________________ > > Mesa3d-users mailing list > > Mes...@li... > > http://lists.sourceforge.net/lists/listinfo/mesa3d-users > > -- > > Rob-- > > It may not be the same, but I had similar problems with primitives drawn > near a earth sphere. Turning off depth testing didn't change the > display, but the problem completely went away when I rebuilt MESA with > DEFAULT_SOFTWARE_DEPTH_BITS 31 instead of 16. > > Edit "config.h" to change the setting. > > > -- > BOEING - PHANTOM WORKS <> Michael W. Gilbertson > Systems Analysis <> mailto:mic...@bo... > Seal Beach, Calif. > Rob-- Never mind. I just tried your test program on my machine and got the same result as you. It is not properly accumulating polygons that are less than a pixel in size. -- BOEING - PHANTOM WORKS <> Michael W. Gilbertson Systems Analysis <> mailto:mic...@bo... Seal Beach, Calif. |
From: Brian P. <br...@va...> - 2001-06-11 22:04:34
|
Rob Hynes wrote: > > Hi, > > For a while I've been having problems with software rendering of triangle > strips arranged into rings. The problem is that if the grid is too fine, > or the object too distant, or the window too small then parts or all of > the strip are invisible. It appears as either a hole in an object where > the grid is finest, or as a speckled pattern. Background objects can be > seen through the gaps. It seems to depend on the size of the triangles in > relation to the pixel size - changing the window size will change the > effect even if no changes are made to the object definition. The problem > only occurs with software rendering, in 16 or 32 bit colour depth, eg with > the make linux target. Using the Glide driver on a Voodoo3 card (make > linux-glide) I get the problem in windowed mode, but it goes away in > fullscreen mode with no modification to the code. I have tried enabling > and disabling depth testing, back face culling, double buffering and > dithering and none of these make any difference. A program that produces > the problem is attached below. It should produce a white circle with a > small hole in the middle. With software rendering a ring of black > speckles also appears around the central hole. The size of the ring > depends on the window resolution. There may be some crucial setting I've > missed or maybe this could be a software rendering bug? Any suggestions > would be welcome. Rendering very tiny triangles is actually a tricky problem because of accuracy problems in the arithmetic. Other people have had problems with this in the past. Usually, tweaking the code in s_tritemp.h which computes the triangle area and thresholds it has minimized the problem, if not eliminated it. I've been tinkering with your test program and Mesa's triangle rasterizer for a couple hours now. It looks like the only solution will involve snapping the triangle x/y vertices to some integral subpixel position and adjusting the threshold for processing tiny triangles. I've tried to avoid doing this in the past because of the performance hit. However, I think it can be done without too much of a penalty. When I've got something for you to test I'll let you know. -Brian |
From: Rob H. <ri...@as...> - 2001-06-12 09:14:14
|
Hi Brian and others, Thanks for your thoughts on this. As you suggested, changing the area threshold in tritemp.h does reduce the problem in my original code as well as the test case, although it doesn't completely go away. If you can find a more general and/or robust solution that would be great! I'm inclined to agree with Adam that speed shouldn't be compromised for a problem that affects few people, so if the performance hit is significant maybe the fix could only be used if enabled in software or via an environment variable? Thanks, Rob On Mon, 11 Jun 2001, Brian Paul wrote: > Rob Hynes wrote: > > > > Hi, > > > > For a while I've been having problems with software rendering of triangle > > strips arranged into rings. The problem is that if the grid is too fine, > > or the object too distant, or the window too small then parts or all of > > the strip are invisible. It appears as either a hole in an object where > > the grid is finest, or as a speckled pattern. Background objects can be > > seen through the gaps. It seems to depend on the size of the triangles in > > relation to the pixel size - changing the window size will change the > > effect even if no changes are made to the object definition. The problem > > only occurs with software rendering, in 16 or 32 bit colour depth, eg with > > the make linux target. Using the Glide driver on a Voodoo3 card (make > > linux-glide) I get the problem in windowed mode, but it goes away in > > fullscreen mode with no modification to the code. I have tried enabling > > and disabling depth testing, back face culling, double buffering and > > dithering and none of these make any difference. A program that produces > > the problem is attached below. It should produce a white circle with a > > small hole in the middle. With software rendering a ring of black > > speckles also appears around the central hole. The size of the ring > > depends on the window resolution. There may be some crucial setting I've > > missed or maybe this could be a software rendering bug? Any suggestions > > would be welcome. > > Rendering very tiny triangles is actually a tricky problem because of > accuracy problems in the arithmetic. Other people have had problems > with this in the past. Usually, tweaking the code in s_tritemp.h which > computes the triangle area and thresholds it has minimized the problem, > if not eliminated it. > > I've been tinkering with your test program and Mesa's triangle rasterizer > for a couple hours now. It looks like the only solution will involve > snapping the triangle x/y vertices to some integral subpixel position > and adjusting the threshold for processing tiny triangles. > > I've tried to avoid doing this in the past because of the performance hit. > However, I think it can be done without too much of a penalty. When I've > got something for you to test I'll let you know. > > -Brian |
From: Brian P. <br...@va...> - 2001-06-12 14:28:08
|
Rob Hynes wrote: > > Hi Brian and others, > > Thanks for your thoughts on this. As you suggested, changing the area > threshold in tritemp.h does reduce the problem in my original code as well > as the test case, although it doesn't completely go away. If you can find > a more general and/or robust solution that would be great! I'm inclined > to agree with Adam that speed shouldn't be compromised for a problem that > affects few people, so if the performance hit is significant maybe the fix > could only be used if enabled in software or via an environment variable? I've just checked in my changes to src/swrast/s_tritemp.h in CVS. It now snaps triangle vertices to 1/16 subpixel positions and I removed the tiny triangle threshold code. I don't think there is any significant performance penalty. I just had to rearrange a few things in the code. I modified your test program to draw tiny triangles at various orientations in an infinite loop and let it run overnight. It was still running this morning after drawing over 8 billion triangles. No FP exceptions and the rendering looked correct. Hopefully, this will be the end of the problem. Can you grab the CVS code and try it? -Brian |
From: Rob H. <ri...@as...> - 2001-06-12 15:27:30
|
> > Hi Brian and others, > > > > Thanks for your thoughts on this. As you suggested, changing the area > > threshold in tritemp.h does reduce the problem in my original code as well > > as the test case, although it doesn't completely go away. If you can find > > a more general and/or robust solution that would be great! I'm inclined > > to agree with Adam that speed shouldn't be compromised for a problem that > > affects few people, so if the performance hit is significant maybe the fix > > could only be used if enabled in software or via an environment variable? > > I've just checked in my changes to src/swrast/s_tritemp.h in CVS. > It now snaps triangle vertices to 1/16 subpixel positions and I > removed the tiny triangle threshold code. I don't think there is > any significant performance penalty. I just had to rearrange a few > things in the code. > > I modified your test program to draw tiny triangles at various > orientations in an infinite loop and let it run overnight. It was > still running this morning after drawing over 8 billion triangles. > No FP exceptions and the rendering looked correct. Hopefully, this > will be the end of the problem. > > Can you grab the CVS code and try it? > > -Brian I've tried the CVS code with various awkward cases that look awful with 3.4.2 and the problem does seem to be fixed - they all look perfect. I hope the changes will be useful to others as well. Thanks for responding to this so quickly! Regards, Rob |