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.

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 planned to do a similar how-to here, on this blog, in the future. Possibly a videotutorial, so, stay tuned…

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

Until recently, I’ve been handling Dictionaries two ways:

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

Recently I was writing some .NET code and I bumped into Collections namespace. I then investigated further the Hashtable objects and realized I could substitute Dictionaries in MAXScript with Hashtables using .NET classes and objects! Obviously, again, it’s not as elegant as native Python, but it’s closer than manual wrapping of Lists and Arrays!

All you need to do is instantiate a Hashtable object in MAXScript:

HT = dotNetObject "System.Collections.Hashtable"

and then you can call the .Add() method for adding the Key Value pairs! Pretty cool! Also, you can access the Values or Keys similarly to Python’s Dictionaries:

HT.Add "Key" "Value"
HT.Item["Key"]

This is far more productive and intuitive than my previous methods!

Also, then you can pass the Hashtable object directly to IronPython and have it converted to the native Dictionary object using the dict() method, without any issues! Again, this is a much straight forward way of doing such a, rather, complex data type conversion.

I’m currently implementing this approach to my Shotgun wrapper I use with our Python plugin. All seems to be working perfectly fine!

So, I’ve been trying to unify my code page across the SciTE editors (the standalone and the integrated Max’s editor) and settled on a standard UTF-8 encoding, which seemed to work just great. However, I just bumped into a very strange bug where Deadline reported a “bad syntax” error on my jobs which were using PostLoad scripts to automatically repath all my assets in my scenes.

The worst part was, the scripts were perfectly fine. They worked just fine in my local Max sessions, but they refused to work when run on the farm. I accidentaly discovered that it was related to the file’s encoding. When I resaved the file in Notepad (on my server) using the ANSI character encoding, the jobs suddenly started to work.

So, if you’re using a UTF-8 encoding in your SciTE editors, including and especially in the integrated Pro Editor in 3ds Max, make sure to save the scripts in a different encoding before executing them on the render farm.