I’m trhilled to be able to finally showcase, at least, some of our very own Python implementation into 3ds Max!

First off, our primary reason for writing our own, proprietary, Python connection to 3ds Max is Tactic by Southpaw Technology. An awesome asset management system entirely written in Python that I decided to invest in and integrate our tools and software packages into. Another reason for this connection, later came up, was the need for writing much more complex scripts with complex GUIs, since, as you probably know, a few functional lines of code are hardly enough in a modern, efficient, VFX production of today.

The heart of our Python integration is dotNET from Microsoft. I can’t express myself enough how much I appretiate this framework! The brain of our Python integration is IronPython. Also a product from Microsoft, completely open source and free, which are two very important aspects for any pipeline tool in any production facility of any size. Not the price as much as the availability of the software. And with IronPython and Microsoft, I am certain that this piece of software will be around for years!

So, what have we done?

• We’ve developed a bridge that connects MAXScript and Python via dotNET.
• The bridge converts most of native Python and MAXScript data types to and from one another.
• We’ve implemented several, custom, methods in Python that allow us to directly communicate with 3ds Max via MAXScript.
• We’ve also implemented error reporting so that when an error is thrown in Python, it’ll return the exception in MAXScript for debuging.
• Everything is based on dotNET and written in C#.
• The best part? Our Python bridge is completely platform and 3ds Max version independent!

Let me talk about the custom Python methods first. We’ve incorporated a class called mxsCon, that stores several methods for direct communication with 3ds Max as well as a variable
that stores passed arguments from MAXScript to Python for greater flexibility, especially when executing short code snippets.

The initial design meant to provide a way of directly running Python code from within MAXScript. However, with more complex tools needed nowdays, this proved to be insufficient and thus we’ve developed a way of executing more complex Python scripts written externally using IronPython. This works perfectly well if you plan on using 3ds Max’s interpreter and just want to pass values around MAXScript and Python. This is perfectly efficitent and enough for writing really complex tools based on Python. In our case, it’s the connection to Tactic.

However, later, it occured to me that since we have most of the hard work done, why not bring everything over to the Python side. Since Python is such a great and powerful language, why bother with MAXScript! So we developed another method for executing MAXScript code directly within Python scripts and have the result, evaluated in MAXScript, be passed back to Python. IronPython that is. Since all the value conversions had already been done, this proved to be an extremely powerful and efficient way of writing very complex tools, now even, with very complex GUIs. Since everything is based on dotNET, we can utilise IronPython and some of the IDEs available for super quick GUI development. I used SharpDevelop, an open source IDE for writing dotNET applications, for all my GUI and code stuff. Then I just hook up MAXScript commands that I pass Python values to in order to perform some actions in 3ds Max, like opening a file from our server stored in Tactic. Or, create objects and list them in a ListView. Or even write a direct 3ds Max – Maya translator! Why not?

Anyways, here are the methods and their purpose in 3ds Max:

• Python.run( <string> ) — will execute a Python script wrapped in double quotes (effectively a string).

Example:

Python.run
(
	"import sys
	mxsCon.setResult( sys.version )"
)

In this case, Python.run() will return whatever the mxsCon.setResult() will pass to it (more on that later).

• Python.runFromFile( <string> ) [ args:#() ] — will execute a Python script stored in an external file and alternatively pass it custom arguments.

Example:

Python.runFromFile @"C:\myPythonScript.py" args:#( 10., true, #(1,2,3), "some string" )

In Python, you’ll have to catch the passed arguments in order to use them, however the conversion of the data types will be done automatically for you.

• Python.inspect( <data type> ) — this method will inspect what data type you passed to it and how it will convert it to Python.
• Python.getError() — this method returns the last unhandled exception in Python code.
• Python.setVerbosity( <int> ) — allows you to set the level of verbosity for error reporting.
• Python.getVerbosity() — retreives the level of verbosity you currently use.
• Python.resetPy() — a very useful method for resetting our bridge residing in memory in case you’ve changed something radical in the source code etc…

And here are the custom methods developed in C# for IronPython use in the scripts. These only exist when run via our Pythoner.dll module. If you run the Python scripts without Pythoner, you’ll have to handle their lack of presence. I’ve done this via a custom class that I import in the scripts I use. This is extremely flexible since when I run the code outside of 3ds Max, I can still use its functionality without having to deal with error handlers all over the place.

• mxsCon.setResult( <data> ) # this method will return whatever it encapsulates directly to 3ds Max as well as in Python should you need to work with it later in the script.

Example:

import math

def myFunc( arg ):
	sum = arg + 100.
	return mxsCon.setResult( [arg, sum] )

if __name__ == '<module>':
	myFunc( math.pi )

The myFunc function will not only return a List of whatever you pass to it as well as the result of addition, but it’ll also pass this List directly to MAXScript for later use in 3ds Max.

• mxsCon.getResult() # this method will only return the last value stored in memory using the .setResult() method. Useful for later usage in Python.
• mxsCon.convert( <data> ) # this method will convert the input data types from Python to MAXScript compatible data types, but will return then wrapped as a string. This
  may be useful for other usage reasons. I used it for debugging or printing values in Python in MAXScript format.
• mxsCon.execute( <data> ) # here’s where the magic happens. This method is quite complex. It not only evaluates whatever is passed to it in a String format, but it’ll also wait for the result from MAXScript and return it within Python. Another, very cool, feature of this method is similar to String formatting capabilities known from Python.

Some examples of the mxsCon.execute() method:

# assume here's a ton of complex Python code that invokes this method
returnedVal = mxsCon.execute( r'Box()' )
# will create a box in 3ds Max and return OK (converted to True) back to Python.

returnedVal = mxsCon.execute( r'getDir {0}', r'#scripts' )

The .execute method will first evaluate its input into a single string,
in this case: r’getDir #scripts’, in a similar fashion the .format method works in Python.
Then it’ll execute the command in MAXScript and retun its output back to Python.
The output, in this case, will be a string: ‘C:\Program Files\Autodesk\3ds Max 2009\scripts’

But, enought with the talk, see it for yourself in action in this short Windows.Forms demo. (clicking the image will take you to the video)

I am very excited to present a very early development results for our own Python implementation in 3ds Max.

First a bit of an intro. At duber, I’ve setup everything around Python, the most versatile and powerful language I’ve ever seen. I felt in love with Python so much that it even influenced my decision to leave Fusion (my favourite compositing app) and dive into Nuke (my, now, most favourite compositing app). I even invested in a commercial data and asset management system, Tactic, that is entirely written in Python. I run tons of custom Python scripts to tie together programs such as Tactic, Nuke, FrameCycler, Photoshop etc… etc… But the last missing piece to the entire pipeline puzzle was 3ds Max.

There were initiatives to bring Python into Max, both from Autodesk and from 3rd party developers. The problem is, none of those are final, open-source, nor fully functional.

What I need with Max, at least for now, is to be able to communicate with the Python tools running at my studio. I need Max to be able to communicate with Tactic. I need it to communicate with FrameCycler. And I need it to communicate with Nuke. Since I have most of the tiny scripts up and running that provide this communication layer, the last bit missing was Max being able to execute Python scripts and catch Python’s outputs.

We’ve achieved this with IronPython and a bit of C# magic.

Even though IronPython is different from CPython (the regular distro), it provides some additional functionality and mainly, it communicates flawlessly with dotNET. Another area that Max is well tied to. So this made for a perfect match! All we needed was a layer, a bridge of some sort, that’d make IronPython play nice with Max and vice versa. What we have right now is a very early Alpha build, very simple, elegant and light, that does just that! Maybe, if Autodesk doesn’t do it for us, we might extend this functionality beyond a simple communication layer and might actually make Python scripts command 3ds Max, so that we will be able to create objects, modify them, manipulate with the scene etc… etc… all directly via Python’s code. But for now, all I need is a two way communication tunnel that bridges the gap between MAXscript and Python. So far, we can run directly Python commands/scripts from within MAXScript code and we can run Python script files stored on the HDD and return results in MAXScript.

Here’s a sample of what we have right now:

We’re working on proper data type wrapping right now. So far, we’ve got INTEGER, FLOAT and STRING types as well as DOUBLE type (naturally) being properly translated between MAXScript and Python. Hopefully I’ll have all the various data types being correctly translated to and from MAXScript and Python by the end of the week.

Also, the beauty of it is that it’s based on dotNET code and it was compiled independent on CPU architecture, which means it runs as fast and fine on both x86 machines and versions of Max as on x64 platforms. The other huge benefit is it is independent of 3ds Max entirely. It only requires dotNET Framework 3.5+ and IronPython libraries, but doesn’t require a recompile if I need it running under Max 9, 2008, 2009, 2010 or any other future versions of Max!

It is obviously not as robust or complex as Blur’s latest Python plugin, but thanks to that, it’s very versatile and flexible, which is great!

Yes! Once again, Blur studio showed how it’s supposed to be done.

They’ve released, or allowed their Eric Hulser to release, an updated version of their blurPython modules for 32bit and 64bit 3ds Max versions from Max 9 all the way up to 2009! And not only that. They’ve also provided libs and modules for tying up Python, 3ds Max and Qt together! This is massive news as I’ve been trying to get Python (concretely IronPython) work in 3ds Max but I’ve been constantly hitting road blocks until I finally bumped into Blur’s updated blurPython.

The problem with IronPython would be the .NET classes that are required in order to embed IronPython inside 3ds Max. Since I don’t know C# at all, I’m not able to write custom wrappers to use in this combination, unfortunately. Another issue would be incompatibility with other programs that already run Python natively, such as Nuke or Maya, that I want to tie together under one managed pipeline environment in my studio. IronPython is a Microsoft opensource project that brings Python programming to .NET or vice-versa, which is great on many levels and I was really excited on bringing this to Max, since Max is already pretty tied in with .NET and I thought this might have been the best and easiest solution.

Well, nevermind, I’ll leave that part on Autodesk, if they ever decide to bring Python to Max. But for now, I’ll be happily enjoying Blur’s blurPython effort with Qt, which I was about to learn anyways (I bought a Rapid GUI Programming with Python and Qt book a while back, but haven’t gotten to reading it yet).

After a few minutes fiddling with Python 2.6, Qt and a bunch of modules required in order to make blurPython run under Max, I’ve finally managed to get Python code executed and working correctly in Max!

And with a bit of help from Thorsten Kaufmann, I also managed to get Python code up and running from an external editor, which is very useful! Although I use SciTe, which got implemented as a MAXScript Pro Editor in Max 2008, I believe, I can’t get lexer and other language syntax up and running in it since it’s heavily modified and fit for MAXScript only, which sucks. So I use SciTe externally for Python and simply run the code from there to show up in Max.

The only drawback of this is the fact that we’ll be 100% dependant on Blur for maintainig these plugins and modules. Well, modules won’t be an issue, these are open-source, but the parts that are closed-source are inaccessible to other programmers. So, whatever Blur decides to do with their plugins, we’ll have to go their way. Which is a bit problematic for a studio to rely their entire 3ds Max pipline on this (like mine). But we’ll see, maybe Autodesk will acquire or at least somehow officially support Blur’s efforts. Maybe Blur will decide to release the package as an open-source project to the public, or perhaps as a commercial package? If not, we’ll still be dependant on on thing or another, but this might prove to be either a huge win or a huge loss situation. The pros are, thankfully, huge for me, at least. So I’ll take the risk and adopt blurPython in my pipeline, since I need it for accessing Tactic projects and SObjects from within Max.

Python 2.6 had been officially released on 01.09.2008! Some really great new features but still compatible with 2.5 code, which is great for slowly transitioning to the upcoming Python 3000.

Don’t hesitate a second and go for the download!

When I first started developing some tools, to speed up and aid our pipeline, in Maya I was furious to find out about Maya’s implemented GUI tools and methods. It was extremely unintuitive, very badly documented (especially regarding examples of the given object etc…) and heavily limiting. What I’d love to have in Maya was something similar to Max’s GUI objects I was used to.

Especially ever since Max 9, where we finally gained access to the beautiful dotNET framework and its objects, classes etc. I was looking for a similar solution. The only problem with dotNET is its platform dependence. As it’s a Microsoft framework it, obviously, only works on Windows. I’ve heard about Mono for Linux, but since I don’t work on Linux and have very limited knowledge of it, I didn’t investigate any further. There are some other options for platform-independent GUI development, like Qt, which I’m yet to go through. It’s definitely worth looking into, but the great advantage of dotNET, on the other hand, is its presence on virtually any Windows machine, which is simply awesome for heavy tools deployment across multiple machines in a studio environment (I can’t imagine making all our artists to install Qt). So, the obvious step was to look for a way to get dotNET run under Maya.

After searching the net, I quickly realized it won’t be such a simple task as with many other tools I’ve ported to Maya in the form of modules for Python. There is IronPython, which runs under its own interpreter, which makes it impossible to implement in Maya (very sad!), but then I bumped into a project, which seems to be lacking a bit of active development, but looked promising: PythonNet.

There’s a little bit of a glitch. There’s no x64 port and, what’s more irritating, the release version I managed to run under Maya only supports dotNET 1.1, which is a real pitty as the tools you’ll be able to create will have slightly limited functionality for more advanced tools development, but nothing that’d cripple the actual usefulness and richness of the platform, only some more advanced and newly added classes or methods won’t be supported.

An example of the dotNET’s listView object used under Maya:

So, all you need is to download the PythonNet 1.0 RC2 for dotNET 1.1 and install CLR.dll and Python.Runtime.dll in Maya’s bin folder. Done. From there on, you’ll be able to import a CLR module (note the upper-case) and access the dotNET objects and namespaces through it. There are also some nice examples of code to get you going.

Another dotNET example of an actual simple tool I developed for automatic Point Cache assignments:

Here, again, Python really excells in these matters. I’m able to develop a fairly complex GUI for my tools and then instance, inherit and mainly overflow the operators of the GUI, so, in the end, I can plot the same GUI for many various functions, which is very useful.

Right now I’m looking into some ways of getting the alpha verision of PythonNet 2.0, which supports dotNET 2.0 objects, to run under Maya in both x86 and x64 modes. If I get it going, I’ll post the way as well as the compiled modules (as I feel it’ll be necessary).

One of them is, as Adam describes, utilizing Python from within Max and call its native MD5 functions. There are two ways, but both are very limiting. One of them is registering a COM server from within Python and calling the functions through OLE objects from Max. The other possibility is using blur’s implementation of Python’s interpreter, blurPython, and calling the module, somehow, natively. Both of these methods work and are quite easy to setup, however, both of them are very hard to be deployed in a more complex environment.

What I need is an integrated MAXScript solution that yields the same result as the MD5 implementation in Python, so that I’ll be able to directly compare results from within Maya and Max for example. After searching the web and looking into the MD5 algorithm I quickly realized that re-writing the algorithm myself in MAXScript isn’t the way. But thankfully, Microsoft implemented a vast number of hash algorithms into its .NET framework as I learned on the web, so this looked like the obvious choice.

After a few minutes at the MSDN central I found what I’d been looking for. An actual MD5 implementation. However, as .NET is quite a comprehensive and large framework, the implementation isn’t as straight forward as the one found in Python. Nevertheless, all you need are two classes:

"System.Security.Cryptography.MD5"
"System.Text.Encoding"

These are the .NET strings you’ll need for instancing the classes in MAXScript. So, let’s take a look at the code block:


md5Class = dotNetClass "System.Security.Cryptography.MD5"
encoding = dotNetClass "System.Text.Encoding"
MD5 = md5Class.Create()


In this block, I’ve declared three variables, the first two were instances of the .NET classes and the last one, MD5, is a newly created object from the Cryptograpy.MD5 class called by the .NET .Create() method. You have a few options for the method to specify how the MD5 algorithm should treat your input, but I left it at default as I don’t need anything specific.

Now we are set to go through the last step, which is providing the MD5 object with arguments for computing the hash. This is done through another .NET method called .ComputeHash(). Unfortunately for us, the ComputeHash method only accepts either a Byte[] array or a Stream object (not sure whether it’d take a Max’s fileStream object directly, but mu guess is it wouldn’t) to generate the hash based on the input data. This is where the System.Text.Encoding class comes in handy, because it has a method for converting a string through a concrete character table (ASCII, UTF-8, etc…) to bytes. I’ve chosen the UTF-8 even though I’m certain I’m not likely to use anything beyond the ASCII table definition. The procedure to get the byte code of your string is as follows:


encoding = dotNetClass "System.Text.Encoding"
encoding.UTF8.GetBytes(myString)

Bear in mind that you can use different character tables to facilitate your concrete needs, but basically this is all you need to pass the MD5 function to calculate your checksum. With this knowledge, the following code is all there is to calculating correct MD5 checksums inside 3ds Max:

md5Class = dotNetClass "System.Security.Cryptography.MD5"
encoding = dotNetClass "System.Text.Encoding"
MD5 = md5Class.Create()
hashArr = MD5.ComputeHash(encoding.UTF8.GetBytes(myString)) -- it's smarter to store the resulting array of byte values for later manipulation


The interesting part is that by default, this method returns an array of decimal numbers:

#(13, 87, 80, 212, 152, 226, 236, 248, 58, 163, 91, 29, 33, 199, 60, 102)

I don’t know of any .NET method or a property that’d return a standard hexadecimal value as we’re used to from, for example, Python. However, it is easy to overcome with a formatting function (since Max 2008 or with an AVG extension in previous versions) called formattedPrint. I wrote a custom function that solves this whole issue and does exactly what you’d expect from a natively implemented function, it simply expects a value and returns a hexadecimal (correctly formatted) string. Make sure you check the documentation for the correct formattedString arguments as they are quite important in this case for correct formatting of the hexadecimal values! Here’s the code:

fn MD5Checksum input =
(
    md5Class = dotNetClass "System.Security.Cryptography.MD5"
    encoding = dotNetClass "System.Text.Encoding"
    myHash = "" as string
    myString = "" as string
    try (myString = input as string) catch (return false)
    MD5 = md5Class.Create()
    hashArr = MD5.ComputeHash(encoding.UTF8.GetBytes(myString))
    for o in hashArr do
    (
        myHash += formattedPrint o format:"02x"
    )
    return myHash
)

To sum this up, let’s compare this custom MD5 function based on .NET classes with Python’s native implementation. For the sake of completeness, here’s the code you’ll need in order to generate an MD5 hash in Python (I’ll use the same name “myString” for the string variable as in the MXS example above for clarity):

import hashlib
hashlib.md5(myString).hexdigest()

Yeah, I know, very simple, isn’t it Yet again, Python kicks some serious ass here! Anyways, let’s test it on a long string (just to make sure both of the methods yield the same result) like:

"ThisIsAVeryLongStringThatIsHardToReadButShouldStressTestBothMethodsEnough"

Both MAXScript and Python return (strings):

"0d5750d498e2ecf83aa35b1d21c73c66"

So, this is it, now you should be more familiar with .NET classes, how they work from within MAXScript and that the whole .NET framework is one hell of a good job by Microsoft for developers of any kind, such as TDs working in DCC applications, which is sweet!

To save you some time, don’t bother trying to connect to the database (db for short) via the standard example:
DogConn=createOLEObject "ADODB.Connection"
DogConn.Open "driver={SQL Server}; server=localhost; database=test"

output:

-- Runtime error: OLEObject method call failed:
Error Message 1: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied.
method: open()

This concrete driver is a Microsoft SQL Server driver, so obviously, this doesn’t make much senese to use this method for connecting to a MySQL database. Since there are numerous ways of setting up the connection via different providers or drivers I was lost. But thankfully , Sun provides its own ODBC connectors for various operating systems, including 64bit versions for Windows. So download the one that fits your OS and after installing it, just check what name the driver has assigned in the Data Sources(ODBC) under Administrative Tools. It should read “MySQL ODBC 5.1 Driver”, which is exactly what you need for successful connecting to a MySQL database. Easily enough, from the comprehensive list of example connection strings found at ConnectionStrings.com I was finally able to write this code:

DogConn=createOLEObject "ADODB.Connection"
DogConn.Open "Driver={MySQL ODBC 5.1 Driver};Server=serverName;Database=dbName;User=userName; Password=password"

Even though it returns “undefined”, don’t be alarmed, this is a good thing. So, now you’re good to go and start fully appretiating the whole database purpose and design!

As for dotNET. It’s much easier (as it’s Microsoft’s next “big thing”) to code for and also you’re less likely to bump into similar problems. Again, download the latest .NET connector from Sun and try executing this snippet in Max 9+:

dotNet.loadAssembly "C:\\Program Files (x86)\\MySQL\\MySQL Connector Net 5.2.2\\Binaries\\.NET 2.0\\MySql.Data.dll"
DBConnection = dotNetObject "MySql.Data.MySqlClient.MySqlConnection"
DBConnection.ConnectionString = "Server=192.168.1.14;Database=test;Uid=root;Pwd=root"
DBConnection.open()

dotNET works in a slightly different way. Instead of loading up a provider or service, it loads up an “assembly”, which is a dll, in this case Sun’s .NET connector, and then allows you to work with its methods. So I first loaded the dll up, then fired the dotNetObject function, then I specified the connection string and finally opened up the connection. Then you’re good to go!

Even simplier is the Python way of things, as usual All you need is a MySQLdb module available at SourceForge.net, install it for your version of Python and then try running this code:

import MySQLdb as db
conn = db.connect("serverName","userName","password","databaseName")

Now you’re ready for some serious querying! It really is this simple and that’s why I’m really loving Python. Anyways, these were just a few examples of how to connect to a MySQL database via ODBC, .NET and Python, which is really all you’ll ever need for connecting to MySQL from 3ds Max, Maya or XSI.

I find myself scripting in Maya more and more often. As I’ve expressed many times already, I really love and appretiate Python’s way of dealing with things, so having this language available in Maya is a blessing. The most beautiful part is when software actually does all the hard and annoying work for you Scripting in Maya using Python hadn’t been designed the way it should be. Unfortunately, Python only serves as a “wrapper” around MEL commands and MEL architecture. Fortunately there are attempts at simplifying Python scripting in Maya, such as PyMEL from Luma Pictures (which is a studio I feel honored to cooperate with on The Nutcracker: The Untold Story), which is a fantastic “plug-in” for any Maya TD! which was, not surprisingly, done solely through Python itself A fantastic demonstration of Python’s power. However, PyMEL isn’t the topic for this short post, maybe later, when I get more familiar with it and gain more experience using it.

The main reason for getting used to working and parsing a lot of string data is, as stated above, because, by default, Python acts as sort of a “wrapper” around Maya’s native MEL language. You’ll be passing tons of string arguments and parameters to Maya’s Python interpreter, so knowing how to deal with long strings is a must. Today I was solving a trivial issue of assigning numerous texture inputs to quite a few tripleShadingSwitch objects for some complex material and shader definition. The whole, manual, procedure would have been very straight forward, but extremely tedious and time consuming. So, as a TD, I was asked to write a little script that’d do the trick with a very limited user input, which basically meant no UI, which is a good thing for a scripter. If you’ve done some UI coding, you know what I’m talking about, especially in connection to Maya

In the end, I dealt with a lot of string variables that were passed throughout the script in Python. It’d have been a pain in the ass doing this sort of thing in MAXScript, as MAXScript isn’t very “string friendly”. I mean, of course there are various string functions available, but they don’t come even close to waht Python has to offer! A single Python module, called “string”, did all and much more I needed. For example, after importing the module, I was able to, very effectively, break a string down based on a keyword argument and separate individual words. While this concrete example is very easily doable in MAXScript, not so easily doable in MEL, there are many other examples that aren’t so easy to do in MAXScript or MEL in comparison to Python. One example for all. Let’s say you have to deal with namespaces. They usually occur in applications like Maya or MotionBuilder which preven users from naming individual objects the same name under the same level in a hierarchy. When you have multiple hierarchies, you may bump into objects with the same name. Maya will return the shortest namespace possible, so instead of returning a “Sphere1″ it’ll return a “myHierarchy|secondLevel|thirdLeve|Sphere1″ if multiple objects with this particular name exist in the scene. So, for whatever reason, what if you need to replace the specific namespace separator with something else? Here’s an example of a very long string of several words separated with a colon (as it’s a common character for identifyingnamespaces) that you want to replace by an underscore character, let’s say for compatibility reasons (say you want to pass this string to Max). Here’s how to do it in Python (including Python in Maya):

from string import *
aVeryLongString = "a:very:very:very:very:long:string:with:namespaces"
aNewString = replace(aVeryLongString,":","_")

the result: a_very_very_very_very_long_string_with_namespaces

Great! Only three lines of code and very little brain usage was actually needed to perform this task How about MAXscript? Well, MAXscript has a function called replace(), the problem is, it expects a string, a start position, a number of characters it should replace and an actual new string that’ll replace the old ones. Certainly usable, but very inconvenient, especially for casual or beginner scripters. How do you go about this limitation? You can’t import a “string” module or anything like that in MAXScript, so you have to write your own, custom, function to do that for you, which would be one of many ways to solve this little issue. For this example, I wrote a custom function that mimics Python’s replace() functino behavior including the number and nature of arguments it requires.

aVeryLongString = "a:very:very:very:very:long:string:with:namespaces"
fn replaceAll str old kwrd =
(
    while findString str old != undefined do
    (
        str = replace str (findString str old) kwrd.count kwrd
    )
    return str
)
replaceAll aVeryLongString ":" "_"

the result: a_very_very_very_very_long_string_with_namespaces

Basic break down: the function takes three arguments, the actual string you want to work with, and old character you want to replace (it supports more than one character) and a new, keyword (kwrd) to replace with. When invoked, it goes through a while loop to search for the old character string and replaces it with the new kwrd character string. After it’s all done it returns the new string.

Even though this took only a few more lines of code, I used two string specific functions and a loop clause all wrapped up in a custom function to do the trick for me. Besides, as I already mentioned, this method is much more complex and hard to code for an inexperienced scripter who just wants to perform a simple character replacement function. These are the tiny little differences that may cause a lot of trouble and headaches when developing really complex and large scripts or, for example, when you have a Junior TD at the studio who should help you out with simpler, smaller tasks and they bump into some similar problem like this one, which it’s as if they weren’t there since you end up doing the work yourself anyways.

I’ve been recently doing quite a lot of R&D on XML, MySQL etc… in conjunction with Max and/or Maya and I constantly bump into obstacles when building the same code I did in Maya through Python, in MAXScript. The problem is, MAXScript is a proprietary language and therefore, you’re stuck with what you have. It’s a great, easy to learn and easy to master language, don’t get me wrong, but if you’re missing some specific features, you’re pretty much doomed. There are some extensions to be found on the net for MAXScript, but usually, they were done by a guy in similar situation you find yourself, but with extensive knowledge of Max’s SDK and C++/C# programming. I, unfortunately, have very limited knowledge of C++/C# programming and therefore I 100% rely on what I can find on the internet.

On the other hand, Python, for example, is an open-source scripting language. Very mature, very popular, ver widely accepted. This leads to a lot of individual, task specific, modules. So, in my case, recently, when I needed to write to or read from a XML file, I simply downloaded a PyXML package, read briefly the documentation, skimmed through some sample code and in a few hours I was able to write my own procedures to derive data from XML files and write them back to another XML. MAXscript doesn’t have any dedicated procedures/functions for such a task, so you either end up writing your own functions for this purpose, which is rather time consuming or you try your luck and try to search the internet for some already finished code, if there’s any. Same deal with the MySQL connection I was dealing with recently. Again, MAXScript doesn’t provide an extensive way of connecting to a database, it has an AODB object, which is quite limiting and a bit outdated nowdays. Thankfully, there seems to be a solution through dotNET objects, but I can’t use this method in Max prior to version 9 (you may not believe it, but I still prefer Max 8 nowdays ).

So, as you can see, languages such as Python are really a smart way to write your tools in and based your pipeline around. Obviously, Python isn’t the only scripting language of this kind, but it’s very popular and widely spread. I also highly recommend it because of its simple syntax, yet robust toolset. A very smart and far-sighted move from Guido van Rossum, kudos!

Interestingly enough, when I started looking into extending my technical skills and knowledge beyond 3ds Max itself at first I got a bit frustrated. The reason was I thought (as probably many other technical artists out there, based on many discussions I read) that I spent years developing some scripting and technical skills to find out they were useless and I’ll have to learn something entirely different in order to stay at the cutting edge and still being competitive. Now while 3ds Max isn’t a factor here, it’s just a platform anyways, I dived into Maya recently and faced a, seemingly, difficult decision: do I go the MEL way or do I learn Python (available in Maya since 8.5)? The decision turned out to be petty simple! I’ll learn both! As I devoured the user reference files, some tutorials and some books, I found out that once you learn one scripting language syntax and logic, picking up any other (similar) language is quite easy.

Well, MEL, out of the three, comparatively, is the most difficult to grasp, not because of the sheer number of functions and attributes, but because the syntax is a bit too complicated (to my tastes) and the integration of MEL in Maya is also a little too restrictive (compared to MAXScript that I’m coming from). Now, the fact that Maya supports Python (too bad Max doesn’t natively support it as well), even though in a bit of a “MEL falvour” is pretty cool and only thanks to this fact I was able to pick up scripting in Maya very, very quickly! So, what’s so special about Python? Python is extremely easy to learn! Let me compare complexity-wise the three: Python < MAXScript < MEL and if I was to compare the three feature-wise: Python > MEL > MAXScript, so the clear winner is Python. Now, I’m primarily a 3ds Max TD, therefore I’m not able to fully appretiate Python’s power and strength from within Max, or am I? Thanks to the ever-so-awesome folks at Blur and their dedication to using 3ds Max in their pipeline, we have something that’s called “blurPython” which is an extension to MAXScript that allows you to call Python functions and modules. This alone takes scripting in Max to a whole new level! Even though you don’t have a direct Python syntax support in Max, you can’t call Max’s functions with Python (sort of, you can do that actually but it hasn’t got much to do with Python itself) you can access Python modules and functions from within Max, which is awesome. Now think about the feature set of Python, the fact that Python has been around for longer than Max itself and that it really is a production proven scripting framework and you’ve got a one hell of a powerful weapon in your TD arsenal! Especially if you’re into building custom pipelines and data sharing!

This article isn’t that much about all the posibilities you can do with Python itself, I’d rather like to compare some features of MEL, MXS (MAXScript) and PY (Python). So, first things first. When I started exploring Maya’s scripting and its logic, I buped several times into my old habbits of code testing, exploring and writing that I carried from Max. Some examples, when developing some code I tend to setup a bunch of testing global variables in order to speed up some UI testing, cut down on number of clicks in order to test out some tools with more complex UI etc… So I started developing some primitive scripts in Maya that were a bit ahead of print "YAY!\n"; :D. Very soon I bumped in MEL’s design “limitation” (it’s not a limitation so to speak, only in my eyes it looks like a limitation, while in fact it’s simply a matter of design), I cannot reassign a different value class to an already declared variable. Let me explain: MXS allows me to do the following: global testVar = "Hello!"; testVar = 10 which means: globally declare a variable called “testVar” and assign it a string value of “Hello!” then try to assign it an integer value of “10″. MEL won’t let you do this, which was to me, as a starting MEL scripter, quite confusing. The problem got more serious and I got frustrated even more when I learned that there was no way of “undeclaring” variables in MEL, so the “testVar” was available all the time during the session (which means until I restarted Maya). So, as recommended, you should always test your code in a local scope in MEL, which means writing your code within two curly braces: { ⟨your code⟩ }

This was quite shocking to me as a MXS scripter that I didn’t have the freedom to reassign variables with different value classes. Further on, the limitation touched all the aspects of the language I was used to, like arrays that can only carry a predefined value class, you can’t mix up integers with strings for example in MEL’s arrays (lists). So I put up with the fact and tried to learn a “different” syntax. I spent about 2 weeks learning MEL intentionally avoiding Python in Maya as, at first, I thought it was some kind of a “second layer” language above MEL that won’t do much difference in Maya. Oh, how wrong I was! Python, in fact, is much more powerful (to my surprise) in Maya than MEL. You can do the same with Python in Maya as you can with MEL, however, you can do much more with Python than you can do with MEL! This is quite interesting and since before MEL I had been looking into Python a bit, I got interested in it even more.

Everybody on the net says how easy, yet powerful, Python really is, I had to prove it to myself and started looking into the syntax and general Python logic. How glad and happy was I when I discovered that you CAN reassign different class values to a single variable (just like in MXS), I can mix up array (list) item classes any way I like (same as MXS), but the real surprise came when I realized that the PY syntax indeed was easy, so easy that I even think that it’s easier than MXS! And MXS really is easy to pick up and code in, believe me.

Ok, let’s take a look at some examples that I discovered which are very important in scripting in general. The globally declared variables in PY and MXS can be reassigned with a different value class! MEL doesn’t support this feature.

Python:
varA, varB, varC = 10, 20, 30
print varA, varB, varC
varA, varB, varC = "It", "just", "works"
print varA, varB, varC

MAXScript:
varA = 10; varB = 20; varC = 30
print varA; print varB; print varC
varA = "It"; varB = "just"; varC = "works"
print varA; print varB; print varC
(notice the difference, Python actually supports multiple variable assignments on a single line in order as opposed to MXS)

MEL:
{
   $varA = 10; $varB = 20; $varC = 30;
   print ($varA+"\n"); print ($varB+"\n"); print ($varC+"\n");
   $varA = "It"; $varB = "just"; $varC = "works";
   print ($varA+"\n"); print ($varB+"\n"); print ($varC+"\n");
}
Notice that MEL won’t let you reassign a different value class to an already created variable! It’ll try to convert the new class input to the one implicitly created. So, the code above will actually result in:

// Warning: $varA = “It”; $varB = “just”; $varC = “works”; //
// Warning: Converting string “It” to an int value of 0. //
// Warning: $varA = “It”; $varB = “just”; $varC = “works”; //
// Warning: Converting string “just” to an int value of 0. //
// Warning: $varA = “It”; $varB = “just”; $varC = “works”; //
// Warning: Converting string “works” to an int value of 0. //
// Result: 0 //

Now, let’s take a look at loops. These are most common in any scripter’s arsenal so you really have to learn how to write these in order to process repetitive tasks!

Python:
for i in range(1, 10, 2):
   print i

MAXscript:
for i = 1 to 10 by 2 do(print i)

MEL:
{
   for ($i = 1; $i < 10; $i+=2)
   {
      print ($i+"\n");
   }
}

(notice that I put the MEL code in a local scope)

The MAXScript syntax in this case is far easier to read than Python and especially then MEL (also notice how many extra characters you have to put in the code in order to achieve the same result)

Another very useful feature is functions (in MEL they're called procedures). I'm yet into learning what all is possible with functions in Python, but what I've learnt so far is quite enough for my needs.

Python:
def sumTheNumbers(num1, num2):
   return num1+num2
sumTheNumbers(10, 20) #call the function with some input numbers of choice
sumTheNumbers("You ", "can!") #notice that Python doesn't actually care what class of variables you throw at it as long as it can perform the required task

MAXScript:
fn sumTheNumbers num1 num2 =
   (
      return num1+num2
   )
sumTheNumbers 10 20 -- call the function with some input numbers of choice
sumTheNumbers "You " "can!" -- notice that MAXScript doesn't actually care what class of variables you throw at it as long as it can perform the required task
(same thing, MAXScript is also "kind" to the user as to letting them assigning different value classes and performs the operations on them, if possible.)

MEL:
{
   proc int sumTheNumbers(int $num1,int $num2)
   {
      return $num1+$num2;
   }
   print(sumTheNumbers(10, 20)+"\n"); // call the function with some input numbers of choice (from within a print() function in order to see the result)
   print(sumTheNumbers("You ", "can't!")+"\n"); // MEL will automatically convert the input classes to integer class, if possible
}
(notice that I just declared an INTEGER procedure that expects two INTEGER values to be passed to it, so, there's no way you could summarize two floats (i.e.: 10.0 and 20.0) or even strings (i.e.: "You " and "can't!") and expect MEL to return float or string values respectively. What MEL will do is it'll convert the incoming value classes to, in this case, integers, if possible, and then performs the required calculations!

So, there you go, these were basic and simplyfied examples of the different languages. The conclusion could be stated as Python being the superior language to MXS and MEL and its syntax being most conformable to MAXScript (or rather the oposite, MAXScript being very conformable o Python, as MAXscript is younger). There are, of course, much, much deeper differences or similarities that wasn't the purpose of this article to bring up. I'm yet to learn Python more deeply myself, so I can't name more concrete, deeper, differences among the languages. However, if you're facing the same problem (which language to learn) coming from 3ds max, I'd recommend both, MEL and Python. I learnt MEL marginally just to get a glimpse of how it works and how it treats user input and then I went to Python for its much cleaner and easier syntax and much wider possibilities.