DeepGreenJungle
01-29-2005, 11:47 AM
Hi guys, I recently got back into Maya from using XSI, and am in the middle of trying to figure out how I want to set up a bunch of rigging scripts. One of the things I like about XSI is pseudo object-oriented scripting capability (if you have no idea what I'm talking about, it's more than worth reading up on). So I was thinking that maybe the wonderful system of nodes and connections in Maya provide a good opportunity to represent the same concept. As an added advantage, the relationships you define in nodes (as opposed to code) stick around long after the script is done running, so you can get information about your original data structures much later. Basically, the idea is that instead of passing things around as names and numbers and arrays within a character's generation functions, you store that information as connections between nodes. Let me see if I can explain in an example:
Say you have a script that builds an arm. The first thing you'd do in your script is create a node to act as the "object" for the concept of the arm, lets say we use a script node. Then, over the course of the script, we build three bones (shoulder, elbow and hand), and an IK chain. But as we build each one of these, we also add a message attribute to the arm object script node, and connect the bone/ik/whatever to that attribute. Then, when the arm script is done running, we just return the name of the script node. Now, if later in the scripting process, we want to add a hand to the arm, we have easy access to all of the necessary objects in the arm through our handy script node. This could be abstracted further, so that you could have a "body" object with connections to "arm", "leg" and "head" objects, which in turn had connetions to their own individual pieces. But the fun doesn't stop there, since we're using a script node (I did choose it for a reason), we can attach special functions (methods) to our arm object so that we can manipulate it, or get information about it. These could include methods that made the build process easier, or functions for animators that would get mapped to an interface button (like FK/IK switch functions).
Blah... so that's the thought process so far... but I'm getting snagged up on some logistical things. For example, I'm having trouble thinking how to refer to the scriptNode from within it's own code (so you can access the message attributes)... unless you initialize the code with it's name, but that totally screws you if you ever change the name of your object. Also, it strikes me that the possibility for vast overcomplication and obfuscation abounds at every corner. Unless executed in a very elegant manner, the functions that build and maintain this kind of thing could get really big and obnoxious. Also, as much fun as it sounds like, I'm not terribly sure it'd be worth it. I suppose the value would depend greatly on the specifics of the type of rig you were trying to build, the size of the project, etc.
But I don't know, something to toss out there anyway... anybody got any ideas? I'm sure people have done stuff like this before. I've heard of at least doing this kind of thing for garbage cleanup (was that MacaroniKazoo?) There's certainly room for improvement... Any thoughts on logistical implementation?
Say you have a script that builds an arm. The first thing you'd do in your script is create a node to act as the "object" for the concept of the arm, lets say we use a script node. Then, over the course of the script, we build three bones (shoulder, elbow and hand), and an IK chain. But as we build each one of these, we also add a message attribute to the arm object script node, and connect the bone/ik/whatever to that attribute. Then, when the arm script is done running, we just return the name of the script node. Now, if later in the scripting process, we want to add a hand to the arm, we have easy access to all of the necessary objects in the arm through our handy script node. This could be abstracted further, so that you could have a "body" object with connections to "arm", "leg" and "head" objects, which in turn had connetions to their own individual pieces. But the fun doesn't stop there, since we're using a script node (I did choose it for a reason), we can attach special functions (methods) to our arm object so that we can manipulate it, or get information about it. These could include methods that made the build process easier, or functions for animators that would get mapped to an interface button (like FK/IK switch functions).
Blah... so that's the thought process so far... but I'm getting snagged up on some logistical things. For example, I'm having trouble thinking how to refer to the scriptNode from within it's own code (so you can access the message attributes)... unless you initialize the code with it's name, but that totally screws you if you ever change the name of your object. Also, it strikes me that the possibility for vast overcomplication and obfuscation abounds at every corner. Unless executed in a very elegant manner, the functions that build and maintain this kind of thing could get really big and obnoxious. Also, as much fun as it sounds like, I'm not terribly sure it'd be worth it. I suppose the value would depend greatly on the specifics of the type of rig you were trying to build, the size of the project, etc.
But I don't know, something to toss out there anyway... anybody got any ideas? I'm sure people have done stuff like this before. I've heard of at least doing this kind of thing for garbage cleanup (was that MacaroniKazoo?) There's certainly room for improvement... Any thoughts on logistical implementation?