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.

The thing with 3ds Max is that regular expressions are foreign to MAXScripters and they don’t usually use them. I too am more used to regex in Python or IronPython than MAXScript. However, since we do have access to .NET in MAXScript, we can use its Regex class inside MAXScript.

Why I’m mentioning this and why could it be useful to you? I bumped into a little issue with my pipeline’s handling of rendered files. They assume to be exactly the same as I set them up in 3ds Max, which is logical and correct. However, since I started using Deadline’s SMTD script for submitting my files to the render farm, which takes care of handling the path remapping and storing, it also accidentally took care of letter casing. So, in the end, my render files were being saved all upper cased: “\\SERVER\PROJECT\RENDERS\ABC.EXR” instead of what I set in the Render Dialog: “\\SERVER\Project\Renders\ABC.exr”. The reason was simple, I used simple MAXScript substituteString() method to re-map my local paths to my server, UNC, paths and I converted everything to upper case just in case I got a mismatch:

substituteString (toUpper srcPath) @"D:" @"\\RAMMSTEIN\__UNMANAGED_PROJECTS__"

This wouldn’t be such an issue in a Windows environment, however, when you start dealing with path and file names in Python and you start mixing up casing, you can easily get burnt.

So, the only option left in Python would be to use the re module and search or replace strings based on regular expression matching. In MAXScript, however, we don’t natively have a re module and its methods, but luckily for us, we can use .NET, so that the previous method written in MAXScript using regex would look like this:

regex = dotNetClass "System.Text.RegularExpressions.Regex"
regex.Replace srcPath @"^(D[:])" @"\\RAMMSTEIN\__UNMANAGED_PROJECTS__"

This replaces the capital letter D in the source path srcPath with the UNC server path exactly the same way as the substituteString method above. However, since this is a regular expression engine you’re using, you can modify the search in order to match any casing, should that be your choice.

There are two ways of doing that. The ultimate way I chose in the end was to modify the search pattern to @”^([D|d][:])”, which matches both “D:” and “d:” in the source path and then replaces it with the UNC path at the end.

The other option you can use, should you choose to, is the RegexOptions Enumeration argument at the very end of the method call. If you want to ignore casing, just use this:

regex = dotNetClass "System.Text.RegularExpressions.Regex"
regexOpt = dotNetClass "System.Text.RegularExpressions.RegexOptions"
regex.Replace @"d:\testProject\projFolder\something.exr" @"^(D[:])"
@"\\MyServer\__myProjects__" regexOpt.IgnoreCase

Tadaaa! It’s as simple as that. No path splitting, no case testing, just a single line of a regular expression call (not counting the class call) and you’re done. Besides you can use this at a much greater scale with far more complex regex search strings for anything you like directly inside MAXScript.

Note that I’m replacing a D: drive letter in the source paths since that is my projects local drive. You can use whatever you want, hell, you can replace any and all drive letters in one regex call, if you want:

@"^([A-Z|a-z][:])"

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.

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.

Whatever your reason might be for using .NET Forms instead of standard dialogs, you’ll still want to:

• Create the main form and define its properties
• Define other UI controls, such as buttons, checkboxes etc…
• Define event handlers for specific control objects
• Initialize and display the entire Form with all the controls and functionality tied in

All this is done a little differently in the .NET realm than what you’re used to in MAXScript. But before you start, check out Paul Neale’s great .NET tutorials on his site. Paul provides some great info for anyone trying to use .NET controls in their scripts.

Now, there is one thing I bumped into, you can actually use .NET objects in MAXScript rollouts, however, you cannot use regular max controls in .NET Forms! So, trying to assign a standard button to a .NET Form will result in an error.

You might think that this creates a burden on the TD to actually skin and customize the .NET controls to look like native 3ds Max GUI elements. You can do this, of course, but it’d really be a lot of additional work to hassle around with color classes, HWNDs etc… you actually don’t need to worry about this as there is an Assembly available in standard Max installations. It’s a little .dll, found in the root of Max, called MaxCustomControls.dll. This Assembly contains some of the more exotic controls, such as SceneExplorer, but it also contains a complete Form control that has already been modified so it reflects your 3ds Max environment, including all the colors, themes and even an initialization method for showing the control as a part of the max process/window.

Anyways, back to the topic. You can easily instantiate the MaxForm control as follows:

maxForm = dotNetObject "MaxCustomControls.MaxForm"

This way you have the System.Windows.Forms Form fully tailored to 3ds Max, without any additional work. Standard methods and properties of the .NET Form control are supported, of course. So, all you need now is to start adding controls to it. This is done differently than what you’re used to in rollouts. By simply instantiating buttons, checkboxes, or whatever, inside the scope of the script (because there is no rollout scope) isn’t enough, obviously. For this, there is a Controls property, inherited from the Control.ControlCollection class, that has a few useful methods. The one you’ll need to add controls to the parent object is, naturally, .Add()

Here’s a simple example of declaring a .NET Button and adding it to the MaxForm object:

myButton = dotNetObject "System.Windows.Forms.Button"
maxForm.controls.Add(myButton)

Easy stuff! Especially if you’re used to C# or even IronPython. The little confusing part comes when you want to actually assign event handlers to your controls. This is done completely differently from regular rollout event handlers, but it’s also different from C# or IPy. Normally in C# or IPy what you do is assign a method to a event property on individual controls:

myButton.Click += doSomething

This doesn’t work in MAXScript, however, so you have to opt for a specifically tailored solution to this issue, which is the dotNet.addEventHandler method. It accepts three arguments: the object to which you’re adding the eventHandler, the name of the event it should respond to and finally the method you’ll want the object to call when the given event occurs. So, the same example as above in MAXScript looks like this:

dotNet.addEventHandler myButton "Click" doSomething

The doSomething function has to accept two arguments, the sender and the argument list used inside the function to properly identify what object is calling it and what arguments you used (i.e. right click etc…)

Now, finally, you have pretty much everything you need to start building rich .NET GUIs for your scripts. The last thing to do now is to call the Form object with all its controls, methods, handlers etc… and show it. By default, a Form object has a regular Show() method to display the Form, but, this will result in showing an independent window that “falls behind” 3ds Max when you click anywhere in Max. This isn’t desirable for UI controls. Luckily, as I mentioned earlier, the MaxForm object has a special ShowModeless() method that will display the Form and tie it to the 3ds Max handle (HWND). Here’s the last piece of the puzzle. Please note that I’ve also added the dotNet.setLifeTimeControl method to show you that it’s generally a good idea to let the .NET garbage collector take care of the .NET objects, instead of the Max’s one.

maxForm.showModeless()
dotNet.setLifeTimeControl maxForm #dotNet

That’s it for now. Happy scripting with .NET!

I’m actually scared by the fact that even 24GB of RAM isn’t enough for a high-end workstation these days. And I’m talking about projects up to a maximum of full HD resolution! I don’t even consider 2K or, hell, 4K projects at the moment as I primarily work on TV commercials etc…

This is very interesting as I remember every time I upgraded the amount of RAM of my workstation, I was very pleased with the performance and the amounts of available memory every time I worked on something. But then, not long after, I started to reach the limits of the system’s resources.

The thing is, when you reach the cap of your CPU, or GPU for that matter, your renders just take a bit longer to finish. But as soon as you reach the RAM limit, your apps start crashing and the entire system becomes unstable! So, it is a bit of a problem.

I started reaching the limits not long ago when I had tons of apps open at the same time. Especially Nuke, Max, VMWare Workstation and Photoshop. But on recent projects I started reaching the cap with Nuke and Photoshop alone! It’s terrifying as it suggests that no matter how much RAM I put in the system, it will never be enough!

So, it seems that my next workstation upgrade will, indeed, be a RAM boost. Not sure I’ll be able to buy the full 96GB of ECC RAM at once, but, I’m certain I’ll get there very soon.