Modifying a file reference
 
 
 

You can reference and edit the attributes of the referenced data in a parent scene without changing the original data in the referenced child scene files. Many of the same edits that are possible when working in a non-referenced scene are possible when you work with referenced data in your currently open parent scene. These edits get stored in the reference node of the currently open parent scene. The following edits are possible with file referencing:

You can save edits that were made within the parent scene for a selected file reference to the corresponding referenced file on disk. The edits get transferred to the child reference file so they no longer reside within the parent scene. For more information, see Save Reference Edits.

Related topics

Troubleshooting reference edits

A parent scene file can be adversely affected by edits that are made at the referenced child scene file level of the hierarchy. That is, an edit made at the parent scene level could become unresolvable if node names and connections are changed at the child scene file level. The following are examples of edits that can affect the parent scene’s ability to resolve previously made edits:

DAG hierarchy

It is possible that a DAG node can be non-uniquely named within its particular namespace. This means that two objects in a scene can be named the same provided they exist in separate DAG hierarchies whose path name is unique. If modifications are made to a DAG hierarchy in a referenced child scene file after it has been referenced into a parent scene, such that the DAG paths change from what the parent scene’s edits specify, the edits may no longer be possible, or may be applied in a fashion that was unexpected.

Dependency graph connections

If you rename a node in a referenced child file after it has been referenced into a parent scene, any edits that were made to that node in the parent scene will no longer be possible. For example, two nodes exist separately in a referenced child file, and have an edit that connects them in the parent scene. If either of the nodes are subsequently renamed at the child file level, the parent scene will be unable to apply its edits, because of the name change, and display an error message.

Keyframes

A keyframe on an attribute connects the attribute being keyframed to a new node. If the parent scene file cannot find the node (because its name has been changed), the animation may break.

Character rigs

It is common practice to add, delete, and rename attributes in a character rig. Creating a specific character node can work as a safeguard for any successive changes. The character node should be created in the rig file that will be referenced - not in the parent scene file that references the rig.

Character sets

When referencing character sets, renaming a member of that set or renaming the character itself is not permitted if the referenced file modifies or connects to the renamed object. This could result in the animation not affecting the character set or affecting the wrong member of the character set.

Polygon history

In situations where the surface geometry in a referenced file must be edited, the user can add history to the referenced model. One example of this is pre-lighting, an effect used to store the shading and lighting information from the rendered look of a mesh in its vertex colors. As long as the poly geometry in the referenced file has history, new history can be added in the parent scene. A simple way to add history in the reference child scene file is to select the mesh and then select Edit Mesh > Transform Component.

Keying attribute values

If you change the value of an attribute in a referenced child scene file, there is no way, other than an immediate Undo, to set the attribute back. If it is important to return to that value, consider storing that value by setting a keyframe, Trax pose, or Trax clip. Another option is to store the value as a node preset in the Attribute Editor.

Grouping

When you create file references with the group option, some objects in the hierarchy may receive a double transformation when the new group node is translated, rotated, or scaled when working in the parent scene. That is, when you translate an object, the object receives two commands to transform based on its location in the hierarchy. This can readily occur with rigged characters where a relationship already exists between the skeleton and the skinned character. In these situations you must either turn off the Inherit Transforms attribute for the item in the referenced file, or determine an alternate approach to grouping the hierarchy.

Updating a reference in the parent scene

When multiple users are working on a project, and one user is editing a referenced file that is also referenced by other users, the other users will not see the modifications made by the first user in their own parent scene until they reload the file reference. See Reference Editor overview.

Removing edits from the parent scene

See Removing unwanted reference node edits below.

Saving edits from the parent scene to a file reference

If you require nodes to be written out as part of the save reference edits operation, you can import the referenced file so all of the items reside in the scene, and then select only those imported items, and export the selection as a reference again. In this way, all of the edits to the nodes and attributes will get written to the exported file reference.