Wouldn't it be possible to apply a pixel shader that does the tiling even though there is a texture atlas? Then tiling would be possible in both directions! The pixel shader would have to do the wrapping of u and v. Fabian Giesen (rygblog) wrote at http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-g... "Some of the API state may actually end up being compiled into the shader – to give an example, relatively exotic (or at least infrequently used) features such as texture borders are probably not implemented in the texture sampler, but emulated with extra code in the shader"

You certainly could, but this trades off fill cost against polygon count. I.e. you're using more complex calculations per-pixel for a smaller number of per-vertex/per-polygon computations.

It'd be interesting to look into the question empirically of whether this optimization would be worthwhile.

Also it depends somewhat on the specifics of the application. Two factors come to mind:

(1) Draw distance (drawing many faraway polys that are only a few pixels on-screen probably favors poly-count reduction more)

(2) Extra pixel shader complexity. If you're doing fancy per-pixel stuff with lighting or shadows or whatever, your optimization should become more attractive, because starting with your optimization and adding that extra stuff reduces the percentage of the per-pixel computation that's spent on your optimization.

You could probably deal with this by using a little extra space in the texture atlas

I don't know how well non-power-of two texture coordinates work in GLES and WebGL, but you could put a single column of pixels from the other side of the texture on both sides.

say you have ABCD and so you store, DABCDA, it'd use up some memory but could result in a speed boost since you could likely avoid breaking the normal mipmapping and such. I don't think you'd have to go as far as having half the texture on either side, but it'd be worth experimenting.

> In practice you need a texture atlas (...)to reduce number of meshes.

I believe you meant "to reduce number of texutre swaps"? Otherwise I fail to find how texture atlas is helping in reducing number of meshes in the drawn scene.

> But if you use texture atlas you can't combine surfaces like in the article.

Actually you can, pixel/fragment shader can be used later on to transform texture coordinates just before the texel value will be fetched (obviously this is only possible if you use shaders, but most games nowadays do).

I mean it reduces number of glDrawElements or glCallList calls.

If you have 256 different block types in 1 chunk, using texture atlas there's only 1 mesh instead of 256 different meshes.

https://docs.google.com/viewer?url=http%3A%2F%2Fnvidia.com%2...

Oh ok, I haven't thought about it this way. You are surely right.

I think he's suggesting you need a texture atlas if you have multiple terrain types, so that different areas of the merged-quad mesh might need different textures applied to it. You could get around that with multiple texture lookups and shader work, but the atlas is probably better most of the time.

Very insightful, thank you.

Are there no alternative to texture atlases? It seems weird to restrict yourself to merging in only one direction just because the representation of your texture won't allow it.

As for the bleeding, I suppose it's because the scaling kernel overlaps between the tiles in the atlas? Won't reducing the level of mipmapping degrade overall performances?

It seems weird to me that there's no better hardware support for texture atlases if it's so popular.

Modern hardware does not need texture atlases as it can use a different texture for every pixel. Texture atlas is a workaround for the API that only allows one set of textures per primitive and imposes a huge overhead on each primitive at the same time (e.g. OpenGL, DirectX).