Shotgun, automatic task status update

loocas | Python,Shotgun,technical | Thursday, April 28th, 2016

Get the Flash Player to see this content.

As a pipeline TD you might need to setup task status auto updates in Shotgun. It isn’t as simple as it may sound, because Shotgun, out of the box, doesn’t provide this functionality. However, it can be done with Shotgun Event Daemon and some scripting.

So, first off, a bit of background. As a pipeline guy, automation is essential. You need processes to work automatically, ideally in context and further more in a certain order. That happens all the time. Shotgun, and many other tools, provides a great backend for such automation, however, Shotgun itself doesn’t provide too much automation for its own tasks, versioning, events in general.

Luckily for us there is a large community of TDs working on such tools that can save us a ton of time and effort. (more…)

Going 100% virtual

loocas | opinions,technical | Friday, April 22nd, 2016

AWS banner

Since february this year my studio pipeline went 100% virtual. Due to several reasons I had to get rid of my physical, dedicated render farm, disk station, rack, pretty much the entire server room, and moved to cloud computing.

It goes without saying that it wasn’t as simple and straight forward as I had hoped. Setting up everything took several days (mostly trial/error), but in the end, I moved my entire license server, render farm, Deadline etc. to Amazon’s cloud computing platform.

I picked Amazon for no particular reason. I just had the most experience with it and didn’t really look elsewhere. The setup is so complicated that I didn’t want to invest any more time and money into setting up Azure or Google cloud. The only reason would, potentially, be the cost. Because, let me tell you, virtual computing isn’t exactly cheap.

I’ll discuss my setup, my experience and my reasoning for going to the cloud in my later posts.

EC2 banner


loocas | Shotgun,software,technical | Tuesday, April 12th, 2016


I’ve done quite lot of work with teams using Shotgun, the production tracker, and I’d like to share some of my experiences, tips, tricks and how-tos in context of a Technical Director gluing everything together in a pipeline full of various tools using mainly Python and also MAXScript.

I hope to keep this section of my blog alive as much as possible, so, please, stay tuned. :)

Selecting specific frame ranges of files on disk

loocas | miscellaneous,technical | Monday, April 11th, 2016


Ever needed to select a specific frame range of rendered files on your hard drive (say, only frames 280 through 455)?

I do, all the time. It’s not a problem for a single sequence of, say, only the BEAUTY renders. But what if you have a ton of AOVs (render elements) on your disk and you need to select the same frame range for copying/renaming/moving/deleting/etc…? That can be a real pain in the ass.

Luckily we have Total Commander. :)

If you invoke the quick select (expand selection) window (by the way, this tool will ADD to your selection, which is also handy), you can utilize Regular Expressions. This expression will select only those files within (including) the range of 280 – 455:


It's really that simple and I think you get the logic. You can expand this technique to any kind of sequence of any length. Works every time. :)

Premiere Pro CC and QuickTime encoding error

loocas | software,technical | Wednesday, March 23rd, 2016


Have you seen this error while trying to export your project to a QuickTime movie?

Here’s a simple tip how to continue using this piece of shit of software on higher-end machines:

  • Simply open up the Task Manager
  • Search for the Adobe Premiere Pro process
  • Change its affinity in a way that you disable a few CPU cores for the process
  • DONE

That’s it. Premiere will, suddenly, magically, allow for QuickTime exports.

I hate this software so much…

Nuke 9.0 licensing shenanigans part 2

loocas | Nuke,software,technical | Wednesday, June 17th, 2015

As a followup to my previous post about the new licensing scheme in Nuke 9.0 and up, here’s another, little tip that might help you speed up Nuke launch times:

Watch for the port you’re looking for the licenses on. I know this sounds obvious, but I just recently had to restart my license server after a long time and suddenly Nuke started booting up very slowly. Not as slow as before (as discussed in the previous article), but noticeably slower.

After some investigative work on the server (read: I had no idea what was going on) I launched the FTL tool and ran diagnostics. Everything seemed OK at first, but then I noticed the service was running on a different port than what I had it setup in my environment variables.

After adjusting for this error, all runs as smooth as butter now once again.

So, just a heads up, keep an eye on the port you’re asking for the license on, it will find the license eventually, but it’ll take a lot longer than if you explicitly set the correct port number up.

Nuke 9.0 licensing and speed shenanigans

loocas | Nuke,software,technical | Wednesday, November 26th, 2014


If you’ve upgraded to Nuke 9.0 or even Nuke Studio, like I did, recently, you might’ve bumped into some licensing and boot-up issues with Nuke. So, allow me to share my experience with this upgrade.

First off, Nuke 9.0 is just fabulous. I’m really in love with the software, even though there are a few issues I’m having from time to time. So, after upgrading to NukeX and Nuke Studio 9.0 I also had to update my licenses and with that, the license server. I’m not sure whether The Foundry completely abandoned the FLEXlm license server, or not, but I transferred all my licenses to the newer RLM licensing scheme. With that came a few issues. The most notable one was that Nuke simply did not start up. Easy fix:

  • Stop the foundry FLEXlm server
  • Uninstall any older FLT software, completely, delete your old licenses, especially from the C:\ProgramData\The Foundry\RLM and C:\Program Files\The Foundry\RLM locations on your license server
  • Install the latest version of the FLT software
  • Run the FLT tool and drag-drop the newest license in there. It should install automatically for you.
  • Restart the RLM server


Now this worked. Nuke started booting up, but it took terribly, terribly long. I mean, Nuke 8.xx took about 2-3 seconds to check for the license on my server (via VPN) and boot up. Nuke 9.0v1 took over 20 seconds (!!!) to check for the license and even longer (!!!) for Nuke Studio to fire up.

Something was wrong and I wasn’t sure what. All I suspected was that my setup was acting up as I’m sure The Foundry would’ve done something about this if it were a bug.

And sure enough! I found the issue.


Premiere Pro CC 2014 GPU accelerated previews on new cards

loocas | miscellaneous,software,technical | Sunday, August 10th, 2014


I’ve recently upgraded my GPU to a TITAN Black with 6GBs of RAM, which is awesome, however, Adobe does not “support” this card in its current CC 2014 version.

However, there is no reason this card should not be supported, it’s only that Adobe hasn’t tested the card yet and thus does not provide any support towards it. But, fear not, TITAN Black will render the GPU accelerated previews and everything just fine. You just have to force-enable it in Premiere (and the likes). Here’s how:

  • Go to your Premiere Pro CC 2014 installation folder, in my case: C:\Program Files\Adobe\Adobe Premiere Pro CC 2014
  • Shift + Right-Click in that folder in order to launch the Command Line, from the menu, starting in that folder (this tip is free of charge ;) )
  • Execute the gpusniffer.exe program and see what name of your card it lists at the top
  • Mine said “Renderer: GeForce GTX TITAN Black/PCIe/SSE2
  • In the very same folder, locate the “cuda_supported_cards.txt” file and open it for editing
  • Simply add your card at the end of the list. Do not include the “/PCIe/SSE2″ parts, just the name of the card

Done. Now Premiere Pro CC 2014 recognizes the card for Mercury playback and uses the GPU for acceleration.

Note: If you rather own an OpenCL GPU, edit the “opencl_supported_cards.txt” file instead of the “cuda_supported_cards.txt”.

Migrating encoding presets from Premiere Pro CC to Premiere Pro CC 2014

loocas | miscellaneous,software | Tuesday, August 5th, 2014


If you’re, like me, on the Creative Cloud subscription, you’ve most likely upgraded your applications to the CC 2014 version. Which is all fine and dandy, because your shortcuts and settings got migrated over or synced via the Adobe Sync feature, right? Wrong! For some, unknown, reason the media encoding presets in Premiere and Media Encoder did not get transferred over, so your most favourite and most used presets are just gone and you have to re-do them one by one again.

But fear not, my friends, there is a very simple way (not so obvious, unfortunately, because Adobe chooses NOT to share this info with anyone).

Simply go to your local user directory:


And copy everything from there to the new one:


Done, now your presets will show up in the Premiere Pro CC 2014 as well as in the Media Encoder CC 2014.

3dsmaxcmd rendering error: Unknown error while loading application

loocas | 3ds Max,technical | Thursday, July 31st, 2014


Ever tried to render a scene file on your machine via the command line using the 3dsmaxcmd.exe program, just to save some time loading up the entire program only to hit F9 for a single frame, but then the program fails at frame 0, prior to any rendering?

The reason might be you might be missing Backburner on your machine.

Even though you’re not actually network rendering and you have everything installed properly, if Backburner is missing, this error will surely pop up.

I spent quite a few hours figuring this one out when it worked just fine on my company machines, but it wasn’t rendering on my home workstation.

So, simply run the 3ds Max installation and add Backburner only. Nothing else is needed. You should be fine afterwards.

Next Page »

Powered by WordPress | Theme by Roy Tanck