Texture detail changing by itself [solved]

This is common problem - try to look at fast rotating wheel (I think it is called The Rotating Wheel Phenomenon).

E.g. you have to do some kind of per pixel motion blurring to make illusion of motion and to keep high level image quality ... look at http://http.developer.nvidia.com/GPUGems3/gpugems3_ch27.html - you might get right idea there ;)

Vilem Otte,

Thankyou for posting that link, but I guess you didn't understand what I said. The floor texture gets ugly like that after moving at fast velocity, I mean, after the "motion" (when it's freezed again) it gets ugly.

See the program flow:

-> Floor is freezed (texture is ok);
-> Floor is moving (texture is bad, as it suposed to be);
-> Floor is freezed again (texture is still bad, why?);
-> Floor is moving very fast (texture is much bad);
-> Floor is freezed again (texture is still much bad);

Sorry for my english.

To me it looks like loss of precision in texture coordinates. Are you using full float all the way through?

RDragon1,

Yes. Btw the problem is gone when I take off this line (GL_TEXTURE matrix mode):

glTranslatef((GLfloat) cos(rot), (GLfloat) sin(rot), 0);

So maybe it is a "loss of precision in texture coordinates". But now I can't make my car get velocity... Any idea?

please :(

You are doing something very wrong. You should not be using GL_TEXTURE_MATRIX.

You should be using GL_MODELVIEW_MATRIX. In other words if you have a terrain, when running on it, does the grass move across the terrain, or does the terrain move as a whole?

Quote:

Original post by dpadam450 You are doing something very wrong. You should not be using GL_TEXTURE_MATRIX. You should be using GL_MODELVIEW_MATRIX. In other words if you have a terrain, when running on it, does the grass move across the terrain, or does the terrain move as a whole?

Computer graphics isn't about conceptually simulating the real world if there are better ways to achieve the same result. In this case however I remember it is generally advices not to use the texture matrix for performance reasons (probably optimized away if identity). Instead of a screen-sized quad and a moving texture you need to move the quad (or car and "camera", which has the same end result).

It also means more trouble doing an "infinite" world (texture wrapping does that automatically) and always checking the bounds.

The texture matrix is easier and more convenient, but the result looks like either filtering and zooming a low res texture, not clearing the color/depth buffer before each frame or some weird scaling going on. For debugging, read back the texture matrix and make sure it is orthonormal.

So it's not convenient to use TEXTURE matrix mode to make the world (floor) move. But why? So the texture matrix mode is less eficient than the others matrix? If yes, how to make an infinite world moving using not infinite quads? Maybe creating an giant quad (size of the game world) using GL_REPEAT wrap mode for the rendering texture and moving it in MODELVIEW matrix mode... Well, In my opinion this is a great loss of performance. What you think?

Thankyou for helping me!

Well, I tested it.

1- Move the floor by rendering a textured screen size quad through texture matrix translation;
2- Move the floor by rendering a giant quad (game world size) textured with GL_REPEAT wrap mode, with modelview translation;

Conclusion: the frame rate is the same.
The difference is: in the first option the texture looks, after some time, ugly.

Maybe someone can make a deeper test. Thanks!

I use the texture moving technique (to simulate the track of a tank), and I didn't notice this phenomenon.
Anyway you can use the following with modelview transformation:
Make a quad and repeat the texture 2 times (-1 to 1 texture coordinate range).
The size of the quad is to times bigger, than the size of the screen.

if you translate the map and rotate the car (like in GTA 1):

Let x, y be the coordinates of the quad center in screen coordinates.

if( x > screen_width )
x -= screen_width;
else if( x < screen_width )
x += screen_width;

if( y > screen_height )
y -= screen_height;
else if( y < screen_height )
y += screen_height;

I hope that made sense.

Post code.

The code has no secrets, it's just like this:

What values do floor.xpos, floor.ypos have?

Do you convert it to texture space, or you have say x = 42345312454744?

Maybe it's simply a floating point precision problem.

Maybe the car only seems to have proper speed because of this:
You except to translate it with 0.1, instead it translates with 321321321.1.
So it displays just like it was 0.1 (because the repeat warping), but you loose precision.

EDITED it heavily.

Well, actually xpos and ypos are defined as GLfloat. And they are "zero initialized". The increment function: obj.xpos += 0.001; I really don't know what to do. Maybe my graphic card (Btw Sis Mirage 3, onboard) is the trouble.

So, I would like to say this problem is partially solved. I just change the floor move type, from texture matrix mode to modelview matrix mode. The texture didn't currupt its appearence anymore.