   Texture atlas headaches
  I'm using a texture atlas for my terrain but the texturing quality I'm getting is quite poor.  I'm basically using an approximation of mipmap level selection using this method:float2 dx = ddx(coords * 512);float2 dy = ddy(coords * 512);float lod = max(dot(dx, dx), dot(dy, dy));lod = log2(sqrt(lod));I've been tweaking things for a couple of weeks now and whilst the results are okay, they aren't anywhere near as good as just using a normal texture (non-atlas) and letting D3D9 choose the mip level (with tex2D).I really want to use texture atlases as I can't really determine at runtime how many textures are required per draw call - is there a better way using DirectX9?Or, is there a more accurate method of selecting the MIP level than that above?  I can't use tex2D for 2 reasons; 1) some of this is within a dynamic branch and 2) linear filtering causes issues along edges at higher mip levels.Thanks   
Quote:float2 dx = ddx(coords * 512);float2 dy = ddy(coords * 512);float lod = max(dot(dx, dx), dot(dy, dy));lod = log2(sqrt(lod));why dont you just use the dedicated texture sampling function for that? http://msdn.microsoft.com/en-us/library/bb509679(VS.85).aspxQuote:I really want to use texture atlases as I can't really determine at runtime how many textures are required per draw call - is there a better way using DirectX9?use 3d textures instead of texture atlasses, the hardware will handle wrapping etc.Quote:Or, is there a more accurate method of selecting the MIP level than that above?  I can't use tex2D for 2 reasons; 1) some of this is within a dynamic branch and 2) linear filtering causes issues along edges at higher mip levels.that's why tex2Dgrad was invented.But in general you shall not use dynamic branching for something simple like terrain texturing, that shall be handled at a higher level, you can1. use a static amount of layers and just select them dynamically.2. you can use static branching per terrain-block3. you can use multipass (and it shouldn't be slower as you're probably anyway shader limited), it might, due to culling, be even faster!;  Funnily enough, I tinkered with volume textures last night but I couldn't get the mipmaps to work.I just basically created a volume texture (with one level as a first test), filled the data and attempted to call GenerateMipSubLevels.  The highest LOD level renders fine, but what gets rendered instead of LOD level 1+ looks like random data.If I'm going to head down the volume texture route, any ideas why mipmaps don't autogenerate?  I'm creating my volume texture like this:hr = D3DXCreateVolumeTexture(device, 512, 512, 1, 10, D3DUSAGE_DYNAMIC, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &volTex);// LockBox and fill with data// UnlockBoxvolTex->GenerateMipSubLevels();Wrong forum probably, but it's kind of linked...Thanks   ;  3D textures don't work the way you want with mipmaps since it would mip all 3 dimensions, but you only want the first 2. What you'd need is a texture array, but that's DX10. Also, all textures must be of the same size, but that might be not an issue for you.A problem for you might be that using tiling texture atlases is very tricky with mips since the straight-forward way to compute the tex coords will result in very visible seams. You actually have to adjust the range of tex coords per lod (that's why you have to compute the lod!).Another issue is that you have to repeat the last row and column of each tile texture and you'll have to do that for each LOD individually, otherwise you'll get seams.Conclusion: Tile texture atlasing is a huge pain. Try to go without it if you can.   ;  with mipmpas you'll endup again in manually selecting the mip level from your 3d texture, yeah, I know, that sucks and probably eat ups nearly all benefits (except of the amount of textures that you can store in just one 3d volume).;Quote:3D textures don't work the way you want with mipmaps since it would mip all 3 dimensions, but you only want the first 2. What you'd need is a texture array, but that's DX10. Also, all textures must be of the same size, but that might be not an issue for you.Thanks, Lutz, I eventually found some info on them (there's really not a lot of info out there on volume textures), and came to the same conclusion.Back to the texture atlas and I've just discovered why mine doesn't look good enough, I'm using tex2Dlod which doesn't work with AF (I only found this info in one place and it wasn't even in official docs).  So I'm going to try tex2Dgrad (which does work with AF apparently) and move my dynamic branching up to the chunk level (thanks, Krypt0n).Quote:A problem for you might be that using tiling texture atlases is very tricky with mips since the straight-forward way to compute the tex coords will result in very visible seams. You actually have to adjust the range of tex coords per lod (that's why you have to compute the lod!).I don't have any seams now (after what seams like days of tweaking!)]Thanks   ;  Ok, so I don't have seams when using tex2Dlod and calculating the mip level manually (and adjusting the coordinates), but everything looks too blurred because anisotropic filtering doesn't work with tex2Dlod.  Replacing it with tex2Dgrad is so slow that it's practically unusable (plus I still get seams) and however much I mess around with the coordinates and use tex2D I _always_ get seams.I can't believe that you can't get rid of these texture seams when tiling using an atlas.  I'd be surprised if it's the GPU's fault as I'm using a latest gtx295 and I'd be even more surprised if Microsoft hadn't gotten round this issue in an api as relatively recent as DirectX9 (nov07).  Surely nearly all games that have an outdoor environment have needed to use some kind of texture atlasing/compression?In my endless days of tinkering to see why I'm getting seams, I created an atlas (4096x4096) with just one repeating seamless texture (512x512) all over it, so you'd think that wherever I put my coordinates, I wouldn't get seams - wrong.  Choosing a 512x512 section in the atlas that lines up correctly still gives me these damn seams and they're a totally different colour to anything in the atlas.It happens when I do any kind of multiplication to the coords passed in to the pixel shader.  The coords I'm passing in are the vertex positions of the grid, so I'd need to do some kind of frac on them to get them inline and some kind of mulitplication to single out my chosen tile within the atlas.  Frac or multiplication causes 'discontinuities' - apparently.If I had to go down the multiple pass route, surely that would crucify my frame rate as I might have 20+ textures in view at once and I'd need to draw my terrain (at least the bits with detailed textures) ~20 times?Before I throw in the towel and bin all the hard work I've done on getting my terrain rendering super-efficiently, does anyone have any experience or info on how I could get round this?  I can't believe there isn't a solution..Thanks in advance   ;  I'm using OpenGL now and the situation there is slightly better because texture arrays can be used on SM4 hardware. But for SM3 it's the same problem - tex2Dlod can't do anisotropic, tex2Dgrad isn't supported or is too slow, then there are multiple passes, or maybe something that could be done with 3D textures, but basically everything is slowing down that already older and slower platform.So I think that SM3 hw will be either slow or ugly and that's it. But I reckon for you the situation is worse - with directx that would mean compromising the entire windows xp userbase, even with SM4 hardware [depressed]