Maya Station

Okay, I loaded my Plug-in, now what?

I got this great question the other day, it may seem simple however that is what is so great about the question.

Everyone thinks it's so simple that no one ever writes about it!

What do you do in Maya once you use the Plug-in Manager or the MEL command loadPlugin to load your plug-in.

Once you have loaded your plug-in, shhh, this is the part no one tells you, you still have to create your node in the scene!

To do this you can use the MEL command ‘createNode {nodename}’ so for example to create any Maya default node you could do this:

 createNode Transform;

Here we are creating a standard node that comes with Maya (there are hundreds), the name of the node matches the node name in the documentation under Nodes and Attribute Reference, which you can access from the standard help documentation that comes with Maya:

But you can also use this createNode for custom nodes that you creating using the Maya API. Let’s say you have compiled the Devkit sample ‘pnTrianglesNode’, you would do this after loading the plug-in:

 createNode pnTriangles;

One you run this command, the node is now actually in your Maya scene, and will be saved there on scene save. From here you just need to connect other nodes to this node in your scene.

Also, the other way to create nodes in the API is to use the class MDGModifier, there is a method there called createNode.

~Kristine

Retrieve polygon components in the order they are selected

Maya 2012 provides a feature that allows a selection of polygon components to be retrieved in the order they were selected. This is in addition to the sorted selection that you may be more familiar with. 

In order to perform a selection-order query on your polygon components, you will need to first enable the "Track selection order" setting in Settings/Preferences > Selection.

 

Then you can use the flag -orderedSelection in your query to list the components in the order they were selected:

ls -orderedSelection;

Note that if the option "Track selection order" is disabled this command will return a sorted list, and the result will be the same as if you were using ls -selection;

Thanks to Tim Fowler for pointing this out, as I'd completely missed this feature when Maya 2012 was released.

Owen

 

Blendshapes in Maya 2012 : new features

There are new attributes for blendshapes in Maya 2012:

 

Base weight

A new set of component weights have been added. These weights multiply the various target weights, allowing the user to quickly paint out regions where no target has an effect.

The base weight is an overall multiplier for the targets.

Therefore a zero weight on the base would mean no targets (regardless of their weights) have any effect.

A base weight of 1.0 (the default) would act normally, a weight of 2.0 multiply them by two, -1..., etc.


Normalization group

The blendShapes targets can now be assigned a 'normalization group'. Targets in the same group have the sum of their weights normalized to 1.0 when editing via the Component Editor or the Paint Blend Shape Weights tool). Optionally each group may also use an extra set of weights to include in the normalization calculation. These weights are associated with the group itself, not any particular target.

The normalization weights appears in a new columns in the Component Editor and as new paintable targets in the Paint Blend Shape Weights tool once it is created via the Edit Deformer -> Blendshape -> Edit Normalization group .

A couple of useful procedures for finding related Proxy references

If you have Proxy references in a scene it can be tricky to find which ones are related.

Maya 2012 : HIK menus and MEL commands (part 1)

With Maya 2012 the HIK menus and windows have been revamp.  Here are some of the most needed MEL commands to use the tools without going through the UI

The basic thing to know is that you need to set the current character in order to affect it, this is done by:

To set the current character

//in this example I am setting Character 2

$gCurrentCharacter = "Character2";
refreshAllCharacterLists();

Once the character is set, we can use it with these commands

Locking the Character definition
characterizationLock();

Creating a new Characterization
characterizationCreate();

Creating a ControlRig
characterizationControlRigCreate();

Deleting a Control Rig
characterizationControlRigDelete();

Using the skeleton generator
skeletonGeneratorToolNewCharacter;

Setting the source for a HumanIK character
//to control rig
mayaHIKsetRigInput( "Character1" ); updateHIKCharacterToolEnableCheckBox();

//to stance pose
mayaHIKsetStanceInput( "Character2" ); updateHIKCharacterToolEnableCheckBox();

//to set to a character input
mayaHIKsetCharacterInput( "Character1","Character2" ); updateHIKCharacterToolEnableCheckBox();

Choosing a keying mode, i.e. full-body, partial, or selection
//full body
optionVar -intValue keyFullBody 1; setKeyingMode( );

// body parts
optionVar -intValue keyFullBody 2; setKeyingMode( );

//selection
optionVar -intValue keyFullBody 3; setKeyingMode( );

Turning on and off pinning for individual effectors
//Here I am Character1_Ctrl_RightWristEffector as the effector

//unpinned
setAttr "Character1_Ctrl_RightWristEffector.pinning" 0;

//pin Translate
setAttr "Character1_Ctrl_RightWristEffector.pinning" 1;

//pin Rotate
setAttr "Character1_Ctrl_RightWristEffector.pinning" 2;

//pin all
setAttr "Character1_Ctrl_RightWristEffector.pinning" 3;

Baking the retarget to the control rig or skeleton
//Bake to Skeleton without opening the options
hikBakeToSkeleton 0;

//Bake to Skeleton with opening the options
hikBakeToSkeleton 1;

//Bake to Control Rig without opening the options
hikBakeToControlRig 0;

//Bake to Skeleton without opening the options
hikBakeToControlRig 1;

Managing Custom MEL Scripts and Plug-ins in a Production Environment || Part 3

Managing numerous and complex MEL scripts and plug-ins can become difficult and inconsistent in production environments. The following steps will ensure that your MEL scripts get sourced and your plug-ins will get loaded without error and with consistency throughout your production environment.

3) Dealing with loadPlugin and the commands from the plug-in:

In this situation the userSetup.mel has MEL code like the following and gives you errors.

loadPlugin A;
source "B.mel";
someCommandFromThePluginA();

(someCommandFromThePluginA which is sitting inside B.mel that is recognized only when the plugin A is loaded.) ...and you later run the command which comes from the B.mel file. It fails if it references anything from the plugin 'A'.

The solution is:

loadPlugin A;
evalDeferred("source \"B.mel\"");
someCommandFromThePluginA();

The eval causes the eval'ed string to be compiled at runtime. By that point the plug-in is loaded and available. MEL considers source statements as compiler directives, so they are handled before the script is even run. The only way to get around that is to wrap the source statement in an eval.

Another working example of this would be:

string $plugin = "/usr/aw/maya5.0/bin/plug-ins/Mayatomr.so";
loadplugin($plugin);
int $ret=0;
while ($ret == 0)
    {
    $ret = `pluginInfo -q -loaded $plugin;`
    }
eval ("Mayatomr -mi -file " + $inFile + " -perframe 2 -padframe 0
-tabstop 8");

The loadPlugin and evalDeferred execute right away in batch mode since there is no such thing as "idle" in batch mode.

You can NEVER load a plug-in and expect to be able to use a command from that plug-in directly in the same .mel file.

So does it mean that for the most part, loadPlugin is a trivial to the point of being a "useless" MEL command? Well...not quite. Most people write wrapper scripts to load the plug-in and then call something else.

In apiAnimCurveTest.mel try something like:

global proc int
apiAnimCurveTest ()
    {
    string $soName = "apiAnimCurveTest";
    if (`exists Win32Init`)
        {
        $soName = $soName + ".mll";
        }
    else
        {
        $soName = $soName + ".so";
        }
    // Make sure we can load our plugin
    //
    if (!`pluginInfo -query -loaded $soName`)
        {
        if (catch (`loadPlugin $soName`))
            {
            print ("### apiAnimCurveTest: Fatal error (startup): unable to load
" + $soName + "\n");
            return (1);
            }
        }

    // Force apiAnimCurveTestReal.mel to be reparsed by mel
    //
    eval ("source apiAnimCurveTestReal.mel");

    int $errors = eval ("apiAnimCurveTestReal");

    return ($errors);
    }

And then apiAnimCurveTestReal.mel can use the plug-in commands:

global proc int
apiAnimCurveTestReal ()
    {
    string $soName = "apiAnimCurveTest";
    if (`exists Win32Init`)
        {
        $soName = $soName + ".mll";
        }
    else
        {
        $soName = $soName + ".so";
        }

    // Make sure our plugin has been loaded
    //
    if (!`pluginInfo -query -loaded $soName`)
        {
        print ("### apiAnimCurveTest: Fatal error (startup): unable to load "
+ $soName + "\n");
        return (1);
    }

    // Create some animation
    //
    apiAnimateAnObject;

    return (0);
    }

Managing Custom MEL Scripts and Plug-ins in a Production Environment || Part 2

Managing numerous and complex MEL scripts and plug-ins can become difficult and inconsistent in production environments. The following steps will ensure that your MEL scripts get sourced and your plug-ins will get loaded without error and with consistency throughout your production environment.

2) Adding another global proc to the end of the file:

If you want to add another global proc in the SAME file and make sure that it is available just like other global procs your testProc.mel should look like this:

proc proc1()
{
print ("\n proc1");
}

proc proc2()
{
print ("\n proc2");
}

global proc testProc()
{
print ("\n testProc");
proc1;
proc2;
}

global proc testProc1()
{
print ("\n testProc1");
testProc;
proc1;
proc2;
}

If you try to call testProc1 after starting a new session of Maya, it will not be recognized. One way to fix this is to source the file. This will make all the global procs in that file available. What you do is:

# Add this line inside your userSetup.mel:
source testProc;

2a) However this defeats the purpose of having the automated system of making
available all the global procs sitting in the files that are in MAYA_SCRIPT_PATH.
So, the following will work even without the source statement in the userSetup.mel:

proc proc1()
{
print ("\n proc1");
}

proc proc2()
{
print ("\n proc2");
}

global proc testProc1()
{
print ("\n testProc1");
proc1;
proc2;
}

global proc testProc()
{
print ("\n testProc");
testProc1;
}

The above will work even without the source statement. Notice that although there are 2 global procs in the same file, testProc is still the top proc in terms of hierarchy since the flow of control goes like: testProc --> testProc1 --> proc1, proc2. Again, the order DOES MATTER.

2b) Another way of doing this would be:

proc proc1()
{
print ("\n proc1");
}

proc proc2()
{
print ("\n proc2");
}

global proc testProc2()
{
print ("\n testProc2");
testProc1;
proc1;
proc2;
}

global proc testProc1()
{
print ("\n testProc1");
proc1;
proc2;
}

global proc testProc()
{
}

Now call the testProc from inside the userSetup.mel by adding the line:

testProc;

Just calling the blank proc will make all the other global procs inside the testProc.mel available to you. But you will run into errors if you try to call the testProc1 BEFORE calling testProc.

dockControl part 2: adv. usage

Today, I ‘m going to expand on the blog post that Owen wrote about the new dockControl command in Maya 2011 and look at some more advanced examples of its usage.

Mainly delete the UI when it becomes hidden, a look at the different methods, adding multiple windows and adding them to layouts.  

Delete the docked window when it is invisible

The first problem that will be obvious to users, is that once we create a docked generic window with the dockControl, you lose the ability to bring up that window even after the docked one is closed.

Example:  
You can easily create a docked window with the dockControl. For example, this brings up the script editor docked on the left:

dockControl -area left -content scriptEditorPanel1Window owensScriptEditorDC;

The problem with this approach is that if I close the docked script editor, I won't be able to open the script editor with the main menu (I'll get // Error: line 1: No window found. /).  

Using that little cross to close the window doesn’t actually delete the UI, it hides the window.  And as we all know, Maya doesn't like multiple Outliner or Script editors… so it’s important to delete the UI so you can open the UI again later.

To do that, you use the –vcc (visibleChangeCommand)  and the –io (isObscured) flag to query when the window is obscured and then delete it with the deleteUI command:

$customOutliner = `dockControl -area "left" -content scriptEditorPanel1Window -vcc "if (`dockControl -q -io $customOutliner`) {evalDeferred \"deleteUI $customOutliner\";}"`;

Here the syntax is fairly similar except I am giving a name to the control, so I can delete easily afterwards.  Secondly and most importantly,  I am testing with a query when the window becomes obscured and once it is, delete it with the –vcc and the –io flag.  

Doing it this way is more scripting but it will make the Outliner useable in and out the dockControl.

Two ways to use the dockControl

You might all ready know there are two methods to using the dockControl.  The simple way is to create a window in the usual way, and then use dockControl instead of showWindow. .  

Here is an example of the first method:

$mywindow = `window -widthHeight 200 150 -backgroundColor 1.0 1.0 1.0 -t ""`;
$tabLayout_1 = `tabLayout -innerMarginWidth 5 -innerMarginHeight 5 -backgroundColor 1.0 1.0 1.0`;
string $panel = `outlinerPanel`;
string $outliner = `outlinerPanel -q -outlinerEditor $panel`;
dockControl -area left -content $mywindow ;

Here I have simply changed the showWindow command for the dockControl , and added the appropriate flag.

Second method:

The second way is to create the docked window first, and then parent a window underneath it.  This also means I have to create a tabLayout that is parented to the Maya Main window previously.

global string $gMainWindow;
$tabLayout_1 = `tabLayout -parent $gMainWindow `;
$dockedWindow = `dockControl -l "Custom Window" -allowedArea "all" -area "left" -content $tabLayout_1`;
OutlinerWindow;
control -e -p $tabLayout_1 outlinerPanel1Window;

Here, I create my docked window first, and “parent” a window underneath it.  This also means I have to create a tabLayout that is parented to the Maya Main window previously.

Clearly these two different approaches will give different results, although the first method is an easier concept, since it only involves changing the last line of the script, the second method is much more powerful.  I am actually editing the outliner window (with the –e flag) so the UI will persists when I do a File -> New Scene instead of giving me an ugly white empty area.

Creating multiple tabs with Maya windows

Using the second method, it becomes quite easy to add multiple Maya windows.

In this example, I create a tabLayout and add multiple windows to it.  I create a window with an Outliner and a Hypergraph, and I use the –label flag to name the window “Custom Window”.

global string $gMainWindow;
$tabLayout_1 = `tabLayout -parent $gMainWindow `;
$dockedWindow = `dockControl -label "Custom Window" -allowedArea "all" -area "left" -content $tabLayout_1`;
OutlinerWindow; control -e -p $tabLayout_1 outlinerPanel1Window;
HypergraphHierarchyWindow; control -e -p $tabLayout_1 hyperGraphPanel1Window;

Next saving this new UI in a layout to reuse it

Anyone that has played with the docked window will know that these are not “visible” in the layout editor.  Basically, Maya thinks of a layout as to what fits in the panel area, and since we are docking windows outside of it, this won’t work.

Off course, there is a way around this… with a neat little trick …

We know the layouts are saved in the userPrefs.mel.   For this example, create a layout with a specific name (here I called it SPECIAL) and then do a search in the userPrefs.mel to find the code associated with it.   You will get something like this:

panelConfiguration -label (localizedPanelLabel("SPECIAL"))
    -defaultImage ""
    -image ""
    -sc false
    -configString "global string $gMainPane; paneLayout -e -cn \"single\" -ps (.....)
    -ap true
        (localizedPanelLabel("Persp View"))
        "modelPanel" (....)

We can add a global procedure called by the configString to create our dock window.  So it will look like this :

panelConfiguration -label (localizedPanelLabel("SPECIAL"))
    -defaultImage ""
    -image ""
    -sc false
    -configString "CustomWindow; global string $gMainPane; paneLayout -e -cn \"single\" -ps (.....)
    -ap true
        (localizedPanelLabel("Persp View"))
        "modelPanel" (.....)


And off course, all we have to do now is to create the global proc and add it to the userPrefs.mel.  Simply add this at end of the scripts…

global proc CustomWindow ()
{    global string $gMainWindow;
$tabLayout_1 = `tabLayout -parent $gMainWindow `;
$dockedWindow = `dockControl -label "Custom Window" -allowedArea "all" -area "left" -content $tabLayout_1`;
OutlinerWindow; control -e -p $tabLayout_1 outlinerPanel1Window;
HypergraphHierarchyWindow; control -e -p $tabLayout_1 hyperGraphPanel1Window;
}

Managing Custom MEL Scripts and Plug-ins in a Production Environment || Part 1

Managing numerous and complex MEL scripts and plug-ins can become difficult and inconsistent in production environments. The following steps will ensure that your MEL scripts get sourced and your plug-ins will get loaded without error and with consistency throughout your production environment.

1) Recommended method for MEL scripting:

# Create several local procs in a .mel file.
# At the end of the file write one global proc that connects/calls to all these local procs.
# Name the global proc with the same name as that of the .mel file.
# Put the .mel file in one of the places listed under MAYA_SCRIPT_PATH.

The file testProc.mel should look like:

proc proc1()
    {
    print ("\n proc1");
    }

proc proc2()
    {
    print ("\n proc2");
    }

global proc testProc()
    {
    print ("\n testProc");
    proc1;
    proc2;
    }

Now keep in mind that the order does matter. If the global proc was at the beginning of the script then this will not  work. Notice that the source statement does not appear anywhere yet. This is the way most of the scripts that come with the Maya are written. Adding a new MEL file for every new global proc makes things predictable and reliable.

How much memory you have after opening a scene.

Ever wondered how much memory your file consume.
Use the following MEL while working on your file
 memory -sum;
you can use other flags such as -fm
memory -sum;
memory -freeMemory;

For more information please refer to the documentation under the MEL section.