In 2008 the Blender Foundation made Big Buck Bunny and released all the files under the Creative Commons Attribution 3.0 license for everyone to learn from and play with. Originally the movie was only rendered for standard HD screens. Now it has been re-rendered in cinema quality 4k HDRI, 60 fps, 3D stereo. Not only is there now a very high quality version of BBB to give back to the community, it has been a perfect opportunity to improve the online renderfarm BURP while making it; and to show that it is actually possible.
Resources and raw files
All of the resources created and used to produce both the original movie as well as this revised version have been made available online for free under the CC-BY license.
- Compressed Movie files:
- Raw or processed image files (The kind people at Xiph.org have added Sunflower to their large raw media archive):
- 8bpp PNG stereo files - Cropped, not scaled - great for video encoding tests (faster archive on Xiph.org)
- 16 bit floating point EXR - Raw frames from the renderfarm, uncropped, not scaled (faster archive on Xiph.org)
- Raw or processed sound files:
- Lossless FLAC 5.1 Surround track in 24bit, 48KHz
- Compressed AC3 Surround track used in video files
- Blender production files:
- All 2D,3D,post .blends in a compressed zip file
- Directory of scene files from the .zip for 2D and 3D
- Video postprocessing files directory from the .zip
- List of 3D-camera settings and notes for each scene
- Sound production files:
- Additional links and downloads to the original studio files made available by Blender Foundation
- BBB3D 4K forum thread at BURP
- Online Repository DVD browser, by graphicall.org
- Repository DVD .torrent at blender.org
- Entire Peach Studio Backup, at kino3d.org
- Entire Sunflower Project Distribution
- The Blender Foundation Big Buck Bunny website
- Sebastian Schneider's excellent site on 3D stereo in Blender
If you end up using these files for something really interesting please throw a post on our forum to showcase what you did.
Renderfarm Teams and Statistics
A lot of people took part in the "Sunflower" event where they rendered the 79781 movie frames by providing spare CPU cycles to the online renderfarm project. This is a comparison of the contributions from the different teams involved:
When rendering online each frame is rendered more than once to check for errors in the results. This is why the total number of frames that teams have been involved in surpasses the total number of frames in the movie.
Some scenes also had to be re-rendered to fix flaws - typically those flaws were related to the temporal upscaling (60fps vs 24fps can cause a lot of trouble) or to the 3D stereoscopic effect (things that work in 2D do not always work just as well in 3D).
The Peach movie team originally split the movie into 13 sections and further divided those 13 sections into a total of around 120 individual scenes. The exploded outer ring on the graph shows the distribution of the number of frames that were rendered during Sunflower for each section and the inner ring shows the CPU time used. Some frames took longer to render than others; ranging from a few hours to several weeks of CPU time.
One of the reasons for the high rendering time per frame is that each of the pixels in the roughly 9 megapixel frame has been calculated between 5 and 8 times with a slight shift in its position. This is called "Full Sample Antialiasing" and is a way to avoid pixelation and rugged or sharp edges in the resulting output.
During the Sunflower event more than 3 terrabytes of raw final movie data was produced. Due to the way that frame data is handled while in transit in the backend system on the server this means that at one point the Sunflower project was using around 12TB of storage space - which is more like 35TB of actual disk space with raid mirroring and backups included.
A typical raw EXR frame in the movie ranges from 20-40MB per eye. That means that if you are watching the 3D stereo 60fps version of the movie you will be seeing around 3GB of data stream by in front of you - per second.
There are a good deal of ways for artists to hide little easter eggs here and there. Did you know that the bee that briefly lands on a leaf during one of the very first scenes is actually a tiny monkey head? The monkey is called Suzanne and has a special meaning to the Blender community; similar to the well-known teapot in other 3D tools the monkey is an object that you can insert into your scenes just like boxes, cones and other simple objects. Every year there is an award ceremony at the Blender Conference showcasing the most brilliant Blender art - the Suzanne Awards.
There could very likely be another easter egg hidden somewhere in the mini-site for the Sunflower release."Thanks for the eggs, what about bloopers and out-takes?!"
Plenty of things can go wrong during a production - even when it includes only virtual actors. Blender is well-known for its highly modular and very backwards- and forwards compatible file format. Unfortunately it doesn't always work the way it was supposed to work. The first attempt at rendering the intro scene with the bird turned out to be an eye-popping experience.
Even CG animations can have problems with deforestation. The camera was supposed to have tilted upwards to look at a large trap that the bunny had set up for the rodents. In the first attempt at rendering this scene a mistake in the camera setup meant that only the background moved - causing it to look like all the trees were slowly collapsing.
Improvements made to BURP
A lot of changes went into the renderfarm. Most prominently this was a very good testcase for stability and handling larger than usual data sets. Some of the more technical changes are listed here:
- HDRI images in the form of EXR, earlier only PNG were used
- Support for re-usable libraries by the use of .zip files
- 64 bit clients, allowing for much more detailed scenes and images
- Support for handling really large (4K and above) images and presenting them on the website
- Multithreading to more effectively render large and slow scenes
- Better handling of the rendering queue when many people are rendering simultaneously