# Textures and world coordinates

Hi everybody,

I was wondering if you could help me find the relation between texture size and the world coordinates it occupies. For example, assuming a 128x128 pixel texture (linear mapping) and the following counter-clockwise wall in world coordinates:

glVertex3f(0.0, 0.0, 0.0);
glVertex3f(0.0, 0.0, 150.0);
glVertex3f(0.0, 5.0, 150.0);
glVertex3f(0.0, 5.0, 0.0);

How do I find out how many texture images fit in the wall, both in height and width?

I don’t know if it’s relevant, but I’m using a perspective projection with a fovy of 60.0.

Thanks in advance for your help,

Frederico Jeronimo

Originally posted by Jeronimo:
[b]Hi everybody,

I was wondering if you could help me find the relation between texture size and the world coordinates it occupies. For example, assuming a 128x128 pixel texture (linear mapping) and the following counter-clockwise wall in world coordinates:

glVertex3f(0.0, 0.0, 0.0);
glVertex3f(0.0, 0.0, 150.0);
glVertex3f(0.0, 5.0, 150.0);
glVertex3f(0.0, 5.0, 0.0);

How do I find out how many texture images fit in the wall, both in height and width?

I don’t know if it’s relevant, but I’m using a perspective projection with a fovy of 60.0.

Thanks in advance for your help,

Frederico Jeronimo[/b]

Texture coordinates are bounded by coordinates raging from 0-1. Anything in the middle, and you are picking portion of it, regardless of the size…
The lower left corner is 0,0 for a vertex coordinate in 2d… The upper right hand corner is 1,1.

So, to fill you polygon you could have:

glTexCoord2i(0,0);
glVertex3f(0.0, 0.0, 0.0);

glTexCoord2i(0,1);
glVertex3f(0.0, 0.0, 150.0);

glTexCoord2i(1,1);
glVertex3f(0.0, 5.0, 150.0);

glTexCoord2i(1,0);
glVertex3f(0.0, 5.0, 0.0);

I guess…

Originally posted by mancha:
[b] Texture coordinates are bounded by coordinates raging from 0-1. Anything in the middle, and you are picking portion of it, regardless of the size…
The lower left corner is 0,0 for a vertex coordinate in 2d… The upper right hand corner is 1,1.

So, to fill you polygon you could have:

glTexCoord2i(0,0);
glVertex3f(0.0, 0.0, 0.0);

glTexCoord2i(0,1);
glVertex3f(0.0, 0.0, 150.0);

glTexCoord2i(1,1);
glVertex3f(0.0, 5.0, 150.0);

glTexCoord2i(1,0);
glVertex3f(0.0, 5.0, 0.0);

I guess… [/b]

The problem with that approach is that the texture is hopelessly stretched to fit in the wall… I have GL_REPEAT as texture wrap and I wanted to know the exact value to put in the glTexCoord*()…

By trial and error, I found out that something along the lines of:

glTexCoord2f(0.0f, 0.0f);
glVertex3f(0.0, 0.0, 0.0);

glTexCoord2f(18.0f, 0.0f);
glVertex3f(0.0, 0.0, 150.0);

glTexCoord2f(18.0f, 1.0f);
glVertex3f(0.0, 5.0, 150.0);

glTexCoord2f(0.0f, 1.0f);
glVertex3f(0.0, 5.0, 0.0);

works pretty well. The texture would be repeated 18 times for width (spanning across 150 z) and only 1 for heigh (since 5 in y is much smaller). The aspect ratio is acceptable. But I need to find the exact value (i.e 1 texture pixel = ? world coordinates), because I need this at runtime for different walls.

Any ideas?

Frederico Jeronimo

Post some of your code where you set up your images…

Do you have GL_REPEAT for t and s?

Originally posted by Jeronimo:
The texture would be repeated 18 times for width (spanning across 150 z) and only 1 for heigh (since 5 in y is much smaller). The aspect ratio is acceptable. But I need to find the exact value (i.e 1 texture pixel = ? world coordinates), because I need this at runtime for different walls.

Based on this I think you want the texture to remain ‘steady’ on the screen, independent of the position of the wall? Like having the surface of the wall ‘carve’ a piece out of the repeated texture?

If that is the case, then look into texture coordinate generation (EYE_LINEAR I think) instead of trying to determine the texcoords yourself.

If that is not the case but you want the texture to appear ‘correct’ in the real-world sense (i.e. a wall that is 5 units high and 150 units wide has a texture of size 1x1 repeated five times vertically and 150 times horizontally), then use the real-world X and Y as texture coordinates.
(or in this last case, texture coordinate generation with OBJECT_LINEAR might also work).

Good luck,

Jean-Marc.

Originally posted by JML:
[b] Based on this I think you want the texture to remain ‘steady’ on the screen, independent of the position of the wall? Like having the surface of the wall ‘carve’ a piece out of the repeated texture?

If that is the case, then look into texture coordinate generation (EYE_LINEAR I think) instead of trying to determine the texcoords yourself.

If that is not the case but you want the texture to appear ‘correct’ in the real-world sense (i.e. a wall that is 5 units high and 150 units wide has a texture of size 1x1 repeated five times vertically and 150 times horizontally), then use the real-world X and Y as texture coordinates.
(or in this last case, texture coordinate generation with OBJECT_LINEAR might also work).

Good luck,

Jean-Marc.[/b]

Mancha:

I think the problem is not in texture init. Here’s what I have:

glPixelStorei (GL_UNPACK_ALIGNMENT, 1);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);

JML:

Yes Jean-Marc, that’s exactly it. I want the texture to remain fixed independently of viewpoint. However, I tried using automatic texture generation in the past but I think I have a problem with that. You see, in my game the camera remains fixed at the origin and it’s the game world that moves at each frame (I’m doing this to avoid gimbal lock, but that’s not relevant at the moment). Therefore, I don’t really know which planes to use in the auto tex gen. I can’t use x=0 and z=0, because the walls keep moving, right?

As for using the real world coordinates, I have just tried that. And it works wonders.
Of course, I can’t use the world coordinates as is or the texture will be way too small (the bricks will only be visible real close), but by dividing both coordinates by 8.0, they appear in the intended size. I had already solved my problem with a real complicated algorithm. I can’t believe the solution was this simple. It comes to show that human beings have a natural tendency to complicate things…

Thanks to both for your help,

Frederico Jeronimo