Hey I just want to share a bug fix that fixes a texture seam problem I've had for a while.

See this post:
http://www.gamedev.net/topic/602143-tex ... eam-issue/

screens:

First image shows the fix. The visible seam in that is part of the texture. Second image shows the problem.

http://imgur.com/JRXAm&qQBPE

The problem:
Basically because I'm generating my uv in shader based on world position, it's confusing the mip map selection process resulting in seam on every cubic block. My solution (this is but one possible solution) is to use ddx,ddy on the world position themselves and pass it to the function tex2Dgrad(). The trick is to select the correct component based on which face you are facing. If you use texture atlas and the cubic extractor you are doing this already. Anyway, here is the code:

http://pastebin.com/kupaj0Xh

To use:

[code]
float4 Tex2DAtlas(sampler2D tex, float2 uv, float4 dxdy)
{
return tex2Dgrad(tex, uv, dxdy.xy, dxdy.zw);
}
[/code[

I saw this go past on your blog - it's good to have a proper fix for it. So do you now have any artifacts left from the use of texture atlases or have you fixed them all?

I had two issues while using that modified Nvidia atlas tool from Ogre (http://www.ogre3d.org/forums/viewtopic.php?f=4&t=61602), 1) seam, and 2) no texture greater than 4096. #1 is fixed. #2 is if you want to use a texture say 256, the tool reduces that by half, which effectively means your tex. is now 128. So you say let's increase the texture size to 512. But if your total atlas dimension exceed 4096 the tool refuses to run saying atlas size must be power of two when in fact your atlas is power of two. A bug with the tool basically.

However I don't really want to do it like that if I don't have to. I don't want to make a 1024 texture then have it reduced to 512. That's what you get if you use the Ogre's solution. Maybe another way to resolve this (off the top of my head) is do it like mega textures, duplicating just enough so filtering is correct. The trick I guess is fitting as many textures as possible into a power of two atlas (without reduction by half thing) or something like that.

actually this didn't solve my problem. It did resolve it for a single texture, for atlas it just won't work no matter what I do. What I found in the end is that if you use fract() in the shader to generate texture coordinates you still get seams no matter what. This is because pixel shaders work with 2x2 pixel neighborhoods for everything. I tried several tricks in order to get rid to no avail, I even tried having the entire texture be the same color, still seam (this points to problems with the hardware). In the end the way I got rid of the seam is to pass in UV coordinates. Believe me I've looked at post after post detailing the solution to this seam problem, even though they don't explicitly say they pass in the UV they all assume this. (well I found one post that was having the same problem I was having, and no matter what he tried he also got seam no matter because he was generating textures in the shader with fract.) In my case this works fine because I already use one set of texture coordinates to pass in material in a vector4, leaving me with a vector3 for actual uvs.

Edit: Here are the bookmarked links I have on this problem. You may have more luck with it. I'm not looking into it further I will just pass in uvs and be done with it.

http://www.gamedev.net/topic/602143-tex ... eam-issue/
http://www.gamedev.net/topic/534149-sol ... reenshots/
https://bitbucket.org/masterfalcon/ogre ... Atlas.hlsl
http://www.gamedev.net/topic/491189-emu ... ure-atlas/
http://www.gamedev.net/blog/73/entry-16 ... explained/

Is there a specific reason you use texture atlas? I ask because I just pass 6 different texture channels and choose texture based on the normal calculated in the vertex shader.

I know it is said using conditional statements in the pixel shader is slow, but I have never really noticed any difference in speed between my single-texture version (no conditional statement), and my 6-texture version (6 conditional statements).

Then again, I have never rendered more than probably a few thousand quads and maybe 16 voxel materials at once.

Given all the difficulties everyone seems to be having, is there a particular advantage in using texture atlas over a conditional shader using multiple texture channels?

If I understand you correctly you have extracted meshes per single type of voxel material, each of these single material mesh has 6 texture binds which you select in the pixel shader using conditional branching depending on which face the cube is facing? That would work, but from what I understand you can expect to have only 8 texture slots per pixel shader. That wouldn't fit in case you need normal maps and gloss maps. (3x6 textures.)

If you don't care about DX9 you can use texture arrays. Texture arrays gets rid of all the stupid problems with texture atlas, basically.

Another option that I've looked at is megatexture / sparse virtual texturing. In this scheme, you would use it as a texture atlas, by this I mean putting your NxN texture atlas into a sparse virtual texture and generate the associated mip maps and look up table. You may run into problems with needing to constantly page out least recently used pages because the texture atlas may not fit into virtual texture "ram" because you are randomly accessing the texture atlas (vs. in a normal spare virtual texture you get locality of reference). But this can be mitigated by using multiple textures as the working "ram" for sparse texturing. However, you will still get seams if you generate texture coordinates in shader because of the 2x2 pixel neighborhood problem with discontinuities (no I really don't have proof that this is the actual issue, all I can say is if I pass in UVs I get no seams). Virtual texturing is basically a fancy scheme for mapping uvs into some other space through a texture look-up, so if your input is garbage.... you know what they say, garbage in garbage out. That's my theory anyway.

These texture atlases are really a pain, huh. As discussed there are other solutions (different texture units, using slices of a volume texture, etc) but they all have problems. I think texture arrays are the only solution which work 100%. You would also have the option to break up the mesh and draw each material as a seperate batch but of course this will raise your batch count. To be honest I think you've done a pretty good job with the atlases.

@DefiniteIntegral - I think the main limitation with multiple texture units is the number of texture which you can support. The exact limit will depend on your hardware, but it won't match the hundreds you can fit in an atals. Oh, and don't worry too mauch about the conditional branching. It's generally OK if adjacent pixels tend to take the same path as they are processed in groups.

Thanks for that. I only plan to use per-vertex lighting anyway without any normal or specular maps so the 6 texture units are fine for my purposes.

After reading many posts about it on these forums I am glad I don't need to worry about texture atlases etc at the moment...

Just an update on the situation: I've resolved all the seam issues by moving to dx11/10 with Texture Arrays. Basically the problem (I think) was due to using fract() on worldPosition to generate UVs. The hardware doesn't like that. With texture array I can use hardware texture wrap and it just works. So does texture filtering....it just works without hacking your texture atlas. Also no STUPID MANUAL LOD calculation which was a major pain in the butt for me.

http://twitter.com/#!/fdastero/media/sl ... m%2F7n999l

Despite what I said about vertex lighting, I was thinking about switching to OpenGL + Texture Arrays myself. I just have no idea how to implement texture arrays when using Ogre3D. I know it is possible, there just seems to be basically no documentation about it.

Good work there.