So this is a weird one, the first frame of my interior animations is taking much longer than the succeeding frames. Exterior animations don’t seem to have this problem, the only difference I can think of is that the exterior is lit with an HDRI and the interiors use CoronaSky.
As you can see in the attached image, this one was 30min more (all “mules” are identical specs). The UHD cache was calculated separately and this job is loading it from a file.
Are there more frames than visible in the screenshot? Would be interesting what #7 has done a few frames later.
Is this scene specific? So if you sumbit a testscene to #7 and some other, do they render equally fast? Just an idea that maybe #7 is slower generally because … well a failing fan or something similar…
#7 Matches the other machines later on, i’ve attached a pic.
It’s not just that one job either, I’ve attached a second where the average render time is a bit lower, but the first frame still takes a significant % longer.
So, after a bunch of testing use the Alpha scene, I’ve come to the conclusion it must be something in the pre-rendering stage of the render, or a plugin we are using. All the alpha scene tests I did (30min time-limit, 400passes, start at frame 5) had no difference in render time between any of the frames. The pre-render time was less than a second (rather than in the minutes in our usual renders), so this is what leads me to believe it is something in the pre-render stage on our problem animations.
I’ll try to test with a slimmed down version of the problem scene next week.
In general the Backburner timer starts not when rendering, but when the renderjob is being sent the first time. Thus the first frame time includes the following:
Wake from LAN,
Downloading max file,
Downloading textures,
Accessing corona proxies,
Opening up max,
Loading all the plugin crap,
And lastly, opening up the max file.
This adds up to quite a bunch, and this time doesn’t even account for actually rendering. Thus it is not unusual to have the first frame being ludicrously long “to render”
You are right-when it’s about one node starting a sequence. But look at the log in OP. All nodes starting the job are faster than #7 rendering their specific first frame. What you describe is btw the reason why I asked what #7 has done later in the job.