S
Simon Eves
I am trying to write a Python module to embed the functionality of
Maya (the 3D modelling and animation application from Autodesk,
formerly Alias) for doing scripted scene manipulation and rendering
processes in Python.
I am aware of the CGKit project, which does this and a lot more, but
it is over-complex for our needs, and also does not work in the
context of a pure command-line Python script, only as an alternative
scripting language within Maya.
I am also aware that the next version of Maya (8.5) is reputed to have
Python integrated, hopefully both internally and externally as I am
trying to set up.
Since I'm impatient, and also love having my code obsoleted within
months, I'm still going ahead with doing it myself but have hit a
problem.
I have the code in two forms.
Firstly, a pure C++ module, which links with the Maya DLLs (this is on
Windows, before you ask) and provides three functions, one to
initialize the Maya engine, one to send it a command it it's
proprietary native scripting language, MEL, and a third to shut it
down.
An input script for this would be something like:
import maya
maya.initialize()
maya.mel("float $a = 1.234; print $a * 2;")
maya.cleanup()
I also have it in the form of an executable which embeds the Python
interpreter and implements the middle function as an internally
"added" module, doing the initialize and shutdown itself (sandwiching
the Python stuff). This version can either read in a script file and
pass it to PyRun_SimpleFile() or pass stdin to PyRun_InteractiveLoop()
to allow you to enter Python interactively just like python.exe.
An input script for this would just be the maya.mel(...) line, since
the rest is implicit.
In both cases, if I feed it an actual Python script file, then
everything works properly. The Maya engine fires up, and I can feed it
commands which it will execute, and it shuts down at the end.
However, also in both cases, if run interactively, if you send a
command to the Maya engine to perform a particular process, it does it
correctly, but the interactive interpreter is then broken. Whatever
you then type, even a blank line, results in a SyntaxError exception,
with the pointer pointing to the end of what you typed.
The process in question is telling Maya to load a plug-in (a DLL)
which is an application extension to render or export to the Mental
Images "mental ray" renderer. This is a fairly complex DLL which
itself is dependent on other DLLs, but that really shouldn't matter.
I then tried building the executable version of my code in Debug mode
against my own debug build of Python (I have tried 2.4.4, which is our
current user version, and 2.5, with the same result) and then IT WORKS
PERFECTLY!
If you've stayed with me this far, well done.
Anyone have any ideas what could break the interactive interpreter
mechanism like this?
Obviously I have no control over the behaviour of the Maya API
libraries or the mental ray libraries which are subsequently loaded,
so it could be that something is trashing memory somewhere. There is
no hard crash I can debug, though (especially since the problem
doesn't happen AT ALL with a Debug build).
Maybe I need BoundsChecker to trap it. Shame I can't afford it... <:\
Yours hopeful that I haven't bored you all to tears,
Simon
Maya (the 3D modelling and animation application from Autodesk,
formerly Alias) for doing scripted scene manipulation and rendering
processes in Python.
I am aware of the CGKit project, which does this and a lot more, but
it is over-complex for our needs, and also does not work in the
context of a pure command-line Python script, only as an alternative
scripting language within Maya.
I am also aware that the next version of Maya (8.5) is reputed to have
Python integrated, hopefully both internally and externally as I am
trying to set up.
Since I'm impatient, and also love having my code obsoleted within
months, I'm still going ahead with doing it myself but have hit a
problem.
I have the code in two forms.
Firstly, a pure C++ module, which links with the Maya DLLs (this is on
Windows, before you ask) and provides three functions, one to
initialize the Maya engine, one to send it a command it it's
proprietary native scripting language, MEL, and a third to shut it
down.
An input script for this would be something like:
import maya
maya.initialize()
maya.mel("float $a = 1.234; print $a * 2;")
maya.cleanup()
I also have it in the form of an executable which embeds the Python
interpreter and implements the middle function as an internally
"added" module, doing the initialize and shutdown itself (sandwiching
the Python stuff). This version can either read in a script file and
pass it to PyRun_SimpleFile() or pass stdin to PyRun_InteractiveLoop()
to allow you to enter Python interactively just like python.exe.
An input script for this would just be the maya.mel(...) line, since
the rest is implicit.
In both cases, if I feed it an actual Python script file, then
everything works properly. The Maya engine fires up, and I can feed it
commands which it will execute, and it shuts down at the end.
However, also in both cases, if run interactively, if you send a
command to the Maya engine to perform a particular process, it does it
correctly, but the interactive interpreter is then broken. Whatever
you then type, even a blank line, results in a SyntaxError exception,
with the pointer pointing to the end of what you typed.
The process in question is telling Maya to load a plug-in (a DLL)
which is an application extension to render or export to the Mental
Images "mental ray" renderer. This is a fairly complex DLL which
itself is dependent on other DLLs, but that really shouldn't matter.
I then tried building the executable version of my code in Debug mode
against my own debug build of Python (I have tried 2.4.4, which is our
current user version, and 2.5, with the same result) and then IT WORKS
PERFECTLY!
If you've stayed with me this far, well done.
Anyone have any ideas what could break the interactive interpreter
mechanism like this?
Obviously I have no control over the behaviour of the Maya API
libraries or the mental ray libraries which are subsequently loaded,
so it could be that something is trashing memory somewhere. There is
no hard crash I can debug, though (especially since the problem
doesn't happen AT ALL with a Debug build).
Maybe I need BoundsChecker to trap it. Shame I can't afford it... <:\
Yours hopeful that I haven't bored you all to tears,
Simon