Publishing a node attribute to a container makes that attribute visible at the container level. A published attribute consists of three parts:
You can modify published attributes as though you were modifying the values of the corresponding internal attributes directly. This allows you to:
Published attributes make up the container’s interface and are still editable when a container is locked. Thus, by publishing a set of attributes and then locking the container, you can ensure that users are only able to interact with the contents of that container through those specific attributes.
If a published name on a container exists but is not connected to an internal node attribute, the published name is unbound. Published names do not appear in the Attribute Editor, Outliner or Channel Box until they are bound since modifying them would have no affect on the container’s contents. You can bind and unbind attributes to published names with the Asset Editor.
You can publish published attributes from a child container to a parent container. This allows you to build container hierarchies to better manage your scenes.
For example, in a car scene you may create a container for the front wheels named front_wheel_CNT that is encapsulated by the container for the entire car named car_CNT. You can then publish the wheels’ rotation first to front_wheel_CNT and then publish those published attributes to the car_CNT.
You can also publish a container node’s own attributes to itself. This is useful if you want to allow an artist to change views or control other container attributes when the container itself is locked.
Templates use published names to define what published attributes it requires.
You can also publish nodes. For more information, see Published nodes.
Like publishing attributes, you can publish a node to a container. Published nodes are primarily used to define the way encapsulated DAG nodes are expected to interact with external DAG nodes in the hierarchy. You can publish a node three different ways:
Like published attributes, published nodes are the only encapsulated nodes that can be reparented after their container is locked. A parent anchor or child anchor identifies, respectively, that a node in a container is allowed to be the parent or child of a node outside the container. A root node functions as the node selected in a container centric selection (for more information, see Container centric selection) and is useful for directing a user to the primary node in a container.
Here are a few common ways of publishing nodes for a locked container:
Published nodes are the only nodes that appear under a container when that container is set to Black Box mode and container centric selection is automatically respected so that only published nodes can be selected or pick-walked. Essentially this makes all non-published nodes in the container transparent and thus makes Black Box mode the primary means of hiding the internal structure of a container and ensuring that other users connect the container’s contents to the rest of the scene in the intended ways. For more information on Black Box mode, see Hide unpublished nodes and attributes.
You can also protect your container’s integrity by locking it. When a container is locked, you can only parent/child published nodes. For more information on locking containers, see Lock a container.
It is important to note that published node relationships are handled differently from other relationships in Maya. Rather than using the node’s name directly, parent anchors and child anchors rely on the published name of the parent/child to manage the relationship between objects. This is especially useful when working with file referencing.
For example, suppose you reference a file with a bouquet and parent it to an arm in the parent file. If you alter the hierarchy or name of the bouquet file, Maya is unable to maintain the relationship between the arm and the bouquet in the parent file since the DAG path has changed.
Maya no longer recognizes its relationship to the arm and as a result the bouquet loses all its relationship data and is reset to the origin.
You can avoid this problem by encapsulating the bouquet in a container and publishing bouquet_GRP as a child anchor. Then you can change the names and structure of the bouquet without affecting the relationship to the arm.
