I was shocked and very pleased to hear that Shotgun Software decided to unify their pricing and bring it down to $49 USD per month per user with the API! How awesome is that?!
That brings me to a thought of actually releasing our duberPython plugin for a ridiculously low price so that EVERYONE can use Shotgun and our Python module in their pipeline!
Let me know what you think, guys and I’ll prep the installations in the meantime.
Just a shout out to those who downloaded my RV Explorer integration Python script.
I’ve updated it so that RV now accepts file sequences with various leading zero lengths as I bumped into this issue myself recently.
Hope I haven’t caused you too much trouble.
Here’s the updated script: v0.3
This post is basically just a note to myself, because I keep searching for this every now and then and every time I forget the syntax. So, here’s what you need to do in order to extract .msi archives to a specific folder of your choice.
To extract files from a .msi file from the command line, type:
msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo
For example, to extract files from X:\installs\someProgram.msi into C:\someProgram you would type:
msiexec /a X:\installs\someProgram.msi /qb TARGETDIR=C:\someProgram
In February, I wrote about calling the JSON variant of the Shotgun API from the IronPython 2.7.1. Now it is time to upgrade the pipeline tools to the latest versions of both IronPython and the Shotgun API.
There are, however, some steps you have to take in order to make things work without issues.
Naturally, you still have to follow the steps described in the february article. In addition to that, however, you also have to modify the Shotgun.py some more. On lines 52, 53 and 54, remove the relative module paths. So, basically just remove the dots from the “.lib“. For some reason, IronPython is having issues with relative imports outside of packages.
After that, everything should be running smoothly again.
Here are a few screenshots from the IronPython console as well as from the MAXScript Listener in 3ds Max 2013.
duberPython (utilizing IronPython engine 2.7.3):
As you might know there has been a significant change in the latest Shotgun API that’s somehow transparent to the CPython users, but presents a rather significant roadblock for IronPython users (including our duberPython bridge, that is based on the IronPython engine).
First, let’s discuss what’s changed in the API so dramatically that it breaks IronPython compatibility. It’s the introduction of a JSON formatting that requires a few specific CPython libraries that are not available in IronPython. The effect it has on CPython users is a faster data transfer to/from Shotgun, but other than that, the API looks to be unchanged from a user point of view. You still keep calling the same methods and you’re getting back the same objects. From IronPython point of view, you’ll hit a roadblock as there are a few modifications you’ll have to make to the Shotgun modules in order to make them run in IPy without issues.
As with my previous post, I’m preparing a few handy tools for 3ds Max artists using Mari and Nuke. This bit is the fun part with Nuke: live communication between 3ds Max and Nuke.
I’m starting to write a useful set of tools for Mari and 3ds Max users. This is the very beginning – establishing reliable communication from 3ds Max’s MAXScript console directly to Mari.
I’ll keep you posted.
Here’s a video demonstrating the power and practical usage of Shotgun (data) brought over to 3ds Max natively via our Python plugin, duberPython.
I’m, along with Gavin Greenwalt from Straightface, featured in Thinkbox’s study that took a look into the Deadline Power Management feature and how it can help save your studio money in the end.
Go ahead, it’s an interesting read.
Every TD knows that command line tools are among the most powerful in their arsenal of tricks and secrets.
I want to mention RVIO, as today it saved me quite a lot of time (again), which is absolutely key when a deadline is coming.
My client requested a minor tweak of animation (a lip sync, to be concrete) on an almost finished shot. So, the general approach would be to do the change, have the animation data go through the pipeline and at the end have the finished frames ready to be loaded in an existing edit, which then gets rendered out and the final result gets showed to the client.
All fine, until you realize your render farm is completely full with other shots, so you have to skip the “beauty” pass rendering and only present the client with a, somehow, polished preview directly from your 3D package, which isn’t the safest way, trust me. But this client is great and understands that what he sees is actually only a preview of the animation.
So, the last piece of puzzle to solve is to get the preview assembled with additional layers of information (such as frame number, shot name etc…), basically a slightly customized overlay. All this sounds nice and simple, you just open up (in my case) Premiere Pro, swap the layers, render out the portion you need and be done with it.
But this certainly isn’t the TD way.