Texture "jumping" around at high-texture-coordinats

Ok, got all my program up and running ,though there are some weird things happening with the texture.

I can’t really explain it, that’s why I made this video:
http://members.home.nl/painbug/Capture-002.avi
(Look near the cursor in the middle and you will see it).

When I have 2 Polygon’s next to eachother,and I’m at a high-coordinate, the texture seems to jump around at the seam.

This only occurs when I’m at coordinats like x14000 y200 z6000 etc…,
when I’m at x0 y0 z0 it doesnt happen at all.

I tried using floats, double’s, and even integers for glVertex… and
glMultiTextCoord, though without any results.
I have played around with the Perspective, ie. setting the near-plane to 10 and far-plane to 10,000 … or 2/2000 etc.

Z-buffering is done correctly and all polygons are not fighting along the depth-buffer.

Some people said that it maybe be the way how I’m building my mipmaps, so I’ll post my texture generation code here:

// Generate a texture with the associative texture ID stored in the array
glGenTextures(1, &textureArray[textureID]);

glPixelStorei (GL_UNPACK_ALIGNMENT, 1);
glBindTexture(GL_TEXTURE_2D, textureArray[textureID]);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);

if (engine_init_bpp < 24) textureType = GL_RGB4;
else textureType = GL_RGB;

gluBuild2DMipmaps(GL_TEXTURE_2D, textureType, pImage->sizeX, pImage->sizeY, GL_RGB, GL_UNSIGNED_BYTE, pImage->data);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP_SGIS, GL_TRUE);

///////////////////////////////// SET TEXTURE COORD \\\\\\\\\\\\\\\\*
void SetTextureCoord(double x, double z,int MapSize,int Mod)
{
// Find the (u, v) coordinate for the current vertex

double u = ((double)(x+LvlMem[Mod].Xmod/2) / (double)MapSize); // - (LvlMem[Mod].Xmod/2/MapSize)
double v = -((double)(z+LvlMem[Mod].Zmod/2) / (double)MapSize); // - (LvlMem[Mod].Zmod/2/MapSize))

if(engine_init_detail == true && g_bMTSupported == true)
{
// Give OpenGL the current terrain texture coordinate for our height map
glMultiTexCoord2DARB(GL_TEXTURE0_ARB, u, v);

  // Give OpenGL the current detail texture coordinate for our height map
  glMultiTexCoord2DARB(GL_TEXTURE1_ARB, u, v);

} else {
glTexCoord2d(u,v);
}
}

Thanks for your time

looks like precision problems…
you are using ‘x’ and ‘LvlMem[Mod].Xmod/2’ in your calculations.
are they floats or integers ? i suggest using floats.

LvlMem[Mod].Xmod is a Float,and is the current value of vertexes that have to be skipped in the Heightmap (in my program its locked down to 32.0f).

[This message has been edited by GuustFlater (edited 11-25-2002).]

You must keep your numbers on the modelview stack low and also the transformed numbers and texture coordinates.

For example. If the eye is out in the boondocks at say 25,000,000 then any object near it must be translated by around the same numbers. This can easily be accomplished by subtracting the object translation from the viewing translation in software with high precision. When you do this on the CPU in double precision then you retain some of the precision you otherwise lose. If you have big explicit vertex numbers you need to subtract some large number from them and remember the offset to subtract it from the viewing numbers.

Texture coordinate management is even simpler. You just subtract some fixed round number (no decimal fractions) from the texture coordinates on each region of the model to keep the numbers low since they tile in a repeating pattern every time your fraction loops. This should bring the texture coordinate to around the origin and will make no visible difference except the increase in quality.

I dont have any problem with the vertex numbers (they are correctly drawn in place), but I cant possibly make the numbers “smaller”, the world I render is rather big and the camera is small (2/2000) and if I would make it any smaller it would result in more problems

The texture precission should be ok, because textures are drawn correctly (except they “jump” when I translate the camera on the Y-axis),even at high numbers, I tried your solution and the problem still occured

More info added…:
I use 3 textures…

1. 1024x1024 (Stretched over the whole terrain)
2. 256x256 tiled 32 times over the whole terrain.
3. 512x512 tiled 512 times over the whole terrain.

At the moment the terrain is (0,0) x(8192,8192) big (I use a Heightmap of 256x256 that I enlarge 32 times).

[This message has been edited by GuustFlater (edited 11-25-2002).]

I’d be very careful with big texture coordinates values. Some hardware have restrictions about tex coords.

I found that recently on a Radeon 8500. If you try to use big tex coords (can’t remember the values, but it was in the millions), even if the geometry itself is at the origin, that filtering was disabled in one direction only. That is, as if it was using GL_LINEAR in the U texture space direction, and GL_NEAREST in the V direction.

I’m pretty sure it’s a hardware restriction. Modify your texture coords to more reasonnable values to get ride of it…

Y.

Guust,

I’ve done a lot of this type of large coordinate rendering and I know this subject very well. Take it or leave it, but this is your problem. One or both of my explanations is the cause of your problem. You make the objects smaller by dividing the model up, translating it to the origin and remembering the local offset for each section.

There is no easy fix, it needs to be corrected along the lines I have described.

[This message has been edited by dorbie (edited 11-25-2002).]

Something’s been bugging me about this, so I wanted to follow up. Hardware tends to ‘normalize’ texture coordinates as much as it can to preserve precision later. I think your problem is that you have a texture you’re getting really close to and you have tiled it several times over a large polygon, this means that you really don’t have the precision required to preserve accuracy at the texel scale, particularly in the situation here where one edge is getting clipped. The solution is the same, you need to divide your database so you have fewer tiles of texture per primitive. Because of the software I work with I equate this with large area database management issues, you may not.

[This message has been edited by dorbie (edited 11-28-2002).]

Thanks Dorbie, your reply was very usefull.
Getting results as I speak

Originally posted by Ysaneya:
I found that recently on a Radeon 8500. If you try to use big tex coords (can’t remember the values, but it was in the millions), even if the geometry itself is at the origin, that filtering was disabled [b]in one direction only. That is, as if it was using GL_LINEAR in the U texture space direction, and GL_NEAREST in the V direction.

I have that problem too. It happens on both the 8500 and the 9700. It does look like nearest filtering but it happens in both the s and t directions for me.
That has to be a driver bug, I can’t imagine the 9700 having the same problems as the 8500 with everything else being of so high quality.

Edit: Oh, and it happens for texture coordinates of just around 1000 too.

[This message has been edited by PH (edited 12-01-2002).]

If you are having problems like this please send your app to devrel@ati.com

One thing that people should be aware of is that GL spec is quite lax with regard to the precision of things like texture coordinates. An implementation is only required to handle texture coords up to a magnitude of 1024 according to section 2.1.1. FWIW, the 8500 and 9700 both exceed this capability, but other factors can hurt your precision. For instance if Q is large the divide will start to lose precision for projected textures, also if using the fragment shading capabilities on the 8500 the internal numeric format only has 16 bits of precision. (Don’t just write a texture coord to a register then fetch unless you have a really good reason)

Finally, the ARB_fragment_program spec has tightened the precision and range requirements a bit. This should go a long way to eliminating some of these things in the future.

-Evan

[This message has been edited by ehart (edited 12-02-2002).]