Hi Neddiedrow,
I apologise for the inconvenience caused by this fault, and thank you for your bug report.
1) Can you please send the log file to
aaron@bundysoft.com. You can find the log file by selecting in the start menu the following link:
All programs\Bundysoft\L3DT Professional v2.7\L3DT logs
This link will open a folder containing the log files. The file I would like to have a look at is 'log.txt'.
2) When you generate the attributes/normal/light/texture maps, have you tried enabling the 'split map into texture' check-box? The issue with contiguous memory has been discussed in this forum many times over the years, as so has the fix; using non-contiguous memory by splitting the maps into tiles. Most wizards have an option of 'split maps into tiles'; if you use it, you shouldn't see any such RAM allocation problems. You can always export as a non-tiled image at the end, so long as you use the BMP format*.
3) What was the texture size in pixels? Also, what was the file size of the corrupt bitmap, in bytes (exactly) please? I'd like to know if the export has failed part way through. A correct 16k x 16k texture bitmap written by L3DT should be exactly 805,306,422 bytes.
4) Can L3DT load the bitmap? To test this, please drag the bitmap onto the L3DT desktop icon. L3DT will load it as a greyscale heightmap**, so the colour data will be ignored, but it will nevertheless test whether the file is wholly corrupted. If L3DT cannot re-load the file, please post back here with the error log it throws.
5) To verify L3DT's behaviour with large textures I have, just now, generated a 16,386x16,386 pixel texture (as a mosaic) and exported it as a huge single bitmap. The only problems I found were that the GIMP and Windows Picture and Fax viewer claimed the image was corrupt because it was too big (they run out of memory). The image loaded fine in MS Paint and Paint.NET, however, and L3DT can of course re-load the image properly. Thus, whilst some programs will report large images as corrupt, it ain't necessarily so. What program did you use to load the bitmap?
My tests indicate, at least to my (optimistic?) interpretation, that there is no technical problem in producing and exporting large textures in L3DT. However, I will readily concede that there is a user interface problem in that L3DT does not prevent users from attempting to generate non-tiled maps that will likely result in memory catastrophes. This I will be rectified in the next release, using new default settings (mosaic on by default), and new warnings in wizards if users override these defaults.
In any case, if the logfiles you send show that this fault was caused by a bug in L3DT or a plugin (other than the above UI loophile), I will do my absolute utmost to fix the problem as soon as possible.
Again, I apologise for the frustration and time loss caused by this fault.
Best regards,
Aaron.
* I recommend the bitmap format because this plugin nomonally has no additional memory requirements. In contrast, the plugins that write the JPEG/PNG/PCX/TGA/etc formats will need to load a duplicate copy of the entire map into memory, and so for large maps (>8192x8192 pixels) these plugins may fail to export if the memory space is fragmented. The BMP plugin does not have this requirement. I would of course like to work out why the BMP plugin seems to have failed this time, but for that I will need a little more info (see pt1, pt3 and pt4).
** Please note that the import of a 16k x 16k bitmap will take ages (say, 10 minutes), during which time the user interface may be unresponsive, and at certain stages there may be no progress display. Please be patient.