I updated my Shotgun wrapper for duberPython yesterday to support the latest and greatest Shotgun API ver. 3.0.15.dev. All seems to be working pretty well, without any issues.
I added all the methods available by the API to my MAXScript wrapper, so that everything is fully accessible, through duberPython, from inside 3ds Max!
I will be releasing this wrapper to the public real soon, so stay tuned!
That’s right! duberPython is finally ready for it’s debut public release.
But that doesn’t mean it’s a fresh newb of a plugin. It has been used in high-end productions at studios such as Pixomondo or Orbit, etc. on feature films, commercials, full CG animations, etc.
duberPython came into life after a long search for a solution that’d allow us at duber studio have 3ds Max communicate and play nicely with other pipeline tools and DCC applications. duberPython was designed, mainly, to bridge 3ds Max and Shotgun (JSON API is fully supported!) and Tactic. I even wrote a dedicated Shotgun wrapper, so that you can call Shotgun methods directly from within MAXScript (available upon request), so that writing your studio pipeline tools is really, really easy and fun.
The current version runs on the IronPython engine 2.7.3 and is compatible and has been thoroughly tested with CPython 2.7.3 (though, compiled Python modules are not accessible via IronPython).
Currently you can directly call Python code (via string parsing) from within MAXScript, or you can call Python scripts externally and pass it any number of variables for Python processing. The variables will get automatically translated to and from Python, so that strings are strings, booleans are booleans, arrays are arrays, etc. Even dictionary data types are supported in MAXScript (via Hastable dotNET objects)!
So, do not hesitate, head over to python.duber.cz and give your full-featured 30day trial a go and if you find it useful, I’d be very happy if you purchase the full version for only $25 bucks, which is a bargain for what you get! (site licenses are available upon request).
By the way, the full documentation can be read here: python.duber.cz/documentation
This is a quick note to anyone who wishes to set certain environment variables for whatever reason.
If you’ve already done this and know what the EnvironmentVariableTarget Enumeration is, you can skip this post. But to the rest of you, listen up.
If you try to set an Environment Variable in a running process, the default behavior is that the Env Var will be stored in a Process location. This is a sandboxed location available and only valid throughout the process, that created it, lifetime. When you exit the process, the Env Vars will die with it. What this means is you cannot depend on such Env Vars for future reference (i.e. when you restart your process).
This is where the EnvironmentVariableTarget Enumeration comes into play. The other two locations you can use are User and Machine. While the User location will only be available to the specific user that is logged in at the time of the Env Var retreival, the Machine location is global, meaning all users will be allowed to source such an Env Var.
So, in practice, let’s look at MAXScript’s code to do so:
To store an Environment Variable “FOO” containing “BAR” for the currently logged in user, this is what you want to write:
dnEnv = dotNetClass "System.Environment" dnEnvTarget = (dotNetClass "System.EnvironmentVariableTarget").User dnEnv.SetEnvironmentVariable "FOO" "BAR" dnEnvTarget
To store an Environment Variable “FOO” containing “BAR” for all the users on the machine, this is what you want to write:
dnEnv = dotNetClass "System.Environment" dnEnvTarget = (dotNetClass "System.EnvironmentVariableTarget").Machine dnEnv.SetEnvironmentVariable "FOO" "BAR" dnEnvTarget
And if you omit the dnEnvTarget variable completely, which is the default behavior, or if you use Process Enumeration, the Environment Variable will only be available throughout the lifetime of the running process, which is rather convenient if you only want to setup some variables temporarily (such as license paths on render slaves only during the rendering etc…)
Hope this helps.
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.
WRONG!
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:
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.
(more…)
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.
I don’t think I have to praise regular expressions here, however, I wanted to point out one extremely useful case where regular expressions were pretty much the single most useful, fastest and not so obvious choice in my 3ds Max pipeline.
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__"
Here’s a video demonstrating the power and practical usage of Shotgun (data) brought over to 3ds Max natively via our Python plugin, duberPython.
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.