Hello everyone,
we’re trying in our pipeline to share code libraries between different applications and scripts (we’re very interested in th Object Model Pipeline that Rob talked about :): )
So we chose Python 2.7 and we want to code using these softwares / libraries:
- 3ds max 2012
- Perforce and P4Python (needs Python 2.7)
- PyQt
We’re using Eclipse as general IDE for Pyhton programming, but we are experiencing very hard times in trying to share code
between 3dsMax scripts and other pipeline scripts: tha main reason is that we’re trying to use BlurDev’s Py3dsMax to get Python in 3dsMax,
but it is not working properly with Python 2.7 (on some workstation we have a lot conflicts and troubles, maybe depending on the installation order of packages).
Has anyone some suggestion?
Tha main goal is to share Python libraries between the pipeline scripts and the 3dsMax scripts,
and maybe have just one IDE to develop…
Thank you!
We gave up on Blur Python because it doesn’t support all the Max versions we use. Now we have Python (2.6 + Qt) and Max (MXS + C#) talk via sockets and JSON-RPC. For the socket communication we use ZMQ. Been working very reliably for over 1 1/2 years now with 100s of artists using tools with that implementation.
Although be prepared to spend some development time. But if you don’t care about proper RPC and just send basic messages then it’s much simpler of course.
Hey Robert!
Are you allowed to talk about what specific problems you had with the Blur stuff? For example, did any binaries just need to be recompiled for your version of Max? I’ve been curious about it as well, but haven’t try to set it up just yet… the RPC stuff sounds interesting, but I’d be curious to know whether to spend dev time on that, or fixing issues with the Blur stuff. Thanks!
-J
It’s been about 2 years ago that I last looked at it. Back then we had to support Max 9.0 - 2011 both x64 and x86. Blur dev docs weren’t really that good. compiling ourselves didn’t appeal (was there even source back then?). x86 had, I think, Python 2.6 and x64 had 2.4. Just too much hassle. The RPC / sockets solution has proven to be stable and usable, even though running Python directly would have been much nicer.
The positive side effect though is that we can use this solution also for Photoshop and Zbrush to make it talk to Python
Hmm interesting… I’ve used the win32com to talk to Photoshop through Python and that worked pretty well. I’ll give RPC a look at too… sounds like it might not be a bad thing to have, independent of the decision to use the Blur stuff. Thanks for the feedback man!
If you have a lot of python that’s package independent, you can also host IronPythoninside of max. You will have to get alternate wrappers for perforce (p4.net or the new dotnet perforce api) and QT (qyoto) since IronPython doesn’t support cPython extension modules - but you will have access to about 80% of the python standard library and you can run pure-python .PY files (not .PYC, if that matters…). This route makes sense if you have a lot of common, non-application-specific python you want to leverage; but it’s not going to be tightly integrated with max like the Blur plugin would be.
extra:
http://area.autodesk.com/blogs/chris/launching_python_scripts_from_the_3ds_max_2012_subscription_advantage_pack
[QUOTE=RobertKist;20767]We gave up on Blur Python because it doesn’t support all the Max versions we use. Now we have Python (2.6 + Qt) and Max (MXS + C#) talk via sockets and JSON-RPC. For the socket communication we use ZMQ. Been working very reliably for over 1 1/2 years now with 100s of artists using tools with that implementation.
Although be prepared to spend some development time. But if you don’t care about proper RPC and just send basic messages then it’s much simpler of course.[/QUOTE]
I did a hack and slash socket implementation after giving up on Blur’s python plugin. However I did not manage to get ZMQ involved in the process.
May I ask how you brought it into the fold? I would love to use it if I can as my current socket work is not the quickest or the most efficient.
Thanks!
We’re using C# with ZMQ, then load the ZMQ assembly (its a wrapper for the regular zmq dll called clrmzq) and our dll in max script. Our own C# code handles dealing with ZMQ. We’re not dealing with it directly from Max. Tip: only clrmzq is architecture independent - i.e. you can use clrzmq with x86 and x64, however the main zmq dll must match the architecture of the 3ds Max version you’re using.
On python there should be a module called pyzmq. For communication we use the “pair” method. It’s very simple. There should be plenty of examples. Just try it our in Python first, then move to having Python and C# talking to each other.
Lovely, thanks for the information.
I’ve not done any C# work in my day, so I’ve been trying to get around that short-coming.
It however keeps looking like I’ll need to get my feet wet!