FTP and File Control

Over the course of the production of this short the DropBox service is acting as our 'CVS Host'. So since the start of this there has been some issues, fixes and other ideas to further the use of this pipeline without having to reach the 2.5 GB limit as well as over extend our access to the private FTP server.


DropBox service : Maintains the "main" assets currently worked on.
FTP Server : A private server that serves as backup and storage to free up Dropbox space.
Animux SVN : Talks are in place for project hosting on this network….

  • This is where the Stages come into focus. Each stage will use DropBox and the FTP server accordingly.
  • As of June 10 2009 we are in Stage 1 and will remain so until most likely July, while also starting Stage 2.

One thing is certain - FTP storage WILL be used, for resources that are no longer needed, or have been placed on hold for the time being. Using DropBox, while a very cool CVS type service, it has it's limits in size for the free account level, in fact a 3GB maximum limit.

So one solution at this time to save space is to set goals on the models themselves. This may require redesigning the folder structure itself as this would aid in the process of file transfer and where resources are placed.

  • Once models are considered complete, the file is zipped and sent to the FTP server.
  • The zip file itself should be named (modelname)(type)(date).zip or .tgz. This essentially places them in stasis until needed later during the animation process. Even if this temp location is used for a period of days it can help with project folder size.

When the animation stage begins we can then determine what content is needed, grap it from FTP and begin laying out the process for that shot.

  • Once the shot is done, again place the content in .zip or .tgz format with an additional (anim) tag in the name. This way we know it is done.

(This above process needs to be reworked, it may not function as well as thought)

Ideally we would want a full SVN server, where to find one has been tricky as well. Something that I am looking into but production will continue on regardless.


It has been decided that SVN is not a good choice for our project, at least the Blender side of things. Some concern was raised about how it would handle binary files, since SVN is mainly meant for text file version control. Blender's file format saves as binary, as opposed to the Renderman format which is easily readable by any text editor.
So in it's place we will be using Unison for file synching. Paul Gregory is building the script tools that we will be using to keep all files up to date on our own systems. We are dubbing these tools as "Arachnid", to keep with theme of the project. In the meantime we will continue to use Dropbox as it has served us well and we are still below %50 of our file space availability.

SVN will most likely still be used for the final RIB files when we go into final rendering since it would be far easier to export from Mosaic locally into a RIB render specific directory rather than trying to accomplish this remotely via VNC client. That process will have to be worked out at a later date.


We are trying to keep logs of changes. Of course this always can be overlooked by all so please try to remember to record changes in the MAIN CHANGE LOG.

One neat feature of Blender is that the text editor can also serve as a log file for that file in particular. This makes it very easy for people to make changes and then make note of it on that file, as opposed to adding changes to a general log file in the project folder. Plus in the internal log it is noted for that specific file.

Bug Reporting

If encountering bugs related to Mosaic or Aqsis please make sure to zip (or tar) up the Mosaic export directory and place them into /ProjectWidow/RIB_BUGS folder. If your project folder is filled with extra unrelated files, go into Mosaic and press 'Purge Export Project Folder' and then re-render the bug in question.

This way both Eric, Paul and Chris can get the exported data and examine the problem. If they need additional info or files they will let us know.

Outside Research

One of the best ways to figure things out with RenderMan, or as inspiration is to use the Pixar Research Library, something that is highly technical and only those with some excellent math skills should attempt to duplicate. For artists it serves as great way to fully understand some of the concepts of RenderMan and it can also serve as a point in the right direction. Considering these papers are from the very place where it all began it serves directly to RenderMan as opposed to "general" rendering methods.

Pixar Papers


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License