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.

"Few are agreeable in conversation, because each thinks more of what he intends to say than that of what others are saying, and listens no more when he himself has a chance to speak." - Francois de la Rochefoucauld

Intel Core i7 920, 24GB RAM, GeForce GTX 1050 4GB video, 6TB HDD space
Poser 12: Inches (Poser(PC) user since 1 and the floppies/manual to prove it!)

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?

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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.

Eternal Hobbyist

 

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

 Don't sweat the petty things, and don't pet the sweaty things!  ; )

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.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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?

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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.

 

"Few are agreeable in conversation, because each thinks more of what he intends to say than that of what others are saying, and listens no more when he himself has a chance to speak." - Francois de la Rochefoucauld

Intel Core i7 920, 24GB RAM, GeForce GTX 1050 4GB video, 6TB HDD space
Poser 12: Inches (Poser(PC) user since 1 and the floppies/manual to prove it!)

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

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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).

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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).

Obviously, rty says it's still relevant in some respect.

So when was the C++ code added to Poser?  I wouldn't have trusted it prior to the 99 standard (as the language was pretty much a shambles before that - and still suffers to some extent - hey, they're finally making a new standard that'll fix remaining problems and, of course, extend the language).

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone

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

Yes. > Quote - If yes, do you have any explanation why this happens in Poser 6 SR2?

Without reproducing an identical case on my system, I can only speculate. > Quote - And any means to get this fixed (by e-frontier)?

Please understand that I will leave announcements about future company and product plans to the product management and PR people. > Quote - 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).

One of the things happening in the "Rendering" step before the first bucket is drawn is the creation of the raytracing acceleration structures. If the scene renders fine without raytracing, that might be an indication of where to look. It could help to uncheck "visible in raytracing" for objects about which you know that they will not appear in raytraced reflections or shadows. As said above, this is just a guess. If you have a scene with which this problem can be reproduced reliably, I suggest you send a bug report to e frontier tech support so that this issue gets tracked and eventually ends up on the right desk.

Quote - Obviously, rty says it's still relevant in some respect.

I seriously doubt that. The FireFly renderer (which is where the symptoms show up) didn't even exists when that P4 memory limitation got fixed. > Quote - So when was the C++ code added to Poser?

Before my time. And it wasn't just "added", quite some amounts of existing C functions and globals were cleaned up in C++ classes.

Quote - Without reproducing an identical case on my system, I can only speculate.

Well, part of my reason to post here was for other people to check it.
Any scene will do, it just has to be big/complicated enough to make Poser go over the 1.5 GB limit while rendering. For checking memory usage, people can download the free "Process Explorer" app from System Internals (see my first post for link), or use Windows' task manager.

Quote - Please understand that I will leave announcements about future company and product plans to the product management and PR people.

I fully understand. My question was, can you hint to them that there might be a problem?
See below about e-frontier and filing bug reports.

Quote - If the scene renders fine without raytracing, that might be an indication of where to look.

Thanks, I'll check this ASAP.

Quote - uncheck "visible in raytracing" for objects about which you know that they will not appear in raytraced reflections or shadows.

Since I use raytraced shadows, everything counts...

Quote - I suggest you send a bug report to e frontier tech support so that this issue gets tracked and eventually ends up on the right desk.

I've already tried to file a bug report with e-frontier, on a reproductible bug which has been confirmed by other users on the DAZ forums.
All e-frontier had to say is "it's not Poser, it's your computer".   :-/
So that's a bug (fortunately minor) we'll find again in Poser 7, maybe even in Poser 8...

I really don't feel like wasting my time trying to help people who don't want to be helped, so I won't file any more bug reports with e-frontier, unless they show they really want to get Poser fixed, in which case I'm ready to spend as much time as needed to help get it solved.

Quote - One of the things happening in the "Rendering" step before the first bucket is drawn is the creation of the raytracing acceleration structures. If the scene renders fine without raytracing, that might be an indication of where to look.

All right. I tried to render the same scene without raytracing and it rendered fine, but memory usage stayed below 1.5 GB.
So I added another character to the scene, and tried to render that. Right in the beginning, before starting to render the shadow maps, memory usage went up to 1.5 GB, and Poser 6 gave me the "There has been a problem, please lower memory usage, etc" message... At this point Poser was using 1.5 GB, overall memory usage was 1.7 GB.

So the 1.5 GB limit exists also without raytracing, except that Poser handles it better, detecting there is a problem, and doesn't fall into the infinite loop it does when raytracing is on.

Go to the 3DMax forum and search under "'memory"' (last 45 days)

There you will find instructions to install a switch into the boot.ini file of windows to allocate 3GB of memory to programs. It works with 3DMAX and I dont see why it would not work with Poser

Quote - It works with 3DMAX and I dont see why it would not work with Poser

Because Poser isn't even capable of using the standard 2 GB...   :'-(

Thanks anyway.

I tried it, just so I can't blame myself for not having tried, and no joy. My Windows is much faster (I guess it helps memory management of the 64 bit Athlons), it boots in 10 seconds, but Poser doesn't change, it still can't stand using more than 1.5 GB...

BTW, stewer, if you happen to read this, I forgot to say that while Poser is in his loop, if you click on "Cancel", it will show "Canceling...", CPU will drop at 0% and that's all she said.
I've waited a whole night, it never finished "Canceling".

So this loop is:

• Showing the background color in the preview window (always clears the preview).
• Using CPU at 100% but doesn't prevent Poser form refreshing, unlike the true rendering, when Poser only refreshes after having drawn a new bucketfull.
• You can drag the little render progress window freely around, which also shows Poser isn't doing anything serious.
• Of course Poser never renders the slightest bucket.
• Can be canceled, without avail: CPU drops (almost at once) to 0%, memory usage stays high (no memory freed), and the message "cancelling" never goes away.
• This happens when memory usage reaches between 1.5-1.6 GB while initializing.

On the contrary, a "good" render will do the following: (YMMV)

• Show the preview untill the first bucket arrives, replacing the rest of the pic with the background color.
• Poser refreshes only when it draws a new bucket. Between buckets it doesn't refresh.
• The little render progress window can only be moved in the fraction of the second Poser draws a bucket (sometimes). The rest (most) of the time it's pretty well stuck.
• When you click "Cancel", well, it cancels! It takes some time, but it aborts the render.

My usual render settings: Raytracing (2 rays), displacement, shadows, min. shading rate 0.20.
No texture filtering, no smoothing.
Pics always using AO and only raytraced shadows (no shadow maps).

replying to add that I have this exact problem as well.   I never pinpointed the memory limit, so that helps. 

I generally would hide/remove/change the objects in the scene until it would render.   Usually turning off texture filtering would do the trick - but there was a risk of trans-mapped hair looking awful.

Also, there were times I could kill poser, restart and be able to render the scene, so I usually give that a try.   As you say, you can tell right away if it's not going to work - shows background color, poser window min/maxes quickly etc.

Thanks... It really helps to know one is not alone...      :-)

BTW, when a Poser scene is on the limit, you only can render it after restarting Poser. Poser never cleans memory before rendering or after finishing a render; So if you make the same render twice, the first time it will work, the second it will crash. I always restart Poser before rendering. Helps also not to forget to save le latest version of my scene...

Great stuff. I just bought a computer with 2GB of RAM... :(

Still waiting for it to be delived. Hope that my new compy would be running Poser 6 and Everquest2 at great performance. Seems like I have to do with EQ2 until/if this thing gets fixed.

Don't feel bad, those 2 GB of memory will come to good use, sooner or later. Who would buy a computer nowadays with less than 2 GB, unless it's just for using Excel and making Powerpoint presentations?

And concerning Poser, well, let's hope e-frontier will get this fixed, now it's known to exist. Chances are it's just a stupid oversight, 2 lines of code to be fixed (once you have found them...)    ;-)

Well what I am hoping for is new code for Poser 7.

(Oh and the $$$ to buy it :) )

 

 

 

"Few are agreeable in conversation, because each thinks more of what he intends to say than that of what others are saying, and listens no more when he himself has a chance to speak." - Francois de la Rochefoucauld

Intel Core i7 920, 24GB RAM, GeForce GTX 1050 4GB video, 6TB HDD space
Poser 12: Inches (Poser(PC) user since 1 and the floppies/manual to prove it!)

I have the $$ to buy it, but I'll only get the 2 licences of Poser 7 if it can do what I want it to do.

I like Poser 6, I like the way it renders, but to be of any use for me, it has to be able to render...    :-(

I just got a new computer and I'm having a similiar problem. The thing that gets me is one of the scenes I've tried to render did fine on my old laptop with 512mb memory, but does the infinite loop thing when I try to render it on the new machine.

I'd be interested to know if any of you got the problem worked out.

Glad I bought Carrara or I'd be out of luck right now for a render engine.

oh forgot to say the new machine has 2 gigs ram.

The only problem is... 64-bit Windows -- how much more RAM will that need? Microsoft are saying even without the fancy graphics for the UI, Vista needs a 512 Meg machine So, new computer, lots of memory, lots of CPU power, lots of money. And until a 64-bit Poser comes along, also able to take advantage of multiple cores (which seems to be what is providing the big gain in CPU power, rather than the clock speed), and that money is wasted. And I find myself thinking that I am still going to be stuck with thatPoser UI colour scheme. It shouldn't be so impossible to make something the customer can adjust to suit their eyes. It might be Poser X before I can afford that sort of upgrade-everything. Which might not be all that long: it's arguable that Poser 6 is more like a Poser 5.5

Quote - a 64-bit Poser comes along, also able to take advantage of multiple cores

I'd already be happy with a 32-bit Poser able to take one core in account...    :-p
It's plain ridiculous having to import full Poser scenes into Vue to render them because Poser can't.

stewer, if you're still lurking around here, I'm ready (as I said) to help & make all tests needed to pinpoint the reason of the problem. If e-frontiers is interested in solving that problem, of course.