My artist is complaining that Maya renders under Deadline are still performing some kind of runup before rendering frames, even though the fluid has already been simulated/cached.
So he says the first few frames render in about the right amount of time (say 30 secs) but by the time he reaches the end of the render (say frame 200), it’s doing a VERY LONG runup time before it starts rendering frames, even though the frames themselves render very quickly. The suspicion is that the render slave is either re-simulating or is reading through every frame of the cache leading up to the relevant frame.
Is there any flag or option we can use to determine what’s happening during the early part of the later frames in the render?
Are you using the MayaCmd or the MayaBatch plugin? This is controlled by the “Use MayaBatch” option in the Maya submitter.
The MayaCmd plugin restarts Maya for every task, so if Maya still needs to walk through the cache, this could explain the problem. I’m curious to know if you restarted Maya on the workstation, and started rendering at frame 200, if it would exhibit the same slow render time. I would expect it to, since it hasn’t processed any of the previous frames yet.
The MayaBatch plugin keeps Maya and the scene file loaded in memory between frames, so that might help, but if a new slave comes along and starts working on frame 200, I would expect the same slow rendering because it wouldn’t have the data for the previous frames loaded in memory yet.
Another question is whether or not the slaves can see the cached data. It would have to be in a network accessible location for them to use it.
I should note that this probably has nothing to do with Deadline, and is just a limitation of distributing this particular type of sim job. If that’s the case, one way to mitigate the problem would be to submit the entire job as a single task (so that no run-up is ever required), but of course all the work needs to be done on a single machine. Another option is to increase the task sizes. If frames only take 30 seconds, then using 10 frames per task or higher should be reasonable, and again would help reduce run-up times.
Cheers,