And here I was feeling so good about my bindPose tool. I had added some functionality that Maya’s dagPose command doesn’t seem to have. I pat myself on the back, job well done. Except it turns out the dagPose command is a little more complicated than I originally thought. It still doesn’t do what I need want it to do, but what it does do can be a bit… odd, depending on how you’re interacting with it.
One of the procedures I wrote over the weekend is meant to save out the member, parent, and worldMatrix values from a dagPose node to a mel file, so the node can be recreated in another file. But while testing it on Rose’s bindPose, I noticed that the values didn’t match up – some of the members would have no worldMatrix values, for example. Looking into this, things got weirder and more frustrating.
If I used `getAttr -size bindPose.members`, I would get a value of 302. Using `dagPose -q -members bindPose` would return a value of 246. A more brute-force method returned a value of 217. But if I loaded the node in the connection editor, there were 305 member slots, and they all appeared to have incoming connections. Even more confusing was that, while the getAttr command said there were only 302 members and parents, it said their were 305 worldMatrix entries.
What I’ve found out, is that even if you tell the dagPose command to store only specific objects, it appears to also store any objects above those, as well as their parents and worldMatrix values. But when queried via the dagPose command, these extra members are not returned. If at some point you reparent an object, and then delete the groups that were once above it, those objects’ connection to the dagPose node will obviously be removed, but their worldMatrix values remain.
For now, what appears to work is to use the `getAttr -size` command on all three attributes, then using the highest value to limit the loop that processes the objects. It’s a hack solution that I have a feeling will cause problems later, but for now it appears to work.
