Thursday, April 24, 2008

Thank you, Chris Evans!

It's nice to see the blogosphere actually helping people out, so if you
are another prisoner of python in Motion Builder, you might want to look at
Chris' very cogent example/tutorial on exploiting the telnet port
here

Love,
Wook

Tuesday, March 18, 2008

MoBuPy #8

Not so much a Python issue as a general Mobu issue.
I tend to leave Mobu up and running all day
(I have two machines side-by-side with 1 shared monitor),
and I find that Mobu tends to die an annoying
and horrible death within 2 to 24 hours.
Often it just decides to leap off to the low address range,
but right now it's just hung,
doing nothing (or as Windows puts it: 'Not Responding').
Other people seen this?

Saturday, March 15, 2008

MoBuPy #7 -- why does it soil itself?

I've noticed that MoBu at Qt don't appear to get along well.
It seems like every 4 to 6 times I run something under Mobu during the
debug cycle, MoBu is crashing.
Even without necessarily making any changes to the code.
I'm having to go the diagnostic print route while getting this
code to work, and it doesn't seem to matter how simple a scene,
or how minimally I've changed the code, after a while,
it just crashes Mobu.

7.5 ext 2 for those who care.

Tuesday, January 29, 2008

MoBuPy #6

Hey, were you wondering just how much Python sucks in Motion Builder?
Try this, in either Python, or Idle:

>>> import time
>>> time.strftime("%D %T", time.localtime())
Now try the same thing in Motion Builders Python window,
but do it without anything
important (or time consuming) loaded...for me,
it blows up (Unknown software exception
(0xc00000d) occurred in the application at location 0x78148b5

Thank g_d they have an easily scrolled and searchable
output window -- oh wait, they don't...

...well, at least time.ctime() works...

Thursday, January 24, 2008

MoBuPy #5

LoadBegin takes 2 arguments: a filename, and a 'merge' boolean;
Strangely enough: setting merge to False doesn't wipe out story information
(like existing character tracks), but setting merge to True does.

Oh MoBu, why dost thou screw with me?

To recap:

mgr = FBFbxManager()
lbv = mgr.LoadBegin(filename, False) # Really merge, don't trash existing data
set anim/elem states if any
lv = mgr.Load()
ev = mgr.LoadEnd()

If any of lbv, lv, or ev is False, this didn't load...

Wednesday, January 16, 2008

MoBuPy #4

1) ProcessNamespaceHierarchy doesn't work as far as anyone on the web can determine;
2) This means that if you want to do what it does, you have to do your own recursive
descent of the models, rig models, and effectors AFTER you get them by index and
individually ProcessObjectNamespace them

Thursday, January 03, 2008

MoBuPy #3

Since sys.exit(any) causes all of MotionBuilder to shut down,
is there any quit method that gets you back to
the Python Console top level?

One can always just 'raise RuntimeError', but it's pretty ugly...

Also, FBMessageBoxGetUserValue always treats the
second button as the abort case,
so if a user updates the value of the text,
it reverts to the originally
supplied (default) text before it returns.

This is anti-helpful.

MoBuPy #2

Well, Python in Motion Builder is a joy to work with.
And No, I don't really mean that.
Say you have a library, let's call it 'mobu'
(which you've written to hide some of the
C++ knowledge/complexity resulting from the swig interface)
that lives in someplace a little off the
beaten path (ie: not in the default PYTHONPATH),
so normally, our client app would
have the following:

import sys
mobu_home = 'z:\net\libdir'
sys.path.append(mobu_home)

import mobu

. . .

Well, this has two unfortunate side effects:
1) every time you drag this client script in,
sys.path will have mobu_home appended to
the end of your sys.path -- go ahead,
bring up the python window, print sys.path after
each time you drag this in...
it's fun to watch it grow endlessly...

2) It doesn't necessarily get the latest (current)
version of the library (I do cross platform
work -- I edit/test (when I can) on a linux
system on the network, and then run apps on
a windows system that has nfs mounted the
target directory where the library lives).
I don't think this is a Windows or NFS problem,
because the following workaround appears
to alleviate the problem(s):


import sys
mobu_home = 'z:\net\libdir'
# Only extend sys.path if we have to...
if mobu_home not in sys.path: sys.path.append(mobu_home)

import mobu
reload(mobu)
# This has to happen every time, otherwise the Python instance in mobu thinks the copy it
# loaded last time is still current
# The good news is that the 'if' above should speed things up in the course of a long session