L3DT users' community
Large 3D terrain generator

FreeImage failed to allocate bitmap

Please report software faults here.

FreeImage failed to allocate bitmap

Postby Philippe Le Miere » Fri Apr 03, 2009 6:13 am

I guess like most, I was hoping to get the maximum resolution out of the Texture map and am trying to save a 8K.

L3DT has generated the texture map fine, but when I go to save I get the following error:

CL3DTio_FIApp::SaveMapFile error
- FreeImage failed to allocate bitmap

CExtDLL::SaveMapFile error
- call to DLL function 'SaveMapFile' failed

CMapGroup::SaveMapFile3 error:
- save failed

Now this suggests to me that it's run out of memory. I'm running x64 Vista with 4 GB of DDR3 RAM. Checking my system monitor, with only L3DT open, I using 2890MB. So I basically have about 1 GB left.

Ok, happy to acknowledge that I may need more RAM. But before I add say another 4 GB to my system, is it possible to confirm that this is the problem?

I understand that I could also perhaps 'Split map into tiles (mosaic map)'. However this then limits the File format to L3DT mosaic map. Are there converts for .mmf files so that I could maybe re-patch it in Photoshop?

The project I'm working on requires terrain generation for Maya and Mental Ray rendering. I've gotten the Displacement map out (Heightfield), but just need the high res texture map now.

Cheers,

Philippe
Philippe Le Miere
Contributing member
 
Posts: 36
Joined: Fri Mar 27, 2009 10:12 pm
Location: Melbourne, Australia

Got it!

Postby Philippe Le Miere » Fri Apr 03, 2009 8:19 am

Hey. You know in life, sometimes, when to take a break from something and then get back into it - it then works. Well, yes, took a break, and had another go. And of course have now been able to save out the texture map.

Weird. Ok, noticed that L3DT has a RAM chart - can now see why this might be useful. RAM chart reads:

Current 1.1GB
Delta 0B
Peak 1.1GB
Paged 60.MB

My system monitor still reads about the same. In fact it now reads 3169MB after saving out the texture map to disk.

Still curious to know what it was, as I'm not sure I could reproduce the same result every time.

Thinking I might just work with 2K or 4K maps from now on.

Cheers.
Philippe Le Miere
Contributing member
 
Posts: 36
Joined: Fri Mar 27, 2009 10:12 pm
Location: Melbourne, Australia

Postby Aaron » Fri Apr 03, 2009 9:29 am

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.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Tile it!

Postby Philippe Le Miere » Sat Apr 04, 2009 5:02 am

Hi Aaron,

Thank you very much for taking the time to explain the problem. I understand now what is meant by tiles and a mosaic map. The theory behind it really helped and was good to read how others have had a similar problem.

Have had a bit of a play around with 'Split map into tiles' turned on. I can see now that this then not only solves the RAM problem, but also enables the option of a much larger terrain than 8K. Interesting how Photoshop by default uses this system, and I can see why L3DT offers the option.

Upon reflection, I think the reason why I was eventually able to save out the texture map was because I instead used the .bmp. Wasn't aware that .bmp is better supported in L3DT, so good to know. At the end of the day it was any uncompressed image format that was needed - so Bitmap was fine.

Good idea to make this thread a sticky, as I'm sure other users may want to learn how to output high resolution maps, while best managing their system's RAM.

Cheers,

Philippe
Philippe Le Miere
Contributing member
 
Posts: 36
Joined: Fri Mar 27, 2009 10:12 pm
Location: Melbourne, Australia


Return to Bug reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron