A lot of people are immediately put off by the cost of cloud rendering. Why would you spend extra money when you could render at home on your own system? To answer that question, I will explain why cloud rendering is not only smart, but also a lot cheaper than rendering on your own system. I developed Barista to help the Blender community take full advantage of the benefits of cloud rendering, without having to become an expert at cloud computing, and also avoid the costs associated with 3rd party providers.
The Origin of Barista
In 2016, I was already a year into learning 3D modeling with Blender. At the time I was learning realistic sculpting in Kent Trammell's Sculpting Workshop on CG Cookie, and I found myself interrupted by issues where my own system couldn't render my scene. After many roadblocks, I started utilizing AWS to render my scenes, rendering multiple tiles across multiple systems. By doing this I could reduce the amount of memory needed, and render a lot quicker (and more reliably!) than I could at home.
The moment I posted my render, other workshop students were curious how I pulled it off. After explaining that it had been rendered on the cloud, several people began asking for help setting up their own personal cloud farm, eventually spurring the idea for Barista.
The Problems with Dedicated Render Hardware
I was already in the process of creating a dedicated system to render prior to development. Even after using AWS to render my sculpt, I still thought home rendering would be most cost efficient. The system cost roughly $1000, making a low-cost and low-power mid-range CPU system. The problem came when calculating the cost spent and the cost of electricity, and of course the time spent rendering. Since I would only create a new render every 2-3 weeks and then spend about 8-12 hours rendering that piece, the value seemed like less than previously thought. After half a year, I compared prices to AWS, and I found I had only saved myself roughly $40 in rendering costs, not factoring in the $1000 I spent on the system itself.
Calculating the Worth of Dedicated Systems
The difficulty with consideration of paying for rendering is understandable, especially when working with open-source software you never monetarily paid for. A common conception is, “If I can render for free, why would I pay?” The question often arises when considering cloud rendering, but is it really free? You pay for your own hardware, maintenance, upgrades, and of course electricity. Sure, you can use the system you model with, but when rendering, you often remove the ability to use that system for anything else. Rendering animations and intricate pieces with ray-tracing is very slow, so professionals will often have a backup system to allow them to continue working while rendering. While having another system does free up a system, the cost is an issue, and chances are you could save a handful of money using cloud rendering instead.
The Actual Cost of Cloud Rendering
First, how much would it actually take to justify a dedicated system? If we use the most cost efficient AMD Epyc™ system as an example (~$0.62/hour). With a ~$14,000 price tag, owning your own AMD Epyc™ 7R13 simply isn’t feasible, but let’s imagine you are considering a dedicated system with an AMD Ryzen 9 7950X, and a cheap video card to keep load off the Ryzen’s built-in GPU. Assuming you will build the system itself and are thrifty with your cost, you could make a CPU-only render system with a Ryzen 9 7950X for about $1200.
Based on AnandTech’s Blender 3.1 render benchmarks, the AMD Ryzen 9 performs half the speed of the AMD Epyc™. In order for you to make up for the cost of the system, you would need to render a total of 3870 hours (161 days) on your dedicated system. Even if you do end up rendering that many hours, you may want to consider the cost of electricity that goes with this. To be generous, let’s just imagine we’re using 200kWh of electricity each hour, where the average cost in the US, 13.16 cents per kilowatt hour. Basically every 5 hours we spend $0.1316. This means after 3870 hours of rendering would add around $102 in energy cost. Again this is being generous with the cost, as we’re using a low-power system as a test; loaded multimedia/gaming systems can often use 800kWh per hour.
What if you render with a GPU instead? With Eevee, rendering is much quicker, so the cost associated is greater, but can make it easier to handle on your own system. Using an AWS g5 with a Tesla® T4 can render Eevee quickly at an extremely cheap cost ($0.13/hour). Using an nVidia® 3090, you can achieve comparable times. So if you wanted to go a dedicated route, you would need to justify $1500 on a cheap system with a mediocre CPU, needing 11,538 hours to match the price with AWS.
There is one factor we haven’t mentioned yet, what about the lifetime of the system? If you use your dedicated system for 3 years before upgrading parts, once you upgrade, you’re adding even more costs to cover. Since AWS updates their systems periodically, you never see upgrade costs. Overall, the cost of a dedicated system is difficult to justify when compared to rendering on Barista.
The Benefits of Barista
Anyone can render in the cloud, so what makes Barista the better choice?
Removing the Middleman
Many people are not already aware, but many Blender render farms use AWS for its backend rendering. The difference is that these farms add service fees on top of the cost to make it profitable. Barista removes the middleman completely, that way you only pay for the cost of AWS without any of the additional fees.
Hardware Automation
Because understanding AWS is the biggest hurdle of AWS rendering, Barista automates as much of this process as possible. In early iterations, Barista offered On Demand instances, and Spot Instances, the latter ~80% cheaper than the former. The two caused a lot of confusion, so Barista switched to only using Spot Instances, and automating the process so users didn't even need to know they existed.
Hardware Limit Automation
When you want to use more hardware, AWS requires users to request access to these systems through a system credit allowance system. Users have to request specific amounts of credits, for specific instance types, in a specific region, all in a specific form. Barista offers an automated process to show users how many credits they have, and gives users all of the specifics needed to request more.
Setup
Barista handles the building of the environment dynamically, installing the version of Blender you want to use, installing and registering add-ons, and also setting various dynamic rendering settings for Blender via a startup script.
Cost
With such an intimidating system, and so many possibilities to scare away new users, it was this reason alone that Barista's mission statement was to become the cheapest AWS cloud rendering platform available. Every decision made since its start has been focused on cutting the cost.
Cost Cutting Examples
S3 and EC2 regions always have to be the same. If you transfer files to an instance in the same region, the cost is nothing. If you transfer to another region, you will pay at least $0.07 per GB.
The automation of Spot Instances was another decision made for this reason, as too many users would opt for the OnDemand instances for ease of use, avoiding the need to understand Spot Instances. Once Spot Instance use was made to be just as easy, and OnDemand removed, potential costs dropped drastically.
With Spot Instances, you can experience interruptions if you aren't careful. This is due to the price demand on the systems used, and if your price is below the current demand, your system can be shut down. For users that rendered intensive scenes in Cycles, an interruption may happen before a frame finishes, causing all the progress before it to be completely lost. This also meant that you had to pay for the time it took for the instance to startup again, and possibly wait for Blender to compile render kernels all over again. Barista allowed users to set a Price Threshold, which would cause the price to grow with these demands (usually in increments of $0.01), and in turn keep the instance from ever going below the demand price.
Why Barista is Important to the Community
With the benefits understood, how is Barista important to the evolution of the Blender community? For one, when new Blender users enter the community, they are often intimidated by the render times of Cycles and LuxCore, developing a belief that throwing bleeding-edge hardware at their issue is the answer. For many years this has become a hurdle for new users, pushing many new modelers away. If new Blender users came into the space knowing they could spend a few dollars to render on the cloud instead, the barrier of entry would seem much smaller than that initial impression.
In tandem, modelers later learn that the time used to render on their own system can be worth a lot when spent to model new pieces. While both CG Cookie and Blender Market have been great proponents to show that paid services bring an unparalleled value to the free alternatives, the concept still isn’t as wide-spread as it should be. Once it is, modelers of all levels can understand the benefits of rendering cheaply, and continue to create without investing in a dedicated system.
Since Barista seems to be the one project constantly pushing to offer more for its users, another benefit is cloud rendering development. Did you know that Barista was the first platform to offer Eevee rendering on the cloud? Per Blender’s Manifest, Eevee was never meant to run in the background, meaning it was never made to render on a remote server. Once seeing the benefits of Eevee remote rendering, a solution was added to Barista shortly after 2.8’s release. There are many features like this one still on the chopping-block for Barista.
The biggest reason Barista is important to the community is to provide the cheapest solution for the community. If you want to render on the cloud through a render farm or online cloud service, you end up paying for those previously mentioned service fees. Barista was specifically made to put the power in the user’s hands, and why it only charges a single fee to cover development for a lifetime of use. You can argue that 3rd party tools like the Brenda scripts are cheaper in cost, but then you need to consider the time needed to learn AWS, and then configure instances to render everything manually.
In conclusion, there is a lot that cloud rendering can do to benefit the community as a whole, it’s just a matter of eliminating the misconceptions to influence adoption.