Today we have an interview with Daniel Müller of RenderPal
, an application allowing 3D artists to manage large rendering farms.
Can you describe yourself and your background?
My name is Daniel Müller, and I am the lead developer behind RenderPal. I live in a small town in Germany and have been programming for more than 17 years. While I have no background in the arts industry, I learned quite a lot about rendering through the development of RenderPal: One day, a friend of mine (a 3D artist) came to me asking for a small favor: He needed a simple tool to batch-render Maya scenes - and so RenderPal was born. It all started as a small, private tool, but eventually grew into what it is now during the past 12 years.
What is RenderPal and some of the main features it offers?
RenderPal - in its current incarnation called RenderPal V2 - is a professional render farm manager. Simply said, RenderPal takes care of your entire render farm, and the users (usually artists) only need to submit their jobs and take a look at what is going on from time to time. This is achieved through various components: The RenderPal V2 Server, which is the ''main workhorse'' handling all the rendering machines and dispatching the jobs to them; then there are the various RenderPal V2 Client instances, which run on the rendering machines; last but not least, the users use either the RenderPal V2 Remote Controller or the its Web Interface to remotely deal with their render farm.
One of the outstanding features of RenderPal is its extremely advanced renderer system: A render farm manager relies on how it can support the various renderers and compositing tools out there, and RenderPal offers one of the most advanced systems in such a program - and yet it is easy to use, even for artists without any programming background.
A key feature of any render farm manager is how much ''automatic everything, please'' you can get. RenderPal offers quite a lot of such features: These allow the users to fine-tune how their jobs should be rendered and monitored, when they should be resubmitted automatically, it can check for missing images and much more. The whole idea behind RenderPal is to liberate the users from manually taking care of their renderings, and RenderPal does a very good job at this.
The latest version adds a web interface, can you describe it?
Oh yes, that's the latest and greatest new feature found in RenderPal V2! Users of a render farm (no matter if it is an artist or an administrator) need to have access to their render farm all the time, 24/7. Anyone who has ever rendered something knows that renderings not always work as intended: Renderer programs crash from time to time, frames go missing, or someone made a change and the whole job has to be restarted.
Since most of us won't be at the office the entire day, an easy way to monitor the render farm (and thus RenderPal) from anywhere was in need. Sure, we already had the RenderPal V2 Remote Controller which does a great job at this, but it requires an installation and simply doesn't work from everywhere, as it requires a ''real'' computer running Windows (or Wine). So the best solution was to build a new tool on the one technology that really is ubiquitously available: The Web.
The idea behind this new web interface was to give anyone access to their render farm using a web browser: This way, RenderPal is available on pretty much any device, no matter what hardware or operating system - and all this without any installation or download! The web interface closely resembles the Remote Controller, and that's just what we wanted to achieve. Users can take a quick look at all the pools, clients and - most importantly - jobs in their render farm and take any necessary actions, like restarting a job or stopping an entire pool.
What would be a typical workflow for someone who wishes to use RenderPal?
The first step is to install everything; we made this as easy as possible, like offering silent installations, and RenderPal is also fully portable, meaning that you can just copy one RenderPal folder to all other computers and things will work as expected.
The next step would be to set up everything: The server and client options, configuring the farm layout (in the form of client pools), setting up the renderers and stuff like that. This is a one-time task, and it isn't a lot of work, actually. We tried to make the whole setup as easy and comfortable as possible.
Once this has been done, the artists can start using RenderPal. Usually, they will submit their rendering jobs to RenderPal either via our submitter scripts (with these, they can submit new jobs directly from within their main application, like Maya or 3dsMax) or by manually creating a job with the Remote Controller. Once the job has been sent to the RenderPal V2 Server, it will be eventually picked up and rendered by the various client nodes. The artists can check the status of their jobs (and control them in various ways, if necessary) at any time using the Remote Controller or Web Interface. RenderPal also offers features like email notifications so that the artists will always know when their jobs have been rendered or something went wrong.
Have you done analyses of the advantages of using this product versus native solutions available from rendering software?
One of the main benefits of RenderPal is that it supports a multitude of renderers, not just one or two. Most render farms work with a bunch of renderers and post-processing tools, and having one solution for all of them is a great advantage. Furthermore, RenderPal simply offers more feature than any integrated solution (like Backburner); the reason of this is simple: We dedicate our entire time to develop a render farm manager, while native solutions are just an addition and will never receive the time and effort we can invest into it. Many users also told us that RenderPal not only offers far more (important!) features, but is also more robust and stable (especially when renderings fail, which simply happens from time to time).
What software and languages are you using to make this product?
What are some of the biggest or most interesting tasks that you have seen clients use RenderPal for?
Oh, there are many, actually! One of the more recent uses was in the making of the movie ''Iron Sky''; the company behind this movie used RenderPal for their rendering needs. We also closely work together with RiseFX, a very well-known post-production company based in Germany; their work include movies like Harry Potter and Cloud Atlas. But my favorite still is when the USSS (US Secret Service) ordered a license of RenderPal! They explained that they use RenderPal to render simulations of different security scenarios - quite cool, if you ask me!
It is really interesting in how many different areas RenderPal is being used. We mainly have users in the arts and game sectors, but we also have users from the architecture, science or even medicine fields.
Have you received much feedback about RenderPal?
Most people are simply happy with what RenderPal has to offer - and this shows us what a great product our once little tool has become! We mainly receive support questions, and through some of these, we develop new ideas. There are some companies we work together with more closely, like the aforementioned RiseFX. Together with these companies, we create new ideas that directly come from the industry, and thus are usually great additions for most other users as well.
And then there are those users who simply let us know how helpful RenderPal is in their everyday chores - and this is the kind of feedback that really makes our days!
Do you think people are going to go more for cloud-based render farms instead of building their own?
This is difficult to estimate I think. Building your own render farm is expensive at first (though not as expensive as it has been in the past anymore). However, using external solutions to get your scenes rendered has its drawbacks as well: First, you have to share your work, and there always is a certain risk that your files will be abused or even fall into the wrong hands; you also don't have as much control as you might need, and your jobs might not be done the way you want (or in the time you need it to be done); last but not least, nobody will render your stuff for free, and so using such solutions might cost you more over time than building your own farm. For companies which only need to render something once in a while and where the risks are acceptable, cloud-based render farms can be a good and cheap solution, but for companies which render more frequently, building their own farm should still be the way to go (especially with fast hardware becoming cheaper and cheaper).
What are some of the future features you plan for RenderPal?
Our current focus lies on the Web Interface. We will extend it more and more, and we want to add most of the features present in the Remote Controller. This is quite a lot of work already, as everything has to be written from scratch, and we also need to extend the core program as well for this to work.
But users can expect some other nice additions as well: More renderer system extensions, more Python integration (and thus more ways to customize RenderPal and integrate it into rendering pipelines), several ''user experience'' improvements... Our to do list still has plenty of nice stuff on it!