Nodes loading bitmaps/instances every frame - excessive render times


Just bought licenses for render manager and am having issues.
Creating an animation job with a range and sending to local nodes results in each node seemingly starting a new single frame and reloading bitmaps/instances every single frame.

This results in 10 min frame times all the way through the animation.
Where-as with the same range on backburner, the first frame is 10mins but every frame from then on only takes 3.5mins.

Can you help please? This is a very strange default behavior for a render farm manager and a very frustrating problem to find on a deadline. If I’m selecting animation as the render type and sending a range, why are nodes reloading everything from scratch on every single frame? The render times compared to backburner are massively high.

Using latest V-ray / Max 2022.

Please use the packed frame option for animations in the job submitter, this will match the behavior of backburner.

By default render manager gives 1 frame to each computer making it easily scalable, but of course in cases when you have a few machines or high loading times this might not be the best. Packed task will solve your issue.

I tried pack frames overnight. I now have my slowest node in the farm doing the last 49 frames while 3 fast nodes sit there idle doing absolutely nothing. Surely this isn’t normal. This job should be finished.

What am I missing here?

Edit-> And if the nodes have to reload bitmaps/instances every 50 frames, that’s still quite a loss in productivity and efficiency in a business where deadlines are the only important thing.

Am I right in understanding that Pulze just cannot efficiently distribute frames to a farm like backburner can? Where the software manages the frame distribution, not the user in 50 frame chunks?

In lieu of a reply I can only assume that render manager isn’t the right fit for large scale scenes and animations. I thought our use-case would be super common and that this would be a bare minimum for farm software. We can’t use something slower than backburner which is a pity because the UI is really nice and you’ve done a great job on it.
What is the refund procedure?

Hi Jai!

Sorry, we don’t always have time to reply the next day to question on the forum. Our main support channel is via email (

I don’t want to get into the technical details about our distribution and max handling technics. We believe it is as efficient as it can get for a 3rd party developer. Obviously Autodesk has more control over their own software and Backburner which leads us to the following possibilities:

A: We distribute each frame to a computer, but since we don’t know which will be the next time the render technically has to stop at the end then the master computer will tell the node to either continue with the next frame or go to another job depending on the situation.

B: You use the packed task solution, where we allocate more frames to a computer using the time range value, but in this case our hand our tight, since we can’t brake it down to smaller chunks ones a node starts to render.

Between two tasks a node might wait a few seconds to get a confirmation from the master computer and under the hood a lot of checks and other monitoring procedures are happening because of that you might loose some time at the end of day.

If you thing that this is not good enough for you then for sure we will refund your license. Please reach out to us at and we will take care of it.

Thanks Peter. I think our most regular use-cases might be a bit too load-heavy for render manager. I did the trial about 6 months back but it was with a smaller project and these inefficiencies weren’t as apparent. I appreciate the support and hope one day you can implement range frame distribution like how backburner or deadline do it.

If I might offer a suggestion in the spirit of improvement - from our initial experience this week with the software, the default settings of render manager had an 8 hour animation job take 3 days on our farm.

For new users this is both confounding, frustrating and is quite the opposite if what a range animation job should do. The terminology of “pack tasks” is not very intuitive and was also referred by you as “pack frames” which further confused the issue as that phrase does not appear in the documentation.

Further more, I noticed on subsequent reloads of render manager, pack tasks was unticked again (which, while it’s a less than ideal solution for animation frame distribution, is 100% a setting we would use 100% of the time)

Thanks again