while doing some animations, i have tried to analyse where and what settings will cost time without helping much in terms of output quality. while doing this rather obvious measurements (trimming render settings), i found that creating the *.exr texture cache costs ffrender a remakable ammount of time. this is especially painful while using the queue manager (with or without slave machines) because this process is repeated for each and every single frame.

in poser itself it's just done once for each new texture - as long as you don't quit poser! and even here it hurts, because each time you start a new session this'll be done again ... but because poser never crashes this won't happen very often, you'll argue ;)

well, anyway; here are some numbers:

on my really fast machine(s) i tailored the render time for a single frame to last about 2mins each (measured on repeated renderings directly in poser). and as soon as i pushed the very same scene to the queue, the time went up about 50% to 3mins each. in other words: for a specific scene ffrender needs about 1 minute to build the texture cache and 2 minutes to render the image. now what is this good for? from my findings: for nothing ... as long as you don't edit the source texture(s), the generated cache will be the same, over and over again.

now, there are 2 possible solutions:

1. resize the source textures - cut dimensions by half, and you'll have a quarter sized *.exr cache; and it is generated faster of course. but still it costs time for every frame for absolutely no use.

2. the trick i come up with - given that your temp/cache folder is on an ntfs drive (mac should be similar), you only need to set the folder security to "create" and "read". in other words, you need to deny any delete action for the folder and subsequent files for the the user account you work with (or the one that starts the queue manager on a net render machine)!

the consequence is, ffrender is still able to create the *.exr texture cache (ps: this is not the main texture cache which is also created but kept between renders), but can't delete it after finishing a frame. and luckily it won't throw any error because of that but quits just nicely. and more fortunately, at the moment the next frame starts, it'll check for existing *.exr textures in the cache, and because they are already there, it skips the creation process (just like if rendered within poser a 2nd time). and e voila, render times go down significantely.

btw: this trick is also possible to apply for poser itself; poser uses it's own *.exr cache folder and the same procedure keeps it from deleting it every time poser is closed (or starts). so if your drive holding the temporary folders is big enough, poser will -over the time- create an *.exr cache file for each and every once loaded texture, but won't do it a second time (as long it sits still there in this cache folder waiting). in other words, while opening poser and loading an already made scene, the texture loading (show in the render progress) is cutted to nearly 0 time - even for the first time it'll be rendered within a session. and if you load characters/materials which cache files were already created yesterday (or 4 weeks before) it'll still use the cached *.exr and don't have to create it again.

i hope i my explanation was somehow understandable - feel free to ask any questions if not.

ps: the standard location of the queue manager texture cache folder in vista/w7 (the one where deleting is to be denied) is:
%USERPROFILE%AppDataLocalTempQueue Manager2.0PoserTextureCache
(this depends on the setting of the "TEMP" enviroment variable) 

the main temp directory for poser can be edited in the settings, and "PoserTextureCache" is a subfolder there.

cheers...

Thanks for the info!

@lesbentley: you're welcome :)

ps: seems, somehow the backslashes got lost, so here's the path again:
"%USERPROFILE%AppDataLocalTempQueue Manager2.0PoserTextureCache"

...

Moi j'ai rien compris

Thank you very much for the tip!,  I hate those loading times in the render qeue for each and every frame, even though everything in the scene is th same, only camera changes. This will help a lot.

Fantastic tip!

The other night I was experimenting with queue manager sending jobs to a faster slave machine and also noticed the increase in render times. This helps explain why.

Implemented as it is right now, the queue manager is usless, IMO, another problem I have with it is the resources it take, it takes memory in the main node as if it was also rendering, which beats the purpose of having other nodes doing the rendering, not to mention the time it takes to transfer each frame, especially if you are in a wireless network. I've opened many tickets since the first time queue manager was introduced, but no luck so far.

Great tip! :)

Thanks.