Yes, that is true. Stuff that should be inherently and implicitly iterable, is not, when accessed from MAXScript.
I had to find out the hard way, so here I am sharing my findings and solutions so that you don’t have to waste time on this nonsense issue.
The problem I bumped into some time ago was when I tried to access Management Object Searchers in my code (for finding various HW IDs and serial numbers). When you call a dotNET iterable (or a collection) in MAXScript, you automatically assume you can iterate over its contents, just like with an array, for example.
Somebody at Autodesk decided that this isn’t the behavior you’d like and instead made you having to jump through hoops and obstacles to get to the object contents.
Anyways, lets look at this problem on a rather simple example of using Hashtables in MAXScript:
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
Ever since I read this blog post on the Area, I was intrigued to get this working in an IronPython environment (that’s pretty much all I know, in the “serious programming” area). Unfortunately for me, the article mentions C++, OLE and COM. Which are my least favourite technical subjects.
So, now when I finally really needed this solution (more on that some time later), I had to ask on the Autodesk forums.
Luckily I got an answer. But first off, huge thank you goes to Larry Minton, an Autodesk Engineer, without whom I wouldn’t have been able to get this thing going.
Now, about the problem. If your facility has a render farm and you happen to work off of your local storage, you have to point your assets to a UNC path where they’re stored so that all the machines on the network can find and load them when rendering. There are many ways of doing this and usually your pipeline TDs had figured this one out prior you even starting any work on the project. Unfortunately for me, I’m the only pipeline TD here. So I had to figure out a way of re-pathing my assets in 3ds Max scene files prior to rendering.
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):
Yesterday, I posted about RV integration in Windows Explorer. Today, I have the script and a tutorial on how to hook this up ready for your pleasures.
Just download the script, place it somewhere safe and follow the tutorial on how to create an RV specific right-click menu entry in Windows Explorer.
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.
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.
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.