trImage error and solution

Started by AndyWelder, July 25, 2007, 05:41:56 pm

Previous topic - Next topic

AndyWelder

While working on a render I got these errors:

trImage: unable to allocate pixelmap: size24000000 bytes

and

trRenderInitBucket(): unable to render buffer

This happened several times and at several stages of the render with different values for the byte size.

I went back and reverted to the saved file and repeated the steps I made. That way I discovered there was a relation with the height setting of the cloud layer. This was a default low cumulus 2D and the only change I made was lowering the altitude. The lower the altitude the earlier the error screen appeared.
So I raised the altitude and was able to finish a render.

The files I used were Volker Haroon's "CanyonImpression", a clipfile with multiple 'suns' extracted from his "Alpine" .TGD and the "Grass7.TGO".
If the (.TGD) file(s) is/are needed I'll post it but it will be pretty big because of the images and 32 MB .TER used.

My system has a 4400MHz Athlon dual core with 2 GB RAM and I noticed a slow but steady increase in the use of RAM by tgd.exe (starting with 1000 MB and ending at 1500 MB).
"Ik rotzooi maar wat aan" Karel Appel

rcallicotte

This is a known issue and may have (notice I say may) something to do with the size of youir TER in your render or simply too complex of a setup for the present program to handle it in memory.  My guess would be the TER overload (for now).

So this is Disney World.  Can we live here?

bigben

File sizes shouldn't be too much of an issue.  My Grand Canyon animation used 160Mb of terrains and 130Mb of mask images without blinking.  The multiple suns may have been over complicating the cloud calculations?? (wild stab in the dark). Moving the clouds higher (further away from the camera) would also have reduced the detail required in them.  I used the canyon tgd for a fill light test and it certainly makes TG strain. I hadn't checkd the RAM usage for the tests, but this may be a contributing factor.

Volker Harun

Joining my paths might be dangerous :D

Oshyan

It's pretty odd that just changing the cloud layer height would affect this, although it may simply be that with lower clouds the overall memory use was higher and thus there was not enough free space to allocate for the image map. In this case it will be the last element that has memory allocated which will encounter the memory limitation, so the cause may be indirect (cloud layers requiring more detail) and the error message may not be clear as a result.

In any case this does indicate a general memory issue so solutions should be approached from that direction. When a 64 bit version of TG2 is available I would expect it to resolve this problem on a machine with sufficient memory.

- Oshyan

jo

Quote from: Oshyan on July 26, 2007, 04:49:49 pm
In any case this does indicate a general memory issue so solutions should be approached from that direction. When a 64 bit version of TG2 is available I would expect it to resolve this problem on a machine with sufficient memory.


When it comes down to 64 bit, I think it would more be a case of sufficient disk space. I haven't heard that 64 bit Windows is limited to the amount of RAM you have installed, so if you have sufficient disk space for the OS to use for virtual memory page files it shouldn't be an issue. Well, depending on exactly how crazy you go with scenes anyway :-).

Regards,

Jo

AndyWelder

Sorry for the late reply but for some reason the reply notifications just landed in my mailbox this morning(?)
Here are some observations and side notes:

The whole render was very memory intensive:
4 images used as source for seven shaders including 2 water shaders (with high opacity and translucency - don't ask me why, I'm only pushing faders ;D).
Added to that are 3 populations and 1 single of .TGO objects.

What I see is this:
Loading TG2 initially takes 50MB.
Loading this particular .TGD makes the mem usage go up to 350MB.
Activating the atmo and light in the preview ads another 40MB, slowly climbing to 50MB.
So now TG2 uses 400MB.
Selecting the atmosphere node ads another 20 MB.
Pushing 'Render Image' makes the mem usage go up to 1250 MB and slowly increasing. Every time a new square section of the image is about to render there is an abrupt increase.


The cloud layer was the last thing I added and changing that had no real impact on the scene. Changing the cloud layer settings was the simplest thing to do.

"if you have sufficient disk space for the OS to use for virtual memory page files it shouldn't be an issue"
XP is running on a 50GB partition exclusively assigned to the OS, it uses little less then 12 GB including the 6GB used for the pagefile (this has a fixed value of min/max 6GB). Other software is installed on different partitions. And the two Terragens each have their own partition.

Oh, and then this: I installed an AMD fix two days ago and noticed the swap file usage display going from a 'saw tooth'  before to a flat line afterwards.
"Ik rotzooi maar wat aan" Karel Appel

Volker Harun

Andy ... in the taskmanager, go to 'Beeld' and choose the bottom option - you can decide what the taskmanager is showing to you. Add 'size of virtual memory' so you can see the total ammount that terragen is using.

Volker

Oshyan

Quote from: AndyWelder on July 29, 2007, 04:08:20 am
"if you have sufficient disk space for the OS to use for virtual memory page files it shouldn't be an issue"
XP is running on a 50GB partition exclusively assigned to the OS, it uses little less then 12 GB including the 6GB used for the pagefile (this has a fixed value of min/max 6GB). Other software is installed on different partitions. And the two Terragens each have their own partition.


The above is only true if you're running on a 64 bit OS. Then each application is allowed up to 4GB to itself I believe, including swap file. For XP32 it will be only 2GB, regardless of main memory and swap file size (e.g. 6GB swap file doesn't help you overcome those limitations *per application*).

- Oshyan

rcallicotte

July 30, 2007, 12:52:02 pm #9 Last Edit: July 30, 2007, 12:55:02 pm by calico
Oshyan, 4G is the Microsoft XP (32) limit - http://msdn2.microsoft.com/en-US/library/aa366778.aspx#physical_memory_limits_windows_xp

I believed the same until someone sent that link to me and this makes it interesting - http://msdn2.microsoft.com/en-US/library/bb613473.aspx
So this is Disney World.  Can we live here?

Oshyan

4GB *total*, not available to the application. Quoted from your 2nd link:

"On 32-bit editions of Windows, applications have 4 gigabyte (GB) of virtual address space available. The virtual address space is divided so that 2 GB is available to the application and the other 2 GB is available only to the system."

Thus 2GB maximum, as I stated. If you enable the /3gb switch it is up to 3gb for an application but I no longer advise this as I have come to understand it actually takes memory *away* from the system, even if it is not in use.

- Oshyan

rcallicotte

I don't think I'd mind the system loss, but I'd better look into it before I waste the time and money.

Anyway, I'm thinking seriously about moving over to OS X.
So this is Disney World.  Can we live here?

Oshyan

Quote from: calico on July 30, 2007, 01:34:29 pm
I don't think I'd mind the system loss, but I'd better look into it before I waste the time and money.

Anyway, I'm thinking seriously about moving over to OS X.


You may not mind, but your system might. ;) If you really need the additional RAM you're much better off just moving to a 64 bit OS.

Unfortunately moving to OS X isn't as simple as installing a new OS. Your minimum const of entry is going to be $600 for a Mac Mini. $1200 for an iMac. If you already have a decent monitor for that price you could get a quad core system twice as fast with twice the memory. ;D My biggest complaint about Apple is the fact that they don't cater more to the power-on-a-budget market. They'd get a lot more converts (people like me) if they let us buy powerful but not bloated systems at a decent price. Insisting on dual CPU for all desktops that don't have a built-in monitor automatically ensures a large price premium, which is unfortunate. They could easily sell a $1000 quad core system (single CPU) and still make good money on the deal. The iMac would still sell because people want the smaller, sexier package and not everyone has a monitor already. But hey I'm not in charge of Apple. Oh well. :p

- Oshyan

rcallicotte

Integrating the hardware possibilities I have now with the OS possibilities of Mac would be very nice.  Maybe I could just create on a Mac and render on a Windows machine.  Hmmm.

So this is Disney World.  Can we live here?

old_blaggard

I'm just jumping off topic here to say that I totally agree with you, Oshyan - the thing that bugs me the most about Apple right now is that they don't have anything between the Mac Mini and the Mac Pro.
http://www.terragen.org - A great Terragen resource with models, contests, galleries, and forums.