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

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

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.