duberPython is available for download!

loocas | 3ds Max,dotNET,maxscript,Python,software,technical | Saturday, July 13th, 2013

duberPython banner

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.

duberPython

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)!

duberPython

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

Persistent Environment Variable creation in MAXScript

loocas | 3ds Max,dotNET,maxscript | Monday, May 27th, 2013

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.

dotNet iterables in MAXScript, a pain in the ass

loocas | dotNET,maxscript,Python,technical | Sunday, May 5th, 2013

Autodesk facepalm

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:

(more…)

Repathing your assets in .max files without 3ds Max

loocas | 3ds Max,dotNET,maxscript,Python,technical | Friday, August 3rd, 2012

Asset Tracking

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. :D So I had to figure out a way of re-pathing my assets in 3ds Max scene files prior to rendering.
(more…)

Calling Shotgun API 3.0.9b2 from IronPython 2.7.3

loocas | dotNET,Python,software,technical | Sunday, July 8th, 2012

IronPython and Shotgun

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.

IronPython 2.7.3:
IronPython 2.7.3 Shotgun

duberPython (utilizing IronPython engine 2.7.3):
duberPython Shotgun

Calling Shotgun API v3.0.8 from IronPython

loocas | dotNET,Python,software,technical | Wednesday, February 1st, 2012

IronPython and Shotgun

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…)

The power of regular expressions

loocas | 3ds Max,dotNET,maxscript,opinions,technical | Tuesday, January 10th, 2012

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__"

(more…)

Shotgun and 3ds Max, practical example

loocas | dotNET,maxscript,Python,software,technical | Monday, December 5th, 2011

Get the Flash Player to see this content.

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

Using .NET controls in .NET Forms in MAXScript

loocas | 3ds Max,dotNET,maxscript,technical | Sunday, September 11th, 2011

If you’re used to scripting your GUIs in Max with the standard rollouts via “createDialog …”, you might be a little confused and lost when you first try to use a 100% .NET Form object instead.

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.

(more…)

Powered by WordPress | Theme by Roy Tanck