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.

With huge thanks to the Shotgun Software support, I was able to work around the few limitations and start using the latest API without issues inside IronPython. Here’s what you have to do, in order to make this happen:

• First and foremost, download the latest Shotgun API from the github site. Place it some place you’d like to use it from, most likely in the Lib\site-packages folder, though my folder structure is completely different and based on different rules.

Now if you try to instantiate the Shotgun class, you’ll get tons of errors, so, allow me to save you a few minutes (hours in my case, to be honest) searching and working around them.

• The first thing you have to overcome the “IDNA” encoding, which isn’t supported directly in IronPython. This isn’t as clean and easy as it could be, though the workaround is rather trivial, but bear in mind you might break something potentially doing this. I haven’t come across any issues yet, so, I’d consider this modification safe. Find the iri2uri.py module in the httplib2 folder, open it and change line 71 from authority = authority.encode(‘idna’) to authority = authority.encode(‘utf-8′). This effectively changes the codec under which you’ll be dealing with the unicode strings. Again, it’s not a clean modification and you can potentially run into issues doing this, but in my experience, all seems to have been working fine so far.

• The next problem will be SSL authentication, which, again, is tripping IronPython’s SSL module. To fix this, open the shotgun.py module and on line 73 change NO_SSL_VALIDATION = False to NO_SSL_VALIDATION = True.

• Then IronPython will still be complaining about a module called zlib, which is a compiled CPython module that cannot be used inside IronPython. Luckily there is a C# variant based on the same code as zlib. Download it from Jeff Hardy’s bitBucket site and place it somewhere where IronPython can source it (i.e. within your PATH). I put it in a recommended folder called DLLs directly in the IronPython folder. This means that the IPy interpreter will source the DLL automatically, but bear in mind you’ll have to add a reference to this library manually in your scripts when run outside the shell.

• The easiest way is to add these two lines in your imports into the shotgun.py module:

  import clr
  clr.AddReference("IronPython.Zlib")

This way you’ll make sure the zlib module required by some of the shotgun modules is going to be readily available.

That’s it! Let’s test it. Oh, one more thing, I’ve found these Python variant couples to be perfectly compatible and working in production: IronPython 2.6.2 and CPython 2.6 and for clr4 folks IronPython 2.7.1 and Python 2.7.2.

IronPython 2.7.1:

duberPython (utilizing IronPython engine 2.6.2):

I hope this helps you out with your IronPython and Shotgun scripting and I’m certainly looking forward to the new versions of the Shotgun API.

A huge thank you to the Shotgun Software support team!

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.

Stay tuned!

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.

Fortunately for me, I’d purchased a license of RVIO some time ago, so I have an extremely powerful and versatile tool in my arsenal of VFX software that just gets the job done, no matter what.

The problem with the Premiere Pro approach, actually, there are two problems: 1) my lazyness and 2) the time it actually takes to get it done. Besides, this way you are also exposing your project to errors. You might accidently save the project and when you least need it, it’ll jump back at you and you’ll have to be dealing with this fuck-up in the least desirable time – the minute before the deadline.

So, the easiest approach for such a trivial task would be something that allows you to combine an image sequence with your sound file and spits out a movie file with the correct size, color, the whole package, basically.

RVIO is such a tool and it is aimed at TDs and people who aren’t afraid of using the command line (which you certainly should NOT be as it is the most powerful, fastest and actually easiest way of getting things done, even in 2011). It allows for both simple and extremely complex image, movie and sound file conversions. See the RVIO site for more info on that.

So, what is the concrete example I’m talking about? Something as simple as delivering a correct file and presenting it properly to the client can be a complex process in a large pipeline. In my case, as I’m a fairly small boutique, what I needed to do was to take an image sequence of the fixed animation, place it in an existing timeline (effectively replacing the previous, fully rendered, version), setting up markers for in-out points, setting up the export settings, correct file name, correct video and audio codecs, correct output size etc… Then have it exported, review the file, upload it to our server and present the link to our proprietary review site for clients to the client.

This entire process isn’t too difficult to manage in five to ten minutes, but presents a bit of a security threat that I mentioned above and also isn’t very flexible or comfortable. Sure, for people that can only deal with their software via nice and polished user interfaces, this is the only way to get the job done, but for a TD, there is a much smarter, faster and cooler way.

Here come the super-powers of RVIO. It’s strictly a command line tool. But to perform all (and many more!) tasks that I just mentioned, all you need is this line of code:

rvio [ "inputFrameSequence_12-125#.tif" "inputSoundFile.wav" ] -codec avc1
-outkeyinterval 20 -outdatarate 1000000 -outgamma 0.85 -outres 1024 576
-audiocodec aac -o "outputMovieFile.mp4"

That’s it! See how awesomely simple, fast, effective and cool this is?!

Now, this was just a command line command you execute directly and you get a outputMovieFile.mp4 in the correct format, the correct in and out of the animation, correct sound and everything between. However, imagine what you can do with this! If you know Python, or on Windows, preferrably, IronPython, you can do WONDERS!

I’ve tied RVIO with Shotgun via IronPython so that I can do very easily, effectively and super fast deliveries to our client on a project with about 120+ shots. It’s not a huge project, though, but the sheer number of shots definitely calls for scripting. There is no way I’d be sitting at 4am at the computer and manually editing and converting 120+ shots to a desired format for review whenever there is a change in the animation or compositing! That’d be a suicide and a complete waste of resources.

What I did was calling a loop on all the shot folders where our final comp files were being stored, picked the rendered files and fed them to RVIO with a few parameters set specifically for that project, similar to what I just showed you above, pulling a few variables from Shotgun, such as in and out cuts, shot name and other data. Then it automatically takes the resulting movie files and uploads them to our review system via FTP. That was it! With about fifty lines of code I achieved a task that’d take me at least three hours of intensive file hassling and messing around! All of this then takes about ten minutes to process, which is perfect for a coffee break.

Besides, it’s recycable, in a sense that when there is something changed in any of the shots and we need to re-deliver, I just run the script again.

This is what I love about my work! The effectivity, productivity and the cool factor, of course.

Just a quick shout about the compatibility of duberPython and the latest and greatest IronPython 2.7.1 release (released a couple of days ago). All working smoothly and quickly, as expected.

Should you need more info on duberPython or what we’re doing with it and Shotgun or Tactic, just drop me a line and I’ll be more than happy to show you how cool duberPython is.

I’d test driven RV a few months ago to see what all the fuss was about. I was kind of satisfied with RV at that time, but didn’t really have a strong reason to switch from my beloved FrameCycler. Now, however, I needed a strong platform for conforming, ingesting and generally managing my review and delivery pipeline. My two immediate options were MetaRender and RVIO.

First of all, I am not a big fan of acquisitions. I admit it’s sometimes to the better for all of the parties involved, but sometimes, for the worse. I personally don’t see Adobe investing too much (at least not in the begining) to FrameCycler and MetaRender. They admitted they were more interested in the color grading suites. Secondly, RVIO provides a bit more robust framework for transcoding etc… and seems overall more powerful.

So, that’s the reason right there, I’m slowly switching to RV mainly thanks to RVIO. I wish FrameCycler all the very best, I certainly don’t want to see it go and it most likely won’t go anywhere, but, I think there are more interesting things happening on the RV side.

That’s right, folks! I am thrilled to announce, that Pixomondo, the company behind some of the most challenging VFX shows, such as Sucker Punch, Iron Man 2 or 2012, has purchased and implemented our duberPython plugin for 3ds Max, allowing them to tightly integrate software, such as Shotgun, into their complex pipeline.

We’ve also helped with scripting Shotgun wrappers and optimizing the duberPython engine to suite Pixomondo’s needs. This resulted in a more refined, streamlined and faster IronPython connection for 3ds Max TDs, scripters, developers or even regular users.

A few key points of duberPython:

• It allows for direct calling of Python code from within MAXScript
• Also allows for Python script files to be called with unlimited number of arguments
• duberPython supports behind-the-scenes data type conversions between Python and MAXScript
• duberPython is a dotNET assembly, which means it’s a 3ds Max version and release agnostic (can run on Max 9 to 2012, both x64 and x86)
• duberPython is built on IronPython and thus supports the latest dotNET version and 3ds Max releases
• duberPython was created for the sole purpose of enabling 3ds Max users to use tools like Tactic or Shotgun
• duberPython is available for licensing! Get in touch for more info.

I’d love to show you more, so, you can either wait for me to make a nice presentation and put it up here, or, you can get in touch and I’ll give you a private presentation and provide you with a fully functional, time-limited, version of duberPython.

I’ve been really lucky to have been able to use Shotgun as a developer for some time now (getting to know the API, integrating it into 3ds Max pipelines, etc…).

Now, for the first time, I’ve actually tried to use it on a production we’re working on here at duber studio. The reason is the sheer amount of shots needed to be done, even though they are not very complicated.

We’re currently working on a number of animated shots for a portable devices app to be released soon, first locally, then globally. It’s an app aimed at helping people with their fitness excercises. So, we have to animate a ton of shots of a main character doing various different excercises.

Again, it’s not very complicated, but since I’m working with a collegue of mine on this project I also need a tool to manage the production. It actually surprised me how useful Shotgun is even for a team of just two people! It’s incredible how much time and effort you save when you don’t have to hassle around with Excel sheets and tons of e-mails.

Further on, I’m currently integrating certain actions into Deadline, so that I can automate a ton of tasks on the production. For example, I’ve setup Deadline so that when we submit the 3ds Max scene files, they get rendered, when they finish, Nuke automatically picks up with a pre-made automated comp (visually approved by the client) and then after that Deadline will process the frames again and will generate QuickTimes, delivery masters and preview JPEGs. While all these steps will get annotated in Shotgun.

Pretty exciting stuff for a geeky TD, right? Anyways, I’m currently just looking into best ways of doing this effectively and as open as possible, so I can share the stuff with others as well.

All in all, Shotgun seems to be one of the tools that you really need all the time, but you know you found the answer only after you’ve fully discovered its possibilities and potential. I highly recommend talking to the Shotgun dev guys in regards to a demo or trial. You won’t regret it. I certainly didn’t!