Python + MXS

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

REPLY TO THREAD
 
Thread Tools Search this Thread Display Modes
Old 06 June 2007   #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.
__________________
Georg Duemlein
 
Old 06 June 2007   #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.
__________________
Paul Neale
http://paulneale.com
 
Old 06 June 2007   #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.
__________________
-Dave
 
Old 06 June 2007   #34
How are you calling the python scripts? Same way that is shown in the Project Management thread?
__________________
Paul Neale
http://paulneale.com
 
Old 06 June 2007   #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.
__________________
-Dave
 
Old 06 June 2007   #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.
__________________
Paul Neale
http://paulneale.com
 
Old 06 June 2007   #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(PythonComC  lass)
  
  ############################################
  #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
 
Old 06 June 2007   #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.
__________________
-Dave
 
Old 06 June 2007   #39
Originally Posted by RealThing: 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
 
Old 07 July 2007   #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.
__________________
- d3coy.com -
technical articles, scripts, and gallery

Last edited by d3coy : 07 July 2007 at 02:10 AM.
 
Old 07 July 2007   #41
Originally Posted by d3coy: 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
 
Old 07 July 2007   #42
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.
__________________
- d3coy.com -
technical articles, scripts, and gallery
 
Old 07 July 2007   #43
Originally Posted by d3coy: 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
 
Old 07 July 2007   #44
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!
__________________
"There Really is No Secret"
Martin Brennand - mocha Product Manager - Imagineer Systems
 
Old 07 July 2007   #45
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.
__________________
Paul Neale
http://paulneale.com
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 07:23 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.