I have a Q6600 (quad core), 4GB of 1066MHz RAM, dual SLI video cards and 1.2TB of hard drive. Recently I've been facing RAM issues in Poser that might mean I need an upgrade: I have too many texture maps on my scenes.

Since each screen usually take at least 30 mins to render, what I do is: I set them up during spare daytime, and right before I go to bed I go to AMINATION / MAKE MOVIE, and set it to render IMAGE FILES. So it renders several frames of my scene while I sleep. Now, whats been happening is that when I wake up, Poser is crashed halfway, with a window saying it's low on memory. Usually when rendering several angles of the same scene, it will render several frames, but crash on the frame that focus on the horizon, where you can see a lot of the ground in an angle. When focusing down into the ground on an small angle where you can't see a lot of it, it won't crash. I assume that it could be because when its rendering a piece of the ground thats far in the horizon, that piece has a lot of the texture and the materials in it. (could it be?)

From what I understand (please correct me if i'm wrong), those 3D programs uncompress all your texture's JPEGs inside your RAM into 3 bytes-per-pixel images (RGB), so a 1000x1000 pixels image would take 3MB of RAM (1000 * 1000 * 3) even if on disk they take 20kb as a low quality JPEG. Also as far as I know, the renderer don't use HD swap, meaning that either you have enough RAM for all your uncompressed textures, or you won't render your scene. This is to improve rendering speed, because otherwise it'd take way too long for the renderer to get pixels from your HD swapped RAM. (not sure if it's entirely correct, please correct me if its not).

So, I have 4GB of RAM, which I thought to be more than enough for Poser and anything I could throw on it. Well, it's not. So I'd like to ask you guys:

1. How much RAM you have on your Poser computer? Do you run out of RAM on complex scenes? Were you having RAM issues that made you put more RAM, and did it solved the issues for good?

2. Any tips on how to get scenes to render when there's almost enough RAM?

3) Asside to texture maps, what else drains a lot of RAM? I usually have 3 texture maps on my main character, and a LOT of nodes on my material room. Everything from math (multiply, add, subtract...) to specular nodes, noise, and so on. Do these also consume a lot of RAM?

4) My motherboard supports 8GB of RAM, but if I put 8GB it will cut its RAM clock by half. Will this be a severe impact on my rendering times?

Thanks in advance for your advise!

When POser tells you that you have a memory problem it means that you have not a memory problem,  but you have a Poser's problem.
Textures comsume a lot of memory, but today you have a lot of memory too!
A texture of 4000x4000 will use 48M, if you use 40 of then you have only used 2GB of memory and today's computer have several GBs of RAM and don't forget that virtual menory (disk) extends the total available memory and who decides to use RAM or disk is Windows and not Poser, Poser only request memory and Windows allocate it.
When you run of memory physical + virtual your Windows crash or becomes very very slow, windows and dialogs of any application lose colours and so on, better restart your computer if still it respond.
Poser can give you messages that has no memory even you render only the background plane at 600x600.
One reason I found was a corrupted Poser.rsr, if I overwrite this file from a backup copy Poser returns to work normally.
Other reasons can be corrupted pz3, cr2, pp2 files, you can correct them with a text editor if you are able to find where the problem is, if not you must start all again from ground zero and the files are lost.
A buggy geometry can be the guilty, this time it was not a Poser's guilt, only he got crazy with wrong data.
On the other side I was able to render complex scenes with only 160M RAM and 100M virtual memory.
Even today I have only 500M RAM and my virtual memory is limited to 700M (I can extend it if I wish, disk space I have a lot) and I use a lot of textures and many figures, the only penalty if I overload the scene is that it takes a lot to render, of course with more RAM it will render much faster.

Well, theres the textures, but there's also the geometry, materials calculated at runtime, Poser's routines and Firefly's routines... so you take a 4000x4000 pixels texture and lay it over a 100 thousand polygon mesh, add smooth on top of it and turn on raytracing... only god knows what might happen to your RAM. So I wouldn't blame Poser for not using just a bit more RAM than the area of my textures combined.

But I was able to realize a very direct connection between the number (and size) of textures and Poser running out of RAM and crashing on my face. I also noticed a very dramatic improvement when I went from 2GB of RAM to 4GB. But before I go about putting 16GB of RAM on my PC, I'd like to hear the thoughts of people that had similar RAM issues.

Right now I was able to render my scene by lowering the bucket size from 64 to 16. Took longer, but it all went very smooth. I was even able to browse the internet while it was rendering.

I think it's ZE inconvenient of a 32 bit render vs a 64 bits render ...

Number of polygons has no importance for memory, it only affect the rendering time.
Even if you use 128 bytes per polygon it gives 13M for a 100,000 polygons mesh.
I don't know how efficient is Poser internally, probable bad. In theory the important thing should be the number and size of the textures. The same texture applied to 100 objects should use the memory of only one texture.

You can find how much memory is used by Poser clicking CTL-ALT-DEL and it will open Windows task manager, in the processes tab you will see the memory used by Poser.
You can leave task manager open and add elements, textures to the scene and see how memory use changes.

How about you first tell us which Poser and Windows version you're using, so you can get some useful advice?

if the OS is still 32bit, adding more than 4Gb of ram is a pointless exercise ( if PC ).
AFAIK  Poser can only access up to 2Gb of ram as an application, but if it is 'large address aware'
using the /3GB switch in the boot.ini may help with the out of memory problem.
i had a problem with a scene in DS3A 32 bit, could not render it.( i have 3 Gb of physical ram installed ) altered the boot.ini to /3GB and the scene rendered fine.

Dizzi is right. There are different answers for Poser 6 versus Poser 7 as to how much memory you need. P7 introduced a texture cache that supposedly means you use the same amount of RAM regardless of the number and size of your textures. Whether that really works right or not is questionable, IMO. Not sure. For Poser 6, that's definitely not the case and you have to consider the total memory needed by all textures. But ... P6 also has a render setting for Max Texture Size which will influence this, as it can shrink the textures before using them.

Despite what you were told above, polygons do matter. For example, a single figure comprising 200K points, connected up as 100K polygons, along with just 20 body morphs will consume around 138 MB. Put 10 of these into your scene, even if they are the same V4, and you are using 1.4 GB of RAM just for the base geometry just for posing them.

Then you have to consider the implications of rendering. For any given bucket, the polygons and vertices visible through that bucket are copied to the rendering data structures and moved from model space into world space. The bigger the bucket, the more of these are kept. If two distant figures can be seen in a given bucket, nearly their entire geometry is copied into the renderers data structures, sans morphs of course.  So decreasing bucket size has a significant impact on rendering resources. When you have chewed up a lot of RAM just for modeling/posing, there isn't much left to do the rendering. Poser 6 and 7 have a 2 GB limit per process.

However, you can expand your use of RAM by rendering in a separate process with P7. This means the modeling data does not have to share process address space with the rendering data. The renderer can have 2 GB all to itself just for world-space polygon and texture info.

We have to also consider the implications of displacement. You bring up an interesing point about looking across terrain at the horizon. Does your terrain use displacement? Then, bingo, looking towards the horizon will include a bigger percentage of the terrain geometry. The relevance of this is that Poser is a REYES renderer, and it subdivides your geometry into micro-polygons. The degree to which this can explode your RAM requirements varies with the geometry and viewing angle and the Min Shading Rate, believe it or not.

You mentioned nodes - nodes are cheap with regard to RAM. They are insignificant and you need not pay attention to node count. I have had no problem rendering a scene with various props collectively comprising 10,000 different nodes.

But when those nodes create displacement, and you get enough micro-polygons in a single bucket, RAM starvation is easy to achieve. When I was doing extensive experiments to verify this, I successfully crashed Poser using only a single polygon. I put a Noise node into the one-sided square hooked into displacement. I then shrank and zoomed the camera into it so I was like a tiny bug floating over a tiny but very detailed terrain. Crash, big time. But it looked cool before it died.

Note that the texture cache that BB mentions applies only to FireFly, not the OpenGL preview. If you're working with many textures, switching from textured shaded to smooth shaded mode will reduce memory usage. 

Regarding the texture cache, I have noticed that Poser8 writes texture cache files (*.exr files) in a temp directory on my harddisk. The path to the temp is...

c:Dokumente und EinstellungenMyNameLokale Einstellungen
TempPoserPosertexturecache

Well, I guess it did it before SR1 too, but after installing SR1 I noticed that those cache files doesn't get deleted after closing Poser. Those files are quiet big and can easily amount to 1 GB after just one short Poser session. Shouldn't they get deleted automatically?

By the way, how much RAM you guys have?

RAM does not matter. Poser is restricted to 4GB address space as any 32 bit application, so only the 64 bit firefly of Poser Pro is able to access more memory. And that virtual memory can come from RAM or swap file. Even a PC with only 512 MB RAM can render a Poser scene that uses 1.5 GB of memory.

Poser can use up to 2/3 GB on 32 bit Windows and 4GB on 64 bit Windows. So more RAM won't help you anything - for rendering only if you got Poser Pro.

I am running Poser 7 on amd athlon 2.08 ghz processor with 512 mb of real memory and system managed virtual memory (80gb free disk)  I typically render three figures with clothing and props  but i use 800 x 600 or so sizes. (max 1024 x 768 cause I like to view the whole pic) I once did 3000 x 2000 for printing .

I sometimes reduce 4000 x 4000 textures down to 2000 or even 1000 depending on what they are used for . Background prop get lower res textures. These are named as file_med or file_low so there is no confusion over whats being used.

with a 32 bit operating system more than 4 gb of memory is wasted and you may find the system doesnt recognise the whole 4 gb but only 3.5.  If you run 64 bit then more memory is better because it 2gb +2gb per task for 32 bit apps, the system can put operating system tasks in extra memory.

Quote - Despite what you were told above, polygons do matter. For example, a single figure comprising 200K points, connected up as 100K polygons, along with just 20 body morphs will consume around 138 MB.

This is a size of a cr2 file and not the memory used. Cr2 fules are text files and not binary and not allocated bytes of memory.

Rendering only needs some buffers and it doesn't matter the number of polygons of a mesh, what matters are the dimensions of the mesh, even so the memory used is not so big.
Subdivision doesn't use more memory and a z buffer render uses more memory than scan line or raytracing renders.

Do you want to know how much memory Vicky4 is using? Click CTL-ALT-DEL and look in the task manager and see it by yourself.
Two Vickies4?, just do the same and see..

Quote - RAM does not matter. Poser is restricted to 4GB address space as any 32 bit application, so only the 64 bit firefly of Poser Pro is able to access more memory. And that virtual memory can come from RAM or swap file.

Well my crashes are only when rendering anyways. Poser 8 itself doesn't crash at all. So I'd assume Firefly would be able to address 16GB of RAM as a 64-bit application? And if not, rendering in 4 different processes would then make each process able to address 4GB?

About displacement maps, I just disabled my displacement maps and tried to render, and it crashed the same. All frames of the scene renders just fine, but just that one that views the ground as it fades on the horizon crashes. If I move the camera so that it can't see the horizon, it won't crash.

It's a Poser's error, nothing to do with memory.

• Go to the frame that crashes and save the scene (pz3).
• Quit Poser and open it again loading this pz3, render only this frame and see if crashes.
• Proably it will crash, if not ignore the following and it is another story.
• If crashed, remove some element from the scene, save as another pz3, render this frame and see if crahes.
• Repeat the process until stops crashing or is nothing left in the scene.
• If stopped crashing add again elements or load a previous pz3 and remove other element.
• Repeat until you identify the element that is the cause of the crash, probably will crash with only this demoniac element in the scene.
  Depending on the results maybe you can get a clue of what is happening.

Quote - Poser 8 itself doesn't crash at all. So I'd assume Firefly would be able to address 16GB of RAM as a 64-bit application? And if not, rendering in 4 different processes would then make each process able to address 4GB?

Poser Pro's renderer is 64 bit, not Poser 8's. You Poser cannot render in 4 different processes, just in 1 with multiple threads, so that won't help you.

So, are you using a 64bit OS or not (probably not). And is your problem really memory related, did you check the taskmanager?

I am using Vista 64-bits, Poser 8 SR1, have 4GB of RAM, and I always try to leave task manager open with the Performance tab selected where it shows RAM and CPUs usage. Thats actually how I know it crashes sometimes: all CPUs are steady at 0% activity (because when rendering using "Make Movie", you cant see whats being rendered).

The RAM usage starts usually at 2.7GB total, and goes up, up, up... until it gets to 3.81GB. Then it oscillates there between 3.81 and 3.75, and eventually it'll crash.

Btw, mostly it will only crash on scenes where the camera is poiting to the horizon, where you can see the ground fade away (even though the ground isnt that big, its usually the actual size the GROUND object comes in Poser). So the same scene that crashes, if I just move the camera to an angle where less ground is showing, it will not crash. I do believe this is indeed related to RAM usage, as it many times crashed with that window saying its out of RAM, and also in the past I got rid of this problem by putting more RAM (from 2GB to 4GB).

Also, the problems I have are with 0.05 Shading Rate. If I use 0.20, I have no problems but the earth ground texture won't look as sharp as 0.05.

Quote - Also, the problems I have are with 0.05 Shading Rate. If I use 0.20, I have no problems but the earth ground texture won't look as sharp as 0.05.

That makes sense. You are experiencing the same thing I did with the noise node and displacement - micro-polygons are created based on the Min Shading Rate. More precisely, the Min Shading Rate roughly specifies the area of a micro-polygon. Actual shader evaluation happens at the vertices of the micro-polygons.

When you make the Min Shading Rate .05, you're saying you want roughly 20 micro-polygons per pixel in your render. That means all the geometry you see is cut up into millions of tiny pieces and these tiny pieces are evaluated.

Do you have smoothing enabled? Smoothing will trigger micro-polygon displacement, even if you have displacement turned off. Smoothing with a very low shading rate results in an enormous number of micro-polygons.

Now, the micro-polygons are only built on a per-bucket basis. That's why decreasing bucket size can reduce the amount of memory you need.

Suppose you have a bucket size of 32. That's 32 by 32 pixels, or 1024 pixels in each bucket. Now with MSR = .05, you have at least 20 * 1024 or 20480 pixels per bucket. This doesn't sound like much. But when you have a single polygon that is much bigger than the bucket is (from the cameras point of view) then the entire polygon is cut up, even though not all of it is needed. So if you have big wide polygons, Poser actually makes a lot more than 20480 micro-polygons for a given bucket. It could easily make millions or tens of millions, depending on the geometry.

When you view these polygons across a landscape, many more of them fit into a bucket vertically, so many more are cut up. Let's say you managed to arrange your viewpoint so that 100 polygons are visible in a single bucket that includes the horizon. These 100 get divided into 100 million micro-polygons. Each micro-polygon is 36 bytes, so now you are into 3.6 GB needed to hold them just for one bucket. Poser dies.

This is similar, though not exactly the same as my test of a single one-sided square, rendered with an extreme zoom. The single polygon effectively gets exploded into the equivalent of a 100K by 100K render, of which only a tiny piece is actually needed for a given bucket. Poser dies.

By the way, a single naked hairless V4 with Morphs++ loaded and no textures on her consumes 36 MB of RAM, according to Task Manager. Kawecki likes to suggest things to try, but he doesn't try them himself. I suggest you pay attention to what I'm telling you.

Do you have Texture Filtering on for the ground texture? Try turning that off, and go to MSR = .5. I bet it looks great and renders a lot faster and uses a lot less RAM.

I have a scene with nothing in it but a Poser Hi-Res sphere. I have scaled the Sphere by 10000% horizontally, so it forms a large rounded disk. A curved surface with relatively large polygons, viewed from edge on.

This is how it renders.

Each bump is a render. The wider the bump, the longer it took to render. The higher the bump, the more memory was being used.

The first bump is with MSR=1 and Polygon Smoothing turned off in render settings. Quick and small.

The second bump is with MSR=.5. Slightly taller and wider.

The third bump is with MSR = .05. Twice as tall (twice as much RAM used to render) and it took 4 times as long.

The fourth bump is with MSR = .05 and Polygon Smoothing enabled. Now the RAM needed skyrocketed in the beginning, when Poser was doing buckets near the horizon. As it moved lower it was no longer including so many polygons in a single bucket, so the memory use dropped.

If you were using a ground prop with MORE polygons, not less, it would actually use less memory. The problem is the micro-polygons are built for an entire real polygon. So if you have big real polygons, you have many more micro-polygons, even if the bucket size is pretty small.

The first four renders are from before.

In #5, I changed the camera focal length from 100mm to 200mm, magnifying the distant polygons. The memory use went up more than before.

In #6, I changed the camera focal length from 200mm to 300mm. The memory use went up still more.

In my little test case here, I doubt I could get it high enough to kill Poser. But clearly the particular circumstances of bucket size, micro-polygon size, terrain geometry, and your camera angle and zoom level are all conspiring to send your memory needed into the stratosphere.

I increased my bucket size from 32 to 64 and rendered again - that's the last peak on the right.

This time it went a little higher, and started to come back down as it worked below the horizon. But ... Poser crashed!!! That's the precipitous drop at the end.

Weird. It should not have crashed. It was not out of memory at all. In fact, it had given back a about 500 MB. Something must be buggy. Too bad I didn't save the scene. I bet I could reproduce that crash at will. SM would like to see that one.

Oh, if SM wants to see Poser crashing, all they have to do is drop by for some beer.

I'll try your suggestions after it finishes rendering. I increased a bit the MSR for the ground. Its at 0.1. I know that at 0.2 it won't crash at all, and at 0.5 it will definitelly not crash, but I'm affraid that at 0.5, the texture will blur a bit and the ground won't have that look I want. At 0.05, it looks so good that I can see the bacteria crawling over the specks of dirt.

You might try using two copies of the terrain. Slightly rotate and position one copy so that it crosses the other copy in the middle distance.

Set a low MSR on the one you can see up close. Set a higher MSR on the distant one. You can set MSR on each actor. The problem is the distant parts, which don't need a low MSR, so you should be able to have the best of both.

Quote - Do you have Texture Filtering on for the ground texture? Try turning that off, and go to MSR = .5. I bet it looks great and renders a lot faster and uses a lot less RAM.

Texture Filtering on the ground texture is set to Quality. So you're saying to set it to None and set the ground Min Shading Rate to 0.5?

If the problems comes from the ground plane replace it, as suggested, by a high resolution plane, probably you can find one used for dynamic clothes.
Poser ground has 22x22 polygons, replace it by one with 100x100, it will give 10,000 polygons that are not too much but will reduce greately the clipping and subdivion problem.

Another possibility is that the normal of a polygon viewed from the camera becomes exactly 0,0,0 (a line), this normally doesn't happen, you are using floating point and always will give some small number even very small. But the probability to happen will increase with objects very far in the horizon and the computation can give a denormalised floating point value, a NaN or a normal exactly 0,0,0.
Poser in this case should have to do is not render this polygon or render it as a line, but if instead tries to render it as a polygons very strange things can happen and not only a crash.

Well I think the issue was really the very low MSR on the very large ground plane. It's kinda sad, though, to know that Poser's renderer will only use 4GB of RAM always, so its no good to upgrade my hardware.

I'll try also some of Baggings tests to see what happens. So far my scene has no actors. It's supposed to be an brazilian indian preparing the ground for planting, so no other app was up to this challenge like Poser. And he can't be naked either as kids will probably see this, so I gotta venture with cloth and collisions... oh boy... well, maybe just a loincloth won't be that hard to do.

Well.., Indians and statues cannot be nude.
Are they planting suggar cane?

" so no other app was up to this challenge like Poser"
Actually vue is up to that challenge.  If you had it you can import your Brazilian M4 into the scene and put him to work in awesome scenery.
Love esther