I just did a build of the XML plugin for Maya 2008. The zipfile now contains a binary for Maya 2008. The only caveat is that the 2008 binary hasn't been tested. I won't have access to 2008 until next week, so it may work, it may not.
I finally have gotten around to packaging up the binaries for the XML parsing plugin. I finished it up two weeks ago but with GDC and then suffering through a cold the week after GDC, I've been too busy sleeping or trying to get caught up at work to get it packaged up and posted.
This plugin lets you load and save XML to and from MEL string variables and files. It's pretty permissive about the XML it will read. There are binaries for Maya 7.0, 8.0 and 8.5. Initially I was going to stop using this with 8.5 and move over to Python, but I find the Python/MEL integration so unwieldy that I use Python far less than I initially thought. So, I may be building a version for 2008 as well. I can probably build versions for earlier versions of Maya. I think I have access to 6.5 and 5.0 but I'll have to see.
Take a look at the documentation page and you can download the binaries from my MELScripts/Plugins page. I'll try to get the source code up in a reasonable time frame, but may be a couple of weeks.
Let me know of any comments, suggestions and bugs. One area I haven't used much is the data items. Pretty much all the XML I work with is all elements and attributes.
Enjoy.
As it turns out, one of the most generally useful pieces of code I've written at work is an XML parser plugin. The studio uses XML for a variety of things: configuration files, asset storage and description, and also XML is stored in attributes on Maya nodes.
We had an XML parser library in C++ but nothing callable from MEL. The studio hadn't switched over to Python yet so there was no good solution. Before I got there, any functionality that needed to parse XML was either written in C++ (which means there are a number of tools written in C++ that should be MEL), or people just kind of did a rough grovel through the XML to extract what they needed and just hoped it worked.
Two or three weeks after I started (back in February or March of 2007), I spent a weekend wrapping the C++ XML library in a plugin. I took the design decision to make the interface look like the C++ methods and so I ended up with MEL commands like:
xmlGetNumChildren
xmlGetChild
xmlGetNumAttributes
xmlAppendAttribute
etc.
There are about twenty different commands. In hindsight this wasn't the right decision. While it's useful for people familiar with the XML parser, it's not very familiar to those native MEL speakers.
Even so, this has been very useful at work to a wide variety of people. So I decided I needed the same functionality at home, so I've been working on an XML parsing plugin in my spare time. I'm using Python some (both at work and at home) but haven't moved over completely so I think this will definitely get some use.
I found an XML parser by Frank Vanden Berghen to use and I've been writing a plugin in my spare time at home. It's given me a chance to correct the design flaw described above. Now there's just a handful of commands, one each for elements, attributes and data (plus a few utility functions for doing file I/O, etc). The commands support create, query and edit modes. A much better MEL-ish interface.
I'll be posting the plugin binaries plus the source and VS2005 project file in the next week or so. I've got a bit more work to do to finish it up along with some more testing.
My muscle system creature rig has gotten put on the backburner for a while. I ordered the MuscleTK plugin for Maya and the software arrived fine, but I could never get the cgToolkit people to send me an activation code. After two weeks of e-mailing them myself and having the store where I bought the software e-mail them and getting no response, I returned the software (kudos to the company I ordered it from, they were awesome!). I'll give Michael Comet's plugin a try next, but I need to save up for a little bit to afford it.
So, the next bit I'm playing around with for my demo reel is a rag doll physics simulation. Something similar to the basics to Natural Motion's Endorphin, but done as a Maya plugin. Initially, I just want to get the basic physics in place; I'll see where it leads me after that.
Here's the first test. I thought I'd try YouTube as a repository for some of my video tests. There's no real physics going on here, just a dampening of the oscillation. This is really just testing out my infrastructure (making sure I know how to connect things up correctly and drive joint rotations properly).
Hmmm. The YouTube embed doesn't show up in my RSS reader (GreatNews)...
This is what it looks like in the hypergraph:
I'll post again once I get some real physics dropped in.
[Okay. Wow. The format of this post looks terrible... I'll see what I can do in the next day or so to get it fixed...]
[Better, but some of the code is broken across lines. Oh well.]
[Correcting the code fragment. It had my fix in it as originally posted.]
I just spent about twenty minutes debugging a problem with someone else's MEL script.
The script I'm trying to use has the following code snippet in it:
{
string $currentSelXform[] = `ls -sl`;
string $currentSelShape[] = `listRelatives -shapes $currentSelXform[0]`;
if ($currentSelXform[1] != "")
{
warning "No base mesh loaded. Please select only 1 polygonal mesh to load.\n";
} else {
if (`objectType $currentSelShape[0]` != "mesh")
{
warning "Base mesh must be a polygonal mesh. NURBS and SUBD surfaces are not supported.\n";
} else {
textField -edit -tx $currentSelXform[0] currentBaseMeshTextField;
print ($currentSelXform[0] + " was loaded as the base mesh.\n");
}
}
I select the menu item that calls this, and nothing happens. Now if you look at the script, every path prints either a warning or a message indicating success. Why was this doing nothing when I call it?
Turns out that the script was bailing out on the call to the objectType MEL command. After nosing around, I find the shape node for the object I was selecting is called 'subdTessShape1'. As it turns out, I've duplicated this shape many times. Guess what the shape node for all those duplicates is called? Yep, 'subdTessShape1' (this surface started out as a subd surface and is now a polygonal mesh).
This line:
string $currentSelShape[] = `listRelatives -shapes $currentSelXform[0];
returns the shape name in $currentSelShape[] as 'subdMeshShape1'. When this is passed to the objectType command, it just bails because (apparently) it doesn't know which one.
listRelatives should be called like so:
string $currentSelShape[] = `listRelatives -shapes -pa $currentSelXform[0]`;
So, MEL scripting Tip #1:
When passing object names around, always use full path names. When getting object names from listRelatives, use the -pa flag to get the full path.