L3DT Users' Community

Hi, Aaron,

I'm experiencing a peculiar issue. Whenever I try to File > Import > Heightfield... and choose a heightfield of a supported file format (.PNG, .TIFF, .RAW, .TER, etc.), I get this error message:

CWizardPane_Import::SetFilename error:
- file format is not recognised

I say it's peculiar because this issue started happening about a couple days ago. It seemed to be working just fine before about a few days ago for me.

At first, I thought I just needed a simple reboot of my computer (I kept it running all day, and thought perhaps I was just seeing issues with possible overheating), so I shut it down and restarted it, but that didn't work.

I also tried disabling and re-enabling the L3DTio_TIFF extension in the Extension Manager, and as well as reloading the extension, and neither of those did the trick.

Then I tried a full uninstall and re-install of the following versions:

• L3DT Pro 11.11
• L3DT Pro 13.11 beta 1

And that didn't work either.

I then realized that there was a new developmental build available, L3DT Pro 14.01 beta 2, and so I downloaded and installed it, and tried importing a heightfield again, and still no luck.

What I'm thinking is that it's possibly something on my end, and not so much the software itself, but I'm just trying to eliminate down to just what could be the issue here. I don't think it is, but I can't be too sure. I'm wondering if I perhaps tried to open an inappropriate file somewhere and maybe it threw things off with L3DT? I doubt it, but maybe you're more familiar with this issue than I.

If you could help this situation when you can, I'd greatly appreciate it.

- Brian Lockett
3D Freelancer

Oh, and maybe I should add my technical specs:

• Windows 7 Home Premium (64-bit), SP1
• Intel Core i7-2670QM (2.20GHz) processor
• 8 GB RAM
• NVIDIA GPU (1 GB memory) [don't have the exact specs ready at hand, but can dig it up, if needed]

And as mentioned before, my versions are:

• L3DT Professional 11.11
• L3DT Professional 13.11 beta 1
• L3DT Professional 14.01 beta 2 *just installed*

If there's anything else you need from me (logs, error reports, etc.), just let me know. I will check back periodically in the Forums here, and I can also be reached directly via email (address down below).

Anything to help the situation--I simply can't live without my L3DT!


- Brian Lockett
(macromanjr@gmail.com)

Hi, Aaron,

I found out what was the problem. Apparently, the issue was in the way the particular 3D program I was using, Blender, exports (or rather, encodes and/or compresses) .PNG and .TIFF files.


Other Software Might Be the Issue...

Blender has different settings for images exports (BW, RGB, RGBA), as well as bit depth (8-bit, 16-bit) for certain image types such as PNG and TIFF, and I think these settings various affect how the images are encoded and/or compressed.

There might just be a difference in how it encodes/compresses various image file types. I'll have to test it out more to be sure.



...But Workflow Changes Seems to Be My Main Issue

Usually, my workflow consists of taking custom heightmaps I extract from meshes in Blender to another program World Machine 2 (WM2) for a few operations before I import them into L3DT.

I believe the heightmaps from WM2 are no problem to L3DT, as I've just tested out importing past terrain heightmaps in .PNG and .TIFF file format as exported from WM2, and they all seem to work fine. (I can also import .TER files just fine, as well, though I did have an issue with one recently-created .TER file earlier.)

When I try to import 16-bit .PNG and .TIFF heightmaps exported from Blender and imported directly into L3DT, they get that particular error message. Some .RAW and .BMP files likewise I recently created also seemed to give an error message.

Though, it seems these latter two are probably a similar issue of file encoding/compression differences, since again, my older .RAW and .BMP files exported from WM2 seem to work fine.



Not a Bug--Just a Technicality

I think I can deduce that issue isn't a bug--it's an issue of supported encoding and image compression of the certain heightmap image files, in the way the various programs write their image files.

I changed my workflow a bit in dealing with some commissioned work lately, by shortcutting the step of processing the heightmap in WM2 before bringing it into L3DT. This recent change seems to be what manifested the issue.

I do know there are several file encoding and image compression differences that different programs each recognize--seems like hardly any two programs I have really support all of such differences unanimously, except for image editors like Photoshop that typically give various file-encoding/compression options.



A Feature Suggestion

Maybe you could look into at some point in the future? It'd be great to have L3DT support practically any TIFF/PNG/BMP/RAW heightfield file, maybe a format converter extension to make such incompatibly-encoded/compressed files as L3DT-compatible. But, for now, I think there are workarounds, with my original workflow.



I'll keep an eye on the issue (and mind my workflow) to ensure that it is just an issue of how image files are written and I think next time I'll make a brief screen-captured video of any issues I encounter, if an issue arises.

Anyways, I hope this helps someone else encountering this slight issue. I think I should be fine now. I'm just glad I'm back in business again. Thanks.


- Brian Lockett
3D Freelancer

Hi Brian,

Supporting all possible TIFF formats is a big ask; it's not called '(T)housands of (I)ncompatible (F)ile (F)ormats' for naught. The type of TIFF L3DT currently supports is the GeoTIFF variant, which is fairly widely used to store real-world terrain data, but not so much for artificial terrain. L3DT's TIFF plugin does not support any form of compression, and I'm not likely to change this given the other comparable formats available (PNG, for instance).

As for PNGs, L3DT should support pretty much all PNG variants, or at least that's the intention. If you have PNGs that won't load in L3DT, please send a small example to aaron@bundysoft.com, and I'll fix the plugin. Ditto for BMP, TER, etc. You can send me a troublesome TIFF too, and so long as it doesn't use any particularly funky compression I should be able to support it.

Best regards,
Aaron.

Yikes! I knew there was a chance that such a suggestion would be easier said than done, but I wasn't aware that it was that complex.

Well, I'll just stick with the methods that keep TIFF files compatible with L3DT. And I'll just make sure the TIFF files uncompressed. That's fine. I completely understand. It's not a major issue now that I better know what I'm looking for with TIFF files.

As for the .PNG/.TER issue, I haven't encountered it again since the last time I reported it with the newer files I've produced. Most of my .PNG/.BMP files work--it just seems to be a few select ones that don't. I think it just depends on what program I use to produce them. I've sent you an e-mail of the few exceptions of files that give me messages.

For the most part, though, I've been working around the file compatibility issue. Thanks for your response.

- Brian L.

Hi Brian,

The problem is that L3DT doesn't properly handle filenames containing extra dots / periods / full stops unrelated to the file extension.

For example, when loading your file 'WIP 2.5.1 (FINAL RE-RENDER).png', L3DT looks through it's extensions for a file format plugin that can load files with an extension of '5.1 (FINAL RE-RENDER).png'. Obviously, no plugin exists for this specific extension, so it throws the error you noticed. I'll change L3DT handle dots in filenames in the usual / expected way, but this can't happen until after L3DT 14.02 is released. In the mean-time, try changing the extra dots in the filename to underscores or something.

Thanks for the bug report.

Best regards,
Aaron.

Aaron wrote:Hi Brian,

The problem is that L3DT doesn't properly handle filenames containing extra dots / periods / full stops unrelated to the file extension.

For example, when loading your file 'WIP 2.5.1 (FINAL RE-RENDER).png', L3DT looks through it's extensions for a file format plugin that can load files with an extension of '5.1 (FINAL RE-RENDER).png'. Obviously, no plugin exists for this specific extension, so it throws the error you noticed. I'll change L3DT handle dots in filenames in the usual / expected way, but this can't happen until after L3DT 14.02 is released. In the mean-time, try changing the extra dots in the filename to underscores or something.

Thanks for the bug report.

Best regards,
Aaron.

I came back here just to say that I figured out the problem about four minutes ago--it was the dots in my files' names! I should've checked back here sooner today!

I truly thank you for looking into it--if I hadn't changed one of my file names by mere curiosity (I changed one of my file's name because it felt too long), I would've still been very puzzled.

Also, thanks for considering adjusting the filename handling for some point after 14.02 is released. I look forward to seeing L3DT 14.02 as well. Though, now that I finally know what the issue is, I should be fine now. Yeah, as you suggested, I think I'll go with underscores.

Phew! Thanks a million, Aaron!


- Brian Lockett