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.
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.
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
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.
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
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.
Hi, d3coy,
Thats almost the exact workflow I use on a day to day basis. Its easy (relatively easy). I talk to python servers through a COM class I have written that creates the Pyro connection which max communicates through… I will try and put together and example this week for everyone…
The other approach which i prefer and have used with success is to create your own slave app that runs on each machine, I’m currently porting my pyro version to twisted to take advantage of asynchronous networking which is great if you want to write a render manger or “allot” of other things… again ill try and post some examples as time permits…
Cheers
Dave
Awesome spec,
I was thinking about it some more, and thought it might not make sense to completely build my own system when something like Pyro exists. I’d love to see how you’re accessing Pyro objects through COM. Otherwise It’d involve a lot of python socket programming with a .net socket app that MXS uses to bridge to the python server. Can Maya’s and XSI’s python integration import modules like Pyro?
*edit: I need to look more at Twisted. Its hard to find tutorials on the web for it though, I suppose because there are so many books on the subject.
Ill try and post the code up for you asap… I would also love to no whether maya or XSI can import modules as well, I’m making the assumption and saying yes, but still not sure…
Certainly coding an app thats working with sockets is hard work, rather more time consuming, and thats before we get into threading, thread locking etc… Allthough .Net and python communication is certainly something I will do some reasearch into…
Cheers
Dave
Loving the momentum of this thread guys!
Hopefully i’ll actually get a chance to try some of this out when my work has calmed down!
I’m loving this thread as well.
A couple of questions. Can one of you please tell me what Pyro and Twisted are and what they do? I’m looking them up but I’m going to quess that I’m not going to figure out how you are using them with Max from what I will read on the web.
Thanks guys. This thread is going well.
Pyro is a Python Remote Object library written in python itself. Basically it allows python code segments to sit on a centralized server and clients can execute the code from anywhere on the network. You can think of it as distributed COM for python. More info and documentation can be found here http://pyro.sourceforge.net/
Twisted is a Python event driven network engine also written in python. I’m not that familiar with it only know that it’s used as a python based web framework although I prever Django. Maybe someone else can elaborate on how this fits into their pipeline and maxscript. The projects home page is http://twistedmatrix.com/trac/ .
Ok, how does Pyro differ them setting a path to a folder on the server were you have modules that can be used? I might be missing something major here.