Hi CBFASI,
Thanks for the bug report. This is a longstanding issue with the way Sapphire renders high-resolution textures or textures with non-power-of-two resolution ratios, and can be avoided with the judicial selection of texture tile size or renderer patch sizes, as explained in this
user guide page.
To summarise, the terrain is split into a number of ‘patches’ (typically 64x64 heightfield pixels), and each patch must be covered by one,
and only one, texture tile. This means that the texture tile size must be equal to the patch size times the texture resolution, or be an integral multiple thereof.
If you haven’t noticed this problem in previous versions, I’m guessing it’s because you normally use a non-power-of-two texture resolution (e.g. 10x), and you normally don’t split the texture into tiles. In the latest version, L3DT may split the texture into tiles even if you don’t ask it to, in which case it will default to a tile size of 512px. This default will work properly for texture resolutions of 1x, 2x, 4x, and 8x, but will not work for texture resolutions larger than 8x, nor for prime-number resolutions (3x, 5x, 7x).
Assuming you’ve kept the default patch size in Sapphire, the allowed texture tile sizes as a function of texture resolutions are given below:
- Tex. res. = 1x, tile size = 64 or integral multiple (128, 256, 512, etc.)
- Tex. res. = 2x, tile size = 128 or integral multiple (256, 512, 1024, etc.)
- Tex. res. = 4x, tile size = 256 or integral multiple (512, 1024, 2048, etc.)
- Tex. res. = 8x, tile size = 512 or integral multiple (1024, 2048, etc.)
- Tex. res. = 10x, tile size = 640 or integral multiple (1280, 2560, etc.)
- Tex. res. = 16x, tile size = 1024 or integral multiple (2048, etc.)
- Tex. res. = 32x, tile size = 2048.
If you’re using an odd texture resolution not mentioned above (e.g. 7x), you can calculate the required tile size using the formula already mentioned (patch size x texture resolution). If increasing the texture tile size is not an option, then you can reduce the renderer patch size, as explained in the userguide linked above. This is recommended when using high texture resolutions, as small patch sizes are preferable to large tile sizes. Note however that the patch size must be a power of two for efficient triangle tessellation.
I believe Sapphire already automatically adjusts the patch size to correct for large texture resolutions. However, I don’t think it also corrects for non-power-of-two texture resolutions. I will look into it and let you know what I find.
Hmm...one solution to this problem would be for Sapphire to detect when the combination of tile size / texture resolution / patch size is going to be a problem, and automagically copy the texture to a temporary mosaic with a ‘correct’ tile size. This becomes hairy if the texture is huge (thus copying takes too long), or if the user wants to edit the texture map, as there will then have to be some more copying between the temporary map and the project texture map. There will probably be identical complications if the user wants to edit the attributes map. Hmm...some more thinkering will be needed here before I start coding.
Cheers,
Aaron.