Hi Philippe,
Thanks for the bug report. I think in this case L3DT is behaving more or less correctly, but perhaps counter to your expectations. I did however find a few small related bugs, so I'll leave this thread here in 'bug reports', rather than move it to 'help and support' as I was tempted to do on first reading.
To explain what L3DT is doing, and what you have to do to avoid the error message you reported, I must first explain some terms relating to file format support in L3DT. L3DT divides file formats into two categories:
- 'Native' formats, which store enough information to ensure no (or little) data loss, and;
- 'Non-native' formats, which do not store critical map information and thus may result in data loss.
Let's now consider the JPEG format. When using JPEG to store heightfield data, this image file discards the height scaling data, and instead clamps all values between 0 and 255 greyscale units. Thus, JPEG is considered a non-native file format for heightfields, and should only be use for import or export*.
Anyway, getting back to your issue. As we've discussed previously, mosaics maps load/save map tiles to/from disk during calculations. To prevent map data corruption, this operation must not lose information, and thus the mosaic map must internally use a 'native' format for each map tile. Now, as you know, you can import or export mosaics in non-native formats, such as a heightfield as a mosaic of JPGs. However, after you import a mosaic in a non-native format, you have to convert it to a native format before L3DT can do anything useful with it; for instance, running the inflate algorithm.
If you use the '
File->import->heightfield' option to load the heightfield mosaic, this will automatically convert from non-native to native mosaic formats. However, I've just noticed in the current build that the file filter list in the import wizard is incorrect and doesn't include MMF, and I have fixed that in the next dev build.
The option I assume youy used ('
File->Open') also loads mosaics, but it doesn't do the format translation (I will make it do so now.) Instead, users were recommended to manually update the file format using '
File->Format preferences' menu option, selecting the 'Project maps->Heightfield->HFZ' tree option, and pressing the 'Use format' button. This will re-save your mosaic in L3DT's default native heightfield file format 'HFZ'. At least, it does in most cases, but when I just tested it with a JPG mosaic heightfield opened using the 'File->Open' option, it didn't work until I toggled the format a few times (convert to TER, then back to HFZ). This too will I fix for the next dev build.
However, is this something that might also happen to other file formats if I do manage to get an uncompressed 16-bit in, for example?
You'll get the same behaviour with
any image file. Images don't store the true floating-point height scale, so L3DT considers the lot to be 'non-native'. However, in the next build, you shouldn't have to worry about it because L3DT will do the translation automagically. I'll let you know when it's ready for download.
Best regards,
Aaron.
* Aside: Conversely, the JPEG format
is considered a native format for light map and texture data, as it stores colour data with sufficient accuracy for this purpose. Hence, a format may be both native and non-native, depending on its suitability for each map type.