Recently we posted on the Autodesk Developer Network an experimental library we have been developing in conjunction with EPHERE called MaxSharp. MaxSharp provides a simplified wrapper around the 3ds Max 2011 API that can be used from both Python and C#. If you are an ADN Sparks member you can download it from this url. Be aware that because this is a research project you can't redistribute the DLLs, but you can still use them for your own internal use.  

As many of you know in 3ds Max 2011 we added technology for safely loading .NET assemblies and creating custom user actions in .NET (via the CUIActionCommandAdapter class). However exposure of the 3ds Max API to .NET remained limited to only a handful of classes in the ManagedService assembly.

This meant that if you wanted to use the 3ds Max SDK from a .NET assembly you would have to manually expose API elements (e.g. classes and functions) to .NET via C++/CLI or else use the infamous PInvoke API. The other alternative was to use a 3rd party library such as the Max .NET library from EPHERE.

While Max .NET saves developers a lot of time, it mimics the structure of the C++ SDK. This has two problems: 1) it is not the kind of API that a C# or Python user would expect, and 2) it is very hard to learn for new developers.

Let’s contrast how you would build a Teapot and move it using Max .NET with MAXScript. In Max .NET you basically have to write C# code like you would if using the 3ds Max SDK from C++ (note we use the “var” keyword of C# 3.0 of later to infer the variable types, and make it more script-like):

void DemoTeapotHardWay(IGlobal global) { 
    var cid = global.Class_ID.Create((uint)BuiltInClassIDA.TEAPOT_CLASS_ID, 
      (uint)BuiltInClassIDB.TEAPOT_CLASS_ID); 
    var obj = global.CreateInstance(SClass_ID.Geomobject, cid) as IObject; 
    var n = global.COREInterface.CreateObjectNode(obj); 
    var ps = obj.ParamBlock; 
    ps.SetValue(0, global.COREInterface.Time, 20.0f); 
    n.Move(global.COREInterface.Time, global.Matrix3.Create(), 
        global.Point3.Create(20, 20, 0), true, true, 0, true); 
} 

Now compare the same code in MAXScript:

obj = teapot()
obj.radius = 20.0f;
obj.position = [20, 20, 0]

To be fair the Max .NET library does more than just expose the C++ API to .NET. In addition to other things it provides the ability to write various plug-in types other than global utilities or user actions (e.g. controllers, geometric objects, etc.) entirely .NET. It also comes with a rather interesting remoting library, but that is out of the scope of this post.

My dream for quite some time was to develop an API that would be nearly as easy to use from C# and Python as MAXScript is. I posted the results of some experimentation in a previous blog post over a year ago. Thanks to a recent collaboration with EPHERE, we now have the MaxSharp project.

MaxSharp does three things for .NET developers:

1. It exposes a large chunk of the C++ API to .NET via the Autodesk.Max.dll. This assembly is not documented but can be examined using the Object Browser in Visual Studio.
2. It provides a high-level API that resembles what one would expect when using a .NET library or a Python scripting API. This is the MaxSharp.dll.
3. It makes it easy for people to write Python scripts that use much of the 3ds Max API. This is done via a “RunPython” function exposed to MAXScript (see MaxSharp.ms in the startup folder of the installation), and via a sample user action (see MaxSharpDemo.dll or the accompanying source code).

Here is the MaxSharp approach to creating and moving a teapot from C#:

var obj = Primitives.Teapot.Create();
obj["radius"] = 10.0f;
obj.Node.Move(Point3(20, 20, 0));

The Python version is very similar:

obj = Primitives.Teapot.Create()
obj["radius"] = 10.0
obj.Node.Move(Point3(20, 20, 0))

While this is all extremely cool (well at least for programming geeks like me) there are some important caveats to using MaxSharp. I did include a number of C# and Python samples in the distribution but as you start to use it an industrial scenario you may realize that the exposed API still comes up relatively short when compared to MAXScript. This is why the project only has a limited release as a research project.

All is not doom and gloom: almost every class in the MaxSharp assembly provides a public property from the low-level Autodesk.Max.dll, which contains a significantly more comprehensive list of attributes and methods. This means that if you are not faint of heart and are missing some functionality in the MaxSharp.dll you can get to it by rooting around in the Autodesk.Max.dll using the Visual Studio object browser and the 3ds Max SDK documentation as a guide.

For some people the ability to use MaxSharp to run Python is by itself a pretty big win. For others the advantages may be a bit less obvious, especially since there is already MAXScript. I find Python to be a powerful technology because of the large number of preexisting Python modules and the huge pool of people and forums you can get support from.

Technically MaxSharp only supports IronPython which has some small differences from standard Python (as implemented in CPython). You can see a partial list of differences here. I should point out that there is one big win from using IronPython, which is the ability to use a Visual Studio debugger to set breakpoints and inspect variables. This is made possible via a tool called IronPython Studio. For fun I posted a video showing the process of attaching the debugger to 3ds Max and setting a breakpoint in a Python script here.

If you aren’t already an ADN Sparks member and want more information or just desperately want to get your hands on this exciting new technology then check out the ADN Sparks home page.