Any way to bypass this?
When/if Poser allocates more than 1.5 GB of memory, it enters what seems to be an infinite loop: No error message, no rendering (although it still uses 99% CPU). You know it has happend because the cursor is free (no hourglass), the screen refreshes faster than usual, and you can drag the render progress bar window freely around.

Using Process Explorer to check what Poser might be doing, I noticed that each time Poser had allocated 1.5 GB (and not an octet more) and gone sour... I've waited it out once, but after no single bucket was rendered in a whole week, I killed it.
It happens with different scenes on my 4GHz Athlon with 2 GB of (physical) RAM, but also on my old 3.2 GHz Athlon with (also) 2 GB RAM. Both are dedicated computers, nothing else is running on them. There shouldn't be any memory problem, since the total memory usage never goes over 1.6-1.7 GB, less than the available RAM, no need to swap (and my RAM is clean, both computers have passed 2 days of Memtest86 and 2 days of 95prime with no error). The suspicious thing is Poser always croaks at 1.5 GB, that can't be a coincidence.

And no, reinstalling a clean Windows (2000 or XP Pro) and Poser 6 (SR2) doesn't change anything either.

Any way to fix this? It's really a showstopper, especially for scenes which can't be cut in pieces (because of reflections and shadows).

Thanks in advance (even if I don't have much hope)... :-(

Nope. Thats the limit (though I thought it was 1.2 GB)

Hopefully the bottleneck, stranglehold, chokepoint (add your own :) ) will be done away with in Poser 7 and beyond.

It's (mostly) a Windows limititation.
The normal per process limit is 2GB (code and data), if a program is specially compiled and linked (with the appropriate flags) then the per process limit is 3GB.

Unless Poser is turned into a true 64 bit program (running a true 64 bit machine / OS), then this is as good as it gets.

But it's mainly a Poser limitation.  With 32-bits, access to 4GB addressing is available.  Windows limits this (for some unknown reason) to 32-bits signed which brings it to 2GB (or 3GB with the switch).  Poser imposes an arbitrary limitation beyond that to the 1.2 or 1.5GB size.  This is funny since Poser textures and polygonal meshes consume vast amounts of memory.
What I want to see is how eFrontier is going to handle the ever-increasing 64-bit market (where memory is only limited by slots, motherboards, and memory module sizes - all of which are sure to grow to allow unheard of memory sizes: 16GB, 32GB, 512GB, 2TB, and onward for some time).  Three or four years from now, when many systems are 64-bit multiprocessors, will Poser still be the fossil that it remains?

Quote - It's (mostly) a Windows limititation.
The normal per process limit is 2GB (code and data)

I would already be happy if Poser was able to handle the standard 2 GB; Right now it dies at 75% of that, that's why I say it's a bug.

I really hope they will fix that ASAP. It makes Poser useless for people wanting to render 1-2 clothed figures in a somewhat realistic scenery. AFAIK DAZ|Studio can now use multiple processors; I love Poser, but it is really starting to look old.  :-/

The key is thing is not to forget that the 2GB limit applies to both CODE and DATA.

D|S is subject to the same per process limits.

And I agree that Poser is long over due for a complete rewrite, but such an exercise isn't without it's own problems and consequences.

Quote - The key is thing is not to forget that the 2GB limit applies to both CODE and DATA.

Sure, but actually Poser caves in when code + data are only 1.5 GB worth. Heck, even adding the memory Windows uses, the total memory usage doesn't even come close to 2 GB.   :-(

A complete overwrite? Yes, that would be great of course, but I'd already settle for a true 2 GB memory limit.

Right now I have to export the scenes and render them in Vue (for instance). Thatfor I can't use all the nice features of Poser. So why would anyone pay for an app just good to apply textures and poses, and move figures around? D|S does that for free.
My point is, e-Frontier better get a move on, instead of answering "it's not us, it's your computer".  :-/

I came with the same problem and resolved it... I didn't resolved the memory issue, but found that the main problem are the incredible high realistic textures...

My scene did not have to much things: a clothed Victoria 3 (several seperate clothes), a scene (The Ruins by Stonemason) and the VAP car by Sanctum Art. Even with the Maximum texture size set to 2048, i couldn't render it... And i have 2 GB of RAM.

The thing is that the background (in my scene the VAP car) don't need the texture size to be 2048 pixels. And the car has a lot of high resolution textures. The main problem is that you can't say in Poser that for this object, i want to use a maximum texture size of 512,

What you can do is resize the textures and use them... The memory usage will be reduced and you will be able to render your whole scene at once. This can be a long long work... That's why i made an application to do it "nearly" automatically (you must select which textures you want to reduce). The app is actually in beta testing... but will soon be available (for free, for WinXP with Framework 2.0).

Textures are already at 1024 (Poser default max texture size)... Not to mention about a third of the figures use Poser materials (no textures) to economize memory... No, my problem can't be solved through texture tweaking; My background is a procedural texture too (starry sky).

Of course we can go back to using flat colors, but I'd rather not...  I'd rather have e-Frontier fix their mess.

Quote -
... That's why i made an application to do it "nearly" automatically (you must select which textures you want to reduce). The app is actually in beta testing... but will soon be available (for free, for WinXP with Framework 2.0).

That sounds good, but you can do this now with Irfanview with a batch conversion. However, in Irfan all the selected textures have the same operation applied to them (ie. everything has to be reduced by 50%, converted to greyscale, etc). Will your program be able to apply different reductions to each texture?

That's why Poser should have been a Pose,animation and scene setting tool.They better improved the rigging and the character designing tools and added some advanced export  options for rendering in your favourite 3D-App.

Quote -
And I agree that Poser is long over due for a complete rewrite, but such an exercise isn't without it's own problems and consequences.

Agreed. Poser is still, at it's heart. 1995 Mac (!) code. Real improvements to the program, including better posing ability and boning, could well mean that existing figures become incompatible?

At least you will need a Figure converting tool that welds  the cracked mesh and reads the bodyparts as weight-maps.And it must be able to creat morphs from selections.Ask the programmers here,Is it possible to do?

Quote -
That sounds good, but you can do this now with Irfanview with a batch conversion. However, in Irfan all the selected textures have the same operation applied to them (ie. everything has to be reduced by 50%, converted to greyscale, etc). Will your program be able to apply different reductions to each texture?

I know you already can do it with IrfanView or any other good picture viewer. But what my app does is (i think) better:

• it resize all the pictures and rename them (can be done in IrfanView);
• it change automatically the references in the poser file.
• you can change in which runtime you want to save your textures (but keep the subfolders structure)
• you can do the reduction as you want for each textures individually, for the selected textures or for all textures in an actor (figure or props).
• the resize can be in percent or/and set the maximum texture size.

I'm curious to know how big is your scene and how many textures you are using to make Poser "crash". Does it crash also with a max texture size of 512 pixels ?

it might take 20 texmaps at 4096X4096 (64 MB) for poser to fill up RAM to the 1.5 GB limit. unless, of course, poser was rewriting the same textures (redundantly) to different parts of the RAM, which might cause it to max out quicker than one would expect. but then the big problem, since P5 and P6 were introduced, has always been rendering. hence some people don't waste time trying to render in poser. they use some other app that has 21st-century code in it. so it's a big decision for e-frontier. now that there's no white knight on the horizon to purchase and repackage poser, they're stuck with rewriting it from the ground up.

Quote - I'm curious to know how big is your scene and how many textures you are using to make Poser "crash". Does it crash also with a max texture size of 512 pixels ?

If you mean me, the scene is two Millenium figures, both clothed and with hair, 3 scenery figures (all 3 sharing the same texture), and several plants (half a dozen, all sharing the same texture). All this on RDNA Macrocosm with a skydome; Macrocosm has a tiled texture, skydome a procedural one. So actually there are only 10 different textures @ 1024x1024: Two Mill figures skin and head (4) + 2 Hairs (2) + 1 dress (1) + Scenery figures (1) + Plants (1) + Macrocosm (1). The rest is Poser procedural textures.
No I didn't try to lower the max texture size to 512, since the final render is supposed to be 1200x1200 (trying and failing at 800x800 though).

Just by reading the description of your scene, i would say that it should work...  The textures should load and use about 32 Mo of RAM

You should try to render wtih the Maximum Texture Size to 512. Because if it don't work, it might be something else.

Also, what are your render settings ? Could you post a sceenshot ?
I found that the "Texture filtering" is wonderfull, but uses a LOT of memory.

Finally a last thing... Your two Mill Figures... are they morphed ? Did you inject all morphs to both figure ? Because if you did, they use a lot of RAM too... This might be an issue.

I've know plants to murder a render or two.

Does P6 have the multipass rendering thing? Where it will do relections etc in separate passes?

I've been using P5 alot recently so I can't think offhand.

Interesting to see what Efrontier attempts with the next version. It's heartbreaking after setting up a scene to discover it's going to be one of "those" render sessions with all the problems.

Cheers

Quote - You should try to render wtih the Maximum Texture Size to 512. Because if it don't work, it might be something else.

Nope; As I said in the first post, I have this problem with many different scenes; And the only thing they all have in common is that the memory usage goes over 1.5 GB.
And removing some pieces (so memory usage goes under 1.5 GB) makes them "renderable" again, that's how i usually manage to render in Poser.

It really is a memory allocation problem, especially since (except that, and a couple of well know minor bugs) Poser 6 is rock solid on my computers. Never had an unexpected crash.

Quote - Also, what are your render settings ?

Always: Raytracing, shadows, displacement, no filtering, no smoothing, the rest is default. I've tried a bucket of 8, doesn't change a thing. BTW shadows are raytraced, economizes memory too...

Quote - Finally a last thing... Your two Mill Figures... are they morphed ? Did you inject all morphs to both figure ? Because if you did, they use a lot of RAM too... This might be an issue.

Morphed indeed, but just the couple morphs I used are injected...

(My, is Rendo slow)

If it's a killer pz3 that you do not want to rebuild then, you may have to bracket in your figures one at a time. Better, see if it will render the Skydome by itself and then add a figure at a time. This at least will tell you what is tripping up the Ram. You may have to render in layers or, splice 2 renders in post. Many have to resort to this.

That's what I usually do, except that in some cases it isn't possible to render in layers: Because of reflections on other objects, because of shadows of some objects affecting light conditions on other objects, and/or because actually a couple figures are imbricated, like people inside a car for instance, with glass transparence/reflection and car shadows affecting them.

In this specific scene all I could easily remove is the skydome, but I don't expect it will change much since it doesn't even have a texture. As for the figures, they are inside the vegetation, and if I have to spend hours in Postwork drawing stencils and faking shadows, it isn't worth it; I'll try rendering in Vue (but it's a pain, because, as I said, most textures are Poser procedurals).

Actually most of my scenes are too heavy for Poser, despite me losing a lot of time improving memory usage.  :-(

Apparently Poser is only good for rendering NVIATMAS: Render naked Vicky with her sword, paste on pic of temple, no memory problem.  :-/

I don't know if you own "GlowWorm". It allows to do multiple render pass. You should then render the reflection pass and add it in a normal pass.

One last thing... Some objects (hairs are often concerned) have problems with Poser. They use a huge amount of memory...

I hope that the next version of Poser will allow to have an "unlimited" render... like the Vue render system.

Hairs as in Dynamic Hairs are particularly awful for memory, and when in an animation... ugh.

Quote - I don't know if you own "GlowWorm". It allows to do multiple render pass. You should then render the reflection pass and add it in a normal pass.

Yes I have it, but unfortunately, since Poser can't load the scene, it doesn't render anything...

Just a last request... Can you do a "sceenshot" of your scene as it appears unrendered ?

Why not, but it will have to wait till I get home (at work right now).
That been said, I could make a whole gallery with all the scenes on which Poser chokes...

It's not a memory bug, but a limitation of the hardware. The current 32-bit CPUs can only address a maximum of 2 GB memory. When the computer starts up, at least 512MB of memory is eaten up by the operating system. That leaves about 1.5GB RAM for program code and data. The solution, as mentioned earlier, is a move to 64-bit hardware and software. The Apple Mac G5 and OS X are both 64-bit, but most software is still written for 32-bit machines so it cannot take advantage of any extra RAM. I don't know if Apple's Intel Macs are 64-bit CPUs, but I suspect they are not due to cost and heat isues. With Intel building duel core CPUs and software able to recognise it (like Photoshop already is), that'll cut render times in half but we'll still need Poser written in 64-bit to clear that hoop. keepin' my fingers crossed

Quote - It's not a memory bug, but a limitation of the hardware. The current 32-bit CPUs can only address a maximum of 2 GB memory. When the computer starts up, at least 512MB of memory is eaten up by the operating system. That leaves about 1.5GB RAM for program code and data.

That's 2 GB per application and not for all programs. Processor architecture and Windows improved a bit since the stone age ;-)

Quote - When the computer starts up, at least 512MB of memory is eaten up by the operating system. That leaves about 1.5GB RAM for program code and data.

Even if the 2 GB limit were general, it wouldn't explain this.
As I mentioned in my posts, Poser crashes & burns when the overall  (Poser + Windows) memory usage is only 1.7 - 1.8 GB (Poser taking 1.5 GB, Windows 0.2 - 0.3 GB). That leaves a 0.2 - 0.3 GB headroom.

BTW, sorry, forgot to make that screenshot yesterday. I had big server problems at work till late in the evening, and when I finaly got home I had completely forgotten about Poser stuff...

I would get recommended virtual ram settings from MS for your real Ram. I thought Real + virtual =2048t addressable.

Quote - I would get recommended virtual ram settings from MS for your real Ram. I thought Real + virtual =2048t addressable.

Yes, indeed, I have a total of 2GB (real, physical) + 4 GB (swap, virtual) = 6 GB of RAM. But Poser never managed to saturate my real RAM, since it's deceasing at 1.5 GB.
Poser should peak at 2 GB, for a total of 2.2 GB (Poser + Windows), thus using 0.2 GB of swap. It never did.

(BTW my Windows is very lean, since it's a dedicated computer: 200 MB of memory usage, counting the disk cache (I've toned down using the "application server" setting, since Windows just loves using all memory for making a huge disk cache, and having to swap afterwards...).)

And all this is happening on two different computers, one running Win2000, the other WinXP Pro, both dedicated to CG, clean of any parasite app. Different chipsets, different processors, different video cards, yet both have the same problem: If Poser (6 SP2) allocates over 1.5 GB of memory, it won't render a thing...  :-/

I can't call that a coincidence, nor a hard/software problem.

Not sure but, 4 gigs virtual? Even with the "switch", nothing can exceed 3gigs. I've not messed with ramm in a long time (superstitious) since things are going ok. There is a guy (svdl). IM him... he teahes comp science in Netherlands and posts here. He's built a few nice pcs and holds the record for V3's in one scene.

Quote - Not sure but, 4 gigs virtual? Even with the "switch", nothing can exceed 3gigs.

Ideed, I went overboard, but since I had 230 GB of free space on the system disk, I just entered RAMx2, as usuall...  ;-)

Quote - I've not messed with ramm in a long time (superstitious) since things are going ok.

:-D

Quote - There is a guy (svdl). IM him... he teahes comp science in Netherlands and posts here.

I've heard about him, I have some nice freebies from him.
I don't think he can do wonders though; I'm a IT professional myself, I have built and designed dozens of PCs, even for professional use (you know, the kind you get sued for compensation when it doesn't work as expected...).
You can make renders with thousands of Vickies given enough time, by layering or by pasting rendered figures on invisible billboards. But some pics can't use it. Add a couple reflective surfaces, and neither layering nor billboards are possible anymore...

I have two gigs of RAM PC3200 and a 3.4 gig P4. I still get out of memory errors!

I have four gigs on a dual Xeon (even though one of them is never used by 32-bit XP).  I still get out of memory errors! ;)

The only way to overcome this is:

64-bit computer which accepts more than 2-4GB memory. (check)
64-bit OS (check for both Windows and MacOS - and Linux and other OSs)
... and the crucial one dependent upon eFrontier
64-bit Poser (nope)

No way around that last one.  Even if everything is 64-bit and you have terabytes of memory, all of no use without a 64-bit application to utilize it.

Waiting for a 64 bit version, accepting several processors and doing distributed rendering, I already would be happy if they fixed Poser so it can use the standard classic 2 GB of memory.

That would already make a 25% (that's a quarter!) increase for everyone, on your existing Windows and hardware...    ]-(

Yep.  Why the addressing is limited like this is a mystery.  You'd think that just by virtue of updated OS process allowances, Poser would be able to access the full 32-bit range given by Windows or MacOS. Is there somehow some built-in check to avoid using more memory than a certain amount?

In this case I guess it would make a gracefull stop, give an error message, something looking like intelligent design.

Actually in these situations Poser goes in what looks to be an endless loop, so it really looks like a bug in the render initialisation to me.

It's a very different behaviour to the messages Poser gives when it really runs out of memory during rendering (like when you use a too big fixed bucket).

Intelligent Design?  Poser?  I was thinking more along the lines of Creationism.  ;0)

It is possible that there is a mismanagement in rendering memory.  Maybe their approach is to preallocate all the necessary memory in order to expediate render and it isn't working as envisioned. ?

From my experience, it is bad to treat memory errors in a monolithic form - it only leads to inflexibility or crashes.  On the other hand, this smacks of not correctly evaluating dependencies - one missed item is not checked for validity and the entire process collapses.

Quote - Intelligent Design?  Poser?  I was thinking more along the lines of Creationism.  ;0)

:-D   ;-)

Quote - On the other hand, this smacks of not correctly evaluating dependencies - one missed item is not checked for validity and the entire process collapses.

Could be.  Anyway - its a bug, and they should fix it. I can understand it didn't matter when nobody had more than 256 MB of RAM, but now everyone has 2 GB, even people who don't do 3D start having it.
Not to mention we're about to switch to 64 bit.

Quote - > Quote - Intelligent Design?  Poser?  I was thinking more along the lines of Creationism.  ;0)

:-D   ;-)

Quote - On the other hand, this smacks of not correctly evaluating dependencies - one missed item is not checked for validity and the entire process collapses.

Could be.  Anyway - its a bug, and they should fix it. I can understand it didn't matter when nobody had more than 256 MB of RAM, but now everyone has 2 GB, even people who don't do 3D start having it.
Not to mention we're about to switch to 64 bit.

UH, not everyoine has 2GB of RAM.

Quote - UH, not everyoine has 2GB of RAM.

Not yet.

When you'll upgrade your computer, will you only buy 256 or 512 MB? I bet you'll go for the max, since it's only marginally more expensive.

aye :( so you say that poser will crash in render on a computer who has 2gb of physical ram ? (and to say i bleeded my veins on xmas to get a brand new pc for poser mainly, with this exact amount of memory :( does the 1.5gb alocation limit concerns both physical and swapfile combined ? is there any tweak tool to FORCE a process to only be allowed to take up to a certain given amount of ram and not more ?

Quote - Yep.  Why the addressing is limited like this is a mystery.  You'd think that just by virtue of updated OS process allowances, Poser would be able to access the full 32-bit range given by Windows or MacOS. Is there somehow some built-in check to avoid using more memory than a certain amount?

Nope, no built-in checks. Poser is using standard malloc+free/new+delete for memory handling. And I have seen it go up to 2.5GB VRAM usage on OS X (haven't tested on XP in a long time). If it bails out earlier, it means that a memory request has been rejected by the OS.

But why the memory bug fix?  I have 4GB of memory and, for 4 and ProPack I think, if you had your VM set to over 2GB, Poser would do odd things.  Why is this?

From Technical Support:

The virtual memory is probably set very large, on the order of 4 gigs or more. Reduce the total minimum to 2 gigs or less. Restart the system.
For users who have 2 gigs or more of RAM and virtual memory, a memory updater would have to be applied.

and

This memory handling updater will allow Poser Pro Pack users with greater than 1 GB of total memory (RAM + virtual memory = more than 1 GB) to run normally.

Since systems have been 32-bit for some time, this makes absolutely no sense and does not agree with your statement (since almost every other application does not have this strange type of issue).  How many applications required a patch in order to support more than 1GB of memory?

Of course, these issues do appear to have been resolved in P5 and P6.

Robert

Quote - aye :( so you say that poser will crash in render on a computer who has 2gb of physical ram ? (and to say i bleeded my veins on xmas to get a brand new pc for poser mainly, with this exact amount of memory :( does the 1.5gb alocation limit concerns both physical and swapfile combined ?

They will eventually fix this; At least I hope so...

No, the limit I discovered is absolute: 1.5 GB, no matter if it's pure RAM, or RAM + Swap.
I've had this problem before, when I had only 1 GB of RAM, but at that time I thought it was just a problem with Poser not liking virtual memory. But since it persisted after I've got me 2 GB of RAM (and even now I got myself a second computer with another OS version), I don't think there is any doubt possible...  :-(

Quote - course, these issues do appear to have been resolved in P5 and P6.

Precisely. How would a problem that was fixed five years ago still be relevant for this discussion?

Quote - And I have seen it go up to 2.5GB VRAM usage on OS X (haven't tested on XP in a long time). If it bails out earlier, it means that a memory request has been rejected by the OS.

So apparently it is a problem with the Windows version of Poser 6. It's definitely not a problem with my computer(s), Vue 5I (now they've fixed the memory bug) is able to use all my memory without any problem. As I said, I've seen this on Win2000 and on WinXP, on two different computers with different chipsets, so it seems to be a general issue, and not a specific driver/app conflict.
Or, of course it might be I have very, very bad luck, and own the only two computers on which Poser 6 won't work as usual... But somehow I don't think that might be the problem... ;o)

BTW, I imported the whole Poser scene Poser couldn't render into Vue 5 Infinite, and was able to render it in Vue... So there is nothing wrong with that scene either.

Quote - Precisely. How would a problem that was fixed five years ago still be relevant for this discussion?

Because you said they use standard malloc/free (I doubt there is any trace of new/delete in Poser code - C at best, assembly in many cases).  Well, have malloc/free changed in five years?  Was memory allocation different five years ago?  (No, it's been about the same for the past ten or more).  So it is relevant to Poser's superiorly archaic code that these issues persist even though 32-bit systems with such addressing have been around for nearly twenty years.  I will admit that Windows 98/ME and before were not truly engineered to support the possible 32-bit memory spaces, but this cannot be said of 2000/XP (and the issues of 4/ProPack still remain on these systems).

Quote - Because you said they use standard malloc/free (I doubt there is any trace of new/delete in Poser code - C at best, assembly in many cases).

Trust me, there is lots of new/delete in Poser. I have written my good share of it. > Quote - Well, have malloc/free changed in five years?

No, but the Poser code has. The part that caused the old P4 memory problem has been fixed a long time ago.

Quote - Trust me, there is lots of new/delete in Poser. I have written my good share of it.

Should I understand you are one of the Poser developpers???

If yes, do you have any explanation why this happens in Poser 6 SR2? And any means to get this fixed (by e-frontier)?

As I said:

• It's platform and Windows version independant (happens in Win2k and WinXP Pro)
• If Poser allocates >= 1.5 GB while preparing a render, as soon as the little progress window switches to "Rendering", Poser 6 enters some kind of loop; The hourglass cursor dissapears, but Poser still uses 100% the CPU, without doing anything (waited for days - nothing).