the Forge main page
A Project refers to some work to be done.
A project got at least a name and a list of members,
and further it can be given some resource like
online storage, versioned repositories and more.
Projects are created and accessed trought the "Forge",
which is a Cineca internal Web Application that initially
was mimicking sourceforge.
Basically it manages a big svn server where each project
have its own subfolder, and only project members have access.
In the same way, project can have online-unversioned-storage
which can be accessed through the WebDAVS protocol and from
the web-browser using ElFinder.
Another optional feature is Trac, which allows to manage
tasks, and monitor the SVN status.
Some planned features are to provide repositories based on GIT
and OpenClouds ( and open source solution similar to DropBox )
The steps to create a Short Movie Projects are:
the Forge main page
the Forge project list
Project Resources and permission (add, administrators and users are link that leads to their respective configuration forms)
We followed the "Kiss Rule" and stated that an Asset is a production file, thus Blender files, textures, audio files, and so on. (all and only the required files) We discarded the hypotesis to define an asset as an entithy inside a Blender file, this will have lead to an overwhelming complexity, and if a single enthity is so relevant, it can have its own blender file in the library. Another possible way to define an asset is "something that need to be supervised", but our director/art directors found more practical to do supervisioning only of the rendered shots, so this definition do not fit our use case.
Our repositories layout is pretty standars and follows the scheme in Big Buck Bunny. The Movie is made of scenes (sharing a common scenography) scenes are made of shots (single camera take). Shots are Blender file with the camera, the lighting, the compositing network, and the animation. Models are linked in the shots as groups from their respective files in the library, and the linking use a relative path. The whole production folder can become easily huge, taking hundreds of GB and hours for the first checkuot, so in future production we would like to split the library in in a "common" library and some "scene" libraries. This will allow artist working on a limited part of the movie to checkout only a subset of the whole production assets.
The Cineca Render Farm lives on a different host then the Forge,
in particular it live on the supercomputer PLX which provides
274 nodes summing up to 3288 core Intel Westmere 2.40 GHz.
Each node is equipped with two graphic accelerator NVIDIA Tesla M2070,
48 GB of memory and Infiniband connectivity.
The RenderFarm can be connected to any project on the Forge,
the procedure involve a couple of manual steps, and the most important
is the initial checkout of the project SVN repository, subsequent SVN
update can be preformed from the UI.
User access the RenderFarm using the same credentials of the Forge.
The Outputs of the RenderFarm are the third repository needed by the production of a movie.
The Outputs of the RenderFarm are not versioned ( since delete operations
on an SVN can be undoed, deleting a versioned files never release space,
and this will be a problem for us ) but we decided for a partially manual versioning :
each job run will output into a new folder, user can browse all the rendering
of a single Blender file, and manually delete the outputs wich are no more needed.
(more on this later)
the render Farm home page, listing all the connected projects
A Render Farm Project Home Page
The RenderFarm doesn\'t assume any particular repository layout. In its basic usage (useful for testing and small jobs) the user can browse the repository and can start a job on each blender file found. Blender Files can be added/removed in any moment, the renderfarm checks for new/deleted blend files at svn-update time. Removing a Blender File from the repository will remove in cascade all the associated jobs and their outputs.
The Render Farm project file browser.
Selecting a Blender File will
popoup a dialog with the relevant items, in this case just the render button.
The Blender File dialog during the rendering stages (click to enlarge)
The Blender File properties dialog and the job history (click to enlarge)
Browsing the render farm output (click to enlarge)
From the RenderFarm perspective a "Movie" is a collection of Blender files taken from the current project, with a name, plus some common settings like the frame size and the rendering channels. Usually our project have the Animatic, a LowResolution Mono movie used during most of the production and the HighResolution Stereo movie rendered near the end of the work.
the movie configuration form (click to enlarge)
Grouping Blender Files in movies gives two adantage:
First the Movie page release from the need to browse the repository folders
and gives a quick overview on the status of all the renderings involved.
Clicking each blenderfile link pops up the dialogs already seen.
Second, movies pages provide an "encode" button which concatenate
the latest run of each movie shot (by calling ffmpeg append )
and thus give a preview of the whole movie
the movie page
(1) The third colum on the movie page should be able to display:
(2) the movie encoding feature, which now is appending all the shots in a single movie, can be improved to run given a final-editing-blender-file.
(3) A more ambitious task would be to provide support for the management of production tasks. In this moment we are using a shared google doc where each cell represent a task and its color indicate the task status ( to do | in progress | to be supervised | approved | rejected ) Also the doc indicates who is using a file so to enforce access to the assets in mutual exclusion. Possible approach would be using the Trac services or similar web application, or integrate with Opam from Francesco Paglia.
the doc used to track tasks.
