I just discovered the border parameter in glTexImage2D which I find very useful for my needs (tiling a very large -4096x16384- texture in tiles of 2048x2048), and its associated GL_CLAMP mapping mode.
To my surprise, both are marked as deprecated in OpenGL 3.0, but I don't see any feature that would replace it for tiling.
Is there any other way to tile large textures, while keeping smooth filtering from one texture to the next ?
GL_CLAMP is not very useful for seamless tiling if you don't use borders. But if it suits you, then it's OK. GL_CLAM_TO_EDGE is not deprecated, and, it is my humble opinion, will better serves your purpose.
You can implement seamless tiling in fragment shader.
I understand this is little bit more complicated then using GL_CLAMP and texture borders.
Check if the texture coordinate is on the edge, then emulate border by sampling neighbor texture. You would have to emulate linear filtering on the edge yourself.
implementing seamless tiling in fragment shader sounds extreme, it requires providing 9 textures unit (main texture+4 borders+4 corners) and a bit of math in the shader. Just to have some tiling.
I think I will just use a NPOT texture with 2 additionnal rows/columns for each border, and simulate appropriate texture coordinate depending on GL_CLAMP or GL_CLAMP_TO_BORDER.
You can have the border in one additional texture.
No need to have 8 of them.
but I agree that if the textures are not dynamic it can be prepared in CPU.
The funny thing is that they just added GL_CLAMP style filtering back in -- but only for cubemaps: GL_ARB_seamless_cube_map.
Thus illustrating that there are conditions under which GL_CLAMP_TO_EDGE isn't good enough for seamless tiling....
That's not what seamless cubemap does. What it does is allow the cubemapping to sample across texture boundaries, from the edge of one texture to the edge of another. It has nothing to do with GL_CLAMP.The funny thing is that they just added GL_CLAMP style filtering back in -- but only for cubemaps: GL_ARB_seamless_cube_map.
Hi Alphonse,
To achieve seamless tiling with GL_CLAMP, you load the border texels with the just-inside-the border texels of the adjacent texture tiles. This allows the filtering sampling logic to work as if it were sampling from the adjacent tile.
Even better, you can pull this trick across all mipmap levels and is works perfectly because the 0..1 texture coordinates are always "just inside" the border texels.
This is effectively exactly what seamless cube map does. But the cube map logic is simpler because you don't have to explicitly specify the border texels. They are implicitly defined by the edges of the other faces of the cube.
Although you can treat the outer ring of a non-bordered texture as a pseudo-border, by shrink your texture coordinates inward, this doesn't work right for other mipmap levels, because the texture coordinates are not right.
I'm not saying you couldn't use GL_CLAMP for other purposes (after all, nobody is forcing you to define the border texels that way). But you can't get that seamless tiling effect *across all mipmap levels* with any other standard texture wrap mode.
Really GL_CLAMP was ingeniously designed -- but apparently it solved a problem that didn't need solving for most video games. [Edit: except for skyboxes].
And it is that difference, that GL_CLAMP requires border texels explicitly specified by the application and seamless cube mapping doesn't, that makes them entirely different. One of these is automatic, the other requires explicit work, takes up precious memory, and cannot be used with any form of texture compression.This is effectively exactly what seamless cube map does.But the cube map logic is simpler because you don't have to explicitly specify the border texels.
OkOne of these is automatic,
Only if you need to use it. And having a correct result is worth the little extra work.the other requires explicit work,
Are you kidding ?takes up precious memory,
Say you have a fully mipmaped 1024*1024 texels texture, this will only add 8232 texels for borders, about half percent of total texture...
The alternative is to manually duplicate content across textures and play with blended parts to hide seams. Talk about previous memory wasted.
That is right, one would need a compression accepting 2-divisible textures, or not compressing borders at all.and cannot be used with any form of texture compression
Posting Permissions
