For some users, getting the most out of your rendering budget requires more than just cost control; it requires cost optimization. One of the questions we often get once artists begin using Conductor, is “how do I run the most cost-efficient renders?” The answer depends on several considerations, including render time, scene length, and most importantly, the DCC/render software you are targeting.
Some software vendors charge per core-hour, meaning smaller machines cost less, and as you scale up the size, the cost increases proportionally. Other vendors charge per instance or machine-hour, and the price of that package remains constant, regardless of machine size. This model can be less intuitive, as artists think smaller machines equate to lower cost, but the longer render times on those machines end up with quite the opposite effect. Knowing these details about your specific workflow is key to maximizing cost-efficiency.
In a significant pricing change from one of our key partners, Autodesk reduced their overall cost structure and shifted to machine-based pricing for both Maya and Arnold. This shift has the potential for driving down cloud render costs if correctly leveraged, so let’s quickly review the software providers on Conductor and how to best leverage pricing models for each.
Table 1: Pricing model by software package
Core-Hour Models
Core-hour models scale pricing along with the size of the machine, making them reasonably intuitive. Smaller machines are less expensive but take longer for the render to complete. Larger machines are more costly but renders complete more quickly. What isn’t as obvious is how these cost considerations relate to one another. Render packages scale exceptionally well with additional CPUs, so core-hour pricing should have consistent costs regardless of the scene’s machine size. As shown in the table below, assuming linear performance increases, running 1 hour on an 8-core machine with core-hour pricing amounts to the exact cost of a 30-minute render on a 16-core machine, as well as a 15-minute render on a 32-core machine.
Table 2: Core-hour cost comparison for different machine types
Machine-Hour Models
Machine-hour models incentivize larger machine types by keeping costs consistent regardless of the number of CPUs. So, as mentioned above, smaller doesn’t necessarily mean cheaper. Using our earlier example, updated below, the machine-hour pricing reduces overall frame cost when maximizing the machine’s effective power by reducing runtime. For those studios and artists using Autodesk Maya or Arnold on Conductor, this new model offers significant cost-savings, given the correct machine selection. If you previously ran Autodesk renders on Conductor and are submitting work in the future, shots submitted on 32-core machines and above will be incrementally cheaper.
Table 3: Machine-hour cost comparison for different machine types
Other Considerations
While the software pricing model has the most significant impact on render cost, other factors are worth considering when planning for your next cloud rendering project.
Scout Frames: Conductor offers an online cost estimator, but nothing is more accurate than running some elements of the scene itself. The Conductor plugins have a built-in feature for this very purpose, called “Scout Job”.
When enabled, your entire scene uploads to Conductor, but only a select number of frames will render. This feature allows you to investigate your render’s correctness and evaluate per-frame cost before running the remaining frames. You can find more practical information about using Scout Jobs on our Tour page at conductortech.com/tour.
Preemptible/Spot vs. Standard Instances: Preemptible instances (or Spot, on AWS) are temporarily available and highly cost-effective machines in times of low cloud demand. Conductor targets these machines by default through a selection in the plugin. These machines are roughly half the cost of standard machines but can be pulled from a render mid-cycle, losing all progress. While this happens infrequently (less than 5%), preemptions can cause cost overruns and delays if not correctly addressed. A few helpful tips:
Long-running renders: For renders over 1 hour, consider submitting scenes at off-hours, avoiding high-demand times during the workday. If scout frames run over an hour on, say, 32-cores, try running on larger machines to reduce render times and thus the likelihood of preemption.
Automatic retries: Conductor offers auto-retry functionality for preemptions, but in high-demand times of day, this can lead to numerous retries without success. Consider a modest retry policy of 1 or 2 retries, then reevaluate the remaining frames’ process, whether running them off-hours or switching from preemptible to standard.
Fast-approaching Deadline: As is always the case in VFX and Animation, the objectives of meeting deadlines and keeping costs minimal are frequently at odds with one another. Cloud rendering is a great way to mitigate this difficulty if managed correctly. A great way to accomplish this is turning off the retry policy by setting it to “0”. This method will render as many frames as possible on low-cost machines, leaving a small portion of frames left to render. You can then change the remaining preempted frames to standard machines and retry in the Conductor dashboard (our web UI). This will guarantee the scene’s completion on is time, while keeping your rendering costs as low as possible.
In closing, cloud computing addresses numerous post-production needs when done correctly; scalability for final rendering, reduced turnaround time, and cost optimization. Conductor was designed to make cloud rendering more accessible for this industry, enabling users to reap the benefits of cloud, regardless of in-house expertise or resources. For those who have the time and interest in getting even more value out of our platform, these strategies will save you time and reduce rendering costs. By following the guidelines above, your studio will be well equipped to use cloud rendering in the most effective way possible. For further questions, please contact [email protected].
Comments