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…)
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__"
(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.
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.
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…)
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:
- String parsing (i.e. a very primitive way of handling foreign data types, not really recommended)
- 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…)
