Containers/Assets and constraints

[BoostAbuse]

My issue is that, like most rigs, I use control curves to drive the joints. If my control curves are inside a locked container, how can I cleanly constrain to and from them? That is, how do I avoid the constraints creating connections in to the container?

If your control curves are inside of a locked container then you can make them Published Parent or Published Child Anchors. The way the system works is that you can define published nodes that will still remain exposed when you Black Box your asset.

A Published Parent Anchor defines a node that is allowed to have child nodes but cannot be a child itself of a node. An example of this would be a Hand control which you want to constrain an accessory to the controller.

A Published Child Anchor is a node that can be a child of another node in the scene but cannot be a parent. An example of this might be parenting your Root control to a Car asset so that the character always follows the car around when driving.


This problem is compounded even further due to the fact that I like to group each of my control curves so that constaints can be applied to the group, rather than the control, allowing the control to be repositioned freely, even when constrained. This group being inside the locked container makes this step nearly impossible.

If this is how you work then you could define the group nodes as Parent & Child anchors so that you can freely move them around or attach them anywhere and then be more strict with your actual controller objects using Parent or Child anchors.

With the Published Anchor system you should be able to do the workflow you are looking to achieve when the asset is Black Boxed and also with Lock Unpublished having been set.

If you have any further questions let me know, I am the designer working on the Assets features so I'll do my best to answer any questions you have.

-s

[Soviut]

Outstanding reply! Your last point about publishing the groups as parent/child and the wrist as child only is a really good idea.

Thanks!

[Soviut]

One thing I've noticed about the containers is that I can't Lock the container without causing all the published nodes to lock as well. Likewise, if I leave the container unlocked, constraining to the published nodes seems to send connections in to the container.

Is this normal behaviour? Are the connections actually going into the container, or are they just being drawn that way in the hypershade? I assumed that connections to published nodes would connect to the edge of the container, the same way published attributes do.

I'm trying to avoid making any connections into the container to prevent referencing issues when something inside the container changes. Naturally, this is the whole purpose of containers in the first place, but the way the connections are being drawn has me worried.

[BoostAbuse]

Lock Unpublished should only lock down any unpublished nodes/attributes, it should leave all of your published attributes and your published nodes intact.

This is normal behaviour :) What actually happens behind the scenes is that we pass the constraint through the attributeAlias array which stores the node.attr to the container.publishedAttr. The benefit to this is that you can essentially rename any object inside the container at any point in time and as long as the published name remains the same Maya will be able to maintain the association between the source and destination connection (an example would be in a referenced pipeline where you might change a bunch of joint names, a mesh name or a prop name and typically lose your constraint connections or relationship operations but with the containers published attributes this gets resolved).

Truth be told, your constraint is still wired back up to your original node.Attr that you specified but we just pass the connection through attributeAlias first. You won't have to worry about any reference issues with naming so long as your published node name (the attributeAlias name) does not change.

If you reference your character into an animation scene and the animator adds a ton of constraints and animation, you can actually rename L_Hand_CTRL to Bob and so long as it's published name (say L_Hand_CTRL) remains untouched Maya will be able to resolve the connection because we are no longer looking at a name based resolution but are actually looking at the plug information on the node itself.

Hope that helps and isn't too programmer'ish description :)

[Soviut]

The more low level and programmer-esque the better in my case. :)

Just to clarify, when you say its 'published name' do you mean the name that sits next to each published node in the attribute editor that gets automatically assigned when publishing as child or parent anchors? Because I noticed that when I renamed a node inside my container that had been published, say L_Hand_CTRL to L_HandX_CTRL, the published node visible on the container changed as well.

[BoostAbuse]

Lets see if this helps some (quick draft) and hopefully it attaches. It's a quick draft that shows you what your published names look like in relation to the actual node.attr names and how they can differ if you want them to. I just opened this up in the Asset Editor but you can also see the published names in the Attribute Editor and Channel Box as well.

[Soviut]

Yet another amazing answer. This helps a lot since I haven't even had a chance to investigate the Asset Editor. I think I have a handle on this now, you've provided more than enough information for me to feel comfortable introducing this into our pipeline for our next production.

[BoostAbuse]

Glad to be of help, I just PM'd you with my direct email. If you have any future questions about Assets don't hesitate to fire me an email and I'd be happy to help out in any way I can.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.