Hey people, I have written a Qt-based plugin for Mudbox.
It’s a highly verbose UI tool-box, for version-control, that interfaces with our in-house CMS, so functionally, it just deals with saving and opening files, from the host-application’s stand-point, so it should be easily convertible to other applications.
I wanted to know if I can modify it to run in 3ds-max as a plugin, using the 3ds-max SDK and the Qt-SDK.
I couldn’t find anywhere on the web talking about it.
I know that autodesk has started using some elements of Qt in 3ds-max a couple of versions ago, but I
can’t tell if that means you can create Qt-based plugins for 3ds-max.
I know all about Blur’s py3dsMax thing, that has a customized version of PyQt built-in, but it would be a lot of work converting the C++ based Qt code into pyQt, and I might not be able to use the .ui file which is quite verbose. I have modified-inherited QAbstractItemView’s all over my plugin, and it would be a lot of work converting all that…
Does anyone have an idea whether this can be accomplished?
Don’t know if you guys are in max2012 yet, the subscription extension supplied the maxdotnet dll with which you can use ironpython : http://area.autodesk.com/blogs/chris/launching_python_scripts_from_the_3ds_max_2012_subscription_advantage_pack
Best I can think of, otherwise the blur approach or maybe get in contact with Lucas Duber : http://blog.duber.cz/misc/pixomondo-uses-duberpython-in-their-3ds-max-pipeline
Cheers,
-Johan
If all you need from 3dsmax is opening/saving files, perhaps you could launch your tool as a standalone process and communicate with maxscript via TCP methods as JonadB demonstrated in this thread, or other cross-process methods.
Yea we know all about the Max.Net thing, we have long relationship with Marsel from Ephere, and we’re in all the Beta programs…
I don’t see any benefit to my needs, by purchasing a proprietary IronPython implementation (even if putting aside the fact that’s it’s gonna get into max built-in in the future anyways…)
As I would like to reuse what I’ve already written in C++ for Mudbox and Maya, in 3ds-max also. If I go the python root, it would make much more sense converting my Qt-based C++ code into PyQt, and use it that way in Maya and 3dsMax (using blur’s py3dsmax), and maybe in the future – Fusion and Nuke. Long-term-wise, that is the best approach.
Rewriting from scratch into a .Net framework, makes no sense to me, from any angle…
Not for short term, and definitely not for long term…
The IronPython rout makes even less sense…
It’s .Net AND python… It’s not portable to applications that have no .Net…
Even staying in C++ Qt makes more sense then that, application-portability wise…
I am looking for a way to re-use the Qt-based C++ code in a 3ds-max plugin, and loading up the Qt-UI inside 3ds-max.
Anyone knows if this is possible?
As for external-interfacing, it has too many caveats…
what happens if an instance of 3ds-max crashes?
What happens when we start launching multiple instances of 3ds-max on the same machine, as we regularly do…?
And on-top of that, it’s not integrated into the UI – you can’t dock it – it looks foreign to the application…
I believe there are ways around it…f or example, you could hold a reference inside your external process to the instance to the 3dsmax process from which it was started, and force something like docking using win32 calls.
I’m not saying these solutions are simple or elegant, or that this is definitely the way to go in this case, but just that it might technically work.
Yea, well, it might be technically plausible, but I have to way all angles, pros and cons, for each approach against the others to get a well rounded decision.
So far, it doesn’t look promising…
10x for the tip, though…