Could someone explain to me what the significance of being able to adjust the Firefly bucket size and whether or not to render in "separate processes"?
And/or benefits/detriments?
The manual just kinda glosses over those parts, barely hinting at some mysterious promise of performance increase of unspecified origin if adjusting those settings.
Poser Pro, that is.

I have a 64 bit quad core (Q9550 @ 2.83 ghz OC'd to 3.2 ghz) machine with 8 GB of 1066 RAM and a 300 GB Velociraptor SATA drive. (two other WD SATA drives in it too, but the OS and page file are on the raptor). Running Windows 7 x64.

I try changing the settings - buckets from 32 to  64 to 128, and alternating back and forth between separate processes and... I guess non-separate processes... and I don't see any difference in render times. Maybe a few seconds give or take.

Maybe that's because my PC has more than enough RAM and is using the 64 bit Firefly? Are those settings just for the RAM-deficient running on 32 bits?

If someone could give me the technical lowdown, I'd sure appreciate it. :-)

By the way, the manual says that the 64 bit Firefly render engine will only run in 64 bits if background rendering is selected. Later, on the same page even, it says that if you have a 64 bit system, the 64 bit Firefly render engine will be used. That's a contradiction, and I even see the 64 bit FF kick in in Task Manager, even when rendering to the regular document window.
I've read several people say that 64 bit FF only runs in B/G, but I'm kinda skeptical about that - it appears it runs in 64 bit at all times.

Separate Process means your Operating System will treat the Render as a Separate Process, not part of the Poser Session. (This leads to better Memory allocation.)

Bucket Size is how much the program tries to render at a time, basically.. Smaller Bucket needs less resources.

Make sure you set your machine to 4 Threads and Separate Processes. Then run in Background. Bucket Size for most scenes 64 or 32 should be about right. Simple Scenes you could go as high as 128 without taxing your system.

Not sure where the text you mentioned is located, but the FFRender64 is  not activated from basic Render Command.

Thank you, ratscloset.

I was wrong, it's not the main Poser Pro manual, but rather the reference manual - page 22.

Quote -
If your computer has a 64-Bit Operating System, Poser Pro will use its 64-Bit FireFly Render Engine to access as much memory as possible. To utilize the 64-Bit FireFly Render Engine, you must select Render in Background.

A few lines down on the same page:

Quote -
Poser Pro will automatically select the appropriate Render Engine for your system. If you are using a 32-Bit system and render in Firefly, Poser Pro will use the 32-Bit Render Engine. If you are using a 64-Bit system and render in FireFly, it will use the 64-Bit Render Engine. This allows the Render Engine to access more memory thereby better utilizing available memory.

And I swear I've seen FFrender64.exe in Task Manager even when not rendering to background. Unless that's just the name of the process, regardless.
I'd check it again, but I can't right now.
In any event, I believe you... the apparent contradiction in the pdf had me wondering.

Anyhow, thanks for the 'splain.  :-)
So basically, FFRender64 is operating as if it were a separate program when "separate processes" is selected?

"Poser Pro will automatically select the appropriate Render Engine for your system." should read

"Poser Pro will automatically select the appropriate Render Engine for your system on installation of Poser Pro".

(FFrender64 is not installed on a 32bit system)

Quote -
(FFrender64 is not installed on a 32bit system)

If that's the case, then it does render in 64 bit at all times. I don't have a FFRender32.exe.

Now I don't know what to think. ;-)

but you do have a FFRender.exe.......which is the 32bit.

Yeah I just noticed that.

hmm thinking on it, it could also refer to the right FFRender being selected when you hit render in a separate process - FFrender or FFRender64.

to early. need coffee.

Quote -
hmm thinking on it, it could also refer to the right FFRender being selected when you hit render in a separate process - FFrender or FFRender64.

to early. need coffee.

I don't use "separate process", outside of a few times I've experimented to see what happens. And I know I've seen FFRender64.exe as a running task, regardless of B/G or not, and not FFRender.exe.
shrug

I think I know what's happening here. I probably was only really paying attention to Task Manager when I was using the BG render, to see the CPU and RAM usage. So my belief that I've only seen FFRender64.exe running may be flawed due to not paying attention at other times.

I'd check right now but my Poser box is also my Lightwave box and I have LW chugging away on a cloth sim that's probably gonna take a week, being that LW only uses one lousy core for dynamic calculations...

Poser Pro can render on 64 bit  colour space on either 32 or 64 bits machines. Not to confuse 64 bit colour with 64 bit cpu.
64 bits colour means colours in an image mean each pixel can be any of 2^64 colours (18,446,744,073,709,551,616 colours) in contrast of 24 bits colour which is any of 2^24 (16777226 colours).
To be able to use the huge amount of colours in 64 bits colour space (which generally means using high dynamic range images, or hdri, you must either render to the queue, or use the background render and save to hdr or exr.

Just in case anybody out there was getting mixed up...

In Poser 7, if I don't render to a separate process for a complex scene and I want to cancel the render, I run the risk of Poser locking up on me (before I ran to a separate process it did it constantly). When I switched to a separate process to render and need to cancel, it's immediate and Poser is still fine. Makes Poser happy, makes me happy ;o).

That's what I've noticed now that I render to a separate process. Poser doesn't choke and I don't wanna choke something...lol.

Laurie

Poser Pro is compiled as a 32-bit application. Firefly-64-bit is compiled as a 64-bit application. If one has a 64-bit OS, and runs Poser Pro without sellecting render in a seperate process, Firefly will run as part of the 32-bit Process of Poser Pro. This will mean that it can address about 2gigs of memory. In a seperate process, Firefly 64-bit can access more memory (which is the advantage of being a 64-bit application). Even with a 32-bit machine, rendering in a seperate process allows Firefly to access more memory than if it is run as part of Poser (as the Poser process has its own ovehead). I fail to see any advantage in not using a seperate process.

LMK

Quote -
I fail to see any advantage in not using a seperate process.

Well I can, now. I just did some tests on a scene weighing in just under 2 GB of RAM usage and rendering it in a separate process took 55 seconds longer than in one process.

I have to say that Poser 8 is able to load, manipulate, and render scenes that would grind Poser 7 to a halt or crash it. It also renders faster than Poser Pro (which could also handle larger scenes). I cannot wait to see what Poser Pro 2010 will be able to do.

If the extent of difference between rendering in a seperate process or not is 55 seconds, I don't care much (I don't do annimations). But, if using more complex processing (like IDL) greatly ups the render time, then I am open to changing my mind. Thanks for the test.

LMK

It seems to scale somewhat, not regular, for lack of a better way to describe it. If I back my camera off, where there's less "scene" in the picture, the difference in render times becomes lesser. I guess that makes sense.
And it seems to depend on scene size. Large complex scenes show a greater difference, while a scene with only one figure in it and nothing else will be just about the same speed. I guess that makes sense, too.
So I guess the thing to do is to just take it as it comes, and adjust depending on the scene variables.

I've actually become quite impressed with Poser Pro overall - I definitely think it's the best version yet.
But I think I'll be ordering Poser 8 later this week anyway. In spite of all the problems I've read, the reported increased CPU usage efficiency is drawing me in.