I’m trying to use Maya (2008, if it matters) as a level editor of sorts. I don’t need a huge amount of functionality; giving certain objects the “DCS” EggObjectType and useful names gets me pretty far. A couple things that would be nice to have that I’m not sure how to accomplish:
Stand-in geometry in Maya that is not exported as a bunch of triangles, but kept around for placing objects at runtime. That is, it would be nice to drop in a bunch of medkits in Maya in such a way that rather than exporting medkit geometry as part of the level, instead on Python side I was able to pull out a list of transforms marked “there was a medkit here”.
Arbitrary key/value tagging of objects. There appears to be provision made for this in the EGG syntax through the um, tag, but I’m not sure how to inject this through the Maya exporter.
I have a fair amount of experience mucking about with the Maya plugin API and (shudder) MEL, so if stuff needs to be hacked in I can hack it in. Just looking for the path of least resistance here.
I should amend that for (2) one compromise is to predefine a number of key-value pairs that you might want to define. In melscript you can tag a node with any number of predefined keys, and that key can map to any arbitrary egg syntax using the Config.prc file, including a particular key-value pair.
That is, suppose you had defined the “sfx” key to indicate the name of a sound effect to be played when you bump into a particular object. You want to have the value of the pair be the name of the sound effect, like “wood.mp3”, “metal.mp3”, or “glass.mp3”. You can’t set up a system where you type in the name of the sound effect file in Maya, but you can set up a “sfx_wood”, “sfx_metal”, and “sfx_glass” definition in your eggObjectTypes.mel script, and map each of these to the appropriate mp3 filename in your Config.prc file.
So, as long as you can predefine the kinds of attributes you want to apply, you can do anything you like in melscript.
Thanks for the tip about locators generating bare DCS nodes. The one limitation there is that the stand-in geometry in Maya is useful to have, such that artists can visualize which way the object’s pointing, make sure that it’s not intersecting other stuff, etc. I suppose I could add the stand-in geometry as a child of the locator, and mark it with a “hidden” eggObjectType – a little hackish, but not too bad.
As for #2, I think I’ve solved my own problem (or rather, y’all did, IN THE PAST) – I took a look in the source of maya2egg, and found the following promising-looking comment:
…which looks like it solves my problem, just about. Sure enough, sticking on an enum-valued custom attribute causes the enumerant (not the associated value) to be stuck in as the value of the named tag in the egg file. The exporter expects only an enum, but I can just slot in a line to try getting it as a string instead if it doesn’t work as an enum.
Man, working with a free engine with an actual, robust, mature toolchain is a breath of fresh air.