In Maya, message attributes are a special class of attributes (parameters), which have no data and are exempt from dependency rules.

They are very useful for scripting. For example, two nodes can cross-reference each other:
B connects to A.messageFromB
A connects to B.messageFromA
(pseudograph)

Once those connections are established, later scripts can navigate from A to B, or from B to A, without needing to make any assumptions about object names or hierarchy. In principle, message attributes can also serve as pointers to individual attributes, although I generally used them to point to nodes.

Max offers an “node” data type, which allows one node to point to another. But this connection is considered a dependency, so it won’t allow two nodes to point to each other, or an upstream node to point to a downstream node.
Is there a better solution?

You need to use maxObject or maxObjectTab. These require you to set up a weak reference using nodeTransformMonitor and setting the node property to the node that you are going to store. Once you have it stored in the maxObject you can access the node via the .node property, this stops any dependency loops from happening.

I didn’t know that you could do it in Maya at all. When was this added?

Paul Neale
PEN Productions Inc.
penproductions.ca / paulneale.com
Master Classes for Max, Mudbox and Composite
DotNet Tutorials

MX Driver Car and Trailer Rig On Sale!

Thank you for the info!

messages in maya… how long… well,

I first learned Maya on version 4.5, and I’m pretty sure it was already implemented then.
A lot of core features in the program are built on message attributes. For example, set membership is handled by messages; a set is basically just an abstract node with an array of messages hooked to the member objects. And sets are at least as old as… well, light linking for example. And shader assignment. Both of those features are built on sets.

messages connections are simple to script too… for example this works :
addAttr -at message -ln “pointerToCube2” pCube1;
addAttr -at message -ln “address” pCube2;
connectAttr -f pCube2.address pCube1.pointerToCube2;
listConnections pCube1.pointerToCube2;
// Result: pCube2 //
*

In this example, one of the attributes is a named attribute serving as a pointer. The other is a generic target serving as an address. It’s not necessary to add new attributes to the target just to have something to point at; you could use pre-existing attributes instead (pointing to the instance ID would let you distinguish between instanced objects; effectively you’d be hitching a ride on the hooks provided for the Set Membership system) but I usually used a named attribute as the “address” just for clarity or perhaps out of habit.

A quirk of message attributes, is that you always want the attribute being pointed TO to be on the upstream end of the connection. You might say this is a side-effect of dependency, but only indirectly;(both objects can still cross-reference). It’d be more accurate to describe the reasons as an emergent property of the way the connection system works.

A regular (non-array) attribute can have unlimited outgoing connections but only a single incoming connection. So if we want to use them like pointers… well, a pointer has a name, but only points to a single address; whereas an address is anonymous but can be pointed to by an unlimited number of pointers.
So as you can see, in order for the concepts to correlate, the side with unlimited connections has to be the “address”, and the side with a single connection limit is the “pointer”.

*Granted, I’m not making a defense of MEL; way too much string manipulation. The nodegraph in Maya is to die for though. I still miss it <=)

MEL I don’t like at all but your right about the node graphs. Max will have it one day I’m sure..one day.

I might have actually looked at what you are talking about in MEL but couldn’t get it to work they way that I expected and abandoned it. I should have looked closer.

Some other things that you might want to look at the same time is scripted plugins, modifiers and geometry. With modifier class you can create modifier like the attribute holder and then build any tools into it that you want instead of using custom attributes. CA defs are great for character specific tools but are hard to update when you want to make blanket changes to the way your systems work in a large production. Instead build a custom modifier that can be applied to any character and store all the needed reference nodes in maxObject or maxObjectTab parameters and control what you need to through those. Another thing that you can do is have script controller on objects in a character rig and have the script controller hold reference to this custom modifier, in the custom modifier you store all the scripted functions that the script controllers need to work. This really cleans up the mess of hundreds of script controllers in a scene and makes it easier to make global changes to the code base, just update the custom modifier and when your characters load into the scene they have the new code.

Paul Neale
PEN Productions Inc.
penproductions.ca / paulneale.com
Master Classes for Max, Mudbox and Composite
DotNet Tutorials

MX Driver Car and Trailer Rig On Sale!

penn 11 August 2009 09:58 AM

MEL I don’t like at all but your right about the node graphs. Max will have it one day I’m sure..one day.

I hope so. There are some basic architectural problems to overcome though.
For example “connection” is not a type. For every way that a controller can relate to something else in the scene, there’s a unique dance to learn; you can change the inputs of a script, but a wire has to be rebuilt, etc. In order to enforce good graph behavior on that band of misfits, someone’s going to have to refactor them to comply with the necessary abstractions.
I’m no programmer, but I’m pretty sure that’s a lot of work!

On the other hand (so I don’t come off sounding too glum) one thing I love about Max, is that the scripting language offers predefined types for quats and matrices. MEL doesn’t, for reasons I’ll never understand. I guess they figured you’d never want to do those sorts of operations outside of the API.

penn 11 August 2009 09:58 AM

CA defs are great for character specific tools but are hard to update when you want to make blanket changes to the way your systems work in a large production. Instead build a custom modifier that can be applied to any character and store all the needed reference nodes in maxObject or maxObjectTab parameters and control what you need to through those.

That sounds like great advice, and I’m just now starting to approach the point where I can appreciate it… though lately it seems like I’m stuck playing catch-up. Came in with about 6 years of professional experience in Maya; joined a Max project already underway. I was trying to learn the software and organize a rigging pipeline when the team switched to Cat. Understandable; the project needed ready solutions and I wasn’t on board early enough to offer any alternatives. Gave me a whole new set of problems to solve though.

With a lot of tinkering and perhaps a bit of ingenuity, I got our Cat to jump through some hoops. In fact, I’m actually proud of the current draft of our primary rig, which is saying a lot considering my gut reaction to Cat is the same as yours. But I still feel like I’m back in college, overwhelmed and wiring everything by hand… and a few parts of Cat don’t seem to be accessible by script at all, unfortunately. It’s hard to get far enough ahead of the curve to plan a process. I’m trying. Thanks again for the help!

Well if you have more questions I’m sure that I can get you over the humps. I have about 14 years in Max, well I started on Max the day Max 1 shipped I think. Did a year before that as well in 3DS DOS 3 and 4.

Paul Neale
PEN Productions Inc.
penproductions.ca / paulneale.com
Master Classes for Max, Mudbox and Composite
DotNet Tutorials

MX Driver Car and Trailer Rig On Sale!