well i guess the topic says pretty much everything i’d like to ask :)

.:bugs bug me

You dont use Python in 3dsmax because it’s not built in.

YiannisK 10 December 2007 05:39 PM

well i guess the topic says pretty much everything i’d like to ask :)

See this thread on cg society. Everything you need for getting python to talk to max is there.

--
James Kelly
fo co mo so

At our studio we’re using Python more and more to replace MaxScript in our tools.  For us there’s several benefits to this:

- Python is a mature, full-featured language and provides a lot of useful functionality that’s simply not there in MaxScript.
- Python isn’t bound to a specific 3D application.  This allows us to create tools that have very little app-specific code, making them much easier to deploy for multiple 3D applications (Max, Maya, etc.).
- We’re using Python as the embedded tools scripting language in our next-gen editor tools.
- Python is just fast and fun to program with.

One example is a Max exporter script I recently wrote.  It’s about 500 lines of Python code, with only 15 or so lines of MaxScript to do the low-level stuff.  The script uses wxPython for its GUI interface, but is still parented to the main 3ds Max window so it looks/acts just like any other MaxScript tool to the artists.  The Max-specific code is fired off over the COM connection with Max, and the results are returned to Python for it to deal with.  Add a few lines of MEL (or Python for that matter) and the same tool works in Maya.

I’m actually giving a talk at GDC 2008 in February called Python for Technical Artists.  I plan to show the above in action and cover the upsides of Python for this sort of thing in more detail.

Adam Pletcher
Technical Art Director, Volition, Inc. / THQ
blog: Tech Art Tiki

I really would like toi learn that :D

Adam Pletcher 11 December 2007 03:04 PM

At our studio we’re using Python more and more to replace MaxScript in our tools.  For us there’s several benefits to this:

- Python is a mature, full-featured language and provides a lot of useful functionality that’s simply not there in MaxScript.
- Python isn’t bound to a specific 3D application.  This allows us to create tools that have very little app-specific code, making them much easier to deploy for multiple 3D applications (Max, Maya, etc.).
- We’re using Python as the embedded tools scripting language in our next-gen editor tools.
- Python is just fast and fun to program with.

One example is a Max exporter script I recently wrote.  It’s about 500 lines of Python code, with only 15 or so lines of MaxScript to do the low-level stuff.  The script uses wxPython for its GUI interface, but is still parented to the main 3ds Max window so it looks/acts just like any other MaxScript tool to the artists.  The Max-specific code is fired off over the COM connection with Max, and the results are returned to Python for it to deal with.  Add a few lines of MEL (or Python for that matter) and the same tool works in Maya.

Very cool. We’re looking at doing all our tools in python now for some of these very same reasons. We don’t want to get tied to a specific app (although Autodesk does own the two we use most). Would you be willing to post an example of your script? Just the com stuff so we can look at how you do it? This is new ground for us.

Thanks.

James

--
James Kelly
fo co mo so

The COM bits of what we’re doing is explained in this thread on CGTalk, as someone mentioned above.

Some of the win32 code posted in that thread is actually from the book “Python Programming on Win32” by Mark Hammond and Andy Robinson.  An excellent book if you want to learn more about Python and COM, and the Win32 API in general.

I’ll be happy to post some code examples when my GDC talk is further along and I’ve cleaned things up a bit.

Adam Pletcher
Technical Art Director, Volition, Inc. / THQ
blog: Tech Art Tiki

Adam,

I’ve gotten the basic python to max communication working (as per the cgtalk thread). But it sounds as if you’re opening up a window in max that is just a container for a python script (the way you would use a dotNet control). Is that what you’re doing? And if so, I’m stuck on how to get max to talk back to python. Do I need to register python as a com object the way I had to with max? I’m a little in the dark here and any help would be great.

Thanks in advance,

James

--
James Kelly
fo co mo so

The Python tool window I mentioned is just a wxPython frame.  You can then use the pywin32 extensions to tell Windows to make the main 3ds Max window the wxPython window’s parent.  Windows takes it from there and it behaves just like any child dialog in Max.

The fact the Python script also uses COM to talk to Max is incidental.  Windows certainly doesn’t know/care what the script does.

I don’t have examples I can post yet, but I’ll do that when they’re ready.

Adam Pletcher
Technical Art Director, Volition, Inc. / THQ
blog: Tech Art Tiki

Thank you for your help.

.:bugs bug me

Adam Pletcher 12 January 2008 12:16 PM

The Python tool window I mentioned is just a wxPython frame.  You can then use the pywin32 extensions to tell Windows to make the main 3ds Max window the wxPython window’s parent.  Windows takes it from there and it behaves just like any child dialog in Max.

The fact the Python script also uses COM to talk to Max is incidental.  Windows certainly doesn’t know/care what the script does.

Ahh, got it (I think). You don’t launch the python frame from maxScript, you launch it separately (or via the command line in maxScript) and the script childes itself to max. Are you able to make the dialog dockable this way? I’m asking because I’m trying to port a maxScript tool that we dock below the time slider to python (in the hopes that wxPython will do the interface stuff faster than maxScript which it certainly does stand alone).

--
James Kelly
fo co mo so