4 ms·

In practice you need a texture atlas (http://en.wikipedia.org/wiki/Texture_atlas http://en.wikipedia.org/wiki/Texture_atlas) to reduce number of meshes. But if

by exemd 13y ago

In practice you need a texture atlas (http://en.wikipedia.org/wiki/Texture_atlas http://en.wikipedia.org/wiki/Texture_atlas) to reduce number of meshes. But if you use texture atlas you can't combine surfaces like in the article. The solution is to create 1 dimensional texture atlas like this: http://manicdigger.sourceforge.net/webgl/data/atlas1.png http://manicdigger.sourceforge.net/webgl/data/atlas1.png. Then tile in only 1 direction. Minecraft does it and I first read about it in one of Word of Notch posts - http://notch.tumblr.com/post/176620207/i-rewrote-the-tesselator http://notch.tumblr.com/post/176620207/i-rewrote-the-tessela.... It's good enough. Manic Digger (http://manicdigger.sourceforge.net http://manicdigger.sourceforge.net) has great framerate at Pentium 4 and Geforce 2 MX. But there is one problem: in mipmaps there is bleeding between individual textures. The solution is to use: glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 4); It's good on desktop, but there is no GL_TEXTURE_MAX_LEVEL on OpenGL ES and WebGL! I guess it must be done with custom mipmaps or with a pixel shader?

deleted 13y ago
[deleted]
simias 13y ago
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.
- deleted 13y ago
  [deleted]
- pandaman 13y ago
  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).
mbel 13y ago
> 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).
- NickPollard 13y ago
  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.
- exemd 13y ago
  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%2Fdocs%2FIO%2F8230%2FBatchBatchBatch.ppt https://docs.google.com/viewer?url=http%3A%2F%2Fnvidia.com%2...
  - mbel 13y ago
    Oh ok, I haven't thought about it this way. You are surely right.
atesti 13y ago
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-graphics-pipeline-2011-part-1/ 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"
- picomancer 13y ago
  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.
simcop2387 13y ago
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.
- deleted 13y ago
  [deleted]

by exemd 13y ago

deleted 13y ago

[deleted]

simias 13y ago

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.

deleted 13y ago
[deleted]
pandaman 13y ago
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).

mbel 13y ago

> 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).

NickPollard 13y ago
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.
exemd 13y ago
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%2Fdocs%2FIO%2F8230%2FBatchBatchBatch.ppt https://docs.google.com/viewer?url=http%3A%2F%2Fnvidia.com%2...
- mbel 13y ago
  Oh ok, I haven't thought about it this way. You are surely right.

atesti 13y ago

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-graphics-pipeline-2011-part-1/ 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"

picomancer 13y ago
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.

simcop2387 13y ago

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.

deleted 13y ago
[deleted]