Python + MXS

#21

I’m curious…with the implementation of python in maya, i’m wondering if max will head the same way??

If so, do you think it’s a good thing or a bad thing?

Personally, I’d like to see a little more OO implementation in the API (I know the core API is OO, but max script isn’t … to my meger knowledge … but this is not the place for that disscussion)

Personally. I’d like to see the scripting side updated, as powerful as it is and as simple as it can be, it can sometimes be frustrating…just gets you close enough to a solution, but not quite overline.

Just thought I’d ask the question and see what others think

#22

Hi Shane,

I think adding Python to 3ds Max would be a pain… Maya is well designed so adding Python to it wasn’t so difficult. It’s not the same story for Max.

#23

I agree completly, python is very good at gluing the pipeline together even more so if you have a multi package workflow so max maya fusion/shake… and yes python string parsing is very strong along with its XML parser which is all C and well developed…

I have to admit I would love to see python in max, although i think hell will freeze before it happens :slight_smile:

Cheers
Dave

#24

Here is one that I would like to see as it is right up the line or what I’m doing. A tie in with the Python XML parser and a data base. I gather this is possible but I haven’t looked into what data bases Python will work with, I’m guessing any of them. Is this correct?

#25

I’m guessing any of them. Is this correct?

This is correct.

The reason that hold me back from doing extensive DB stuff until now was:
Not many people like to have a DB on the same machine as a maxinstallation.
Also: not many admins like a DB that is accessible from any host.
All this leads to proxy scripts, where you have the scripts running on the DBserver that will be queried through HTTP or curl (don’t know what the python name for curl is).

But speaking of xml and databases:
Maybe a XML database like eXist is a good idea, as parsing xml from/to relational db’s like mysql is sometimes ugly.

#26

Thanks, I’ll dig further.

#27

MySql is really simple in Python with the ‘MySQLdb’ module, it makes connection and interacting with the database simple. For xml i like Element Tree which as of version 2.5 of python is in the standard lib. Its very fast and easy to use.

I do prefer to with XML than SQL, I wrote our server here in Python that works off a XML back end, its not to difficult to do, so long as you can get your head around threading etc…

Cheers
Dave

#28

cool , im waiting for it long time . with python , im free from max envirment , and free from C++ . lol .

#29

Just so that I’m clear on this. There is an XML data base? Is this free? Or are you writting XML files?

I’m just working on modules in Python, this is far easier then Perl that is for sure. Well for me anyway. The help files are really good so far.

#30

Need a bit of help on packages? Is a package just a diescription file of what modules to import?

So you list the name of the package and then the names of the sub folders and then the modules in them??

#31

There is an XML data base?

Exist:
http://exist.sourceforge.net/

Xindice:
http://xml.apache.org/xindice/

There might be others as well.

The ‘drawback’ of those is that you use xpath and other xml-techniques instead of godd-old-sql-syntax.

Also they are better for storing document-style-data. Relational databases seem to be better for storing data-style-data. I guess this will be a new field of research.

#32

For now back to the XML file parsing. So in max I have the dotNetObject “system.Xml.XmlDocument” for reading and writting Xml docs. In Python I have modules that can do the same. I don’t want to have to write the same code twice, once in Max script once in Python.

Can python use the same .net method as Max?

Should I write it all in Python and call the python functions from Max some how…if so…how?

I have the oposite from the above worked out in my head but that isn’t the way that would be most effective if I ever want to include another app.

#33

This is a really interesting development. I’ve been calling python scripts for various things from 3dsmax for a while now but to be able to do it the other way around opens up some interesting possibilities.

Thanks for posting this. Although I still hope that a native python interface finds its way into 3dsmax someday.

#34

How are you calling the python scripts? Same way that is shown in the Project Management thread?

#35

Since it’s for in-house use only it’s not nearly that refined. Currently I’m just executing python.exe <script> params (normally an xml file that’s generated by the maxscript side of things) using the doscommand syntax. It pops open a dos window so not exactly transparent but it works.

Most of the python use here has avoided 3dsmax b/c of issues with integration. So it’s been used for pipeline things and as runprogram calls in renderman scene files for adding and rendering of some large astronomical dataset stuff that 3dsmax just can’t deal with very easily. This is integrated into 3dsmax’s scene via some scripts which deal with the coordnate system translation and the exportation of the cameras into rib files and queueing the results in Deadline and such to be rendered as a layer for later compositing.

Once I have more time I’ll have to look at this thread and see if there are more elegant ways to do some things. Including making some of the python scripts cull down the data sets and atleast allow some level of visualization of them within 3dsmax. I hope to move some of the logic that’s currently in the 3dsmax scripts to python now that it appears there are some easier ways to get data back and forth. Allowing me to reuse alot of code in other 3d apps.

#36

This is exactly what I’m looking at as well. I don’t want to have CMD popping up every time something is run.

Once I get things working I will post examples here. Could be a while as I just found out that the client now needs something really fast so I’m going to hobble together a solution that should get them further then what they currently have which is nothing.

#37

Hi, Guys,

I prefer to use COM instead of doscommand etc… Its very easy to make class written in python into a COM service. Here is a repost of the code in the Project Management Thread.


  #A simple Python COM server, as simple as it gets.
  class PythonComClass:
  	_public_methods_ = [ 'SplitString','SomethingElse' ]
  	_reg_progid_ = "PythonDemos.Utilities"
  	#Make sure you generate a new Class ID, use pythoncom.CreateGuid()
  	_reg_clsid_ = "{41E24E95-D45A-11D2-852C-204C4F4F5020}"
  	
  	def SplitString(self, val, item=None):
  		"""Splits a string"""
  		import string
  		if item != None: item = str(item)
  		return string.split(str(val), item)
  	def SomethingElse(self):
  		"""Some other method"""	
  		return "Something Else"
  	def __PrivateMethod(self):
  		return "This is a private method"
  
  
  
  #Make sure this module has not been imported. Register COM server
  if __name__=='__main__':
  	print "Registering COM server..."
  	import win32com.server.register
  	win32com.server.register.UseCommandLine(PythonComClass)
  
  ############################################
  #MXS
  
  releaseAllOLEObjects()
  obj = createOLEObject("PythonDemos.Utilities")
  obj.SplitString("asd_asd", "_")

I would normally have a bunch of private methods that handle connecting to servers etc (or whatever you want them to do). Then just have a few public methods to call, this is a really powerful way to talk to python as you can of course return data as well…

Cheers
Dave

#38

Thanks for that Dave. Very interesting indeed.

I could be wrong here so please correct me if I am. But the one downside I see is that the python code itself is influenced by the target host application…which is less than ideal when you’re trying to use python as a neutral middle ground for a pipeline that consists of multiple applications. So if you want to use your python code from multiple applications extra care would have to be taken to wrap the python application/scripts in COM in a way that the application/script can also be run outside of the COM interface for programs that natively support python. This would especially be true in mixed OS environments where you can’t count on COM support being available.

I guess that’s what we live with until 3dsmax has a native python interface…which one can only hope is soon.

#39

I agree 100% until max has python implemented as a scripting language (I’m not holding my breath) we are stuck with either wrapping existing apps that we have written so there COM compatible or parsing commands via command line etc… On the mixed os side of things, I generally will write an app once and then do some platform testing to determine whether or not to register classes with com etc…

Cheers
Dave

#40

A safe way to construct a “Python middleground” would be to open a socket to a server (Python scripted) that holds all of your global methods (database access, whether sql or xml or whatever, project management functions, etc) and could be called from anywhere with access. You’d only ever have to write an interface to the server whenever you add other packages to the pipeline.

It’d require extra initial setup, setting up a TCP server, writing the byte-headers of your different return values for the functions, etc, but it’d pay off. If many computers will be using the functions at once, the server could be multithreaded with stackless python or the standard thread api. OS independence, package independence. Just a thought; I just don’t like depending on a Windows-only interop service.

If only something like Pyro could be used from within Max.