I am using a texture atlas of 512x512 pixels; which means each of the 4 images is 128x128 pixels in size.

Ok it's definitely something to do with the linear sampling and mip-mapping, I have read a bit more about this, apparently because I'm using a texture atlas, the changes between the texcoords are changing so rapidly that it confuses the mip-map level selection. Although I don't entirely understand this, I have discovered the function SampleGrad and SampleLevel (I'm using shader model 4).[/quote]Yeah, when you sample a texture, the hardware measures the rate-of-change of the tex-coords, and uses that info to select a mip level. When you do your manual texture-wrapping logic, you're having a big effect on the rate-of-change at the edges.
It would help if you posted up some of your shader code, but I'll just pretend this is your code ;)float2 uv = input.uv;
uv = /*do wrapping / atlas logic*/
float4 colour = tex.Sample( S, uv )
What the driver does with that code, is basically turn it into this:float2 uv = input.uv;
uv = /*do wrapping / atlas logic*/
float2 ddx_uv = ddx(uv);
float2 ddy_uv = ddy(uv);
float4 colour = tex.SampleGrad( S, uv, ddx_uv, ddy_uv );The problem is that it's done it's rate of change calculations after you've done your wrapping logic.

You can fix it by doing the rate-of-change calculations yourself at the appropriate stage:float2 uv = input.uv;
float2 ddx_uv = ddx(uv);
float2 ddy_uv = ddy(uv);
uv = /*do wrapping / atlas logic*/
float4 colour = tex.SampleGrad( S, uv, ddx_uv, ddy_uv );

The 0.01f offset is added to the start or deducted from the end of every single generated tex-coord to simulate a border, it also should mean that sampling done by linear samplers do not pick pixels outside of the texture
So that would be 0.01f x 256, which is 2.56 pixels for each border, giving me a 3 pixel border for each texture yeah?

You see I'm generating the tex-coords when I generate the mesh; it's not how I want to do it - I have always considered this an unnecessary approach to texturing as all of those 'duplicate' tex-coords are being stored against each vertex which is a massive waste of memory. [/quote]Does this mean you're breaking a flat surface up into lots and lots of polygons?
Yeah, that's sub-optimal these days, but it does mean that your only problem is the fact that your border is too small. All that ddx/ddy/SampleGrad stuff doesn't matter if your tex-coords have been pre-generated like this.


The larger you make your borders, the further down the mip-chain you can go before you start getting bleeding issues.
To be really safe, you could split your 512x512 target nto four 256x256 quadrants. Take each quadrant and put a 128x128 sized texture in the centre, with a 64px border around it.
i.e. if you r 128px texture looks like this:TL|TM|TR
ML|MM|MR
BL|BM|BRThen your 256px version with borders looks like this:BR|BL|BM|BR|BL
TR|TL|TM|TR|TL
MR|ML|MM|MR|ML
BR|BL|BM|BR|BL
TR|TL|TM|TR|TL



If you wanted to do the tex-coord generation inside your shader, instead of doing it in advance, you can do it in your pixel shader as follows. This is assuming the above layout of a 512px atlas with 128px textures and 64px border areas.

Vertex Shader
struct VS_INPUT
{
float3 position : POSITION;
float3 normal : NORMAL;
float2 texcoord : TEXCOORD0;//regular tex-coords, as if you were using regular (non-atlas) textures
float2 atlasSector : TEXCOORD1;//either (0,0), (1,0), (0,1) or (1,1) -- which part of the atlas to use
};
struct VS_OUTPUT
{
float4 position : SV_POSITION;
float2 texcoord : TEXCOORD0;
float2 atlasSector : TEXCOORD1;
};
VS_OUTPUT vsMain(in VS_INPUT vIn)
{
VS_OUTPUT vOut = (VS_OUTPUT)0;
vOut.position = mul(float4(vIn.position, 1.0f), WorldViewProj);
vOut.texcoord = vIn.texcoord;
vOut.atlasSector = vIn.atlasSector;
return vOut;
}
Pixel Shader
float4 psMain(in VS_OUTPUT vOut) : SV_TARGET
{
float2 uv = frac(vOut.texcoord);//perform wrapping into the 0.0 to 1.0 range
uv *= 0.25;//resize from a 512x512 area to a 128x128 area
uv += float2(0.125, 0.125);//offset by the 64px border
uv += vOut.atlasSector * 0.5;//offset into the desired quadrant
vOut.color = groundTex.SampleGrad(s0, uv, ddx(vOut.texcoord*.25), ddy(vOut.texcoord*.25));
return vOut.color;
}