It still doesn't work. Is this the correct way to do it? Do I need blending for this to work? If I offset the tiles to make sure they're snapped to the pixel grid it works, but that makes it snap when moving slowly. How do people usually solve this?

Obvious questions first, are you taking those borders into account when generating the UVs? Seems like they'd be good to get rid of, just duplicate the tile's edge pixels out.
–
ssubeOct 25 '11 at 20:11

@peachykeen yes, the first 64x64 tile is positioned at 1,1 so the UVs will go from (1/1024,1/1024) to ((1+64)/1024, (1+64)/1024), if the whole texture is 1024. Do you think that duplicating the border pixels instead of adding transparency will work better?
–
user408952Oct 25 '11 at 20:32

My guess is it's related to filtering, pixel->voxel mapping, or something along those lines. If so, duplicating them will hide the issue, if no other fix is available. Before you resort to that, though, try to make sure your uv coords and filtering line up properly.
–
ssubeOct 25 '11 at 20:51

5 Answers
5

Your border shouldn't be transparent, but rather the pixels from the opposing side of each subtexture. For example the border on the right hand side of each sub-texture should be a copy of the left-most line of pixels, i.e. the pixels that it would wrap around to.

That is how you "cheat" wrapping for the texture sampler on the borders.

I did this, but added a copy of the rightmost column to the right side, instead of the transparent border. I did this because the tiles don't wrap (e.g. the middle, top one in the tile image in the post. That has sand to the left and stone to the right). This makes it look kinda ok, at least with the iphone 4 resolution.
–
user408952Oct 26 '11 at 19:02

Thank you so much! My models are looking a LOT better now :-)
–
Lea HayesApr 16 '12 at 16:39

So what about the corners of the texutres, what should they be?
–
paulmApr 1 '14 at 21:40

The pixel from the corner diagonally opposite
–
HanneshApr 3 '14 at 15:43

I had a similar issue with a texture atlas. I fixed it by insetting the image by 1.0/TEXTURE_ATLAS_PIXELS_PER_SIDE * 1/128.0. The 128 number you need to figure out by experimentation. The upside for me is no one is going to perceive 128th of a pixel being missing. I made this modification to the texture coordinates being sent to the graphics card and not in a shader. I have not tried doing this with texels in the shader, like you have. I've read different information on how to handle texture bleeding but for a texture atlas this was the easiest solution for me. Adding borders to my textures which are tightly packed and follow the power of two rule would cause me to have a lot of whitespace.

Can u explain in more detail? May be u can provide some manuals? thanx
–
Sergey KopanevApr 28 '12 at 8:29

I think he means what I did. In my case I have a 256x256 png which is a 16x16 grid of 16x16 pixel textures. Say you're determining texture coordinates for the top left texture, from pixel 0,0 to 16,16 (or really 15,15). Instead of using s,t coordinates 0,0 and 1/16,1/16, you use, say 0.001,0.001 to 1/16-0.001,1/16-0.001. Make sense?
–
GrumdrigSep 11 '12 at 19:34