Design Map importation and support for uncompressed image f

[Philippe Le Miere]

Having a little trouble importing an uncompressed image file type into L3DT.

Can import a .jpg, when going File > Import > Design map ...
Then setting the Horiz Scale and Min/Max alt, and Import design map parameters is all fine.

One interesting thing though (and it's not really a problem) is when the 'Noise shape' is set to 'rolling', it automatically resets it back to 50%, or half way between rolling and fractal. Guessing this is a 'feature', that ensures the map is read accurately. I set all other settings for Design map parameters effectively to zero. I can then work in detail, such as erosion, calculate a heightfield map and all is good.

Jpeg is fine, but am noticing that it's artifacts are also coming in and perturbing the terrain surface. It actually adds to the variety of the surface, but would prefer to have some control.

Have tried .pgm for example but get:

CMapGroup::LoadMapFile2 error

- error loading file

CMapGroup::LoadMapFile error

- Call to LoadMapFile2 failed

CWizardPane_ImportDM::LoadMapFile error:

- map is zero-sized

Error loading file

Now, this .pgm is effectively saved out in Photoshop. Have tried .png and .bmp all resulting in the same error. Is this just Photoshop being anonying? I could use Imagemagic to convert image file formats. I understand that sometimes file formats can be a little fussy, and different image programs can use a format's standard a little differently.

Starting to see a benefit in working with L3DT as a pipeline, where basic grey scale maps are imported into L3DT, processed for extra detail and then outputted for 3D rendering. Ideally would like to work with uncompressed 16-bit images. Any suggestions or ideas on the requirements of an image file before importing into L3DT?

Thanks,

Philippe

[Aaron]

Hi Philippe,

Can you send me the PGM file (zipped, if you please)? The DM image import works fine for me, and I can't reproduce this error. Is the image still open in Photoshop? If so, it may be a permissions problem, and you'll have to close the files in Photoshop before loading them in L3DT.

One interesting thing though (and it's not really a problem) is when the 'Noise shape' is set to 'rolling', it automatically resets it back to 50%, or half way between rolling and fractal.

This is a curious display side-effect of the way L3DT internally calculates its fractal and peak noise parameters. If you're willing to dig through the forum history, there was some discussion on the behaviour of these sliders a few years back, and this behaviour was considered less confusing than the alternative. Anyway, when you set the 'noise strength' parameter to zero, the 'noise shape' slider becomes meaningless (you've already said there won't be any noise, so it doesn't matter what shape it is). Consequently and somewhat indirectly, when L3DT is calculating the slider positions in the 'design map parameters' wizard, it doesn't know where the noise shape slider should be when the noise strength is zero, so it guesses 50%. However, actually doesn't matter, and when you have a non-zero noise strength, the noise shape slider position will be calculated correctly. Thus, this is a "won't fix".

Best regards,
Aaron.

[Philippe Le Miere]

Hi Aaron,

Have taken a second look at importing grey scale images into L3DT as Design Maps.

The PGM's were in fact open in Photoshop when I tried it the first time. However, I've now tried importing the .pgm with Photoshop closed and got the same loading error.

I don't really have any affinity with the .pgm format. Personally I usually work with 16 bit TIFF, but L3DT alas doesn't seem to support this format. I'm basically looking for a floating point image format that is supported by both L3DT and Photoshop. Open to any suggestions

Thought maybe .pgm might be the one. It would be kind of you to test my .pgm files. Interested to hear the result you get.

Thank you.

Philippe

[Aaron]

Hi Philippe,

I'm basically looking for a floating point image format

Floating point is a tall order for images. Of common image formats, I think only TIFF actually supports floating point values. Perhaps you could try 32-bit floating point RAW.

Alternatively, if you're only after high-precision files (16-bits precision or more), I suggest you use 16-bit PNG.

With regards to the PGM images; I have to do a little bit of work on the L3DTio_PGM plugin to allow it to read these 8/16-bit binary integer files. I'll let you know when the updated plugin is ready for download.

Best regards,
Aaron.

[Philippe Le Miere]

All good. Thanks Aaron.

Will experiment a bit with the image formats available in L3DT.

Yes, TIFF is a pretty versatile image file format .

In my experience, I have found Photoshop to occasionally not conform well to image file format standards. No biggy on the PGM, I'm sure I can work around it.

Thanks again for looking in to it though.

Cheers,

Philippe

[Aaron]

Hi Philippe,

I've updated the PGM plugin to properly load these PGM's from Photoshop. As an aside, Photoshop should have saved these files with a PPM file extension because they use the P6 identifier (Portable Pixel Map, PPM), rather than the P2/P5 identifiers (Portable grey map, PGM). Nevertheless, you can download the updated plugin from:

http://www.bundysoft.com/L3DT/downloads/plugins/bin/L3DTio_PGM-bin.zip

To install this plugin, extract it from the zip archive and copy it into the following directory:

Code: Select all

C:\Program Files\Bundysoft\L3DT [version]\Extensions\


Then, load L3DT and open the extension manager ('Extensions->Extension manager' in the menu). In the extension manager, select the 'L3DTio_PGM' plugin from the list, click 'remove' (and OK if prompted), then select the 'Load new' button, and select the new 'L3DTio_PGM.zeo' plugin.

Please let me know if you have any problems.

Cheerio,
Aaron.

PS: The image in your 16-bit PGM file only had 256 distinct height levels, which means it had previously been stored at 8-bit precision. In such cases, expanding an 8-bit image into a 16-bit file does not improve the precision; it's still really only 8 bits of data per pixel, with lots of padding zeros.

[Philippe Le Miere]

Thanks for the plugin update Aaron.

kind regards,

Philippe