Maya & Scene Management

While Maya gets more bells and whistles with every release it is still pretty useless in a production if there is no one, caring about all the data management. The problem is, if scene/cache imports, exports and versioning is done manually we tend to produce a big ugly mess. Especially if we are in a hurry. Nobody wants to spend time typing in data, prepare scenes, or even worse, clean scenes up. We just want to grab the latest version of whatever we need and get going. I always tried to remember this when designing stPipelineTools. This is why 90% of the UI elements are just buttons. And I’m relatively proud of that. You just choose a prop, material, set, shot, camera or a light and push a few buttons. Everything else is handled automatically.

Fast & Easy To Use

I tried to provide fast workflows and make it easy to use. So even with a small team and if something needs to be done really quickly, stPipelineTools won’t stand in our way. Actually, with the very first click, we will save some of our precious time already. But of course the more complex the project gets the more helpful it will be.


Furthermore, I tried to make stPipelineTools an all-in-one solution. It doesn’t matter if you are working on props, doing scene layouts, animations, lighting, or crafting some neat materials, stPipelineTools handles all of that.

Parallel Workflows

And most importantly stPipelineTools enables true parallel workflows. That is made possible because it differentiates very strictly between the scene that we are working on and the scene that gets pushed into the pipeline. For example, we can leave a lighting setup or some arbitrary test objects in our prop scene. This makes it very easy to go back to whatever we were working on and as soon as we publish our prop it gets stripped automatically. So it is made sure that there is no clutter in our assets at all. And that enables it, that other departments are able to work with a placeholder very early on and everything gets updated automatically as it becomes available.


A Quick Breakdown of the Functionality stPipelineTools Offers:

  • Prop, Material, Camera, Light, Set, Shot Library
  • Automatic Versioning
    • One click Version up
    • Always the latest version is opened
  • Outliner Structures
    • There is some special machinery that forces everybody to keep the outliner tidy.
    • Assets are parented under appropriate group nodes automatically
  • Easy Publish
    • Only the stuff that really belongs to an asset gets published
  • Push & Pull Mechanics
    • Cameras, lights and materials can be updated from everywhere
    • No workflow interruption
  • Parallel Workflows
    • It’s totally possible that prop modeling, set dressing (with that prop) and shot lighting (on that set, with that prop) and animation (for that shot, in that set, with that prop) is all done at the same time.
    • stPipelineTools generates a lot of unique scenes and Maya projects so that everything is independent and can be updated at every time
  • Lights are Divided into Prop-, Set-, Shot-, and Miscellaneous Lights
    • This enables individual workflows
  • Easy Preview Image Generation
  • Automatic Puzzle Mattes Workflow
  • Easy AOV Assignment
  • Custom Render Settings and Custom Defaults for Every Scene
  • Material Creation for Substance Workflow
  • Alembic Caches
  • Proxy Sequence Caches

So,  What’s Next?

At the moment I’m not quite sure, what to do with stPipelineTools. It works at least with Maya 2015-2017, but Windows and Redshift only. Linux and Mac OS support should be doable, but extending it to work with other renderers would take some time. I would love to share this tool with everybody (or sell it for a small amount), but I am not sure if I have the time to support people who are using it. I tried to make stPipelineTools very stable and reliable, but it would be nonsense to believe that there are no bugs in 5500+ lines of code. Furthermore, I would need to write some sort of documentation, to help everybody get started and to show some tricks and hidden gems. So, yeah, I’m not sure what to do with this tool. But if anybody is interested in this, please feel free to reach out to me, and maybe we can discuss some options :)

2 thoughts on “stPipelineTools

  1. Hi Stefan, I just came across your blog while googling “firefly nuke”, so thank you for that!

    I’m writing because I think stPipelineTools looks fantastic. I am a very small operation (mostly just me) that tends to do lots of shots at the same time (65 shot in 6 weeks currently). I used to work at the big houses and I miss organization, pipelines, etc, etc. I would definitely pay for your tool. I used Sunday Pipeline for a few years but can no longer get that to work in 2017, and I’ve used OpenPipeline (which I hate), and also a Nuke pipeline tool from Cragl called ‘smartLib’, etc and this looks to beat them all. I am a hybrid studio– I do my 2D work on 2 Mac Pros and my 3D work on a Windows machine which I set up initially as a Redshift box for a show I did last year. I guess I’m offering to beta test for you or whatever if you decide you want to develop this commercially or whatever. Let me know. thanks– Tony

  2. stefan

    Hi Tony,

    Thank you for your nice comment and I am so sorry, for this incredibly late response… I switched my job and moved from Germany to Canada and I love my new job, but I was so busy, that I never found the time to respond properly.

    Anyway, I recently picked up stPipelineTools again, I am highly motivated to work on it and release it to the public at some point. In fact, I have already started to investigate the current status of stPipelineTools and I would like to make it future proof. This means two things: Converting the UI to PySide. It’s currently PyMel, which works great and does its job, but a PySide UI would pave the way to port this tool to Nuke for example or to build a standalone application.

    The second thing is a proper database. Currently, stPipelineTools naively hunts through folders to look for files and with hundreds of props, this tends to get a bit slow. I built a prototype with a MySQL database and it seems to be working quite well for my needs. Now I obviously need to refactor big parts of the current code, to make it read and write to the database and to strip out all those horrible folder searches. I am admittedly not super experienced with databases (not at all honestly) so I need to think carefully and read a lot, on how this stuff works and to design the database correctly.

    To make it short, I want to release stPipelineTools, but before I do that, I want to make it right. It will follow the same concept and principals as described in the post above, but with a hopefully much better codebase to build upon.

    When the time comes, I would love to have you as a beta tester :) I’ll get back to you soon!
    Thanks again, for your nice words and great to hear, that you like the tool. That really means a lot to me.


Leave a Reply to Tony Hudson Cancel reply