Hi Philippe,
I'm going to make this thread a 'sticky', since it seems to come up a few times over the years (see answers:
1,
2,
3,
4,
5).
For the sake of thoroughness, I'm now going to explain exactly what's going on. Please feel free to skip to the next two paragraphs if you only care for the solution.
When you try to save a JPG, PNG or TGA image, L3DT uses a nifty image library called 'FreeImage' to perform the compression. To do this compression, FreeImage makes a duplicate copy of the image in memory. If you have a large image, say, 8192x8192 pixels, this will require an additional 256MB of
contiguous memory over and above the other memory being used by L3DT for textures, light maps, shadow maps, attributes maps, normal maps, heightfields, water maps, alpha maps, and any other maps you may have calculated. 256MB may not sound like a lot, and indeed it isn't, but the trick is finding 256MB in a contiguous (i.e. uninterrupted) address strip. After hours of serious RAM use at high consumption levels, your system will suffer from a 'fragmented' RAM address space (analogous to fragmented disks), with lots of little bits and bobs of memory in use all over the place. Thus, even though you may have much more than 256MB of free RAM, you may not have any single free block that is 256MB in length. In this case, the request to allocate memory will fail, FreeImage will fail, and L3DT will show you the error you saw.
Programs like PhotoShop get around this by storing images in RAM as a set of tiles, each occupying a small block of memory. For example, a 8192x8192 pixel image may be stored as 64 blocks of 4MB each, rather than a single block of 256MB. Obviously, it's much easier for the operating system to find space for lots of little blocks than it is to find space for one huge block. L3DT supports this trick too. It's called a mosaic map. More on that later.
Your easiest option for 'fixing' this problem is to instead save the file as a bitmap, rather than a JPG/PNG/TGA. This is because I wrote the bitmap plugin myself, and I've made it share L3DT's memory, so it doesn't need to allocate any additional memory to save the image. This bitmap plugin will save images up to the limit of the bitmap format (32768x32768 pixels, IIRC).
Your better option would be to have generated all the maps as mosaics. When you do this, L3DT won't always need to keep the textures, light maps, shadow maps, attributes maps, normal maps, heightfields, water maps, alpha maps, etc in memory at all times. It will in fact page them out to disk, tile by tile, and only load them as required. Furthermore, when mosaics are loaded into RAM, they are loaded as may smaller blocks. This means that L3DT won't need to lay claim to any particularly large regions of contiguous memory, since the tiles can fit almost anywhere. Thus, L3DT will leave more space for FreeImage when it wants to allocate its block.
Now, you may not like the idea using mosaic maps for everything, as you want your map to be a single file, not a bunch of tiles. However, you can always export the map from L3DT as a single file. If you use the bitmap plugin, you will be able to save a huge single file (larger than will fit in RAM), since the plugin can write the bitmap whilst only holding a few small mosaic tiles in memory at a time. This means, for example, you could write a 2GB image file on a system that only has 256MB of RAM (I used to do this, back in the day.) Now, the caveat here is that even though you may have L3DT storing its maps as mosaics, FreeImage won't, so eventually there will be an image size that FreeImage won't be able to save because it won't fit in contiguous memory. In such cases, use a bitmap, for reasons already described.
Regarding your question "
should I buy more memory?" The answer is
no. It's unnecessary. L3DT doesn't need to hold all the maps in memory at one time, and if you use the mosaic map feature, it won't *. Should all-mosaic maps be the default option, to relieve users of the need to manually click the check-boxes? I think so. I'll change this for the next release.
Best regards,
Aaron.
* As an aside, it will actually make some operations slower if you try to keep all the maps in RAM (e.g. consider loading/saving the project.) This seems counter-intuitive, particularly for those users who have shelled out for huge amounts of RAM and want to see it being used, regardless of whether it makes the operations any faster or not.