triangles junction artifacts on radeon cards

This topic is 4073 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hello, On my two pc with radeon cards (9700 and 9200) I obtain this kind of artifacts at the triangles junctions: small white dots coming from the background at the edges (note: there is no artifact when the camera direction is parallel to the rectangles normals, they appear when the camera move). But everything's fine on my brother's geforce 7600. Here is the (really simple) C code used to create the image:
#include <GL/glut.h>

float rx = 0.0f, ry = 0.0f;

void reshape(int width, int height)
{
glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
gluPerspective(60.0, (GLdouble)width / (GLdouble)height, 0.1, 10.0);
glMatrixMode(GL_MODELVIEW);
}

void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);

glTranslatef(0.0f, 0.0f,-1.0f);
glRotatef(ry, 1.0f, 0.0f, 0.0f);
glRotatef(rx, 0.0f, 1.0f, 0.0f);

glColor3f(0.0f, 0.0f, 0.0f);

glVertex3f(-0.128, -0.064, -1.024);
glVertex3f(-0.128, -0.256, -1.024);
glVertex3f(0.128, -0.256, -1.024);
glVertex3f(0.128, -0.064, -1.024);
glVertex3f(-0.256, 0.064, -1.024);
glVertex3f(-0.256, -0.256, -1.024);
glVertex3f(-0.128, -0.256, -1.024);
glVertex3f(-0.128, 0.064, -1.024);
glVertex3f(0.128, 0.064, -1.024);
glVertex3f(0.128, -0.256, -1.024);
glVertex3f(0.256, -0.256, -1.024);
glVertex3f(0.256, 0.064, -1.024);
glVertex3f(-0.384, -0.256, -1.024);
glVertex3f(-0.256, -0.256, -1.024);
glVertex3f(-0.256, 0.136, -1.024);
glVertex3f(-0.384, 0.136, -1.024);
glEnd();

glutSwapBuffers();
}

void idle(void)
{
glutPostRedisplay();
}

void motion(int x, int y)
{
static int oldX = 0, oldY = 0;

rx += x - oldX;
ry += y - oldY;

oldX = x;
oldY = y;
}

int main(int argc, char **argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);
glutInitWindowSize(640, 480);
glutCreateWindow("Glut");

glutReshapeFunc(reshape);
glutDisplayFunc(display);
glutIdleFunc(idle);
glutMotionFunc(motion);

glClearColor(1.0f, 1.0f, 1.0f, 1.0f);

glutMainLoop();

return 0;
}


Does anyone have an idea of the cause of this problem and a possible fix? Thanks.

Share on other sites
Well, I may have found something, it seems to be an issue with the precision of the projection, as if I replace the call to gluPerspective with glOrtho, no artifacts are visible anymore. But it sucks, I cannot believe you cannot draw adjacent triangles without cracks between them!

I tried the same thing with Direct3D and there is no crack between the triangles, what's wrong?

[Edited by - x86ppc on June 26, 2007 8:46:56 PM]

Share on other sites
I am going to throw this out there, but do you have depth testing enabled and writes on?

Share on other sites
As you can see from the code, depth testing is not enabled. I tried to make the code sample as simple as possible, but enabling it and adding glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); changes nothing, as it seems to be a rasterization problem. What drives me crazy is that this problem does not appear in Direct3D.

And as additional proof of the problem, I just changed the background color of some OpenGL and Direct3D demos (from humus.ca) to green, and on the OpenGL ones, you see green points all over the triangles borders.

Is my radeon 9700 just crappy?

[Edited by - x86ppc on June 27, 2007 7:21:58 AM]

Share on other sites
Quote:
 Original post by x86ppcIs my radeon 9700 just crappy?
FP math is a bit broken believe it or not - it's just slightly worse on ATi cards.
If you're doing what I think that behaviour is perfectly normal AND valid. I suppose the vertices are not shared. This means FP computations are not guaranteed to converge... so, good luck!
Shared vertices should really be indexed. This ensures the FP value will be the same. In other words, if you have 4 quads near each other...
*--*|  ||  &--*|  |  |?--?--?|  |  |*--&  |   |  |   *--*

All the '&' vertices should be shared/indexed. Otherwise, FP math is allowed to produce different results when interpolating. For '?' this is similar but those points will have the same FP vec3 to start from and will produce the same value - you see that the bottom of the barst don't leak.

A wireframe would help.

Share on other sites
Thank you for your enlightening answer, true the vertices aren't shared as you can see from the source code (where you can also see that it's just 4 quads with different heights so I don't think a wireframe view is necessary). But if I put the same height value for all the quads:
*-*-*-*-*| | | | |*-*-*-*-*

there is no crack anymore! I understand it comes from the interpolation at the & points giving different results than the specified points, but I don't see what shared vertices are adding to the picture, from what I understand the solution is to add vertices at the & points so the values are not interpolated.
Am I missing something?

And so the solution would be to do:
*---*|   |*---**---**----*|   ||    ||   ||    |*---**----*3 quadsinstead of:*---*|   ||   |*----*|   ||    ||   ||    |*---**----*2 quads

[Edited by - x86ppc on June 27, 2007 8:25:40 AM]

Share on other sites
The shared vertices would guarentee that the intersection points of the two polygons would be the same. Just because seperate floating point numbers should be identical, doesn't mean that they are as far as the computer is concerned.

Share on other sites
Quote:
 Original post by x86ppcaren't shared as you can see from the source code
I'm sorry, I admit I don't look at the source. It gives me the creeps. Pictures are more fun!
Quote:
 Original post by x86ppcthere is no crack anymore! I understand it comes from the interpolation at the & points giving different results than the specified points, but I don't see what shared vertices are adding to the picture
If the values are the same, nothing - besides being a good practice in general and avoiding useless replication of data.

What's is different from two vertices with the same value and the same index is that the same index guarantees to the HW the same value and post-T&L cache optimizations do apply.
For non-indexed vertices this doesn't happen. Non-indexed vertices are considered always different, even if they have the same value and get transformed multiple times.
You must see the bigger picture. Not just that one.
Same Index --> Same Value --> Same Result and optimizations
Same Values --> Same result
Quote:
 Original post by RattrapJust because seperate floating point numbers should be identical, doesn't mean that they are as far as the computer is concerned.

If you say so... but I don't see how this could happen and if it happens, I don't see how this could satisfy the invariance rules, which are especially targeted at vertex processing.

Could you elaborate a bit more on this?

1. 1
2. 2
JoeJ
20
3. 3
frob
17
4. 4
5. 5

• 10
• 10
• 11
• 13
• 9
• Forum Statistics

• Total Topics
632197
• Total Posts
3004727

×