For power of two textures, which texels reside at U/V coordinate(s) 0.5? Is it possible to have a texel reside at 0.5? I ask because an algorithm I'm working on needs to be able to access specific texel(s) when the U or V coordinate is 0.5.

Thanks in advance!

Edit: Found it. For example, a 256x256 texture it's the 129th texel on the U/V axis.

Texture coordinate 0.5 is the middle of the texture, so if you have an even number of texels, the middle is the edge between two texels. The exact texel center of the n:th texel is at texture coordinate (n+0.5)/size (n is zero-based indexing of texels), which is where the texels color is defined. Sampling at this point gives you an unfilteted color value of the n:th texel no matter what filtering mode is active.

edit to your edit: No, 0.5 is not texel 129 in a 256 sized texture, it is the exact center between texel 128 and 129. If you get the color of the 129:th texel, then you are relying on rounding to round the exact edge of a texel to nearest upper texel, and you also assume nearest filtering. This is not something I would recommend; sample your textures properly if you need exact sampling behavior.

Thanks bob, neither worked unfortunately as I was trying to ensure that triangles that share an edge pick the same texel. I was getting a discrepancy of about +/1 1/256th which destroyed the algorithm so I instead clamped coords close enough to 0.0 or 1.0 to 0.0 and 1.0 respectively. I've done this programmatically in the fragment shader but will try a lookup table once I'm ready to make performance measurements. Unless there's another way?

What was is that didn't work? I only answered your question about what texel coordinate 0.5 addresses. Coordinates and rasterization rules are well defined and behaved in OpenGL. If you have a particular problem you need help solving, then I suppose I can assist you, but you need to describe what you're trying to do and what the specific problem is.

Hi Bob, I should've been clearer. I was not saying you were incorrect, rather neither approach resolved the issue I'm having with the discrepancy. Take a look at the diagram below:



Lets assume this is a subset of a larger mesh lying on the x/z plane (e.g. a height map). Each quad (pair of triangles) spans half of texture space, hence the U component (and V, not shown) incrementing by 0.5 at each vertex as is spans across the plane.

Triangles a and b share a common edge and thus a common U component. What I need is a way in the fragment shader to ensure that fragments on the boundary edge of tri a and b pick the same texel from a non-filtered, non-mip mapped lookup texture. I tried what you suggested as well as simply using 0.5 as the U (or V) component in the texture lookup. No matter what I do, I seem to be getting a slight discrepancy intermittently (in fact, I believe it may occur only when the U or V component is 0.25... 0.0, 0.5 and 1.0 are fine, I'll have to look at my code to be sure).

Hope that clarifies the situation and thanks for the help so far!

If you give the two triangles the same texture coordinate along the shared edge, they will not sample the same part of the texture. The rightmost pixel being rasterized for triangle A is not the same pixel as the leftmost pixel of triangle B, and so they will have different texture coordinates if they share coordinate at the edges, because the texture coordinate is interpolated across the triangles.

Ensuring that the two border pixel for triangle A and B sample the same texel is, I believe, going to be tricky unless the quads are screen aligned. In that case, you can simply extend the texture coordinate for A or B with 1/256. For arbitrary projections, this may be tricky. I cannot see a solution yet. But for any case, the edges of A and B cannot share the same texture coordinate, because they need to overlap to cover the same texel for two different pixels.

Hi Bob,

Yes, this is the very problem I've been having. As I am trying to sample a lookup texture to obtain values in the range of 0.0 to 1.0 (with 0,0 being the top-left of the tri pair quad and 1,1 being the bottom-right), the way I am clamping values ~0 and ~1 is to add more fragment shader instructions to achieve this. Profiling shows that my fragment shader has a very high ratio of ALU to texture instructions so I'm thinking I could shave off the clamping instructions by using a lookup texture which acceptors input in the 0...1 range and returns values in such a range. Input values > than ~0 and less than ~1 will (hopefully) output the same values as the input (depending on the lookup texture resolution, losing accuracy is only a problem for fragments that reside on primitive edges) but border texels (maybe 2 or 3 texels) will return 0 or 1 as they will have the same values as the edge texels. However, I need to do some more thorough profiling and tweaking to determine such optimizations (I am currently fill rate bound).