We noticed an unusual issue with a few files at work as some began to lag and bloat quite significantly during baking etc.
Eventually we tracked it down to duplicating the node’s hierarchy whilst it has a message attr connection (custom, not ‘.message’) to its root (multi-message, index doesn’t matter etc) using connectAttr -nextAvailable.
It appears that duplicating one of the connected child nodes also duplicates the message connection and that of all of that nodes children, but only for the originally connected nodes.
ie
[B]simple 3 joint chain
addAttr(ln=‘children’, at=‘message’, multi=True, indexMatters=False) on the root joint
addAttr(ln=‘root’, at=‘message’) on each of the child joints
connectAttr(child.root, root.children, nextAvailable=True)
checking the connections of root.children would result in;
[child1, child2]
if you then duplicate child1 (first child of root and parent of child2 etc) and requery the connection, you would get this;
[|root|child1, |root|child2, |root|child1, |root|child2]
[/B]
If anything, I wouldn’t want the connections duplicated, but if they must, then it would make more sense to reconnect the newly created nodes.
Whats more, this does not seem to happen if you connect via the existing .message attrs, nor if you duplicate the root node. The connections also remain if you delete the duplicated nodes (obviously) but also if you undo (more surprisingly).
To give you an idea of the implications, often using particular tools that use duplicate often enough, a 3-4mb file would bloat to 30-75mb, have significant lagging issues and from 6+ connections to 98000+ (extreme case).
We’ve resorted back to using the standard .message attrs, but it would be handy to find out why this occurs?
Has anyone else encountered this or am I being abit stupid?