My son has gotten interested in 3D animation with Blender, but his low-grade laptop is too underpowered to render any reasonably complex animation in a sane amount of time. He finally agreed to try out rendering in the cloud, and this post describes what I ended up building.
I came across a promising workshop from AWS that used AWS Batch to split a rendering job across multiple compute nodes. This seemed to be exactly what we needed (really, they had me at Step Functions) so I worked through the workshop steps and got the solution up and running fairly easily.
After testing out the existing code, I decided to make a few improvements:
- Rebuild the project using AWS’s Cloud Development Kit (CDK)
- Use Fargate’s serverless container hosting instead of Elastic Compute Cloud (EC2) servers
- Use an existing Docker image with the latest version of Blender pre-installed
- Leverage Elastic File System (EFS) to share files among Lambda functions and Fargate containers
- Add support for
.zipfiles to allow the pipeline to render fluid simulations (like the steam above), which can’t be packed into a single.blendproject file
Below is a high-level view of the new project:
The basic flow of the pipeline is as follows:
- A
.blendor.zipfile is uploaded to the input bucket in Simple Storage Service (S3). - An EventBridge rule triggers a state machine in Step Functions, which executes the following steps:
- A Lambda function extracts the
.zipfile (if required) and writes the project file(s) to EFS. - A Lambda function analyzes the
.blendfile and determines how many frames need to be rendered. - A Batch job is created and executes container-based tasks in Fargate, each of which renders a single frame and writes it to EFS.
- A single-task Batch job is created to stich the frames together into a movie file, which is uploaded to the output bucket in S3.
- A Lambda function extracts the
And here’s the rendered output in GIF form:
The code for this project is availabe on Github.