Python in 3dsmax - is it viable?



I am considering to partially migrate from maxScript to Python in 3dsmax 2019. I cannot use Blur-Python, so I am stuck with built-in python from Autodesk.

I use maxScript quite extensively. I am aware that Python is not integrated to that level, but is it viable at all? Can it access all render settings? Animation controllers? user defined object properties? Mesh operations?


It would be worth using it for being able to work with classes and for using Qt as UI.
I haven’t fully explored the API because the documentation isn’t very good, but you can always call Max Script from Max Python.

In our studio the aim is to go Max Python first before falling back to Max Script. But it obviously depends on the type of problem and scope of the tool we’re dealing with.


Partial migration is all you will be able to achieve. Python is not a first-class language in 3ds Max. Many things are lacking. For instance you cannot make scripted plugins (geometry, modifier, material, etc…) with Python. For many things you will still have to code in MaxScript.

In 3ds Max 2018 (possibly 2017, I forget) Autodesk enabled Python modules to be imported into MaxScript code. This is similar to how MaxScript can use .NET assemblies. Data can be passed back and forth between MaxScript and Python quite easily. I’ve found (and restructured some pipeline areas at Volition to support) writing library modules in Python and using MaxScript to access those common libraries in 3ds Max. For instance - Volition’s code to parse our custom material format and display the material in a 3ds Max viewport used to be 100% MaxScript, as it required a scripted material plugin. Now it consists of a scripted material plugin and a Python module. The Python module handles all of the custom material parsing and provides a dictionary of material related data. Any program that can utilize Python can now access our custom material format. For 3ds Max the scripted material plugin imports that Python module and uses the data to create a Max material. We can now easily support our custom material format in Maya, Motionbuilder, and Blender, etc… We just have to create connections from the material Python library to the UI & viewport of a given DCC application using the most suitable language for each DCC app.


Thanks to both of you.
Jeff, what you said about going back and forth is a big deal. It makes it easier to take the leap :slight_smile:

Do you know of any list that compares maxScript an Python features, so I can se exactly where Python is lacking?


I don’t know of a published list. I found out about the scripted plugins discrepancy only because my first attempt at a pure Python implementation in Max was refactoring our material pipeline for DCC apps.


Ok, thanks anyway :slight_smile:


The pymxs api is pretty much a maxscript wrapper. So any maxscript scripts or tools you have can be converted and I would recommend it as the features of the python language will make it worth it;

  • proper oop
  • easy access to the many built in and useful modules, json being the most notable that we have used since switching.
  • then there is access to fantastic 3rd party modules such as numpy and scipy which can improve your mathematical based functions by orders of magnitude.
  • Qt gives UI functionality that you can only dream of with the maxscript dotnet implementation.
  • cross platform tools are glorious to behold.

Obviously, as mentioned above, any scripted plugins or script controllers etc will still be maxscript and you will still need knowledge of the maxscript api to be able to use pymxs effectively as the documentation is light on the ground.
It is not an easy transition, especially to do it properly, but if you expect to continue to use max for the foreseeable future, then it’s one you should definitely do as it is more than worth the effort.


I second pymxs. The original Python API seems fairly incomplete and hard to figure out. Once you get used to translating maxscript to pymxs it becomes easy to find answers to max scripting questions, and you can take advantage of resources like scriptspot. You can also call maxscript as necessary with rt.execute().


I prefer to make a global maxscript function and access it via pymxs.runtime, normally stored in a mxsPython struct ( Only usage for this I have had is the use of maxscript as conversion. ) Otherwise everything is doable in python, especially in 2019 with the ability to pass in by reference arrays for the functions that use them.

With sensible repository and code structure you can have an API that is accessible via python and maxscript that meets the coding requirements for each language respectively, which is super powerful.


What exactly is the difference between pymxs and maxPlus? I thought maxPlus was the python wrapper for maxScript?

I see the obvious advantage of being able to use Python modules, but I weigh that up against what to me, seems like a really poor Python implementation … One thing that would be really useful is to be able to send and recieve commands from outside max without having to resort to generating text files. Can I use a network module in Python to do this, with a little standalone python program in the “other end”? (On the same computer)
At the bare minimum I should at least be able to properly generate .xml-files?

FYI: I am not a programmer - maxScript an Python are just additional tools for me, so I might need to be spoon-fed some of this stuff :stuck_out_tongue: (Although I am beyond the very basic)


MaxPlus is a half done wrapper for the Max SDK. It is pretty terrible, but can be really good in the few areas that the implementation is complete.
pymxs is the almost 100% complete wrapper for MaxScript. Super useful!
The two modules are not really compatible as they use different objects ( SDK vs MaxScript objects ), and any benefit of using both is lost when having to convert the data types.

When pymxs was implemented in 2016, there was a full integration of a python27 interpreter ( as far as we are concerned ), which allows for python to be executed from within max, rather than having to import a python file as was the case with the MaxPlus implementation from 2014 - 2015.

Currently, a tool I have written is able to control Max instance A from Max instance B, using the win32 module. - If this is what you were asking?

Python and xml do not really play nicely together, especially the format that AD uses in Max ( .xaf ).
Though, for any native tool that uses said format, there should be an interface to modify it through, rather than editing the xml file directly.

Ultimately, it comes down to the following choices:

  • Are you wanting to modernise an existing advanced pipeline or create a new one from scratch? - Use Python

  • Do you want to extend your functions beyond the native capabilities of max, ie using numpy, scipy, json? - Use Python

  • If you are just writing a handful of small scripts to assist you in your day to day work? - Stick to MaxScript


Thanks munkybutt, I see the difference between the two now .

In regards to control 3dsmax from the outside, its like this: I have written some maxScript tools to automate tasks at work over a few years. (We get huge CAD models to work with.) Now I am writing a program in python and pyside2 that runs each of those scripts in sequence. This is so we can set the whole thing to run overnight.

In order to have a UI for the script in both maxScript and standalone python, the scripts reads a text file where it finds all the UI settings. Both my standalone python program and the usual maxScript interface generate text files that the scripts reads. This way I decouple the script from the UI, which lets me run the scripts from anywhere.

The problem is that all communication back and fourth has to be done with text files. Its not just the UI either. I would like scripts to write logs, I want potential errors to halt the thing etc.
Text files work okay, but I would like something more elegant …

It would be fantastic to have some python script running in the background i 3dsmax, which listens for commands from an outside program. This is where the idea of using some sort of network communication came into play. But I have absolutely no idea if this is possible … All this, except from working in maxScript within 3dsmax, is very new to me.


Easy answer is yes it is possible.
Figuring it out is the hard ( and fun bit ).

A bit of info that might help you out , look at the source code for this sublime text plugin to see how you can send commands to an instance of max from an external python interpreter:
If you are using different python qt versions, qt4/qt5/pyside/pyside2, definitely use to remove any headaches brought about by version differences:

Good luck!


Thanks alot Munkybutt. I will take a look at it :slight_smile: