Home » Blender » Rendering 3D projects in 2016 – facts and figures for RenderStreet

Rendering 3D projects in 2016 – facts and figures for RenderStreet

Last updated on by .

We’re a couple of weeks into 2017 now, and it’s time for our yearly retrospective. As we are doing every year, we’re looking back to see what we have accomplished, and we’re hinting some of the things to come in the current year. You’re walking the path with us, so we’re sharing the experiences.

2016 has been a year defined by growth and focus for RenderStreet. Those two simple words have brought a number of interesting challenges, which were the driver for a sustained technology push. As a result, we have become even more flexible in addressing your needs and more efficient at the same time. This means we are now very well equipped to handle everything you can throw at us, including those awesome 360/VR images and videos you will be making this year.

Let’s see what this meant in numbers for 2016:

  • 99.85% uptime. We had 13 hours of downtime throughout the year, a large part of that being caused by the infrastructure upgrade we announced mid-year. It’s a number we’re proud of, and you can depend on us to be available when you need your renders done.
  • Over 137,000 jobs – that’s 5 times more than in 2015. Even with the dramatically increased volume, we managed to keep the success rate over 99%. Delivering is in our DNA by now, and we’ll keep fighting for these numbers.
  • Over 3.8 million frames rendered with RenderStreet One, our fixed cost program. Keeping the program live, offering a good value for your money and doing so without sacrificing the performance was one of the important challenges we had in 2016. I trust we did it well, but of course, you have the final word.
  • 85% of animations delivered in under 80 minutes – with the on-demand service. Considering the fact that both the rendering volume and the average total render time needed for the animations increased (compared to 2015), maintaining the performance level was also part of the challenges we had to face.
  • Our busiest day: the equivalent of 683 days of rendering on the late-2016 MacBook Pro with Core i7. All in a day’s work. (We’re keeping the MacBook Pro as a benchmark, as a lot of artists still use it for their projects.)

The projects that I’d like to mention – from the technical point of view – were:

  • The individual frame with the longest render time: 244 server-hours in total (over 10 days). It was delivered in 13 hours.
  • The most challenging animation: 420 days of server time in total. Had to be rendered over a weekend, balancing both cost and speed. Delivered successfully with the Studio plan.
  • The longest job rendered in one take on RenderStreet One: 62 days of server time. Not a bad value for $50, if your deadline is relaxed.
  • Our split function performed its magic again for large images, the squarest one being 50,000 x 50,000 pixels.
  • We passed the 250 mark in the number of servers allocated to a single project.

All of the above were rendered in parallel with the other jobs processed in the system at the same time, without any service disruption. Thanks to our tech team for doing the magic! 🙂

In terms of things to come, we have quite a few new releases lined up. The first one will be announced shortly, so keep an eye here on our blog. I’m afraid I can’t be more specific now, so please bear with me for a little longer. What I can say is that we remain committed to providing you a solid, dependable, cost-effective rendering service for your needs. And that we’ll do our best to help you when you need it the most.

Thank you for keeping close in 2016, and let’s have an awesome 2017!

Marius Iatan
CEO, RenderStreet

PS. If you are curious about last year’s numbers, you can find them in my 2016 post.


Passionate about technology and constantly working on making a difference, Marius is RenderStreet’s CEO.

  • Thanks Marius. Any idea how we are tracking this year?

    • We’ll publish the numbers for this year at the beginning of the next one, as usual. No peeking until then 🙂