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.
Update: Since blur seems to have been very quiet on their endeavours of bringing Python to the 3ds Max crowd, I had decided not to wait on 3rd party developers for developing such an important feature in any modern pipeline, no matter the host 3D application, and develop our own Python plugin, called Pythoner. If you’d like to know more, get in touch with me and I’ll organise a demo for you. In the mean time, here are a few features available in Pythoner.