Hi Chieling,
The map definition file you sent me showed your project had a 8192x8192 pixel heightmap with a 4x resolution texture map (i.e. 32,768 x 32,768 pixels). Is this the project you're having trouble with?
If so, the answer is quite straightforward. The 'pitch' field in a DDS image format is a 32-bit unsigned integer that must be set to the value of the number of bytes in the uncompressed top-level mipmap. For you map, that is equal to the texture map size (32,768 x 32,768 pixels) times the size of a RGBA element (4 bytes), which works out at the princely sum of 4,294,967,296 bytes. However, the maximum value allowed in a 32-bit unsigned integer (including the ones in the DDS image header) is 4,294,967,29
5 (or in binary, 11111111111111111111111111111111). That is to say, the DDS image format, as designed by Microsoft, cannot support images that are 32768 x 32768 pixels in size or larger. This explains why the 'GFXD3D9TextureManager' module complains about the pitch mismatch; attempting to store the 'correct' value of 4,294,967,296 for this texture size results in a wraparound to 0.
I will now modify the DDS exporter to refuse to export if the image is larger than the maximum possible size supported by the DDS format.
In any event, as I said in my e-mail, T3D doesn't support 'large' unique textures. T3D loads the DDS images directly into GPU memory as a single texture unit, and the maximum texture size on most graphics cards would be 4096x4096 or maybe 8192x8192 pixels. Hence,
even if the DDS image format supported a texture 32,768 x 32,768 pixels in size, your graphics card wouldn't, and thus T3D doesn't.
To use large terrain in T3D, your options are either:
- Use blended textures instead of L3DT's unique texture. To do this, rename or delete the '[your TER file]_basetex.dds' file. T3D should then load the terrain and use run-time texture splatting to texture the terrain instead of using L3DT's pre-calculated texture. This probably won't look as good, but that's a T3D implementation detail that is beyond my control.
- Split your terrain into separate TER tiles and render them using separate instances of the T3D terrain renderer. This is a non-trivial amount of work, but I believe some T3D users have had success with it. You may wish to have a look around the T3D forum for examples of this.
Since this isn't a bug in L3DT, I'm moving this thread to the 'Help and support' forum.
Best regards,
Aaron.
Edit: Hmmm...I may be a tad wrong about the pitch filed in a DDS header. Upon more careful reading of the specs and my code, it seems that the pitch field in compressed images is interpreted as the number of bytes used to store the 0th mip level in the compressed DXT
n format. This is number is smaller than the 32-bit limit for your texture (by a factor of 8), so it should be stored in the DDS header OK. However, if DirectX back-computes the number of raw bytes required to store the texture in memory and uses a 32-bit integer to do so (as may be a reasonable assumption), it will get the overflow error described above. Furthermore, regardless of any discussion of integer value ranges, T3D still will not be able to load a unique texture of that size into GPU memory, so my above recommendations still stand. Anyway, I'll run some DDS tests to make sure all is as I have stated.