Re: [Mesa3d-dev] Artifacts with very large texture coordinates
Sorry folks, I attached the wrong file. This is the second time in a
week. I have to be more careful. Now the correct program.
Am Do, den 16.12.2004 schrieb Felix Kühling um 1:11:
Hi,
I noticed some strange rendering artifacts with the Savage that are
caused by very large texture coordinates on GL_REPEAT'ed textures. Very
large means that it gets noticeable with texture coordinates 255 or
-256. A real world example that exhibits this problem is Torcs with the
Spring track. Right at the start the effect can be seen very nicely.
The track before the start line shows artifacts, directly after the
start line everything looks fine.
My question is, should I consider such problems an application bug or
would it be wise to implement a workaround? I was thinking of
implementing a TNL pipeline stage that normalizes texture coordinates.
I was also wondering if other hardware has similar problems. I'm
attaching a small test program that demonstrates the effect and a
screenshot of what I get on my ProSavageDDR. With software rendering the
output is almost correct. Compile with
cc -lGL -lGLU -lglut teximage.c -o teximage
Thanks in advance,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
#include GL/gl.h
#include GL/glu.h
#include GL/glut.h
#include stdio.h
#include stdlib.h
#define TEX_OFFSET_X 1024.0
#define TEX_OFFSET_Y 1024.0
#define MAX_WIDTH 128
#define MAX_HEIGHT 128
GLubyte texData[MAX_WIDTH * MAX_HEIGHT * 3];
GLuint texture;
GLuint tWidth = 0, tHeight = 0;
void init () {
GLuint x, y;
GLubyte *p;
glClearColor (0.0, 0.0, 0.0, 0.0);
glShadeModel (GL_FLAT);
p = texData;
for (y = 0; y tHeight; ++y)
for (x = 0; x tWidth; ++x, p += 3) {
if ((x 7) == 4 || (y 7) == 4) {
p[0] = 0;
p[1] = 0;
p[2] = 255;
} else {
p[0] = tWidth 1 ? x * 255 / (tWidth-1) : 128;
p[1] = tHeight 1 ? y * 255 / (tHeight-1) : 128;
p[2] = 0;
}
}
glGenTextures (1, texture);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, tWidth, tHeight, 0,
GL_RGB, GL_UNSIGNED_BYTE, texData);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
}
void display () {
glClear (GL_COLOR_BUFFER_BIT);
glEnable(GL_TEXTURE_2D);
glBindTexture (GL_TEXTURE_2D, texture);
glBegin(GL_QUADS);
glColor3f(1.0, 1.0, 0.0);
glTexCoord2f(0.0+TEX_OFFSET_X, 2.0+TEX_OFFSET_Y); glVertex2f(-1.0, -1.0);
glTexCoord2f(2.0+TEX_OFFSET_X, 2.0+TEX_OFFSET_Y); glVertex2f( 1.0, -1.0);
glTexCoord2f(2.0+TEX_OFFSET_X, 0.0+TEX_OFFSET_Y); glVertex2f( 1.0, 1.0);
glTexCoord2f(0.0+TEX_OFFSET_X, 0.0+TEX_OFFSET_Y); glVertex2f(-1.0, 1.0);
glEnd();
glutSwapBuffers();
}
void reshape (int w, int h) {
glViewport (0, 0, (GLsizei) w, (GLsizei) h);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
glOrtho (-1.0, 1.0, -1.0, 1.0, -1.0, 1.0);
glMatrixMode (GL_MODELVIEW);
}
int main (int argc, char *argv[]) {
int winId;
if (argc 2)
tWidth = 128;
else if (sscanf (argv[1], %u, tWidth) != 1) {
fprintf (stderr, Error: invalid width: %s\n, argv[1]);
return 1;
}
if (argc 3)
tHeight = 128;
else if (sscanf (argv[2], %u, tHeight) != 1) {
fprintf (stderr, Error: invalid height: %s\n, argv[2]);
return 1;
}
if (tWidth == 0 || tWidth MAX_WIDTH) {
fprintf (stderr, Error: width out of range [1:%u].\n, MAX_WIDTH);
return 1;
}
if (tHeight == 0 || tHeight MAX_HEIGHT) {
fprintf (stderr, Error: height out of range [1:%u].\n, MAX_HEIGHT);
return 1;
}
glutInit (argc, argv);
glutInitDisplayMode (GLUT_RGBA | GLUT_DOUBLE);
glutInitWindowSize (250, 250);
glutInitWindowPosition (100, 100);
winId = glutCreateWindow (Texture Test);
init ();
glutDisplayFunc (display);
glutReshapeFunc (reshape);
glutMainLoop ();
return 0;
}
Re: [Mesa3d-dev] Artifacts with very large texture coordinates
Felix Kühling [EMAIL PROTECTED] writes: Sorry folks, I attached the wrong file. This is the second time in a week. I have to be more careful. Now the correct program. Here's what I get with my radeon 7500 with the correct program : http://homes.kataplop.net/~dkm/texturetest2.png Hope it can help :) Marc --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Artifacts with very large texture coordinates
Sorry folks, I attached the wrong file. This is the second time in a week. I have to be more careful. Now the correct program. You're simply working too hard :-) Here you go: http://kempniu.no-ip.com/files/teximage.jpg (Savage/IX 8 MB) Best regards, Michal Kepien --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Artifacts with very large texture coordinates
Am Do, den 16.12.2004 schrieb Brian Paul um 16:45:
Felix Kühling wrote:
Hi,
I noticed some strange rendering artifacts with the Savage that are
caused by very large texture coordinates on GL_REPEAT'ed textures. Very
large means that it gets noticeable with texture coordinates 255 or
-256. A real world example that exhibits this problem is Torcs with the
Spring track. Right at the start the effect can be seen very nicely.
The track before the start line shows artifacts, directly after the
start line everything looks fine.
My question is, should I consider such problems an application bug or
would it be wise to implement a workaround? I was thinking of
implementing a TNL pipeline stage that normalizes texture coordinates.
That could be tricky. If you're thinking of doing something like t' =
t MOD maxValue, that'll often cause incorrect interpolation.
The trick is that you have to change (add or subtract) all texture
coordinates in one primitive (e.g. triangle) in the same way, that is,
the relative differences between texcoords must not be changed.
I've already hacked up something and the result looks good. It computes
the max and min coordinates per direction and then subtracts
floor((max+min)/2 + 0.5)
from all texture coordinates in the vertex buffer. This is done only for
texture coordinates for which the wrapping mode is GL_REPEAT. I havn't
measured the performance, but I didn't notice a major difference. I
guess the Savage has other bottle-necks. ;-)
A patch is attached for anyone who wants to see the gory details.
I was also wondering if other hardware has similar problems. I'm
attaching a small test program that demonstrates the effect and a
screenshot of what I get on my ProSavageDDR. With software rendering the
output is almost correct. Compile with
cc -lGL -lGLU -lglut teximage.c -o teximage
If the hardware implements texcoord interpolation with fixed point you
can imagine how the bits are used.
If the largest texture dimension is 2048, you'd need at least 11 bits
to address all texels.
Then you need some sub-texel bits for accurate interpolation and for
computing the weighting for linear sampling. You probably need 10
bits there.
Allocate another bit for the sign.
Finally, whatever bits are left in the interpolator will limit the
maximum coordinate range. If the interpolator is 32 bits, then 32 -
11 - 10 - 1 = 10. So the max coordinate would be 2^10 or 1024.
Maybe the savage hardware has a narrow interpolator, or allocates the
bits differently.
When you increase the texture coordinate offset you can see the
artifacts get worse with every power of two. So you can literally take
away bits available for the interpolation on the Savage by making
texture coordinates bigger. :)
I believe one of the differences between pro and consumer cards is
the accuracy and range of interpolators.
Or maybe more expensive hardware does the normalization per
hardware-primitive before it starts interpolating.
-Brian
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
? core.2742
? core.2751
? debugfallback.diff
? depend
? diff-20041215
? savage_mesa_20041019.diff
? savage_texnorm.diff
? savagestate.diff
? savagetris.diff
? throttle_and_front.diff
Index: savage_xmesa.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savage_xmesa.c,v
retrieving revision 1.18
diff -u -r1.18 savage_xmesa.c
--- savage_xmesa.c 15 Dec 2004 17:45:23 - 1.18
+++ savage_xmesa.c 16 Dec 2004 21:16:10 -
@@ -109,6 +109,22 @@
NULL
};
+extern const struct tnl_pipeline_stage _savage_texnorm_stage;
+
+static const struct tnl_pipeline_stage *savage_pipeline[] = {
+
+ _tnl_vertex_transform_stage,
+ _tnl_normal_transform_stage,
+ _tnl_lighting_stage,
+ _tnl_fog_coordinate_stage,
+ _tnl_texgen_stage,
+ _tnl_texture_transform_stage,
+ _savage_texnorm_stage,
+ _tnl_render_stage,
+ 0,
+};
+
+
/* this is first function called in dirver*/
static GLboolean
@@ -455,7 +471,7 @@
/* Install the customized pipeline:
*/
-#if 0
+#if 1
_tnl_destroy_pipeline( ctx );
_tnl_install_pipeline( ctx, savage_pipeline );
#endif
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.14
diff -u -r1.14 savagetris.c
--- savagetris.c 14 Dec 2004 22:37:46 - 1.14
+++ savagetris.c 16 Dec 2004 21:16:11 -
@@ -911,3 +911,189 @@
SAVAGE_CONTEXT(ctx)-verts = (char *)tnl-clipspace.vertex_buf;
}
+
+
+/***
+ * Pipeline stage for texture coordinate normalization
+ * This should probably go somewhere else.
+ ***/
+struct texnorm_stage_data {
+ GLvector4f texcoord[MAX_TEXTURE_UNITS];
+};
+
+#define TEXNORM_STAGE_DATA(stage)
Re: Artifacts with very large texture coordinates
Felix Kühling wrote: Am Do, den 16.12.2004 schrieb Brian Paul um 16:45: Felix Kühling wrote: Hi, I noticed some strange rendering artifacts with the Savage that are caused by very large texture coordinates on GL_REPEAT'ed textures. Very large means that it gets noticeable with texture coordinates 255 or -256. A real world example that exhibits this problem is Torcs with the Spring track. Right at the start the effect can be seen very nicely. The track before the start line shows artifacts, directly after the start line everything looks fine. My question is, should I consider such problems an application bug or would it be wise to implement a workaround? I was thinking of implementing a TNL pipeline stage that normalizes texture coordinates. That could be tricky. If you're thinking of doing something like t' = t MOD maxValue, that'll often cause incorrect interpolation. The trick is that you have to change (add or subtract) all texture coordinates in one primitive (e.g. triangle) in the same way, that is, the relative differences between texcoords must not be changed. That's exactly what I had in mind. I've already hacked up something and the result looks good. It computes the max and min coordinates per direction and then subtracts floor((max+min)/2 + 0.5) from all texture coordinates in the vertex buffer. This is done only for texture coordinates for which the wrapping mode is GL_REPEAT. I havn't measured the performance, but I didn't notice a major difference. I guess the Savage has other bottle-necks. ;-) A patch is attached for anyone who wants to see the gory details. Looks like you've got a good understanding of the problem. I was also wondering if other hardware has similar problems. I'm attaching a small test program that demonstrates the effect and a screenshot of what I get on my ProSavageDDR. With software rendering the output is almost correct. Compile with cc -lGL -lGLU -lglut teximage.c -o teximage If the hardware implements texcoord interpolation with fixed point you can imagine how the bits are used. If the largest texture dimension is 2048, you'd need at least 11 bits to address all texels. Then you need some sub-texel bits for accurate interpolation and for computing the weighting for linear sampling. You probably need 10 bits there. Allocate another bit for the sign. Finally, whatever bits are left in the interpolator will limit the maximum coordinate range. If the interpolator is 32 bits, then 32 - 11 - 10 - 1 = 10. So the max coordinate would be 2^10 or 1024. Maybe the savage hardware has a narrow interpolator, or allocates the bits differently. When you increase the texture coordinate offset you can see the artifacts get worse with every power of two. So you can literally take away bits available for the interpolation on the Savage by making texture coordinates bigger. :) I believe one of the differences between pro and consumer cards is the accuracy and range of interpolators. Or maybe more expensive hardware does the normalization per hardware-primitive before it starts interpolating. It might. An engineer with one of the major IHVs once told me a few things about the differences between the pro and consumer cards. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Artifacts with very large texture coordinates
I was also wondering if other hardware has similar problems. I'm attaching a small test program that demonstrates the effect and a screenshot of what I get on my ProSavageDDR. With software rendering the output is almost correct. Compile with cc -lGL -lGLU -lglut teximage.c -o teximage Well, I don't really know what _should_ I get, but here you go :-) http://kempniu.no-ip.com/files/texturetest.jpg (Savage/IX 8 MB) Oh and BTW: the compile command you've shown uses the filename teximage.c, but you attached texturetest.c ;-) Best regards, Michal Kepien --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
