Archives for posts with tag: pipeline

Alembic is an open computer graphics interchange framework. Alembic distills complex, animated scenes into a non-procedural, application-independent set of baked geometric results. This ‘distillation’ of scenes into baked geometry is exactly analogous to the distillation of lighting and rendering scenes into rendered image data.

Alembic is focused on efficiently storing the computed results of complex procedural geometric constructions. It is very specifically NOT concerned with storing the complex dependency graph of procedural tools used to create the computed results. For example, Alembic will efficiently store the animated vertex positions and animated transforms that result from an arbitrarily complex animation and simulation process which could involve enveloping, corrective shapes, volume-preserving simulations, cloth and flesh simulations, and so on. Alembic will not attempt to store a representation of the network of computations (rigs, basically) which are required to produce the final, animated vertex positions and animated transforms.

The production ready version of Alembic 1.0 was announced at Siggraph 2011 and released on August 9th, 2011 by Lucasfilm and Sony Pictures Imageworks with support from major vendors including Autodesk, Side Effects Software, The Foundry, Luxology, Pixar’s Renderman and NVidia.

Home Page: http://alembic.io/
Project Page: http://code.google.com/p/alembic/
Language: C++, Python
Platform: Linux, OSX, Windows
License: New BSD License
Sponsor: Sony Pictures Imageworks, Lucasfilm

Pimath is a boost.python binding for the IMath library that is part of the OpenEXR project.

Pimath binds the Imath API as closely as possible. Each hpp file contains a comment block at the top, highlighting cases where the bindings differ and why. Common reasons include:

Making a function signature more Pythonic;
Removing slightly optimised functions (where the overhead of python itself would vastly outweigh the optimisation);
Removing API redundancy;
Changing misleading Imath function names (rare).
Nice things about pimath:

It provides integral template instantiations where possible – eg V3i;
It provides ‘half’ template instantiations where possible – eg M33h;
It provides to- and from-python conversion for the Imath ‘half’ type;
It spreads type instantiation over several cpp files for quick multithreaded compiling.
It’s organised as a mirror image of Imath – it has corresponding headers, and a free function in Imath is a free function in pimath. If you know Imath, you know pimath.

Project Page: http://code.google.com/p/pimath/
Language: C++, python
Platform: All
License: New BSD Licence
Sponsor: Dr. D. Studios

Afanasy is a free and open source tool to control remote computing. You can compute anything quicker using a render farm – remote computers connected by a network. Afanasy is designed for computer graphics (3d rendering and 2d compositing) parallel calculation. It can compute different frames (or even parts of frames) on several computers simultaneously.

Afanasy provides render farm monitoring. It is very important to watch computers resources during the render process. You can see what kind of resource (CPU, memory, network etc.) is needed to render. It is very useful to know what your farm hosts are doing.

The Afanasy engine simply runs different command lines on hosts and controls running processes. You can use Afanasy to parallel calculate anything you can describe (split) through command lines.

Home Page: http://cgru.sourceforge.net/afanasy/doc/afanasy.html
Project Page: http://sourceforge.net/projects/cgru/
Language: C++, python
Platform: All
License: GPL

Originally developed by Blur Studio, Arsenal was a replacement for 3dsmax’s BackBurner. It’s now a robust render management platform supporting many renderers, including 3dsmax, Maya, Houdini, 3delight, XSI, Nuke, Fusion, Shake and After Effects.

The core is written in C++ using Qt, and PyQt is used to extend Python interfaces. There are GUI tools to manage the queue, custom submitters for some packages, and a generic Python API for others.

Project Page: http://code.google.com/p/arsenalsuite/
Language: C++ Python
Platform: Windows, Linux
License: GNU GPL v2
Sponsor: Blur Studio

JupiterFileCache (JFC) is a general purpose, multi location, multi process, thread safe file read & write cache library.

This is a C++ library that allows caching files in remote (network) locations onto the local client to speed up future accesses to these files. This reduces network traffic, but also, more importantly disk access, on the server. Modern network infrastructures are rarely the problem, but a server’s disks often don’t cope well when hundreds of clients read large files, often repeatedly, by querying small pieces of data, all at the same time.

It comes with a SWIG interface to be easily accessible through scripting languages (e.g Python) without the need to use a C++ compiler.

RSL shadeop implementation, modeled after the automatic network cache in DNA research’s 3Delight. It allows caching files like textures, point clouds or other heavy data, on a render farm client, automatically, by simply specifying the cache location with an environment variable, or in the RIB (with an option). In your shaders you can use the cacheFile() shadeop. It should work with any renderer that has an RSL shadeop API but was tested & used in production with Pixar’s PhotoRealistic RenderMan.

Project Page: http://code.google.com/p/jupiterfilecache
Language: C++ Python
Platform: Linux, OS X, Windows
License: Creative Commons 3.0 BY-SA
Sponsor: Jupiter Jazz