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?
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.
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.
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.
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.
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!”
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
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.
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
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.