Python + MXS


#121

Woo hoo! Just got that same thrill.


#122

Hi,

Again thanks ehulser for sharing the dlx. I’m having the same problem like what cgBartosz has encountered.

I’m currently running python 2.5.1.
It seems like you can import all the built in modules without any error within max. But when you try to import other library it just return undefined as thou it can’t find the path.

However within python there’s no problem importing using:

>>> import sys
>>> print sys.version
2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
>>> import os
>>> os
<module ‘os’ from ‘C:\Python25\lib\os.pyc’>

Thanks again for sharing :).


#123

I’m sure I posted a reply to this a few days ago, oh well…

Basically, I’ve not tried this under python, but have been investigating the possibility using Java. This is what I’ve found…

Max can talk to “OLE Auutomation Servers” … commonly known as COM servers…

So, in order to get this to work, you will need to create your own COM server, register it under windows and, using Max’s “OLE Client” functions, connect and communicate with it…

There is some sample code on the install disk, but you will also want to look up “OLE Client” and “Running the OLE Demo” for more info.

I hope this helps

Shane


#124

Python plugin has been updated on my site.


#125

Ok i have tried with python 2.4.4 and it seems to work fine now without any problem on importing modules.

I guess that the current python plugins is not compatible with 2.5.1. With 2.5.1 the sys version will always revert back to the built-in version which is 2.4.3 (#69) instead of the following result that i’m getting from max with 2.4.4.


sys = python.import "sys"
<module 'sys' (built-in)>
sys.version
"2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]"
os = python.import "os"
<module 'os' from 'C:\Python24\Lib\os.py'>

Not sure if i’m right on this. Hope it helps on anyone else having the same problem. But at least i get to start working on more python tools.


#126

This probably has to do with the plugin being compiled with Python 2.4 libs. Thats the version we’re running and the code was compiled for - do you have both python versions installed? Try flushing the sys.path variable to remap to c:/Python25 instead of 24


#127

which reminds me - I still haven’t mapped setting attributes…will have to get on that…

for instance, cant do this:

sys = python.import “sys”
sys.path = #() – That’ll crash…though it shouldn’t


#128

I have both 2.5.1 and 2.4.4 installed. And yup can’t really remap for now as it will just return


-- Unknown property: "path" in <module 'sys' (built-in)>

I was trying to use MySQLdb module with blurPython in max. But seems like the connection string can’t map correctly yet too. Just to let you know before hand :slight_smile:

This works in python IDLE


import MySQLdb
MySQLdb.connect(host="localhost",user="root",passwd="Mypassword",db="MyDB")

while this doesn’t in maxscript


pysql = python.import "MySQLdb"
<module 'MySQLdb' from 'C:\Python24\lib\site-packages\MySQLdb\__init__.pyc'>
pysql.connect
<function Connect at 0x103E0030>
conn = pysql.connect(host="localhost",user="root",passwd="Mypassword",db="MyDB")
-- Syntax error: at ),, expected <factor>
-- In line: conn = pysql.connect(host="localhost",u
 

Not sure if i’m doing something wrong thou.


#129

Yeah MySQLdb was the big reason I wanted python integration more seamless without using ODBC and OLE.


#130

Hi Guys,

Having had just returned from holidays this is awesome, I definitely have to shout Eric some beers! awesome work! I have only had a quick chance to play with it so far but it looks very impressive… A quick question, what is the likely hood of a 64bit build?

Again thanks to Eric and blur for sharing this with us for those of us who have large and complex python based pipelines this will be fantastic to better integrate max… Thanks to Paul for hosting as well!

Cheers
Dave


#131

Teirz:

Keep in mind you are actually running MAXScript code that wraps Python code, so it still goes through the MAXScript interpreter. In MAXScript, you can’t call a function this way:

pysql = python.import "MySQLdb"
pysql.connect( host = "localhost", user = "root", passwd = "Mypassword", db = "MyDB" )

It has to be in proper maxscript syntax:

pysql = python.import "MySQLdb"
pysql.connect host:"localhost" user:"root" passwd:"Mypassword" db:"Mydb"

right now I don’t have it mapping optional variables though, so for right now you cant pass in optional variables like that, this should work for right now though:

pysql = python.import "MySQLdb"
pysql.connect "localhost" "root" "Mypassword" "Mydb"

Important thing though, and I know this is kinda confusing, you still have to follow MAXScript syntax rules even though its executing Python methods.

specxor:

Hope it helps, we have a Python based pipe and are hoping this’ll help tie it all together too. I’ll include a x64 build in the next release, also a max8 release. We’ve needed both here also.

So, to recap:

Known issues:
No setattr implemented
No optional method variables implemented

Anything else?


#132

Thanks Eric again for clearing my confusion. It all works perfectly now, just like a turbo button for max scripting. Connecting to database is so much cleaner and totally no problem getting the cursor to work. I will try to feedback if there’s any other issue as i am still working on the python based pipe for my studio.

By the way, i’m using this plugin with Max 2008. So we can probably assume that this plugin is ready for max 2008 as well. And the best thing is that at least i won’t have to worry the complains from any Maya TD that they can’t use python as easy in max now.


#133

I would love to hear a brief description on what you are using Python for in your pipelines and what you are doing with it. I’m slowely writting the spec for a pipeline and wonder where others have gone before me.


#134

This plugin should work for max9+ until they switch compilers like from max8 to max9. (theoretically) Though the plugin itself is simple and should easily translate to future versions. I’m hoping this should bridge a large gap in 3dsMax integration as a lot of studio’s I know of use Python in their pipeline.

We started using Python when we added XSI into our pipeline as it was the most powerful of the scripting languages available for XSI, and have since expanded much of our pipe to using Python as the core. Since we have to support 3dsMax and XSI, we keep as much information that we can share and keep in a single library as we can, so naming conventions, path templates, XML formatting, and eventually connections into production tracking and asset management would run as separate python modules that we could now directly incorporate into 3dsMax. Before, we had to duplicate the functionality through a DLL or MAXScript library and it became a pain to manage.

Mostly, I’m just lazy.


#135

We’re porting a tool to help with lip syncing from maxScript to python. Our own version of papagayo that sits just below the time line, if anyone’s familiar with that program. Python is siginifigantly faster at parsing the huge dictionary files and so far, wxPython is much faster than maxScript at drawing our (probably too complicated) interface. If it goes well, we’ll be porting all of our tools to python.


#136

We are still developing it to replace our old pipe for TV series. As my current main focus is TV series which normally has a very tight schedule, e.g. 1-4 episode per month depends on the budget and animation length, by having a proper customize asset management and production tracking system is very important to us. And sometimes we need to swap between maya and max, so it’s more practical to share the data/scripts and any other data e.g. selections sets, enforced naming convention etc to keep the consistantcy without the need to write some scripts twice. Even the XML formatting is extremely useful with the new version of FCP. It’s quite possible that i will be porting all the in house tools to python so those who are more familiar with maya can just duplicate the same function without wasting much development time.

Another thing that i’m working on with python is the asset tracking. Whatever max9/2008 having now is still not as friendly for production. For example, there’s a lot of time i need to know this asset maxfile have merged in which model, with which material library loaded, with which rig, and which lighting master file, and done by which guy. I don’t like the idea of xref as there’s too much limitation, and thanks to PEN (yup here must credit you for your batch processing scripts :)). Keeping track of these without a proper system would really drive someone crazy.

The last thing i wanna hear from my EP is “Which idiot has name this file as EpXX_ScXX_ShXXX_final_final which is not FINAL! Where’s the freaking latest file!”


#137

Hi Paul,

Here is a quick description of what we are currently using python for in our pipeline…

We are using python in our pipeline to mange assets, task assignment, render passes, project creation and project management. Our artists use a standalone application written entirely in python to manage all aspects of the job. We are also experimenting with using python to dynamically create our scene and render files.

All of our asset management is database driven, we use a custom server to handle task delegation, new asset creation and the creation of new projects, scenes and shots. Max files and file structures are dynamically created to conform to our in-house conventions.

We (I) have also been developing a replacement to back burner that will support multiple packages, generate previews and a bunch of other things that are pretty cool ;).

Cheers
Dave


#138

We are using python in our pipeline to mange assets, task assignment, render passes, project creation and project management. Our artists use a standalone application written entirely in python to manage all aspects of the job. We are also experimenting with using python to dynamically create our scene and render files.

All of our asset management is database driven, we use a custom server to handle task delegation, new asset creation and the creation of new projects, scenes and shots. Max files and file structures are dynamically created to conform to our in-house conventions.

Hi Dave,

It seems like everyone is going towards the same direction.
And i believe that the database you are running at had a gigantic and complex setup, at least while reference to what i’m still working on now, cause you have a much complicated pipe there.

I’m interested on how you handle the artist on file managing. Does your artist create all the asset files thru your system, meaning they are totally isolate from e.g. window explorer to create files, or even the default save button in any application that’s involved in the pipe.


#139

Hi Teirz,

It does seem like everyone or allot of studios are going down the python route… With assets, we have a mix between our software handling files but still allowing artists to be able to get at files manually should they need it.

We have replaced all of the standard save, save selected, export etc… with our own tools that takes over from the user and creates entries in the database, all files are saved in there correct location based on the type of asset they are, for instance if it was a character or prop etc… The software handles all of this, we found its much easier if you keep a logical file structure so if artists need to for what ever reason they can still find what they are looking for with out to much effort.

Hope that helped…

Cheers
Dave


#140

That is great info, thanks. I have done the same but I have done it with MXS and XML only at this point. Since I do most of my development for smaller companies these days I don’t always get the time to develop larger tools and systems. I’m looking at creating a flexible tracking system that I can impliment with clients as they need it instead of just reinventing the wheel each time.