Vray - Optimal Render Farm Configuration

[Micha_cg]

Just in the mement I found at the deadline FAQ pages:

"Does Rhino need to be licensed on each render node? "
"Yes."

That's to bad, an additional Rhino license for each computer of a render farm - that's to much for me. It's a pity that my request for "rendering in Rhino demo mode" never got a chance.

[wcmansp]

That's true for the standard Deadline configuration but not for this kind of architecture. In its standard configuration, the way the Deadline documentation describes it, there is a Deadline Slave running on every render node. When that Slave picks up a job from the Repository it is scripted to start the application requested in the job (in this case, Rhino) and execute the appropriate rendering commands on that node. In the standard configuration, then, every node has to have the application. In this distributed rendering architecture there is still a copy of Rhino on the Deadline Slave, but now each Slave can now use up to 10 additional rendering client machines that just need DRSpawner running. These 10 machines don't need to run Rhino and they aren't running the Deadline Slave software, just DRSpawner. At least on the V-Ray for Rhino version we use (1.05.29, EDU) you can install the DRSpawner client (and the materials and RDK) on these machines without installing "V-Ray for Rhino" (which wouldn't install unless it could find Rhino) and DRSpawner doesn't require a V-Ray for Rhino license. So, while you do need a copy of Rhino wherever you run the Deadline Slave software, you don't need that many Slaves; each Slave can use 10 machines that aren't Slaves (and don't need Rhino installed). You need at least 1 Rhino copy for each 10 machines in your farm, but you don't need a Rhino copy on each machine.

[Micha_cg]

Great, so it will be possible to run Rhino and deadline at a master machine and the DRspawner at the slave machines only.

[eazyc10]

Thanks for the indepth information - We're going to try to implement this within the next week or two. I'll report back on my results

ec

[wcmansp]

Micha_cg: Yes. The idea is that there is a machine with Rhino running V-Ray for Rhino in Distributed Rendering mode talking to its DRSpawner clients that now, with the addition of Deadline, can receive/spool/queue incoming jobs, provide job status and notifications back to users, and keep statistics. Because the Deadline Slave can also execute jobs that are essentially Windows command line tasks, the Slave can do things like start and stop the DRSpawners on the client machines (as part of each job, if desired), implement Wake on LAN and powercfg for running in a power savings mode, or implement scheduled changes.

To your earlier question, Deadline does offer one type of job export -- it will transfer a job from one Deadline Repository to another. We have tested this within our organization to transfer certain jobs from our renderfarm (which is only running one Slave) to another unit's renderfarm which is configured in the more traditional multiple Slave on dedicated Boxx machines configuration. They don't run the distributed rendering architecture so a job can take longer but they do offer more Slaves. The question about whether we can export to an external (cloud?) system is one we have considered as we think about how we would expand capacity. If it can be done -- ie. if you can design a system that manually takes a group of files from one machine and copies them into a cloud-based rendering solution -- it can probably be implemented in Deadline because of the amount of Python code exposed to work with. We'll probably look into this over the summer.

eazyc10: Let me know if you have questions and, certainly, how it turns out. The notes were a summary of what we'd found in working with this over about a two year period. I didn't include all the things we didn't end up doing, or changed our mind on after we tried them, but your situation may be different.

[Micha_cg]

If I remember me right, rebus farm was interested to support VfR. Maybe per deadline it will be possible.

[mgibeault]

Hi,

We're looking into ways to improve our small distributed rendering environment here and I would like to have a look at your notes!

Thanks,

-Marc

[wcmansp]

Let me know whether you want this via the Forum's "Private Messages" option (it's 7 messages) or use "Private Messages" to give me your direct e-mail address and I'll send it as a Word document (~7 pages).

[mgibeault]

Hi,
I cannot send you a private message, you disabled the option.
But I'd like to receive the document by e-mail; my address is marc.gibeault at aero.bombardier.com
Thanks!

[mgibeault]

Hi,

Due to some shifting priorities I did not implement our render farm at the time of this discussion.
But we now are back we the need to do a lot of big renders in the coming months and we might have access to a render farm that is currently used for Backburner/Max/V-ray renders. The render farm manager is willing to consider the implementation of Deadline for our needs.
I still have your document 12-03-30 Deadline renderfarm description.docx. Did you augmented in the past months?
Have you updated Rhino to v5 and V-Ray to v2? If so, any problem in the context of your Deadline implementation?

Thanks!

-Marc

[wcmansp]

That's going back a ways. The renderfarm approach we took was because we couldn't dedicate machines to rendering -- our solution uses background rendering on machines that were also used for other purposes. If you have dedicated machines, you may find it simpler to go a more standard route. While you may not throw as many cores on a particular job as using distributed rendering, you get more concurrent jobs in the pipeline (each render machine runs its own Deadline Slave, handling one submitted job). There is a cost factor involved -- distributed rendering requires just one slave, one copy of Rhino, and one copy of V-Ray per 11 machines while standard Deadline rendering needs V-Ray, a Deadline Slave, and Rhino on each machine; some of this may be offset by the simpler, standard, Deadline setup and support.

It would be hard to advise now, as well. We are still running Deadline 5.2 -- Deadline is now at 6.1 -- and V-Ray for Rhino 1.5 (2.0 has a significantly different licensing model); we do run Rhino 5.0 64-bit. We did run into a problem with V-Ray for Rhino 1.5 that required us to modify Deadline's Rhino plug-in to force a scriptable V-Ray setting to "SetBatchRender=On"; this may have been resolved in either V-Ray for Rhino 2.0 or incorporated Deadline 6.X (we haven't tested those). There's some history of this in a Forum "sticky" article with a subject line that includes "...is command line rendering still possible..."

So, if you were to start now, and had dedicated machines to use, and funding, the simpler approach would be a standard Deadline implementation -- 1 Slave/Rhino 5.0/V-Ray 2.0)/machine; that's more "ready-to-wear" and requires less implementation time. Again, I can't speak to any Deadline 6.X/V-Ray 2.0 issues because we haven't tried these and V-Ray 2.0 introduced some new material types. I do see that Deadline 6 is now incorporating some built-in V-Ray distributed rendering features but for the larger market 3DS Max and Maya rendering; not many appear to be rendering still images in Rhino using Deadline. The Deadline implementation we use does solve some problems with distributed rendering (e.g. getting the spawners restarted with each job) but the main problem we needed to solve -- no dedicated machines or money -- may not be the big issues for you. Yours may be more about time to implementation and a simple/supportable configuration.

We can discuss offline if you want; let me know and I'll send you something at your address above.

--Bill

[mgibeault]

Thanks Bill for the detailed info.

The most realistic scenario would be to use one workstation as the Deadline slave with Rhino and V-Ray installed and licensed, and 10 blades in the render farm as DR nodes.
I'll discuss this further with the render farm administrator.

-Marc