eduardo simioni

Tag: howto

right click signal in PyQt/PySide

by on Jun.10, 2014, under Maya, MotionBuilder, pyqt, pyside, python

It’s extremely easy, if you know it’s called customContextMenuRequested:

As for example:

btnLeft.customContextMenuRequested.connect( lambda: self.RMB(btnLeft, oModel) )

It also has QPoint as default value returning the pixel where right click/contextMenu was requested:

btnLeft.customContextMenuRequested.connect( self.asd )

def asd(self, pos)
    print pos
Leave a Comment :, , , , , , more...

creating a dynamic menu system in Motionbuilder

by on Feb.16, 2014, under GUI, MotionBuilder, pipeline, python

There are two main tricky parts in doing this:

1) Organizing your tools
2) The event function

Prior to face this sort of task you need to be aware of the concepts explained on the previous post, python modules and import system and have a very very very good understanding of FBMenuManager.

Organizing your tools

In short, there are two ways of accomplishing this. One is having each menu entry as a simple .py script which is executed with execfile(), the other is to think of each tool as a module/folder. If you want to group stuff into different menus, it helps to think of each menu as a different empty module/folder as well.

So let’s suppose you want a menu structure inside Motionbuilder like this:

  • Scripts
    • Cinematics
      • Mocap Cleaner
      • Mocap Destroyer
    • Gameplay
      • Import Tool
      • Export Tool
    • Generic
      • Animate_Everything
      • Fix_Animation

Cinematics, Gameplay and Generic are the main menus, and they show on the right of “Help”. Mocap Cleaner, Mocap Destroyer, Import Tool, Export Tool are (imaginary) full featured tools, each one in its own folder with multiple files. Animate_Everything and Fix_Animation are simple .py scripts, and they are grouped in one single folder. Like this:

Files organization

The Generic scripts is quite simple to do and it’s covered down below. The way I did for full featured tools though is, obviously, creating one menu entry for each folder inside the Scripts folder. Each of these “menu folders” had a (see below in initialization) with some variables describing their content and would become a main entry besides the “Help” menu. Each folder would then be added to sys.path and create one of these data structures:

class MenuData():
    This stores all necessary information for one new menu to be constructed it`s sub menu items.
    def __init__(self, sMenuName, sFullPath, mMenuModule):
        # menu information
        self.sMenuName   = sMenuName
        self.mMenuModule = mMenuModule
        self.sFullPath   = sFullPath
        # actual FBGenericMenu object for the menu
        self.oMenu       = None
        # the key one, list of tools in tuples, 0 is name, 1 is module or full script path (for generics)
        self.lmTools     = []

So you end up with a list of MenuData’s, one for Cinematic, Gameplay and Generic. Now you need to create the actual FBGenericMenu for each folder. You could simplify this into one single for loop, if you have all tools into the Scripts root you could even do away with the MenuData (which is to create one menu per folder), but I wanted to do something generic and support many different outcomes so I was doing it in two loops described below.

Initializing Tools:

For each MenuData I look for each subfolder (Scripts/Gameplay/Import, Scripts/Gameplay/ExportTool for example) and save each module (present in this subfolder) into MenuData.lmTools. The tricky part is how to do this:

for oMenu in listOfMenuData:
    lDir = os.listdir( oMenu.sFullPath )
    for sPath in lDir:
        sMenuPathWithSubFolder = oMenu.sFullPath + "/" + sPath
        if os.path.isdir( sMenuPathWithSubFolder ) and os.path.isfile( sMenuPathWithSubFolder+"/" ):
            module = __import__( sPath )
            oMenu.lmTools.append( (sPath, module ) )

Line 6 works because each “Menu/Module” path was added to sys.path, so you can easily import each tool without its entire path. The important line though is the last one. It adds a list of tools to MenuData.lmTools with a tuple that contains (“string to the tool module”, “the tool module itself”). And here is why you need to add the menu folder to sys.path. You could still get the tool module with other means, but by having Gameplay in sys.path you can do import ImportTool on other tools and share code between them.

On the tool folder you need a so python can import that as a package. You can (or need) to put variables in there, so the menu system can create the proper menu entry for the tool (to use a custom name, for example). This is an example of what I’m using on /Scripts/Gameplay/Destroyer/

sToolFullName = "Mocap Destroyer"
sStartFileToImport = "destroyerDialog"
sCustomFunction = "mainUI()"

It is important that there’s no code running in this __init__. This file is loaded and ran during Motionbuilder startup, so if there’s something crashing in there the entire menu system won’t load (unless you don’t trust your colleagues and populate it with try/catches).

And here is where python magic happens. Once you loaded the module in MenuData you can access all the contents from that with for example:

print oMenu.lmTools[1].sToolFullName
print oMenu.lmTools[1].sTartFileToImport

And this feature you will need to use on the next two steps.

Create menu entries

You haven’t created anything yet because you need to know WHAT to create. That’s why I was importing each tool before actually creating FBGenericMenuItems. This way the title of the menu item can be set on the tool itself, instead of relying on a separate file altogether.

But when dealing with FBGenericMenu is best to just use code instead of describing it:

oMenuMngr = fb.FBMenuManager()
for oMenu in listOfMenuData:
    # FBGenericMenu
    oMenuMngr.InsertLast( None, oMenu.sMenuName )
    oFBMenu = oMenuMngr.GetMenu( oMenu.sMenuName )
    oFBMenu.OnMenuActivate.Add( EventMenu )
    oMenu.oFBMenu = oFBMenu

    # create menu contents (MenuItems) for tools
    print ('create tool: '+ oMenu.sMenuName)
    for i in range(len(oMenu.lmTools)):
        oTool = oMenu.lmTools[i][1]
        if hasattr( oTool, 'sToolFullName' ):
            sName = oTool.sToolFullName
            sName = oMenu.lmTools[i][0]
        oFBMenu.InsertLast( sName, i ) # you need the "i"ndex for the event function below (although you could use a string instead)

As you can see, a FBGenericMenu is stored in MenuData.oFBMenu. You will need it for the EventMenu function. After that we just iterate through each stored module, creating a menu entry for each one. If the module has a sToolFullName, we use that one for the menu entry, otherwise we use its folder name.


All menu entries call just one function. You don’t want to generate a new function for each menu entry, otherwise you will end up with some heavy meta-python coding. And you shouldn’t need to. EventMenu is called with two variables, control and event. Control is the actual FBGenericMenu that was clicked. Event.Id has the index which you used to add that menu entry, last line of the code snippet above. You also have a Event.Name, which is the actual string being displayed in the interface. With this cards in your pocket you can do this:

def EventMenu( control, event ):
    Runs the script selected from the menu. Each menu entry has a corresponding tool __init__ialized (but not loaded in memory)
    This is stored in MenuData.lmTools[1], and it should have variables/attributes point what should be imported and
    how the tool should be executed. Defaults to main() in /Scripts/MENU/TOOL/
    #print control, event.Id, event.Name

    # find which menu was clicked and get it's MenuData from loMenus
    oMenu = None
    for oTM in loMenus:
        if control == oTM.oFBMenu:
            oMenu = oTM

    sToolName = oMenu.lmTools[event.Id][0]
    oTool     = oMenu.lmTools[event.Id][1]

    # no sStartFileToImport, so we file to import is with same name as folder, as in: /Script/Tool/
    if not hasattr( oTool, 'sStartFileToImport' ):
        sModule = oMenu.sMenuName+"."+sToolName+"."+sToolName
    # with sStartFileToImport, so we have /User/Script/Tool/
        sModule = oMenu.sMenuName+"."+sToolName+'.'+oTool.sStartFileToImport

    #print "Importing:\n{0}".format(sModule)

    # if it doesn't have sCustomFunction we run main()
    if not hasattr( oTool, 'sCustomFunction' ):
        sModuleFunction = sModule + '.main()'
    # otherwise, we run the named function
        if oTool.sCustomFunction.find('(') == -1:
            sModuleFunction = sModule + '.' + oTool.sCustomFunction + '()'
            sModuleFunction = sModule + '.' + oTool.sCustomFunction

    #print "Evaluating:\n{0}".format( sModuleFunction )
    eval( sModuleFunction, sys.modules )

First, we find which main menu (the ones beside Help) the “click” happened, by comparing all MenuData.oFBMenu to control. Once we have the MenuData, we have a list of tools inside, which we can quickly fetch with event.Id, since they were added in order and each have its own unique id. Another option would be to compare strings, trying event.Name in a list of tool names, but since we allow tools to have sToolFullName and comparing string is lower than using an index directly, index is better. This is the shitty FBMenuManager part, if you don’t get how this is working you need more time playing with FBMenuManager, FBGenericMenu and FBGenericMenuItem (and/or I haven’t worded it very clearly).

Once we have the actual tool module (/Scripts/Gameplay/ImporterTool/ we can run the actual tool. I wanted to add some flexibility, so I allowed sStartFileToImport variable in the folder, which points to the actual python file that will be imported. If this variable doesn’t exists, it will try to import a python file with the same name as the folder.

Now though is when python import magic actually gets in the way.

Python “import” command runs the imported script just once. When you do import again, it’s not re-evaluating the imported code. Even if you changed the script locally, you need to do reload module instead, which can cause a series of other problems.

Instead of making self-running scripts, I wanted to also add the flexibility for a function to be called for the tool to start (say you want to run something based on selected objects, for example). That’s why it’s also checking for a sCustomFunction variable. If there’s none, it will use just run (sModule + ‘.main()’).

Lastly, it does eval. Which runs said function.

Generic menu

For the generic menu, instead of loading a module I just save the path for the script in MenuData.lmTools[(“script name”, “full path for script”)] and run them with:

execfile( oMenu.lmTools[event.Id][1], {} )

You will just need to add something in /Scripts/Generic/ (like isGenericMenu=True) so you know that that folder is a generic menu and should run another exec procedure. The empty dictionary {} at the end is to specify a new empty set of locals and globals, otherwise you get scope problems when running scripts without functions.

Leave a Comment :, , , , , , , , , more...

installing python modules on Motionbuilder

by on Feb.25, 2011, under MotionBuilder

It’s quite straight forward, once you have the correct package. Here is two places worth looking for 64 bits modules:

If you install the module it rests under C:\Python26\Lib\site-packages. You just need to copy it to a sys.path from Motionbuilder’s python. A good choice is: C:\Program Files\Autodesk\Autodesk MotionBuilder 2011 64-bit\bin\x64\python\lib\plat-win

Leave a Comment :, , , more...

retargeting animation, howto/tutorial/whatis

by on Feb.06, 2011, under Uncategorized

I think a couple more words for new animators might be helpful.

Retargeting is just the process of “copying” the animation from one skeleton to the other. As you probably know, the simple cut and paste of keyframes between characters do not work. The joints might have different names, might have different rotations, different zeroed rotations, positions, etc etc. Some real time engines are able to do this with very strict rules of how the skeletons must be made, most of the time the difference are just and only the proportions, where just the rotation of the joints (except the root node) are used between skeletons that are mostly equal.

When characters have different skeletons, even with different hierarchies, you have to use some sort of tool, like Motionbuidler. The way it does is to have two characters in the scene, and copy it from “one control rig to the other”. If you haven’t, you should familiarize yourself completely with Motionbuilder’s characterize tools, since they are essential to fully use the software. Characters in Motionbuilder can have many inputs, like an Actor from mocap software, the control rig, which is used to animate or edit the animation of a skeleton, or another character, to “retarget” the animation from this character to the current one.

Getting into more detail, to do this, you import or merge both skeleton hierarchies into one scene. You characterize each one of them, correctly. They need both to be on tpose, and ideally should have all their bones above ground (above 0 y). Refer to Motionbuilder help for this, it’s thoroughly explained there. And this is one of the tricky parts, to use the retargeter script, each animation to be imported must be on tpose on frame 0. You don’t actually need to create a control rig for each one of them, after both are characterized, you just need to select the input type of the new character to the old character, and activate it. Animation on both characters should then be synched, regardless of differences in hierarchies or proportions.

The retargeter script just automates this process, loading a folder containing .fbx or .bvh animations over the new character. It does characterize the animations if needed, but they need to follow either Motionbuilder nomenclature or 3dsMax Biped to be correctly characterized. If they are not, you can just edit the Motionbuilder one inside the script, changing the right column to match the names on your skeleton. You don’t need to change all of them, just the ones present on your skeleton (if you don’t have finger animations don’t bother, for example).

You can, for example, get all or some of the 2600+ mocap files from Carnegie Mellon University Motion Capture Database at, which has .bvh’s and .fbx’s with a tpose on frame 0, and with the retargeter script quickly retarget them over your character.

2 Comments :, , , , , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!