Intro to AETemplates

If you’ve ever written a custom node for Maya, you’ve probably had to deal with AETemplates. They’re those MEL scripts that control how your node appears in Maya’s Attribute Editor. Hence why their name is short for Attribute Editor Template. AETemplates are used by every single node type in Maya including the built-in ones.

AETemplates can be somewhat confusing for folks because, at first glance, their implementation is unintuitive. Additionally, Python is not supported so they must be written in MEL. In this post, I’m going to discuss how AETemplates actually work and then provide a simple MEL example. The intent is to prepare the way for a followup post that will discuss how to build AETemplates with Python and PyQt.

How AETemplates work

Every AETemplate has two modes: Build and Update.

  1. Build – When an AETemplate is first initialized, it is in Build mode. This is when it actually sets up the layout and creates all the buttons, sliders, text boxes, etc., for the user to work with. Build is run only once per AETemplate per Maya session, typically when the user tries to view a particular node type in the Attribute Editor for the first time.

IMPORTANT: It is critical to understand that an AETemplate DOES NOT get rebuilt when the user tries to use it with a different node of the same type. Instead, it is only told to start showing the relevant data for that particular node.

  1. Update – Every subsequent time an AETemplate is accessed or viewed, its update function is called. This function gets passed the name of the node that the AETemplate currently represents. It must then update all the UI elements within the Attribute Editor to reflect the up-to-date data for that specific node.

IMPORTANT: An AETemplate’s update function gets called constantly, even when it’s already showing data for the correct node. Simply switching to a different workspace (in Linux) and then switching back to Maya’s will trigger an update. Therefore, it is important that the update functionality be as efficient and robust as possible.

A Simple Example

For the purposes of this demonstration, I have created a new node for Maya called uselessTransform. It’s basically a standard transform node but with a few extra attributes added so that we have something to mess around with for our AETemplate. The node is written in Python and can be downloaded here along with the final version of its AETemplate: uselessTransform.

First, let’s see what happens when we try to look at our node in Maya without having an AETemplate prepared:

Well, we do see all the transform stuff but where are my custom attributes?


Oh, there they are. Well, that’s hardly ideal since I actually wanted those attributes to show up all the way at the top of the Attribute Editor.

To create an AETemplate, we first need to create an appropriately named .mel file. IMPORTANT: The naming convention for all AETemplate files is AEnameOfNodeTemplate.mel. So for our uselessTransform node, we should name our AETemplate file: AEuselessTransformTemplate.mel.

Next, let’s define some boilerplate stuff:

Notice:

  • The name of the primary AETemplate procedure follows the same naming convention as the .mel file: AEuselessTransformTemplate.
  • Rather than using the usual rowLayout, columnLayout, etc. commands, we’re using the editorTemplate command. This command is central to creating AETemplates

Let’s see what we get with this template:

Wow, that seems worse than no template at all! We can’t even see any of the transform attributes.

Actually, if I were to expand that Extra Attributes section, we’d see every attribute on that node in a huge and unwieldy list (click to enlarge):

If you look at the very bottom, you’ll see that our extra attributes are there.

Let’s start by reproducing the standard AETemplate functionality. We can do this by calling the AETemplate functions for the node type that we have derived from:


Progress!

All we have to do now is add our extra attributes to the top and we’ll be done! The easiest way to do so is:

Notice:

  • The editorTemplate -addControl “attrName command is the easiest way to add new attributes to an AETemplate.
  • No further maintenance is required as everything created via editorTemplate will update itself automatically

We now get the result we want:

Further Customization

Actually, now that I think about it, I really want that Enum Attr to display the values as text (“zero”, “one”, two”, …) instead of digits (0, 1, 2, …). Also, the labels should be different…let’s say “TXT” instead of “String Attr” and “NUM” instead of “Num Attr”.

Well, the label thing is actually pretty easy. All we have to do is add a -label flag to the editorTemplate commands like so:

Result:

Changing the displayed values is a bit trickier though. I suppose we could always modify the uselessTransform plugin itself but that seems silly, especially since the whole point of this tutorial is to learn about AETemplates. Therefore, we’ll have to use a special editorTemplate flag, -callCustom, which will allow us to substitute our own custom MEL procedures and build the enumAttr control exactly as we want.

Notice:

    • The -callCustom flag is passed three arguments:
      • The command that will be called in build mode and should set up the control.
      • The command that will be called in update mode and should modify the control to display data for the correct node
      • The name of the attribute whose control will be created/maintained via these procedures.
    • You may pass as many attributes to -callCustom as you need. E.g.,
    • You may also completely omit the attribute argument from -callCustom and only pass it the build and update procedures. E.g.,

      Be aware that any attributes not explicitly accounted for via an editorTemplate command will appear in the Extra Attributes section at the end.

Personally, I’ve never encountered a case where this would be useful…not passing an attr argument means the receiving procedures won’t actually know which node to operate on.

Now, let’s implement our custom Build procedure:

Notice:

  • The procedure accepts one argument: the enumAttr name. This corresponds to the attributes passed to the editorTemplate -callCustom command. Had that command been given additional arguments, our Build procedure would’ve had to accommodate them within its declaration
  • The attribute names passed to this procedure are in the format of nodeName.attributeName. For instance, if our node is called uselessTransform1,
  • We use attrEnumOptionMenuGrp to create the control. The advantage is that this particular control comes with the built-in ability to connect to an attribute via the -attribute flag.
  • We make sure to provide our new control with a name (UTransEnumAttrOptionGrp) so that we may access it later.

Finally, we implement the custom Update procedure:

Notice:

  • The function signature is the same as its corresponding Build procedure.
  • All we had to do was modify the existing control to point to the same attribute on a (possibly) different node.

Our final AETemplate looks like this:




2 Thoughts on “Intro to AETemplates”:

  1. Tushar Sankhala

    Thanks you very much, you provided a much needed information.

    Waiting for next Posts….

    Reply

Leave a Reply to Tushar Sankhala

  • (will not be published)