If you are drawing a 2d image that's 1920x1200, which of these uses
proper texture coords:



	glBegin(GL_QUADS);
		// Front Face
		glTexCoord2f(0.0f, 0.0f); glVertex2f(0,0);
		glTexCoord2f(1.0f, 0.0f); glVertex2f( 1920.0f, 0);
		glTexCoord2f(1.0f, 1.0f); glVertex2f( 1920.0f,  1200.0f);
		glTexCoord2f(0.0f, 1.0f); glVertex2f(0,  1200.0f);

	glEnd();





	glBegin(GL_QUADS);
		// Front Face
		glTexCoord2f(0.0f, 0.0f); glVertex2f(0,0);
		glTexCoord2f(1919.0f/1920.0f, 0.0f); glVertex2f( 1920.0f, 0);
		glTexCoord2f(1919.0f/1920.0f, 1199.0f/1200.0f);
glVertex2f( 1920.0f,  1200.0f);
		glTexCoord2f(0.0f, 1199.0f/1200.0f); glVertex2f(0,  1200.0f);

	glEnd();

On Thu, 23 Dec 2010 12:26:09 -0800, bob@coolgroups.com wrote:

> If you are drawing a 2d image that's 1920x1200, which of these uses
> proper texture coords:

The first one.

Note that if multi-sampling is enabled, the filters need to be GL_NEAREST
if you want a pixel-for-pixel copy.

On Thu, 23 Dec 2010 23:57:52 +0000
Nobody <nobody@nowhere.com> wrote:

> On Thu, 23 Dec 2010 12:26:09 -0800, bob@coolgroups.com wrote:
> 
> > If you are drawing a 2d image that's 1920x1200, which of these uses
> > proper texture coords:

No it doesn't.

Think the texture like a rectangular grid spanning the range [0 .. 1]
in each direction. The texels (texture pixels) cover the space between
the grid lines. To exactly hit the texels you must address the texel
centers, i.e. the points in the middle between the grid lines.

The exception is GL_ARB_texture_rectangle where the actual texels are
addressed, i.e. the texture coordinate ranges are in [0 .. dim-1].


Wolfgang

<bob@coolgroups.com> wrote in message 
news:7ddea1c0-5b81-41fd-9685-d8280906c2c3@n29g2000vby.googlegroups.com...
> If you are drawing a 2d image that's 1920x1200, which of these uses
> proper texture coords:
>
>
>
> glBegin(GL_QUADS);
> // Front Face
> glTexCoord2f(0.0f, 0.0f); glVertex2f(0,0);
> glTexCoord2f(1.0f, 0.0f); glVertex2f( 1920.0f, 0);
> glTexCoord2f(1.0f, 1.0f); glVertex2f( 1920.0f,  1200.0f);
> glTexCoord2f(0.0f, 1.0f); glVertex2f(0,  1200.0f);
>
> glEnd();
>
>
>
>
>
> glBegin(GL_QUADS);
> // Front Face
> glTexCoord2f(0.0f, 0.0f); glVertex2f(0,0);
> glTexCoord2f(1919.0f/1920.0f, 0.0f); glVertex2f( 1920.0f, 0);
> glTexCoord2f(1919.0f/1920.0f, 1199.0f/1200.0f);
> glVertex2f( 1920.0f,  1200.0f);
> glTexCoord2f(0.0f, 1199.0f/1200.0f); glVertex2f(0,  1200.0f);
>
> glEnd();

Neither.

On Dec 23, 9:26=A0pm, "b...@coolgroups.com" <b...@coolgroups.com> wrote:
> If you are drawing a 2d image that's 1920x1200, which of these uses
> proper texture coords:
>

Neither.

On Fri, 24 Dec 2010 01:03:10 +0100, Wolfgang Draxinger wrote:

> Think the texture like a rectangular grid spanning the range [0 .. 1]
> in each direction. The texels (texture pixels) cover the space between
> the grid lines. To exactly hit the texels you must address the texel
> centers, i.e. the points in the middle between the grid lines.

I know.

But interpolated values (e.g. texture coordinates) are sampled at the
centre of each pixel.

If the texture has the same dimensions as the viewport, mapping the
normalised device coordinate range [-1..1] to the texture coordinate range
[0..1] results in the pixel grid matching the texel grid, and thus the
pixel centres coinciding with texel centres, which produces an exact copy
for either nearest-neighbour sampling or bilinear interpolation.

E.g. for a 100x100 viewport with a 100x100 texture, with all matrices set
to identity, drawing a "unit quad" (with vertex coordinates of -1 or 1 and
texture coordinates of 0 or 1), will result in the bottom-left pixel
sampling the texture at normalised coordinates of <0.005,0.005>, i.e. grid
indices of <0.5,0.5>, i.e. in the centre of the bottom-left texel. For
GL_NEAREST, this will read the bottom-left texel. For GL_LINEAR, this will
interpolate with the bottom-left texel having a weight of 1 and the other
three texels (it doesn't matter which ones are chosen) having a weight of
zero.

If you introduce a half-pixel/half-texel shift in one set of coordinates,
you'll either align pixel centres to texel corners or pixel corners to
texel centres. If you shrink or grow the vertex or texture coordinates,
you'll end up with the relative phase changing across the surface of the
primitive.

Mapping signed-unit (-1..1 i.e. NDC) vertex coordinates to unsigned-unit
(0..1) texture coordinates is correct if you want a texel-for-pixel copy.

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2010.12.24.20.35.57.16000@nowhere.com...
> On Fri, 24 Dec 2010 01:03:10 +0100, Wolfgang Draxinger wrote:
>
>> Think the texture like a rectangular grid spanning the range [0 .. 1]
>> in each direction. The texels (texture pixels) cover the space between
>> the grid lines. To exactly hit the texels you must address the texel
>> centers, i.e. the points in the middle between the grid lines.
>
> I know.
>
> But interpolated values (e.g. texture coordinates) are sampled at the
> centre of each pixel.
>
> If the texture has the same dimensions as the viewport, mapping the
> normalised device coordinate range [-1..1] to the texture coordinate range
> [0..1] results in the pixel grid matching the texel grid, and thus the
> pixel centres coinciding with texel centres, which produces an exact copy
> for either nearest-neighbour sampling or bilinear interpolation.
>
> E.g. for a 100x100 viewport with a 100x100 texture, with all matrices set
> to identity, drawing a "unit quad" (with vertex coordinates of -1 or 1 and
> texture coordinates of 0 or 1), will result in the bottom-left pixel
> sampling the texture at normalised coordinates of <0.005,0.005>, i.e. grid
> indices of <0.5,0.5>, i.e. in the centre of the bottom-left texel. For
> GL_NEAREST, this will read the bottom-left texel. For GL_LINEAR, this will
> interpolate with the bottom-left texel having a weight of 1 and the other
> three texels (it doesn't matter which ones are chosen) having a weight of
> zero.
>
> If you introduce a half-pixel/half-texel shift in one set of coordinates,
> you'll either align pixel centres to texel corners or pixel corners to
> texel centres. If you shrink or grow the vertex or texture coordinates,
> you'll end up with the relative phase changing across the surface of the
> primitive.
>
> Mapping signed-unit (-1..1 i.e. NDC) vertex coordinates to unsigned-unit
> (0..1) texture coordinates is correct if you want a texel-for-pixel copy.
>


Using [0...1] isn't proper in the general (not the special case 
texel-per-pixel) SMOOTH quad case.   A texture coordinate of 0 involves a 
50% interpolation -if smooth- from the texture border value. If one forces a 
CLAMP_TO_EDGE, the then 1st 1/2 texel is a simple replication of the initial 
texel, and not a properly bilinearly interpolated image.  Consider tiling 
tiles of these [0..1] mapped texels as you suggest. First of all, you must 
have CLAMP or you will pull in border texels. This already shows that this 
formulation is, in the general case, are incorrect. And, you will experience 
artifacts at the boundary, and not a completely smooth image. SMOOTH does 
indeed introduce a phase shift in your view, but if the originating texture 
is a properly (cell-centered) sampled data, then you have introduced a phase 
shift.

Consider seismic data, a truly sampled form of data. Using the 1/2 texel 
coordinate shift alignes the texture properly so that a "wiggle" display at 
the same XY coordinate properly sits on top of the pure value at that point, 
and not 1/2 interpolated to the next texel.

Sampling at the half-texels as previously recommended, and having the 
necessary 1 texel overlap, is the only way to get a properly tiled SMOOTH 
(NEAREST is something altogether different) texture image.

jbw

On Sat, 25 Dec 2010 10:43:49 -0800, jbwest wrote:

> Using [0...1] isn't proper in the general (not the special case 
> texel-per-pixel) SMOOTH quad case.   A texture coordinate of 0 involves a 
> 50% interpolation -if smooth- from the texture border value.

Now I see what you're getting at. I assumed that the OP was asking about
texel-for-pixel, and replied on that basis.

Even if this isn't the case, unit-to-unit is still correct for GL_NEAREST
(the OP didn't specify filtering), as this will produce the expected
behaviour for integer ratios (e.g. if the viewport size is exactly twice
the texture size, each texel will be used for a 2x2 block of pixels).

> If one forces a 
> CLAMP_TO_EDGE, the then 1st 1/2 texel is a simple replication of the initial 
> texel, and not a properly bilinearly interpolated image. Consider tiling 
> tiles of these [0..1] mapped texels as you suggest. First of all, you must 
> have CLAMP or you will pull in border texels. This already shows that this 
> formulation is, in the general case, are incorrect. And, you will experience 
> artifacts at the boundary, and not a completely smooth image.

However, trying to compensate for this brings up a number of issues. 
The most significant of which is that, if you're going to offset the
texture coordinates by half a texel, texel sizes vary with the mipmap
level, so this basically rules out using mipmaps (i.e. any of the
GL_*_MIPMAP_* filtering modes).

Also, you have to explicitly account for texel sizes, which rather defeats
the purpose of normalised texture coordinates. If you're using the same
geometry with different textures, you would need to use different texture
coordinates depending upon the resolution. If you're using multitexturing,
you may need to use multiple sets of texture coordinates when a single set
would otherwise suffice. If the textures are tiles of a larger image, you
need a row/column of overlap; if you've been handed a set of tiles from
elsewhere, chances are this probably wasn't done, so you have to re-tile
(and if you were given power-of-two tiles, your re-tiled textures won't be
power-of-two).

All in all, the cure may be worse than the disease.

Beyond the tiling issue, if you're given an image whose corners have known
positions in physical space, there really isn't any alternative. Mapping
the vertices to the centres of the corner pixels will result in a scaling
change, which is a problem if it needs to align with other textures or
with the geometry.

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2010.12.25.22.16.55.282000@nowhere.com...
> On Sat, 25 Dec 2010 10:43:49 -0800, jbwest wrote:
>
>
> However, trying to compensate for this brings up a number of issues.
> The most significant of which is that, if you're going to offset the
> texture coordinates by half a texel, texel sizes vary with the mipmap
> level, so this basically rules out using mipmaps (i.e. any of the
> GL_*_MIPMAP_* filtering modes).

Nope, because of the relationship of texels < pixels when mipmapped down to 
a lower res.

>
> Also, you have to explicitly account for texel sizes, which rather defeats
> the purpose of normalised texture coordinates. If you're using the same
> geometry with different textures, you would need to use different texture
> coordinates depending upon the resolution. If you're using multitexturing,

Different texture coordinates for different texture size, you mean? yes, 
absolutely right.

> you may need to use multiple sets of texture coordinates when a single set
> would otherwise suffice. If the textures are tiles of a larger image, you
> need a row/column of overlap; if you've been handed a set of tiles from
> elsewhere, chances are this probably wasn't done, so you have to re-tile
> (and if you were given power-of-two tiles, your re-tiled textures won't be
> power-of-two).

Don't have to be power of 2. But, yes, the only way to tile properly (in 
SMOOTH mode, 1 texel >  pixel) is to have an overlap.

>
> All in all, the cure may be worse than the disease.

 In my profession, where textures (as well as pixel count) can be quite 
huge, tiling without artifacts is absolutely mandatory.
The tiling issue shows that there's a proper approach, PITA as it may be. 
With extreme zoom, [0..1] coordinates is very obviously off. Consider the 2 
different approaches when a 2x2 texture nearly fills the entire screen. 
Using 1/2 texel coordinate methods propery places the "true value" of the 
sample data at the geometry (the edges), and a continous interpolation 
between. Using [0..1] produces discontinous high-frequency artifacts not 
present in the sample data (texture)

>
> Beyond the tiling issue, if you're given an image whose corners have known
> positions in physical space, there really isn't any alternative. Mapping
> the vertices to the centres of the corner pixels will result in a scaling
> change, which is a problem if it needs to align with other textures or
> with the geometry.
>

If you are working with texel=pixel, this is effectively the NEAREST result 
desired, and absolutely right.
But not when 1 texel > 1pixel.

-jbw 

On Sat, 25 Dec 2010 15:15:42 -0800, jbwest wrote:

>> However, trying to compensate for this brings up a number of issues. The
>> most significant of which is that, if you're going to offset the texture
>> coordinates by half a texel, texel sizes vary with the mipmap level, so
>> this basically rules out using mipmaps (i.e. any of the GL_*_MIPMAP_*
>> filtering modes).
> 
> Nope, because of the relationship of texels < pixels when mipmapped down
> to a lower res.

Can you explain what you mean here?

If you're rendering a polygon at constant depth (and thus constant LoD),
you can offset by half a texel of the finer mipmap level and guarantee
that the pixel centre will interpolate (not extrapolate) the next coarser
level. But that won't work if the LoD varies significantly; to avoid
extrapolation, you would have to adjust the texture coordinates according
to the LoD at each vertex.

The underlying problem is that mipmapping assumes pixel registration
rather than gridline registration, i.e. the levels have 1,2,4,8,...
samples to a side rather than 1,2,3,5,9,... samples.

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2010.12.26.02.36.08.875000@nowhere.com...
> On Sat, 25 Dec 2010 15:15:42 -0800, jbwest wrote:
>
>>> However, trying to compensate for this brings up a number of issues. The
>>> most significant of which is that, if you're going to offset the texture
>>> coordinates by half a texel, texel sizes vary with the mipmap level, so
>>> this basically rules out using mipmaps (i.e. any of the GL_*_MIPMAP_*
>>> filtering modes).
>>
>> Nope, because of the relationship of texels < pixels when mipmapped down
>> to a lower res.
>
> Can you explain what you mean here?
>
> If you're rendering a polygon at constant depth (and thus constant LoD),
> you can offset by half a texel of the finer mipmap level and guarantee
> that the pixel centre will interpolate (not extrapolate) the next coarser
> level. But that won't work if the LoD varies significantly; to avoid
> extrapolation, you would have to adjust the texture coordinates according
> to the LoD at each vertex.
>
> The underlying problem is that mipmapping assumes pixel registration
> rather than gridline registration, i.e. the levels have 1,2,4,8,...
> samples to a side rather than 1,2,3,5,9,... samples.
>


When mipmapping is in play (more texels than pixels). the small offset is 
irrelevant; you get the same texel whether you use 0 or 0 + epsilon. The 
epsilon is always less than 1/2 a texel so they produce the same result. The 
1/2 offset is only significant when # pixels > # texels.

jbw