We have a need to create high resolution images very quickly. We want to investigate using Deadline as a front end for rendering V-Ray models from Max, splitting up the image over many networked computers. Does Deadline simply use the existing V-Ray distributed rendering system? or Does it do magic of it’s own? There’s nothing wrong with Vray’s distributed rendering, just wondering if Deadline adds any advantage for speed, ease of use, or anything else? -marK Gerhard
In terms of rendering through Max, Deadline provides the option to do Tile Rendering. This does not use Vray’s DR, instead each slave will render different regions of the frame, which can then be assembled into a full frame by a separate Deadline Job. The tile assembly can be done automatically by this dependent Deadline Job as long as its in one of our supported image formats (which consists of most of the usual suspects).
I know we also support VRay standalone, if you export your scene file as a .vrscene, but I don’t know if we’re hooking into their DR for it. Unfortunately, I can’t be 100% sure since our lead Dev is out this week, and he’s the guru on this stuff. I’ll definitely have him check in on this thread when he gets back, if you need more details.
Cheers,
- Jon
I’ll take a shot at this as we do distributed rendering using Deadline as the front-end for V-Ray for Rhino; it’s been very useful. The short answer to your question is that while it doesn’t give you any more rendering horsepower than you would have now what it does provide is a professional front end – submission/queuing/tracking/notification/statistics – plus a lot of exposed Python code that allows for additional customization. One feature we were able to add, for example, was the ability to restart the DRSpawners with each job – they seemed to keep some history between jobs and then start to return black or slightly off-color buckets; a restart cleared that up (we run DRSpawner as a Windows service and use Deadline to execute some PSTools commands to get the remote services restarted before each job starts). Altogether the big advantage is that we can run our renderfarm 24x7 unattended.
In terms of how it works, in the basic Deadline model each machine in the renderfarm has both the Deadline Slave software and the specific application you wish to use (e.g. Rhino + V-Ray for Rhino) on it; jobs are submitted via a Deadline client to a shared Repository which the Slaves regularly poll looking for new tasks. The special sauce, as it were, is Deadline’s ability to script a command line that the Slave pulls down with the file to be rendered and uses to launch the desired application (e.g. Rhino + V-Ray for Rhino) and initiate the application’s own rendering process. In this respect you’re not getting anything more in terms of rendering horsepower than if you did this manually but you’re now able to automate it, with all the bells and whistles above. Too, in the basic model, each file renders on just one machine. This makes a lot of sense for standard renderfarms where different applications are being used and no one application can safely borrow CPU cycles from another machine. If you decide to go ahead and use distributed rendering, though, you just configure your application on the Slave node (for us, Rhino) to use V-Ray’s distributed rendering. With V-Ray for Rhino it’s a matter of adding the host addresses of the DRSpawner machines into the appropriate V-Ray configuration tab; Max has some other spots (vray.info/tutorials/vray_distrib … /part2.asp) Then when (for us) a Rhino file with the V-Ray distributed rendering box checked hits the Slave the application uses V-Ray’s distributed rendering, contacts the other 10 hosts running DRSpawner (these machines don’t need the Deadline Slave software on them), and uses them to generate the result so you get the CPUs of 10 machines (actually 11, since the Slave is also a render node) on a single job. Again, this is probably no different than what you can do now, in absolute rendering terms, but you get Deadline to do this all automatically.
Again, our use is Rhino, not Max. Because V-Ray is similar across applications I’ve responded, and because you already seem to be familiar with using V-Ray distributed rendering the issue may be just be becoming familiar with the submission form to get your Max file to the Deadline Repository and from there to a Slave node – Max has more features and dependencies so there are a few more boxes on the submission form to complete than with a single-frame Rhino job.