RAM Usage
The Poser program comes in two varieties: the 32bit and the 64bit one. Poser Pro and all “just Poser” versions are available in 32bit only; only Poser Pro 2010 and up present both varieties . The 64bit variety will install and function in a 64bit Windows only, the 32bit varieties will work in a 32bit as well as a 64bit Windows system.
All 32bit software can handle 2Gb of “user memory” by default, or can be made “Large Address Aware” (or: LAA-enabled) to handle more. All Poser software has that ability already and needs no further adjustment.
32bit operating systems will grant 2Gb user memory to programs, or can be told to grant more. The upper limit is 3Gb. Mac OSX and Linux have this ability enabled by default and hence will grant more than 2Gb to a LAA-enabled program that asks for it. But 32bit Windows requires some additional settings. If those are not set, Poser can use up to 2Gb user memory only. If set, Poser can use more, up to the limit set in Windows, with a max of 3Gb.
On how to set the 3GB-switch in Windows, and how to enable LAA in programs that come without, I wrote the Breaking the 2Gb Barrier TUTORIAL.
Then I select the Processes tab, and select my program of interest from the list. It reports CPU usage and User memory
In the example above, Poser Pro is not busy (00 % processor) and uses 150.868kB (say 150Mb) user memory.
Note that not all of this memory is required in RAM. Windows can decide to put some portion of it on disk (virtual memory) and swap it back in when requested. Also note that this is just the “user memory” portion, the total amount of memory required by Poser also includes space for code, internal tables and system interfacing. But I can’t affect the latter, so I don’t have to worry about it.
How much memory do I need?
- 150Mb for the empty program, just launched and no scene nor figures loaded.
- 150Mb for an average scene. It can be less, with just a single background object. Or far more when I’ve loaded a large scale extremely detailed castle environment with loads of high resolution textures.
- 100Mb for a character (like Vicky 4) including textures and a decent set of morphs, without clothing
- 100 – 200Mb for clothing of that one character
- And then rendering requires an additional 2- (average) to 4-fold (peak) of the amount needed for scene, characters and clothing.
For example:
- I start Poser, delete the default Andy figure (makes an empty scene of 150Mb), and just load Vicky with some morphs (100Mb) and a decent clothing set (150Mb) for a total of 150+100+150 = 400 Mb. Then I render, and Vicky + clothes (250Mb together) goes fourfold, or: adds 1000Mb. Hence at the peak of the rendering process, my total user memory requirements are 1400Mb. During the render, the average memory usage is 900Mb.
- Now I add Mike (+clothes) to the scene, which adds another 250Mb to the design stage. But he also adds 500Mb on the average to the rendering. On the average. Because when the rendering peaks on either Vicky or Mike the memory requirements will be 1400+500=1900Mb in each peak, and when the renderer cannot prevent peak overlap the requirement might be as extreme as 1400+1000=2400Mb.
- As I might (or just might not) cross the 2Gb boundary while doing this, my rendering might crash on a normal 32bit Windows machine. I can save my ass by raising the bar by setting the “3Gb switch”.
- Adding some scenery or a third character will definitely overload the rendering on any 32bit machine. Unless I go for reduced resolution characters, clothes and textures, and/or for reduced quality rendering (eg: turn displacement maps off, etc.).
A special way out is: render as a separate process.
Then I select the Render tab, check the Separate Process option and click [OK]. I do not have to restart Poser, and I might switch it off later.
When I render now, TaskManager shows an extra process: FFRender (the FireFly Renderer).
As one can see in the example above, Poser itself stands still (CPU 00%) while holding the program, one character and clothing for about 410Mb, while the FFRender is doing the work (85% CPU usage) while also using the memory for rendering only (you’re seeing the Vicky 4 rendering peak at about 1000Mb). This does save some memory, and enables me to put more figures or scene detail in while still remaining under the 2Gb or 3Gb limit, as far as the 32bit version of software is concerned (yes, FFRender is LAA-enabled too).
It’s not faster (actually, launching a separate process and reeling its results back in takes a bit extra), it doesn’t save on total systems memory consumption (as the Poser process is still around taking up the extras) and while it’s running I still cannot use Poser for other work simultaneously. But it’s leaner on memory for that specific process which can save the day. And sometimes it seems to cure other things as well, for whatever reason. So when the scene appears prone to crashing at render time, Separate Process is the first way to go. As is observing the programs behavior in TaskManager: do watch the memory consumption for that process.
And… you do save your scenes before rendering, do you? Just in case.
Actually, forking out to a separate process never hurts. Even now, working in a 64bit environment, I’ve got Separate Process switched on and leave it that way.
On top of that, one might benefit from a “hidden feature” when running a 32-bit Poser version in a 64-bit environment. That is; even the 32-bit versions may come (*) with FFRender64.exe which gives us the all 64-bit capabilities while rendering: somewhat faster and no memory hogs. But one has to set “render in separate process” to benefit from it.
Poser itself knows which FFRender to use, but you can tell it yourself by altering the Poser.ini settings (ALLOW_FFRENDER64 1).
(*) I found this in the 32-bit Poser Pro 2010+ program folders, perhaps it comes with Poser itself too. Don’t know.