I'm asking this about Poser Pro 2010, but I guess this probably also applies to all Poser versions using Firefly, but maybe not.
I'm wondering why its first render pass in a scene is so... strange, I dunno, broken up or whatever.

What I mean is, if I load a figure, and hit render, first it obviously has to load all the textures into memory - or I guess its storing them in a folder on the disk temporarily.
Why does it do that by the way? What's wrong with using RAM, or just accessing the textures from the runtime location instead of making copies?

Then it has to calculate any shadow maps. No big deal there (although I'm sure it could be optimized far, far better, being that it seems to do this slower than every other render engine I've ever used)

But where it gets weird is that the first time around rendering, it will only use maybe 5%-90% of my CPU. I have a quad core and I can watch that number jump up and down wildly, but mostly it uses around 25% - a little of each core. That's maybe an average, and it will frequently drop down to maybe 5% and stay there for a while, jumping around  between 5-10%, up to 80%, back down, back up....

I'm thinking it's storing something else into RAM or doing something - who knows, maybe thinking about the scene. ;-)

But all subsequent renders will use 100% of the CPU and will be pretty fast. Not bad, really, but that first render is a killer, taking maybe 5 times longer than all others afterward.

And I see this behavior all the time. It's not just a coincidence. I was going to ask about his a week ago, but I thought maybe it was just one scene in particular, but now after testing it extensively, I've determine it's just normal Firefly behavior.

What is going on - what's Firefly up to? Why can't it do that first render as quickly as all the later ones? is it still loading textures or shaders or something that first time around and that's what holds it up?

By the way, I'm not talking about GI and IBL, just plain old raytracing with some shadow mapping too.

Firefly loads and optimises the textures which, on a complex scene, can take a while. This is RAM rather than CPU intensive.

Why are you using depth-mapped shadows? Raytraced are better.

Precalculating IDL and rendering should both use your CPU at close to 100% on every thread on every core.

What kind of quad-core CPU do you have? What is the bucket size set to?

Well the scene I'm working on that prompted me to write this is about 4.5 GB. Three figures with clothes and hair and a whole bunch of props.

I do use raytraced shadows yes, but I'm not going for ultra realism, more like artistic effect, so I also have alot of lights that use shadow maps too.

Bucket size is set to 64. Windows 7 x64, 8 GB 1064 RAM, Pentium quad core Q9550 (2.83 ghz slightly OCd to 3.1 ghz and very stable btw. )

Like I said, after it finishes that first render, all the others fly by. Surprisingly fast, really - much quicker than Poser 7 Pro Pack ever was.

Quote - What I mean is, if I load a figure, and hit render, first it obviously has to load all the textures into memory - or I guess its storing them in a folder on the disk temporarily.
Why does it do that by the way? What's wrong with using RAM, or just accessing the textures from the runtime location instead of making copies?

It does this for at least a couple of reasons, the main on being that the new files written to disk include several mipmapped LODs, and caching them in this format means that they can be paged in as required to avoid memory problems.
This is an important improvement and negates any texture size / quantity issues during rendering (preview is another matter though).

Quote - It does this for at least a couple of reasons, the main on being that the new files written to disk include several mipmapped LODs, and caching them in this format means that they can be paged in as required to avoid memory problems.
This is an important improvement and negates any texture size / quantity issues during rendering (preview is another matter though).

Ah I see, thank you for explaining that. :-)