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.

Trying to finish up the XML plugin and get it ready for posting. I've been using it for a little while and I just have a few rough edges to knock out. A few more days.

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.

These were a lot more time-consuming than I thought. I draw pretty slow, but each page took me about 45 minutes. I only got about eight minutes into the movie.

Here's the first page:

I like the way a few of these turned out. The opening shot with the horses, the cross and the priest. I like the shot of the priest looking over his shoulder the least. Faces and portraiture are just hard.

Brad showed two sequences from "Ratatouille": one where Remy goes into Skinner's kitchen. He has mishap after mishap until finally he ends up about to escape, but can't quite leave the kitchen and gets caught. The later clip is with Remy and Linguini interacting for the first time. I didn't know too much about this movie before the presentation, but it looks to be fantastic. The animation is absolutely superb, the writing is very good and the what bits of the story I could see look very good. I think this will be another home-run for Pixar.

We got to see one clip from "300" where the Spartans push the Persians over the cliff. The movie has a great look; the action is pretty good. The Gerard Butler fan club had strong representation and he got most of the questions. He is very entertaining and a pretty funny guy.

I also spent some time on the exhibition floor. Stood in the lunch line next to Ernie Hudson.

The Masquerade was entertaining and the Light-side vs. Dark-side Star Wars fan film contest had some funny films.

It was a long day, but quite a bit of fun and a great distraction from work.

I don't think things will change too much because of this. I'll probably add the obligatory "all opinions are my own, not my employers" to the sidebar, but that's about it. I probably won't say too much about work. This blog was really intended to be more about what I'm interested in and what I'm doing personally, not professionally (though there is an overlap).

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.

I'm not normally into portraiture, but I thought then and think now that this turned out pretty well. Of course, I can see a ton of little things that I know aren't right, but I still really like the overall effect.

In getting ready for that, I've been doing some muscle studies.

I don't think I'm going out on a limb to state that one of the requirements of a platform is to be scriptable. I've never understood why platform creators (which is really what Maya is, a platform for doing 3D graphics) have felt the need to create their own scripting languages. There are a number of choices for embeddable languages: Python, Perl, and Tcl. I've always felt that Python was the number one choice. It has been embeddable since version 1.0 came out in early 1994.

Now I don't know how long MEL has been around, but it may predate the release of Python and I totally get not re-engineering something that's working, but I'm really jazzed about being able to use Python do do my scripting. It's awesome that Autodesk has done this work. If this is the type of thing we'll see coming out of Autodesk, I'll be really pleased.

Having built a reasonable sized system (RigBuilder which has around 15K of MEL code with the main driver being around 2K and another 12K-13K of rig modules), I know I needed better data structures than MEL provided several times. Using parallel arrays as an advanced data structure just doesn't cut it.

Now I just have to get my hands on it. Too bad the PLE is based on 7.0.

When I started building a UI around the scripts, I had two main design goals which were:

        1. Easy to change the rig on a limb by just changing a selection in a list. You have IK and you want switchable FK/IK? No problem. Change a selection, regen the rig and off you go.

        2. New rig designs were easy to code and you just drop them in. Each rig subsytem was self-contained - no code changes to hook them in.

When I first started out the project, I couldn't figure out how to meet the second goal. I had a number of .mel scripts. How to tell when a new one had been added? How would I find new rig scripts and figure out what they were? Since MEL doesn't have anything resembling reflection (except for the 'whatIs' command), getting this done seemed pretty difficult.

So, not wanting to get blocked, I punted on the problem. I made the interface to the rig files as simple as possible (each limb e.g. arms, legs, back, etc) had a specific signature for building and that was that. To add a new arm type, you had to go to the menu for arm types, add the string you wanted and then go to the code that looked at the options and add a new clause to the if-then-else and call the new function. Not great, but not terrible.

As work progressed, I accidentally did a really good thing. I separated the scripts into subdirectories: one for the arm modules, one for the leg modules, etc. Then I explictly traversed the directories with 'getFileList' and sourced the .mel files I found.

As I was finishing up the demo reel, it hit me. I could use the 'whatIs' command and query if certain methods existed. Since I was explicitly sourcing the .mel files, I had their name. If the methods I was interested in were prefixed with the file name, that was all I needed.

So, now the interface to a subsystem is pretty simple:

    - a build proc

    - a display options proc

    - a save options proc

    - a couple of procs to get menu strings and stuff

Now, the main generator is completely generic. You want to add a new a new rig type for a limb? Just code up the functions and drop it in the correct directory. It automatically shows up in the UI and is available.

Now of course, the connections are more subtle. Particularly between the skeleton and the rig types. I've eliminated a bunch of the naming problems by automatically selecting the best joint I can find, based on name. However, if the skeleton has a different naming scheme, the rigger can just select the right joint in the rig builder UI. But what if you want a ribbon spine and there's no nurbs plane for the ribbon? You the build just fails. The whole connection between the skeleton and the code is too tight and too implicit.

Something to work on for the next version.

There's been an "Under construction" page there forever, which I guess my provider placed there for me. For the last few days, there's been a rough set of pages that I created with the web app that my provider makes available called "Site Creator". I didn't really like it because it kept losing my pages. They'd show up on the web, but when I went to the site map in the editor they wouldn't be there, so I couldn't edit them.

I looked around at other packages, mainly Joomla. It looked interesting, but it looked like a beast to install. So, I opted for Microsoft Publisher. Not sure I like the look and I definitely don't like the on-disk layout of the pages, but I'll see about customizing that stuff as I go. I probably won't provide any links to the interior until I get that stuff figured out.

So, as I work on new stuff, I'm going to start posting it to this blog. If nothing else, it should help me post more regularly.

Check it out:

This is just the temp score; Hummie Mann and his students will be doing the final score. I've heard August '07 is when it will be finished.