Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] Bug Reporting => [Max] Resolved Bugs => Topic started by: Dippndots on 2016-05-18, 11:47:25
-
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.
Any ideas?
-
Have you checked <maxdir>\network\Max.log of #7? Something unusual there?
Good Luck
-
Nothing out of the ordinary unfortunately :(
-
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...
Good Luck!
-
#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.
-
Ok, now depending on what you are aiming for you could do further testing:
- Render same scene not starting at frame 0 but for example 5 to see if it´s that somehow special frame 0
- Render another scene with mray/vray or even scanline to see if it´s maybe a general bb issue
- You could prepare a test scene which shows this behaviour and share it for others to test
But I don´t know if this is worth the effort for you...
Good Luck
-
good idea, hopefully I'll have some time this week to test some more methods, I'll try using the alpha test scene so I can share it if need be.
-
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.
Good Luck
-
Are you still having these problems? If yes, by any chance, is this max 2014?
-
Doesn't look like it. I can't remember if it was 2014, but we did switch over to 2016 around the time I originally posted, so I think it must've been.
We use noise-limit now too, instead of pass limits.
-
in case of 2014 I would know what it probably was, otherwise I have no idea. In any case I guess it is not happening anymore ;)