40,000 animations for a Fewocious NFT project (rendered in 3 days instead of 7 years)

2022-04-22 · By Richard

PAINT is a generative art project by FEWOCiOUS consisting of 40,000 Paint Drops. Each paint drop is a unique 3D animation, which symbolises a building block of the FewoWorld universe.

A few weeks ago the production team behind this project reached out to us, because rendering 40,000 3D animations required a huge amount of render power.

For the Blender animations they used Geometry nodes to create the unique paint drops. All in a generative workflow (which Geometry Nodes is perfect for). Giving them all kinds of crazy effects and artistic styles:

Credit: Nifty Gateway

40,000 animations (each 200 frames) is quite a chunk of rendering, so they asked us if our render farm was able to do this. We have a lot of experience rendering huge projects fast, but this was a bit of a different beast. We did have prior experience with rendering many different animations based on a single .blend file, so we decided to use the workflow we had developed for that.

(40,000 animations of 200 frames is a total of *8 MILLION** frames to render)*

After some quick calculations, we found it would take about 7 years to render all 8 million frames on an average computer. We had 3 days to get it done.

These 3 days turned out to be one of the most challenging days since the dawn of Blendergrid..

How do you organise a production of 40,000 animations?

First of all, how on earth do you manage a production of 40,000 unique animations? How are the different variations created? How do you keep track of everything? How do you move the files around? These were some of the challenges we had to deal with.

When taking on this challenge, we collaborated with Logan, the creator of a tool called FZRandomizer. FZRandomizer is a very useful Blender add-on which allows you to randomize characters and other mesh objects. In the end we did not use this tool though, because the project required a more custom setup. But it was great to brainstorm and discuss ideas with him.

Managing variations

The way we organised the vast amount of variations was by using .csv files and custom Python scripts.

The paint drop variations were created by a workflow using Geometry Nodes. The way we were able to specify a variation was simply by plugging in different values into the Geometry Nodes Modifier. It's simple enough to automate this with Python.

To manage all the different values per variation, we used .csv files. In theory we could have used a single .csv file for all 40,000 variations, but 40,000 lines in one spreadsheet seemed a bit hard to manage. So instead we divided the 40,000 variations up in batches.

Within each .csv file, every row had input values for all the Geonodes inputs like colour, transparency, etc.

We saved the main .blend file in one central location as our template. Then based on the csv files, we spawned one render job for one animation per line in the .csv file. These jobs were then distributed out to all our render servers. Each render job was using this same .blend file as the template.

Fast rendering

To be able to render 8 million frames on such a tight deadline, we had to reserve almost all our compute capacity for this project. At the same time we were trying to increase our total compute capacity as well. As it was such a close call whether we would be able to make it or not, I personally got on the phone in the middle of the night with various data centers to tap into their resources for even more render speed.

This is a plot of the total compute capacity dedicated to the Fewocious NFT animations to get an idea of the impact this project had. Initially we were rendering some tests and smaller batches of renders which can be seen in the small spikes. But Wednesday March 30th we kicked off the main batches because it had to get done on April 2nd. On Thursday we were able to tap into more data centers which increased the render speed significantly.

File management

Normally, the Blendergrid render farm software organises all desired output files in the cloud (using Amazon S3). Initially this is how we also managed the output of all the paint drop animations (mp4 files). We collected all the download urls and saved them in a spreadsheet similar to the spreadsheet we used to manage the variations.

In the end, it was clear we needed to collect them all in a central location. 40,000 is a lot of files, so we had to be smart about this. If downloading takes any significant amount of time, that would be a problem when multiplying that by 40,000. In the end we found a pretty easy and elegant solution: Dropbox. We transferred all mp4 animations to a central Dropbox directory for easy access by everyone involved in the project. That worked like a charm.

In a nutshell

What the entire approach boils down to:

• Have one "template" .blend file that includes all the assets needed to create every possible variation.
• Have an easy way to specify the attributes of every variation. A .csv file in this case.
• Using our render cluster software, spawning one render job per variation. Based on the lines in the .csv file.
• Reserve a huge amount of compute power to be able to render many of these animations in parallel. That's how we were able to render it in 4 days instead of 7 years.

Want to get in touch about rendering a large NFT collection? You can schedule a call or email us: