12

Let's say we have a texture (in this case 8x8 pixels) we want to use as a sprite sheet. One of the sub-images (sprite) is a subregion of 4x3 inside the texture, like in this image:

enter image description here

(Normalized texture coordinates of the four corners are shown)

Now, there are basically two ways to assign texture coordinates to a 4px x 3px-sized quad so that it effectively becomes the sprite we are looking for; The first and most straightforward is to sample the texture at the corners of the subregion:

enter image description here

// Texture coordinates

GLfloat sMin = (xIndex0                  ) / imageWidth;
GLfloat sMax = (xIndex0 + subregionWidth ) / imageWidth;
GLfloat tMin = (yIndex0                  ) / imageHeight;
GLfloat tMax = (yIndex0 + subregionHeight) / imageHeight;

Although when first implementing this method, ca. 2010, I realized the sprites looked slightly 'distorted'. After a bit of search, I came across a post in the cocos2d forums explaining that the 'right way' to sample a texture when rendering a sprite is this:

enter image description here

// Texture coordinates

GLfloat sMin = (xIndex0                   + 0.5) / imageWidth;
GLfloat sMax = (xIndex0 + subregionWidth  - 0.5) / imageWidth;
GLfloat tMin = (yIndex0                   + 0.5) / imageHeight;
GLfloat tMax = (yIndex0 + subregionHeight - 0.5) / imageHeight;

...and after fixing my code, I was happy for a while. But somewhere along the way, and I believe it is around the introduction of iOS 5, I started feeling that my sprites weren't looking good. After some testing, I switched back to the 'blue' method (second image) and now they seem to look good, but not always.

Am I going crazy, or something changed with iOS 5 related to GL ES texture mapping? Perhaps I am doing something else wrong? (e.g., the vertex position coordinates are slightly off? Wrong texture setup parameters?) But my code base didn't change, so perhaps I am doing something wrong from the beginning...?

I mean, at least with my code, it feels as if the "red" method used to be correct but now the "blue" method gives better results.

Right now, my game looks OK, but I feel there is something half-wrong that I must fix sooner or later...

Any ideas / experiences / opinions?

ADDENDUM

To render the sprite above, I would draw a quad measuring 4x3 in orthographic projection, with each vertex assigned the texture coords implied in the code mentioned before, like this:

// Top-Left Vertex
{ sMin, tMin };

// Bottom-Left Vertex
{ sMin, tMax };

// Top-Right Vertex
{ sMax, tMin };

// Bottom-right Vertex
{ sMax, tMax };

The original quad is created from (-0.5, -0.5) to (+0.5, +0.5); i.e. it is a unit square at the center of the screen, then scaled to the size of the subregion (in this case, 4x3), and its center positioned at integer (x,y) coordinates. I smell this has something to do too, especially when either width, height or both are not even?

ADDENDUM 2

I also found this article, but I'm still trying to put it together (it's 4:00 AM here) http://www.mindcontrol.org/~hplus/graphics/opengl-pixel-perfect.html

Nicolas Miari
  • 16,006
  • 8
  • 81
  • 189
  • Comment: Personally, I don't think the behavior of textures _changed_ between iOS 4 and iOS 5 (it should be part of the GL ES 1.1/2.0 spec); It's just that I got that impression from my experience. Must be wrong, I know, but still puzzled... – Nicolas Miari Jul 12 '12 at 17:41

1 Answers1

10

There's slightly more to this picture than meets the eye, the texture coordinates are not the only factor in where the texture gets sampled. In your case I believe the blue is probably what want to have.

What you ultimately want is to sample each texel in center. You don't want to be taking samples on the boundary between two texels, because that either combines them with linear sampling, or arbitrarily chooses one or the other with nearest, depending on which way the floating point calculations round.

Having said that, you might think that you don't want to have your texcoords at (0,0), (1,1) and the other corners, because those are on the texel boundary. However an important thing to note is that opengl samples textures in the center of a fragment.

For a super simple example, consider a 2 by 2 pixel monitor, with a 2 by 2 pixel texture.

If you draw a quad from (0,0) to (2,2), this will cover 4 pixels. If you texture map this quad, it will need to take 4 samples from the texture.

If your texture coordinates go from 0 to 1, then opengl will interpolate this and sample from the center of each pixel, with the lower left texcoord starting at the bottom left corner of the bottom left pixel. This will ultimately generate texcoord pairs of (0.25, 0.25), (0.75,0.75), (0.25, 0.75), and (0.75, 0.25). Which puts the samples right in the middle of each texel, which is what you want.

If you offset your texcoords by a half pixel as in the red example, then it will interpolate incorrectly, and you'll end up sampling the texture off center of the texels.

So long story short, you want to make sure that your pixels line up correctly with your texels (don't draw sprites at non-integer pixel locations), and don't scale sprites by arbitrary amounts.

If the blue square is giving you bad results, can you give an example image, or describe how you're drawing it?

Picture says 1000 words:

img

genpfault
  • 51,148
  • 11
  • 85
  • 139
Tim
  • 35,413
  • 11
  • 95
  • 121
  • I din't understand which one you are trying to recommend; first you suggest to "sample each texel at the center", but then you recommend the blue method? Why would openGL sample from 0.27 to 0.75 when I specify 0.0 to 1.0? I thought I had to specify myself the coords at the center of each texel (red example), and that the boundaries themselves are at 0.0 and 1.0? – Nicolas Miari Jul 12 '12 at 18:48
  • Also, if I specify a tex coord of (say) 0.0, it will sample between the first pixel in the texture image and the 'outside' (black - assuming no wrap), which is either 'color' or 'black' in 'nearest' mode, and a mix of both in 'linear' mode (which you also seem to mention)...? – Nicolas Miari Jul 12 '12 at 18:51
  • 1
    @ranReloaded I added an image to hopefully explain it better. Let me know if that makes more sense. – Tim Jul 12 '12 at 21:20
  • You are the man! So the bottom line is: I don't need to add the 0.5/(side size) offset to the tex coords, because it is already accounted for in the raster/fragment phase. It makes perfect sense now: Even though the vertices lie on the edges of the grid, the texture is sampled according to each fragment's center. – Nicolas Miari Jul 12 '12 at 21:42
  • So the only cause left is, perhaps some of my sprites have odd sizes, and with their centers clamped to integer x and y, the corners en up in non-integer pixel positions. I must check my snap-to-grid algorithm. – Nicolas Miari Jul 12 '12 at 21:54
  • 1
    Yeah sounds like it. If you said you were drawing a quad from -0.5 to 0.5 and then scaling it, it might end up on non-pixel boundaries. Just make sure that all of your quads vertices lie on integer pixel edges. – Tim Jul 12 '12 at 21:55
  • Just to confirm: Texture parameters for sprite rendering are 'Nearest' filters, and no wrap, right? Am I missing something? – Nicolas Miari Jul 13 '12 at 08:16
  • @ranReloaded : that sounds fine to me. What do you mean 'am I missing something?' – Tim Jul 13 '12 at 21:06
  • I meant perhaps there's some other texture parameter/configuration I am forgetting. I think not, but just to be sure... – Nicolas Miari Jul 14 '12 at 06:22