Pipeline Tools

The impetus for this post comes from two sources. One was an interview I watched on fxguide.com with the head of the Discreet Logic products at Autodesk (Smoke, Flame, and Lustre – kind of), who talked about Flame and Smoke being finishing tools rather than pipeline tools. He was talking about Nuke and how in many ways it is not comparable to Flame because Flame/Smoke are much more than shot-by-shot applications. Instead they are about seeing your whole project and bringing it to a close with titles, complex effects, color correction, etc. at realtime speeds so clients can be in on the process. So it got me thinking about what apps are used in the pipeline and which apps can be used to complete a whole project (animation or film). The other source was the recent news about Luxology and The Foundry merging. These companies create very different products and there are some pretty cool opportunities with the merger. One thing that came up, however, in interviews with users of their products is that The Foundry’s products are very expensive and out of reach for small studios and Luxology’s products are very inexpensive and easy to use. I was really surprised by the candor of John Knoll (ILM vfx supervisor) and Tim Crowson (Magnetic Dreams, Nashville) about how The Foundry’s tools are expensive pipeline tools that are hard to use and how Luxology’s Modo is low-cost, easy to use, and creates really high-quality output. John Knoll also seemed to say that The Foundry could learn a thing or two about software design from Luxology. Stu Maschwitz has also remarked about how there is a move towards easier to use software over never-ending software options that are hard to understand and rarely used. Even the new version of Maya, which is famous for its ability to make the easiest thing take as many mouse clicks as possible in multiple editors, has simplified its interface to make everyday tasks easier. For years I have argued that it should not be so hard to get work done in software applications. I always thought it was funny coming from me because I like a lot of complexity and I am very technically savvy, but I was finding that it was complexity for complexity’s sake or it was a leftover from the app starting out as a pipeline or in-house tool that grew to a more generalized application. Cinema4D is really popular with motion graphics artists because it is relatively easy to use and can produce high-quality imagery with a complete toolset. Blender is free, but it is shrugged off often because it’s free – how can it be good if you aren’t paying thousands of dollars for it?

There are a lot of software applications out there for creating digital content. Depending on your projects, production team size, level of quality, technical expertise, need for sharing data with other artists, GUI preferences, budget, and probably several other reasons you will find yourself looking at all the products out there and trying to decide how you should invest your overhead funds.

Two general options are out there for developing a pipeline. One is to keep everything under one application and the other is to break the process out to separate software tools. The primary reason to use one tool is simplicity – keeping all of your assets and workflow together in one environment. The main reason to break up the pipeline with separate tools is to use the best features of different applications to raise your production value as much as possible (assuming that each tool helps complete a task better than anything else).

An example process that can be done by one or many applications:

  • Live action post
    • Edit
    • Audio mix and sweetening
    • Color Correction
    • Visual Effects
    • Final compilation for delivery

Live action post from the edit to final delivery can be done in one application, such as Final Cut Pro, Avid MC/Symphony, Premiere Pro, and Smoke 2013 (among others, but these tend to be the ones that everyone likes to talk about). It is possible for one editor/artist or a small team to produce content at a high-level of quality in just one of these applications. However, for projects that require complicated sound mixing, extensive color correction, and/or complicated visual effects, a single application may not have all of the tools to do the job at the expected quality. Here’s how this would look if it were broken out into individual pipeline tools:

  • Live action post
    • Edit – Final Cut Pro, Premiere Pro, Avid MC or Symphony, Smoke 2013, etc.
    • Audio mix and sweetening – Pro Tools, Logic, Ardour, Audition, Nuendo , etc.
    • Conform – Hiero, Resolve, Scratch, Baselight, etc.
    • Color Correction – Resolve, Speedgrade, Scratch, Lustre, Apple Color (discontinued), Baselight, Magic Bullet plugins, etc.
    • Visual Effects – After Effects, Nuke, Digital Fusion, Flame, Smoke 2013, etc.
    • Final compilation for delivery – Avid DS and Symphony, Smoke

Using several applications creates some issues that the post-production team will have to deal with. The first is the ability to easily move data between these applications via XML/EDL/OMF/etc. or exporting from one and importing into another. This can be a headache if the applications fail to move data properly. There are also possibilities for data or image quality loss. The other big issue is cost. If the artist/freelancer, small shop, or institution has to maintain licenses of all of these tools then it can get expensive quick. Looking for bundles, suites, or free software often look better than purchasing from different vendors for each application.

3D animation and visual effects is even worse. There are several general animation and compositing applications that can do very high-quality work, but there are also pipeline tools that can offer better solutions to specific problems that can be tough for the general apps to do. Here are some steps in the workflow for doing 3D and/or VFX work:

  • 3D Animation/Visual Effects
    • Model
    • Rigging
    • Layout
    • Animation
    • Simulation
    • Tracking
    • UV Layout
    • Texture Painting
    • Shading
    • Lighting
    • Rendering
    • Compositing

Lots to do and lots of applications to do each part. First the general animation applications: Autodesk (Maya, 3dsmax, Softimage), Cinema4D, Lightwave, Modo, Blender, Houdini. There are others, but these get most of the press. Each can do everything listed below except for compositing (some can’t composite). For compositing just look at the Visual Effects step from the live-action list above and add Blender, Softimage, and Houdini.

  • 3D Animation/Visual Effects
    • Model – General 3D app, ZBrush, Mudbox, Modo, FormZ, Rhino, Inventor, Vue (for landscapes), Silo
    • Rigging – General 3D app + scripting, Motion Builder
    • Layout – General 3D app, Motion Builder, Katana
    • Animation – General 3D app, Motion Builder, in-house tools
    • Simulation – General 3D app, Naiad (recently assimilated into the Autodesk collective), realflow, Houdini, FumeFX, in-house tools
    • Tracking – PFTrack, Syntheyes, Blender, Mocha Pro, boujou
    • UV Layout – General 3D app, Headus
    • Texture Painting – Mari, Bodypaint, Photoshop, Krita, GIMP, etc.
    • Shading – Renderman, OSL, other renderer shading languages
    • Lighting – General 3D app, Katana, Keyshot
    • Rendering – Mental Ray, Vray, Renderman, Arnold, Maxwell, Luxrender, Appleseed (in early stages), 3Delight, Krakatoa, etc.
    • Compositing – After Effects, Digital Fusion, Nuke, Blender, Houdini, Softimage

A boatload of apps here… Moving data between these applications can be very difficult and some pipeline apps like Realflow and renderers require extra costs to render on more than one computer at a time. At facilities that use multiple pipeline tools and/or multiple general 3D apps there are usually Technical Directors (TDs) that create custom tools in Python and/or Perl or a native scripting language like MEL to efficiently move data between apps. This extra technical support is usually beyond the means of small shops, individual artists, and institutions so they tend to feel the pain when going between applications. How are things changing to help these problems?

  • Since Autodesk owns half these apps they have worked on getting data between each app easier – just have to upgrade each year to wait for better workflows
  • Large studios like ILM and Sony Imageworks have released software as open source to make data interchange easier. Projects include OpenEXR, Alembic, and OSL. Other open source projects like the Bullet physics simulator have been integrated into open source and commercial applications.
  • General 3D apps are getting better at what they do so extra funding for pipeline apps are not as necessary except in extreme situations. See the additions of sculpting to Cinema4D, physics simulators in Maya and Houdini, renderers like Cycles and smoke simulators in Blender.
  • Prices are falling and competition is good. The Pixel Farm recently lowered their costs, Luxology’s Modo continues to get better while keeping its price lower than all other commercial general 3D programs. New lower pricing structures for the higher-priced commercial applications seem to come out each year – or bundling like Autodesk does.
  • Open source solutions exist, such as Blender, Inkscape, Krita, Luxrender, Ardour, etc.

Do you really need the pipeline apps? Ask yourself a few questions, such as, can I afford it beyond my regular tools? will I use it regularly (ROI)? do I have a problem that can only be solved with one of these apps? do they play well with my existing apps? do you need to purchase a specific app for a specific position on your team, such as texture painter or colorist? Hopefully you will not find yourself saying no to being able to afford them, but saying yes to having a problem that can only be solved with one of these apps, but don’t be surprised when it happens. Also look for hidden costs, such as render licenses, limited OS support, and annual license fees. Consider leasing specialty apps when that option is available. More than anything – consider the need at hand and choose the tools that can get the work done at the level of quality you expect. Just because there is a specialty tool out there does not mean that it is the only thing that can do the work. BTW, I’ll try to add some links and costs in a followup post.

A little Python project

I don’t program enough. Simple python programming opens up so many opportunities for pipeline tools and extending graphics applications like Blender, Maya, Cinema4D (latest versions), Lightwave (latest versions), Nuke, Hiero, and several asset and job management systems. Python is also being pushed as the main programming language on the Raspberry Pi, which is sitting next to me wanting some attention…

After Europa wrapped I started a programming to-do list that included a tool that checks for missing or bad rendered frames. I was rendering on a lot of different machines for that project and had thousands of frames to manage. I wasn’t using any render management system so there was nothing checking to make sure a frame got rendered properly except me scanning lists of files. The software that runs the cluster at school has no ability to make sure a frame got rendered properly and at home I use Blender’s simplistic network rendering ability of creating an empty frame (to show that the file exists and a free computer can work on the next frame) and then replacing the empty file when the rendered file is finished (BTW, there is a network rendering manager in Blender, but I don’t use it – yet). If a computer fails to complete a rendering there will be a blank frame left behind. A blank file will be left over if a computer fails on the school’s cluster (Callisto) too because I usually setup the files at home (turn on the “placeholder” and no “overwrite” options). While I didn’t have a lot of problems with broken files and unfinished sequences, I felt like I was vulnerable to issues that would be difficult to fix at the last minute – some frames took about 40 minutes to complete on an 8-core/16GB RAM computer.

Over the last couple of days I carved out some time and wrote a python script that looks for both missing files in a sequence and files with zero (0) bytes and then it writes out a report to tell you what’s missing or has zero bytes. It works by typing something like this in the command line:

python badFrames.py /path/to/rendered/frames 4 0 240 /path/to/logs

  • /path/to/rendered/frames = unix-style path to the directory that has the frames. In OSX, /Volumes/Media/Europa/06 (or something like that)
  • 4 = frame padding. The number 4 shows that a frame name will end with 0000, 0001, 0002, etc. This assumes number + extension, such as file0001.exr. The filename can be anything as long as the last 4 (or whatever) characters are numbers.
  • 0 = start frame
  • 240 = end frame (correct/expected end frame, not what’s actually in the directory)
  • /path/to/logs = (optional) the script creates a text file that is saved in this path. If a path is not here then it will save the log file in the same directory as the frames

There is only a little error checking going on so it could break if there are extra files in the directory, such as text files that are listed before the frames (sub-directories/folders are fine though), or you give it a path that does not exist. If people ask, I will add more error checking so it gives actual error messages. Right now it will give you a help message if something obvious is wrong. I might make a GUI for it too – more on that later.

BTW, this will not work on Windows without a few tweaks, but will run on OSX and Linux fine. I am hard coding some slashes in paths that work on unix-based systems only. It does require Python 2.7x or 3.x due to my print statements. I can change them so it works with 2.6 or earlier if you want.

Grab it here (temporary link)