We do all of out meta data association through our tagging system. It relies on a single custom node type that is used as a data container: it has no compute function. It could really be any node type, for that matter, but we chose to go with a custom type to make finding them straight forward and for clarity when looking at them in the hypergraph, for instance.
These nodes are used to represent various types of data, so we format them accordingly. Based on an xml description we can build a tag node based on type and sub-type. So one tag may have a type of material and a subtype of standard, and then a list of attributes or another of type gameplay may have a subtype of damage region, and the associated attributes. The other great power in using connections is that it can make managing complex scenes easier by reducing the number of control points. Each one of out tags is effectively like a set, so it can point to, or be pointed to, by any number of nodes. We have a geometry tag that tells our engine how to handle a piece of geometry: sorting, lightgroup, frontfacing, visible, vertlighting, etc. If there is a level with 500 front facing quads that are all in the same light groups, for instance, we can use a single tag to manage them all. Needless to say, all of our code that handles the tagging system is written in python: versioning, connection management, UI and associated callbacks. I haven't gotten to our rigging system just yet, but that is coming soon and the plan is to use the established paradigm. I'll take a look at that gdc talk. I'd love to hear what others are up to. -Judah On Wed, Jan 13, 2010 at 9:07 PM, John Patrick <[email protected]> wrote: > Glad to hear everyone's input! It sounds like a node network is a good way > to go...it's just a matter > of writing code to sensibly manage with these connections. David, I'm > downloading your presentation now > and will definitely look through it. > > > On Wed, Jan 13, 2010 at 8:56 PM, David Hunt <[email protected]> wrote: > >> I am also a big fan of managing Maya scene data with message >> connections and network nodes. A few years ago we designed a general >> purpose metadata node architecture for use in character rigging. It >> has solved pretty much all of our problems with finding objects in >> scenes which has enabled us to write some pretty cool animation and >> pipeline tools. By relying on the metadata node network we were able >> to remove all of the conditional explicit traversal in favor of what >> we now call Semantic Traversal. It worked well enough to extend to >> other things beyond character rigs such as environments, effects, >> cameras, lights and anything else we could throw at it. >> >> Nodes, attributes and connections in Maya are a great structure to >> work with because they can be set up as similar to classes in Python. >> This can also be read and written to external data files such as XML >> relatively easily. Each one of these formats has its place in a full >> toolset and they are all nicely compatible with each other as long as >> you define some good general purpose conventions up front and a >> manager module to work with them. >> >> This was the topic of an Autodesk Masterclass I did in Asia in 2008 >> and a GDC talk last year. You can check out the GDC material here: >> >> http://downloads.bungie.net/presentations/ModularProceduralRigging.zip >> >> -David >> >> On Jan 13, 7:10 am, Judah Baron <[email protected]> wrote: >> > I don't see using connections as inelegant at all. Actually, it's the >> > cleanest and most reliable way to manage many relationships and >> associations >> > in Maya. It's a manifestation of Maya's core architecture and its main >> > strength. If you look at the way Maya's default nodes work together, or >> the >> > way mental ray is implemented you'll see the same thing. The benefit is, >> as >> > Chad suggests, that you don't have to worry about what the node is >> called - >> > whether it moves around in the DAG, changes name through the UI, or the >> > containing file becomes a reference - as long as the connection is >> > maintained, your relationship is intact and management of that >> relationship >> > is in Maya's hands. As soon as you start tracking nodes and >> relationships by >> > name you take on the responsibility of reproducing what Maya already >> does, >> > which in turn means you will need to generate and maintain a whole new >> layer >> > of code. >> > >> > We use a lot of message connections in our system and it is very >> reliable. >> > It's so reliable that I can't remember what the connection tracing code >> > looks like because it requires so little maintenance. It's been in place >> for >> > around three years, since we started the company, and has not changed >> much. >> > >> > -Judah >> > >> > On Tue, Jan 12, 2010 at 10:12 PM, John Patrick <[email protected]> >> wrote: >> > > Thanks Chad. I guess I'm doing a little wishful thinking here. If >> that >> > > unique id was easily accessible, this might work but without it I >> suppose >> > > messages are still the way to go. Onward and upward... >> > >> > > On Tue, Jan 12, 2010 at 9:30 PM, Chad Dombrova <[email protected]> >> wrote: >> > >> > >> you could pickle to a string and then add that to a string attribute >> on >> > >> the node. the advantage of .messages is that if a node is moved in >> the DAG >> > >> or renamed the connection remains, but pickled string data containing >> object >> > >> names will become invalid. ( on a side note: houdini creates a >> unique id >> > >> for every node in every file for all time. that's pretty handy. i >> wish >> > >> that maya would do that natively, though there are ways of hacking it >> into >> > >> place.) >> > >> > >> -chad >> > >> > >> On Jan 12, 2010, at 9:10 PM, JP wrote: >> > >> > >> > Hi all, >> > >> > >> > I'm currently working on a script that allows for space-switching >> > >> > between objects, and came across some general questions regarding >> data >> > >> > persistence. >> > >> > >> > In short, I have a couple classes I've created that represent >> parents, >> > >> > children, etc, and was thinking about how to keep track of some of >> > >> > this data. In the past, I've used the tried-and-true method of >> > >> > connecting .message attributes between objects and then checking >> for >> > >> > them later. While this works, it's not terribly elegant, and when >> I >> > >> > start having a lot >> > >> > of data I want to keep track of, it becomes cumbersome to inspect >> all >> > >> > of those connections. >> > >> > >> > I was wondering if anyone had experimented with creating file-like >> > >> > objects from script nodes (or other nodes) that would allow >> something >> > >> > like this: >> > >> > >> > f = ScriptNodeFile("spaceSwitching", "r") >> > >> > f.write("Some line of text \n.") >> > >> > f.close() >> > >> > >> > It would also be very very cool if you could pickle data to this >> > >> > ScriptNodeFile object! >> > >> > >> > Obviously, pickling/saving an external file with this data would >> work, >> > >> > but I'm almost certain these would be quickly lost in our file >> > >> > system. I think it would be very handy indeed to be able to store >> and >> > >> > recall data to a node within the scene file. Just wondered if >> anyone >> > >> > out there had come across anything like this, or had any bright >> ideas >> > >> > that might help me with this sort of thing. >> > >> > >> > Thanks! >> > >> > -- >> > >> >http://groups.google.com/group/python_inside_maya >> > >> > >> -- >> > >> > >>http://groups.google.com/group/python_inside_maya >> > >> > > -- >> > > John Patrick >> > > 404-242-2675 >> > > [email protected] >> > >http://www.canyourigit.com >> > >> > > -- >> > >http://groups.google.com/group/python_inside_maya >> > >> > >> >> -- >> http://groups.google.com/group/python_inside_maya >> > > > > -- > John Patrick > 404-242-2675 > [email protected] > http://www.canyourigit.com > > -- > http://groups.google.com/group/python_inside_maya >
-- http://groups.google.com/group/python_inside_maya
