L3DT users' community
Large 3D terrain generator

Unable To Generate Texture

Please report software faults here.

Unable To Generate Texture

Postby neddiedrow » Tue May 12, 2009 12:30 am

I'm currently working on a computer running Windows XP 32-bit with 4 GB of RAM, 3.2 addressed. I'm not upgrading to a 64-bit flavor of Windows until a decent one is available, which means I'm waiting for Windows 7 to go gold.

Unfortunately, for some reason, I am unable to generate maps of the size I desire. Something about contiguous memory - I still have more than enough for each stage I attempt, but eventually, on the way to a texture, I find myself unable to proceed because there is not enough contiguous memory, though I generally have around two gigs free at that point.

I am trying to generate maps for Spring between 24 and 32 map units per side, so between 12296 and 16384 pixels a side. I do not remember encountering these problems in past versions of L3DT - I am presently using the newest stable release of PRO.

Any way around this problem?
neddiedrow
New member
 
Posts: 7
Joined: Wed Aug 29, 2007 9:46 pm

Postby neddiedrow » Tue May 12, 2009 5:53 am

I finally forced a texture out and exported it after about two hours of processing.

For no apparent reason it is now corrupted and unusable. Urgh. What the hell happened to L3DT? What would cause a BMP export to fail?
neddiedrow
New member
 
Posts: 7
Joined: Wed Aug 29, 2007 9:46 pm

Postby Aaron » Tue May 12, 2009 11:11 am

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.
Last edited by Aaron on Thu May 14, 2009 11:13 am, edited 2 times in total.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby Aaron » Wed May 13, 2009 2:11 pm

Hi Neddiedrow,

Following on from one of my later points above, I have modified the wizards in L3DT to automatically split maps into tiles if they are large enough that they may otherwise trigger contiguous memory exhaustion problems. This change is included in L3DT v2.7 build 11, which is on the Pro downloads page now.

Cheerio,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia


Return to Bug reports

Who is online

Users browsing this forum: Google [Bot] and 11 guests

cron