By default, when submitting a MAX2010_64 job via RPM, the task size is set to 1 frame.
So if my understanding is correct, a slave gets a task of rendering a single frame. It starts up MAX and renders the frame… does it then close MAX? Then for it’s next task, it starts MAX again? If this is correct, it seems there would be lots of wasted time while MAX starts and stops, etc. Currently on a slave I’m watching, I see the screen flash for a second as MAX is started again and again.
If this is correct, seems like I should have the task size set to something like 10 frames. In which case, MAX would be started but kept running to execute the render of all 10 frames before being closed.
Normally, Max should NOT restart between tasks. This is controlled by the property “Restart 3ds Max Between Tasks” which should be unchecked by default, and should be sticky between settings (so if you change its state, it should stay that way until changed again).
Note that in SMTD (Submit Max To Deadline), the stickiness behavior and startup defaults of almost all controls are customizable via global and local INI files, but the factory defaults of this property should be as described…
The Deadline Slave checks to see if the scene currently loaded in memory is the same as the scene of the Job that requested the next Task. It also checks if any properties of the Job have changed between Tasks (see 3ds Max tab in the Properties dialog of the Monitor - you can change pretty much anything after submission). If nothing has changed, the same scene should render unless “Restart 3ds Max Between Tasks” was checked…
There is also a second setting which restarts the renderer only (“Render” tab, “Restart Renderer Between Frames”). Basically it keeps the scene in memory, but re-initializes the render instance to free up memory and reset all settings. This does not slow down the rendering at all, but can solve some issues with renderers like VRay if memory is consumed and not released, or render elements don’t have the right content etc…
We only recommend submitting with Task Size > 1 when the frames render times are very very short, e.g. a few seconds. Otherwise, if a frame takes several minutes or hours, it is recommended to keep the Task Size at 1.
If your “Restart 3ds Max Between Tasks” is not checked and Max is still reloading, we will have to take a closer look at the Deadline logs…
Neither of those settings are checked so I must just be seeing the MAX window for a moment or something. This is on a Windows7 machine that I am running the Monitor on as well as a Slave. Normally, the Monitor shows onscreen but periodically while rendering, there will be a white window take over the whole screen for a second and the titlebar shows ‘Unregistered 3dsMax, etc.’ then the window will disappear. It does this repeatedly during the rendering. That’s what was making me think MAX was restarting each frame.
Max startup can take a while.
It would be pretty obvious if Deadline was restarting Max - in fact, there is a separate timing measurement of just the startup time in the Task window. In a typical test of mine in my Monitor, I can see 1m27s for the first frame and 1s for all following tasks (that was rendered on only one slave).
It is normal to see a ghost of the Max UI flashing when Max is being controlled by the Slave. If you have the VFB displayed on the slave though, it should stay there and show frames being rendered one after the other…
Hmmm… I checked on the startup time on a different machine and it’s approximately 50 sec on the first frame and like 2 sec on next so that seems good.
But on the particular system where I am seeing the flashing window appear, when I try to check the monitor to see the startup speed of that system, well that slave is not listed at all in the list as having worked on any frames. And I recall that in the titlebar that appears on the flashing window… it said ‘Not Responding’ so I’m thinking that there might have been some problem on that slave and it didn’t complete any frames. Will have to look deeper into this.
OK, after examining the Slave dialog there were some plugins missing from that MAX install and it was throwing errors. I have now installed the missing plugins and will see what happens on the next render.
OK, the flashing problem was the missing plugins and now that machine is rendering fine. (Startup time on the first frame was about 46sec, second frame 7sec).
But this brings up another issue. Bobo you said the VFB should stay on the screen and be over written with rendered images. But what I’m seeing is, the VFB is appearing and disappearing on each frame rendered. So the VFB opens, render, closes, opens again, render again, closes again, etc. Is this the proper behaviour?
I use RPM exclusively and in RPM, each pass can have a checkbox for VFB. I generally have the VFB checkbox checked because it’s needed if you want to do a preview render and see the image. But in the normal BB Network tab in RPM, there is a setting to ‘Override’ the VFB setting. When I submit a job, I have this setting set so that the render slaves never show the VFB during rendering. (side note… this used to work great for me in MAX2010_64 but broke awhile back and I mentioned it to Grant but it never was fixed. So this has not been working lately). Clearly, Deadline must be using the setting in the pass itself as the VFB is showing. I don’t see any override setting in the Network tab when using Deadline. Is there any way to do an override of the VFB setting when submitting?
On the Task issue, for this particular rendering the frame time was about 10sec per frame. So if I had increased the task size to some number > 1 (such as 3 for example), would I see a speed benefit and the job render faster than using a value of 1? Just wondering how to know when changing the value would be of use.
I have not used RPM in production and don’t know enough about how it works under the hood. What you are seeing is probably what it is supposed to do.
Deadline has its own set of controls regarding the visibility of the VFB (it basically tries to override the VFB settings of Max). Depending on what is having the “last word” on the render slave side, it might or might not work with RPM. The controls are found in the Render tab of SMTD.
The Slave has a short delay between Tasks before looking for more work. If you have the Task Size set to > 1, that delay time will be reduced. So if your frames render in 5 seconds and there are 1, 2 or 3 seconds delays between tasks, you might get up to 50% longer render times. If your frames take an hour, a second or two on top are insignificant. But if frame 4 out of 5 crashes, the previous 3 frames in that chunk would also be re-rendered, which would be ok with 5 second frames, but really bad with an hour per frame jobs.
That’s why we suggest using larger Task Size values for very fast renders, and keeping the Task Size at 1 for general production use.