Maya Station

Free Maya API and 3ds Max SDK 2 Day Training in St Petersburg, Russia

The Autodesk Developer Network (ADN) will be hosting a free 2 day Maya API and 2 day 3ds Max SDK training sessions in St. Petersburg, Russia on May 22^nd, 2012 and May 23^rd, 2012.

This unique opportunity allows you to dive into the inner workings of our software, and come out with a strong fundamental knowledge of the architecture. You will see and understand how you can utilize and benefit from the API’s/SDK’s of these powerful software’s.

1. Maya API (Python) - registration
2. 3ds Max SDK -registration

To register and view the course schedule, please look here:

http://www.adskconsulting.com/adn/cs/api_course_sched.php

Working with Internal Data Using setInternalValueInContext

When writing an MPxNode which stores data internally using setInternalValueInContext that is connect to another node. Everything will work well until you save the scene and re-load the scene. It seems you have to force an update of the attribute of your node with a refresh, such as displaying the Attribute Editor.

The reason for this is the value that is maintain for an internal attribute is only used when the attribute does not have an incoming connection. If the attribute has an incoming connection then the connection determines the value of the attribute and your node has no say in the matter. To handle this, use MPxNode::connectionMade() and MPxNode::connectionBroke() to maintain a flag telling you whether the attribute is currently connected.

In Python, that would look something like this:

class myNode(maya.OpenMayaMPx.MPxNode):
         myNode.myAttr = maya.OpenMaya.MObject()

         def __init__(self):
                 self.myValue = 0.0
                 self.myAttrIsConnected = False

         def connectionMade(self, myPlug, theirPlug, iAmSrc):
                 if not iAmSrc and myPlug == myNode.myAttr:
                          self.myAttrIsConnected = True
                 return ompx.MPxNode.connectionMade(self, myPlug, theirPlug, iAmSrc)

         def connectionBroken(self, myPlug, theirPlug, iAmSrc):
                 if not iAmSrc and myPlug == myNode.myAttr:
                          self.myAttrIsConnected = False
                 return ompx.MPxNode.connectionBroken(self, myPlug, theirPlug, iAmSrc)

In the compute(), check the flag. If it's true then update the internal value from the datablock before using it:

         def compute(self, plug, block):
                 if plug == myNode.someOutputAttr:
                          if self.myAttrIsConnected:
                                   self.myValue = block.inputValue(myNode.myAttr).asFloat()

If you need the internal value outside the compute() then write yourself a helper method which gets the value from a plug when the flag is set and call that method as needed:

         def get_myValue(self):
                 if self.myAttrIsConnected:
                          plug = maya.OpenMaya.MPlug(thisMObject(), myNode.myAttr)
                          self.myValue = plug.asFloat()
                 return self.myValue

Free Autodesk Media & Entertainment API/SDK Webcast Trainings

Free Autodesk API/SDK Webcast Trainings

The Autodesk Developer Network (ADN) is offering free Maya API, 3ds Max SDK, MotionBuilder SDK and FBX SDK webcast trainings. This unique opportunity allows you to dive into the inner workings of our software, and come out with a strong fundamental knowledge of the architecture. You will see and understand how you can utilize and benefit from the API’s/SDK’s of these powerful software’s.

1. Maya API (Python)
2. MotionBuilder API (Python)
3. 3ds Max
4. FBX (C++)

To register and view the course schedule, please look here:

http://www.adskconsulting.com/adn/cs/api_course_sched.php

For specific course agenda’s go here:

http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=785271

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

Global Symbol Evaluation

Are you working on Linux?

Have you ever seen a file with this *.sog extension in your plug-in directory?

Ever wonder what it is?

It is possible to force plug-ins to export their symbols by putting an additional file, with the same name as the plug-in with the extension '.sog' in the directory with the plug-in. This would cause the plug-in to be dlopened using the RTLD_GLOBAL flag.

The .sog extension is our own indication that a plug-in should be loaded with extra loader options.  The RTLD_GLOBAL flag.   Normally we don't set this flag so any functions will be known to the plug-in itself and not pollute the global name space.

Normal plug-in loading:

• pluginName.so

To load a plug-in with RTLD_GLOBAL flag included:

• pluginName.so
• pluginName.sog

The ending ‘g’ meaning global.

You need both files.  The .sog is there for existence only - can be a zero length file.

They should ensure the other plug-in that exports its functions has a .sog file to match that plug-in so it is loaded with global scope.

The presence of a .sog file will enable the plug-in symbols to be available for other plug-ins to use.

Cheers,

Kristine

Exporting Hair Geometry

If you are writing an exporter plug-in and want to add support for exporting hair geometry data (much like the mayatomr functionality). At first glance there does not seem to be any API functionality for hair other than collision solving via MHairSystem, which does not give access to the hair data. To access the hair geometry scalar data (per-hair and per-vertex data) use MFnPfxGeometry::getLineData() and then use MRenderLineArray and MRenderLine to get at the per-vertex data. For other data, you’ll have to access the attrs on hairSystem or pfxHair node directly.

To elaborate the actual hair geometry is represented in the pfxHair node (which is connected to the hairSystem node when paint effects output is used). This derives from the base class pfxGeometry which is also used for stroke and pfxToon nodes.  To get the hair geometry one can use the call  MFnPfxGeomtry::getLineData for the pfxHair node. (Note that if one used curve output instead of pfx output on the hair system, then one could simply access the set of output nurbs curves on the hair system, but as this is rather obvious I’m assuming they want the pfxHair data)

One thing worth noting is that your exporter would also potentially work (to some degree) for paint effects strokes and Maya toon lines, in addition to hair, because they all share the same base class.

~Kristine

Viewport 2.0 API White Paper

For anyone looking for more information on the Viewport 2.0 API that was introducted in Maya 2012, I posted a White Paper here, (this page is also a great resource for API items):

www.autodesk.com/developmaya

but a direct link to the whitepaper is here, which is a collaboration from the rendering team, authored by Matthew Lausch, Autodesk:

http://images.autodesk.com/adsk/files/viewport_2_0_api_gold.pdf (updated pdf)

Here is the Introduction for users doing Google searches:

Maya 2012 introduces a new set of API classes for defining custom drawing, shading and effects in both Viewport 2.0 and Hardware Renderer 2.0 (the new batch rendering version of Viewport 2.0).

Maya’s Viewport 2.0 represents a brand-new rendering architecture in Maya that has been written from the ground up to deliver high-performance on large scenes on top of a programmable shader system offering high-quality per-pixel lighting and effects. This, unfortunately, makes it incompatible with many of the existing Maya API classes, due to their dependence on system memory geometry data, C++ driven rendering, and high state switching overheads. As a result, most existing plugins will need to be updated to support the new API classes in order to work correctly in Viewport 2.0.

This document introduces the new classes and highlights the migration paths from the old API to the new one. In most cases, it should be possible to write plugin nodes that simultaneously implement both the new and old APIs where required, thus maintaining a single plugin that will work in both viewports while artists, tools and pipelines are migrated to Viewport 2.0.

~Kristine

Viewport 2.0 and API Introduction

One of the most important and the biggest changes of the last release (Maya 2012) was Viewport 2.0.  I want to take this opportunity to provide you some additional information on the new Viewport 2.0 API. Previously in Maya if you had several high polygon models and you were trying to manipulate those models, Maya sometimes could behave slowly.

Viewport 2.0 is a brand new rendering system it is based on an internal technology by Autodesk. By using this new architecture, we are trying to replace all the old rendering system. As you can see this is a fundamental architecture change. The purpose of the change is to have high performance when rendering large complicated scenes. Viewport 2.0 is much faster compared to the old viewport. Keep in mind when importing this new technology, we have dramatically changed the way shading and rendering works in Maya.

Viewport 2.0 provides a programmable shader system allowing you more flexibility with customization. You can customize a shape, a shader, or a rendering process; it’s all possible with this new system. This new rendering system includes a new viewport 2.0, but also includes a batch version called Hardwar Renderer 2.0. In Maya 2012 there are a lot of new classes in the API. Since some of the new classes have the same name as the old classes, the new classes are in a new namespace called MHWRender.

~Kristine

Maya API Resources

Over the years I have found some really good Maya API websites that people have created, I wanted to share them with you incase you hadn't found them on your own yet:

API Resources (Good ones I have come across):

http://www.comet-cartoons.com/3ddocs/mayaAPI/

http://nccastaff.bournemouth.ac.uk/jmacey/RobTheBloke/www/

 http://ewertb.soundlinker.com/maya.php

http://ewertb.soundlinker.com/api/api.php

Google Forum:

http://groups.google.com/group/python_inside_maya/topics

PyQt and Maya (Good Tutorials):

http://nathanhorne.com/?p=183

http://www.creativecrash.com/maya/tutorials/scripting/mel/c/maya-mel-qt-and-you-interfacing-with-the-qt-designer

If anyone has any other good resources to share, please do,

Cheers,

Kristine

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);
    }