duber's blog

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.

(more…)

Here’s a video demonstrating the power and practical usage of Shotgun (data) brought over to 3ds Max natively via our Python plugin, duberPython.

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.

(more…)

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.

People have asked me how to actually write a plugin for Deadline that will automatically submit a Nuke scene (or any other, for that matter), so I put together a quick tutorial showing you just that.

If you’re interested in a live demo or more information about the duber Python and Shotgun integration in 3ds Max, drop me a line via e-mail at: ldubeda[at]duber.cz

I’ve had a few customers and clients asked me specifically about getting Dictionaries from 3ds Max to Python using our 3ds Max Python plugin, but I wasn’t able to answer with an elegant or productive way of handling these data types in the MAXScript environment.

Until recently, I’ve been handling Dictionaries two ways:

1. String parsing (i.e. a very primitive way of handling foreign data types, not really recommended)
2. Manual wrapping (i.e. passing in a List or Array object and converting it back to a Dictionary object)

String parsing is the worst possible way of handling such an issue. It’s very cumbersome, highly unintuitive and with MAXScript string capabilities, extremely difficult. Manual wrapping, on the other hand, is rather more elegant, faster and you can use other, known, data types to construct your future Dictionary and have that converted in Python natively. The down side is, you have to be very careful with the way you’re handling the future Dictionary. The thing is, only a tuple of list pairs can be successfully converted to a Dictionary in Python. This is a bit limiting as we don’t have any specific way to tell what is a Tuple and what is a List in our Python implementation in MAXScript as there are no such data types available. So, what I did was I had an Array sent to Python (an actual .NET Array object, by the way) I had that converted first to a Tuple, which is pretty straight forward and then have that converted to a Dictionary. Worked fine, but it was a bit difficult to construct more complex Dictionaries, especially nested Dictionaries, in MAXScript.

(more…)

I’ve recently bumped into a strange problem that kept on crashing on me on my Virtual machine testing my latest IronPython script.

The problem was that a dircet MD5 object comparison of files originating from the same source, i.e.:

from System.Security.Cryptography import MD5CryptoServiceProvider
md5 = MD5CryptoServiceProvider()

file1crc == file2crc

returned, in IronPython 2.7, expected True, but in earlier versions, I got False.

This is the actual checksum converted to a string, so you can see they really are both identical (though computed from different sources):

>>> System.BitConverter.ToString(destMD5)
'2A-74-7D-5F-CC-FD-B6-75-57-C0-30-28-E4-BB-A4-0C'
>>> System.BitConverter.ToString(srcMD5)
'2A-74-7D-5F-CC-FD-B6-75-57-C0-30-28-E4-BB-A4-0C'

Interestingly enough, when I compare the two strings, the result is True.

After an hour or so of experimentation, I had to re-write the script to compare the strings rather than the actual MD5 checksum objects directly, in order to make my script compatible in earlier versions of IronPython.

I still haven’t received an answer to this behavior on the IronPython public mailing list, so, I really don’t have an answer as to whether this is a bug or some kind of a feature that isn’t clear to me. I’ll report back when I get more info.

Once again, after the promising IronPython Tools for Visual Studio 2010 were included in the installation of IronPython 2.7, I decided to give Visual Studio Express another shot. Well, VisualStudio Integrated Shell, to be exact, as Express doesn’t specifically support IronPython.

I’m fairly inexperienced with Visual Studio and also I don’t code very large script/programming projects, thus a full Visual Studio suite is a complete overkill for my needs, however, I really like Instellisense and Autocomplete features it offers, but mainly I really dig the Forms or XAML designers.

(more…)

I’m trhilled to be able to finally showcase, at least, some of our very own Python implementation into 3ds Max!

First off, our primary reason for writing our own, proprietary, Python connection to 3ds Max is Tactic by Southpaw Technology. An awesome asset management system entirely written in Python that I decided to invest in and integrate our tools and software packages into. Another reason for this connection, later came up, was the need for writing much more complex scripts with complex GUIs, since, as you probably know, a few functional lines of code are hardly enough in a modern, efficient, VFX production of today.

The heart of our Python integration is dotNET from Microsoft. I can’t express myself enough how much I appretiate this framework! The brain of our Python integration is IronPython. Also a product from Microsoft, completely open source and free, which are two very important aspects for any pipeline tool in any production facility of any size. Not the price as much as the availability of the software. And with IronPython and Microsoft, I am certain that this piece of software will be around for years!

(more…)