So I started learning Python to do some file organization/text parsing and writing, both inside and out of Max. I ended up just implementing all of Pythons string ops and methods into a MaxScript struct, along with other stuff I continue to write and add to it. What would be the benefit of using Python? Any metrics of how much faster it would be? Assuming one has a working knowledge of Python and strong knowledge of MXS, how much much longer do you think creating a UI and implementing the functionality would be (mostly scared about the UI, text editing scripts wouldn’t be too difficult). It is nice not having to leave Max to do text stuff and not having to set up a COM or however you get Max to communicate with Python, at least for those of us on this side of the canyon.
I do some pretty heavy text editing on a massive scale (like, adding together animations over a couple hundred XML animation files…), and I’ve had to do it for a few things so far. I’d be curious what the benefit would be of using Python in the future, since it really has nothing to do with Max.
So you’re talking about reading and writing large XML files, then?
Short answer: If you’re comfortable with MaxScript and have no complaints about its speed, then stick with MaxScript.
Although reading/writing large (150-200MB) XML files with MaxScript is one of the things that sparked the TAs at our studio to learn Python. We were using regular MaxScript readLine and it was not only dog slow, but consumed tons of memory. Granted, this was prior to the .NET exposure, so I imagine there’s a real XML parser or two accessible to MaxScript today, and perhaps that landscape has changed.
Regardless, we were doing lots of external file manipulation, more advanced UI on our tools, more Windows-level stuff and just felt like MaxScript was limiting for certain things. There’s nothing Max-related about spinning through a few hundred MBs of text or binary building asset lists. We just used MaxScript because it was the language we were most familiar with at the time.
I’m a huge fan of Python, but I won’t say it’s a full replacement for MaxScript… certainly not for things that are inherently Max-specific. It’s the only way to access and manipulate scene data, among other things.
On the UI front, I’ve found Python to be more powerful, but that aside, none of the Python GUI toolkits are as dead-simple as MaxScript’s UI stuff. Truly, it doesn’t get any easier than that. The primary downside is those tools have to run inside Max.
Back to text file work… I don’t have any MXS vs. Python benchmarks handy, but it wouldn’t be hard to gather some. In the “Data Mining” section of the sample scripts from my Python GDC lecture, there’s four different example scripts that mine data from XML files. You could easily modify those to point to your files and do some comparisons.
Alright, if I get some time this weekend, I will (if I remember).
For XML in Max 9 and above, you can use DotNet to read XML files much more efficiently, as you mentioned. Unfortunately, I say ‘xml’ but they are actually proprietary Morpheme XMD files, which aren’t actually XML, they are more like BVH actually. So I can’t use the XML methods, just have to use readLine in the cases I mentioned, but there are other cases with real XML (lots of game-side stuff).
I agree with Adam in that learning Python allowed TechArtists at Volition to write programs/tools that had no business being inside of 3dsmax. It has given us a lot more freedom and flexibility. A couple of TA’s went so far as to write a Python app that had a C-bridge component to the game and modified lighting in the game in real time. Pretty d*mn cool.