I mentioned that we're using json to save complex data onto a mayaNode
attribute. That was only because I we couldn't get pickle to work. Has
anyone had success with this?
class Foo:
attr = 'a class attr'
picklestring = pickle.dumps(Foo)
print repr(picklestring)
pm.selected()[0].addAttr('pickle', dt="string")
pm.selected()[0].pickle.set(repr(picklestring)[1:-1])
pickle.loads(str(pm.selected()[0].pickle.get()))
I think this approach is floored because I'm pickling the object in a single
string using repr().
-Dave
On Thu, Jan 14, 2010 at 2:03 PM, Judah Baron <[email protected]> wrote:
> 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
>
--
http://groups.google.com/group/python_inside_maya
