Salem

Sublime as though my existence may seem, only the Lord can claim perfection; and lacking it, then, myself, there exist things that I do not know. As such, I thought I'd put together this little list of things that technically astute readers of the forums can help out with if they like.

• The client packs certain textures (tiles, particularly) into packed textures ("texture atlases", if you will). How does one properly use linear filtering or multisampling on such textures without risking having texels picked outside the intended subtexture?

(I'm pretty sure there are more than one thing that I've had in mind, but since I can't think of the others right now, I'll expand the list over time.)

loftar wrote:The client packs certain textures (tiles, particularly) into packed textures ("texture atlases", if you will). How does one properly use linear filtering or multisampling on such textures without risking having texels picked outside the intended subtexture?

I see different solution for this problem.

1. While packing textures into altas you can add 1px transparent border between them, so there will be no problems with filtering.
2. You can add(1, 1) to ul and sub(2, 2) from size of textures while binding it. So the pixels for filtering will be actually taken from this texture.
3. The best solution seems to use native glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_[S|T], *);

khronos.org wrote:GL_CLAMP causes s coordinates to be clamped to the range [0, 1] and is useful for preventing wrapping artifacts when mapping a single image onto an object. GL_CLAMP_TO_EDGE causes s coordinates to be clamped to the range [ 1/2N , 1 - 1/2N ] , where N is the size of the texture in the direction of clamping.

http://www.khronos.org/opengles/documentation/opengles1_0/html/glTexParameter.html

APXEOLOG wrote:1. While packing textures into altas you can add 1px transparent border between them, so there will be no problems with filtering.

That's what I'm doing right now, but depending on perspective, it doesn't merely sample the immediately adjacent texels, but sometimes even further from that. It also has the rather grievous problem of preventing mipmapping, since subtextures are no longer aligned to power-of-two-coordinates.

APXEOLOG wrote:2. You can add(1, 1) to ul and sub(2, 2) from size of textures while binding it. So the pixels for filtering will be actually taken from this texture.

While being more mipmap-friendly, I can only assume it would have the same sampling problems as above. (And due to decreasing texture coordinate resolution in higher mipmap levels, the sampling problem would grow worse on said higher levels.)

APXEOLOG wrote:3. The best solution seems to use native glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_[S|T], *);

khronos.org wrote:GL_CLAMP causes s coordinates to be clamped to the range [0, 1] and is useful for preventing wrapping artifacts when mapping a single image onto an object. GL_CLAMP_TO_EDGE causes s coordinates to be clamped to the range [ 1/2N , 1 - 1/2N ] , where N is the size of the texture in the direction of clamping.

Well, the problem with that is indeed that it clamps to [0, 1], which is the range of the entire texture atlas, not the sub-parts of it that are used for individual tiles.

loftar wrote:That's what I'm doing right now, but depending on perspective, it doesn't merely sample the immediately adjacent texels, but sometimes even further from that. It also has the rather grievous problem of preventing mipmapping, since subtextures are no longer aligned to power-of-two-coordinates.

Atlases are good for textures that repeated for many times. For example when i packed all tiles in HnH into one atlas i got about +60 FPS, and UI packing gives me nearly nothing. I think you don't need mipmaps for tiles.

Also i'm sure the solution exists because all android-based games uses atlases and they haven't got problems with it

Will it be feasible to generate texture for each mapcut and then apply filter/mipmaps to it? I know, it would eat more memory, but how much more?

Was watching a google IO presentation and they mentioned using a program called TexturePacker that does this automatically and handles border issues for you.

APXEOLOG wrote:I think you don't need mipmaps for tiles.

from an aesthetic standpoint, he does. imo.

EnderWiggin wrote:Will it be feasible to generate texture for each mapcut and then apply filter/mipmaps to it? I know, it would eat more memory, but how much more?

I have considered that, but come to the conclusion that the memory requirement is too much, at least if the current texture resolution is to be preserved. Each tile is currently 128x128, so a mapcut of 25x25 tiles would be 3200x3200 pixels, or ~40 MB. There being up to 144 mapcuts cached at one time, then, I think you will come to the same conclusion. ;)

sabinati wrote:

APXEOLOG wrote:I think you don't need mipmaps for tiles.

from an aesthetic standpoint, he does. imo.

I agree.

Then maybe have pre-generated mipmaps of whole atlas and then just map textures from appropriate atlas depending on distance to camera.

The problems with that are that 1) it's unnecessarily complex, both code-wise and performance-wise, and 2) it's not remotely as good, since the mipmap level must be chosen for an entire map-cut at a time, and not per fragment, and also precludes such things as anisotropic filtering.

One thing that would solve the problem for real is using array textures instead of packed textures, but those are unfortunately only available in programmed shader mode and even then only on newer cards.