Archive for July, 2004

Mad Mad Scripting

After scripting madly for the past 12 hours, I finally finished adding custom export settings to dtsUtility.mel. Most of the time was spent figuring out how to save and load the settings, reset things to default states, working with local and global settings, and testing testing testing. I released a version that I believe works ok, but, as with any project like this, there could be bugs that I haven’t discovered yet. Seems pretty solid though.

I’ve definitely learned a bit more about working with MEL while updating dtsUtility. I didn’t really learn new commands, but rather, learned more about structuring a MEL script, handling flow control, working with preferences, and – the real doozy – parsing strings. I know I’m not anywhere near being a programmer, but I think I’m getting the logic down in my head now.

I also discovered that SubEthaEdit is an absolutely indespensible tool for my scripting needs. Syntax coloring alone is keeping me with SubEthaEdit. The color coding helps me sift through the hundreds of lines of MEL script that I have crammed into dtsUtility without straining my eyes too much. It even helps when spellchecking and troubleshooting things.

The function browser is also essential for quickly navigating to different sections of the massive script. The syntax mode file that I wrote color codes and flags local and global procedures differently, so it is much easier to see what is what in the long list of procedures. I know other programs have function browsers, but none of them are as easy to look at as the one in SubEthaEdit.

There is no way in hell I could’ve worked this quickly or smoothly with BBEdit. As much as I love the speed and power of BBEdit, the lack of a simple-to-create syntax coloring method is enough to stop me from using it for MEL scripting. I’m not a programmer. I’m not going to spend time writing and compiling a plugin to do syntax coloring for BBEdit when I can do the same thing in an XML file for SubEthaEdit.

Of course, SubEthaEdit isn’t perfect. The syntax coloring does introduce quite a bit of lag as I type. This is probably because it is parsing XML a it formats things.

It doesn’t have all the fancy text processing features of BBEdit, like line ending conversions, key commands for commenting and uncommenting blocks of text, text rewrapping. Yes, you can get those features in a system add-on, but it would be nice to have those options built into the program itself. Those aren’t really essential, but they would be nice to have.

Multi-file options would also be nice. Things like multi-file searches and file concatenation could come in handy. Again, these are not absolutely essential, but they can save a lot of time when processing multiple files from the same project.

Bottom line is SubEthaEdit does get the job done quite well. It has most of the features I need for my work, and it performs at an acceptable level. And, it doesn’t cost and arm and a leg like BBEdit.

Split Personalities

I’m definitely having fun jumping back and forth between two different tasks: setting up the horse model for animation and working on various MEL scripts. It’s been a nice split between an art-related job and an obviously more technically oriented job. My brain really gets quite the workout.

Horse Content Pack

I got most of the leg controls worked out this morning. I set up a variation on the inverse foot setup that I normally use on bipedal rigs. Seems to work ok. I have to finish parenting the IK handles to the controls and do a quick test, but I think it will work fine.

I’m probably going to go with FK for the rest of the rig. I want to keep this as simple as possible, and I don’t want to have to rebuild everything in Max to match. Plus, I know the type of moves I’m going to be animating, and those don’t require any special controls. K.I.S.S.

dtsUtility.mel

After I got tired of working on the horse rig, I switched gears and continued working the upgrades to dtsUtility.mel. I figured out how to get, set, and save the export options on a scene-by-scene basis. The dummy UI I slapped together worked just fine. I just need to hook it up to the actual export commands this week. I think it will work.

Productivity is Good

It’s been a super productive week. Got a lot done on both the Horse Content Pack and some scripting things.

Horse Content Pack

I exported the horse mesh with detail levels as well as the skeleton out of Max and imported them into Maya. That was a pretty good accomplishment for me, considering I wasn’t sure how well the rig itself would come through. Turns out I only had to do a little bit of cleanup. The unit scale was really crazy (scale multipliers of 100), so I had to do some fancy re-parenting work to get everything back to 1. I also got rid of the ugly locators and replaced them with group nodes to clean up the viewpanels.

I was able to transfer the skin weights from the main mesh to the rest of the detail levels without any problems. I used a really handy set of scripts from HighEnd3D called aeSkinWeightTransfer. Really really cool set of scripts. I didn’t have to reskin anything. Just export and import the weights as needed.

I also started on the horse rig in Maya. I’m keeping all of the same base joints to maintain consistency between Max and Maya, but I’m building my own controls that are specific to the Maya scene file. I’m not building anything really fancy right now. I’m just figuring out some good ways of controling the legs with a minimum amount of fuss as well as coming up with a good solution for handling the hips/spine/shoulder areas. I’m still trying to decide if I want to keep it simple and go with a standard FK setup or if I want to build a fancy splineIK rig. We shall see…

DTS Utility

The dtsUtility is getting a few new upgrades this week. I fixed a bug with conflicting procedure names that was really annoying me for a while. Everytime I used dtsUtility on my Mac, my right-click menu went wacko. I finally did some digging in the main application scripts folders this week and tracked down the conflicting name. It was a simple fix, thank god.

I’m also working on adding an “Export Settings” option that retains its settings between working sessions. Right now, the quick export buttons automatically name the exported files using the same name as the Maya scene file, and they only use the export directories specified in the project settings. It would be nice if we could specify export file names and locations for the quick export buttons that don’t rely on the project settings at all and don’t always use the Maya file’s name. Technically, we can manually set export names and locations in the regular Export dialog box, but it can get tedious if you’re doing multiple tests on the same shape.

I had already been thinking about how to do this but never got around to it. Mark McCoy brought it up in the BraveTree IRC channel this afternoon, so I decided to get cracking on it today. The main challenge was figuring out how to get a file directory name from a file browser dialog. Some digging around turned up a nice premade file dialog script that returns just the values that I need.

With that out of the way, all I need to figure out now is how I want to save the preferences. My first idea was to save global options. One set of preferences is easy to manage, but then you run into problems with potentially overwriting files and whatnot. Also, the export preferences would only be stored on whatever machine hosts the files.

The other option is, of course, file-specific settings. The settings could be saved in the Maya scene file as a hidden node. Those settings could be loaded whenever the dtsUtility loads or when the file opens. And, since the settings are actually in the file, you can use the same settings on different machines. Naturally, you’d most likely have to change the export path, but the file name could remain the same.

I’m currently trying out different methods of saving the settings to see how easy they are to work with. I’m probably going to use a scriptNode that doesn’t actually do anything but contains custom attributes for file names and directory locations. Then, when dtsUtility is loaded, it will grab the values from those custom attributes. Initial tests appear to work fine. Now to implement it into dtsUtility.

BBQ for Two

Mei and I bought a little portable gas grill this afternoon and had a private BBQ right on our back porch. It probably violated all sorts of building regulations, but, oh well. We wanted to have a BBQ, and we wanted to do it right here at home. Mei is so smart!

After the initial burnout of the paint finish inside the grill, we laid on the food and start grilling. Pork slices, sliced zucchini, potato slices, and green peppers were on the menu for tonight. Mei marinated the pork with soy sauce, salt, pepper, and red chiles – fairly similar to how she marinated the beef for Matt’s birthday BBQ. Everything was super tasty.

Mei did pretty much all of the grilling and food preparation. All I had to do was put the grill together, assist her when she asked me to, and eat. Considering the fact that Mei can cook well and that she loves doing BBQs, I wasn’t going to argue with that. She’s good. Very good. One of the best cooks I know. And I’m incredibly lucky to have her as a girlfriend.

The BBQ went off pretty well. We had some initial trouble getting the gas lit, but we managed. It’s always nerve-wracking to light up propane. After the fire really got going, things started getting a bit smokey. I’m sure our upstairs neighbors didn’t like the smoke that wafted up there, but we didn’t really care. Their little monster/child runs across their apartment making a huge racket all the time with no regard for us. So this was a bit of payback.

So, now all we have left is a bunch of dirty dishes in the sink and a grill that needs some scrubbing. Looks like I’ll be doing some cleaning tomorrow.