Container Workflows

This topic describes typical scenarios in which you might use containers.

Using Containers to Copy and Update Scene Content (Local Referencing)

Workflow: Group objects into a container, transform them as a single entity, make copies, update the copies, and branch a container off for separate development.

Create a container in a scene.
The container displays in an open state. An open container is fully editable.
Add scene objects to the container.
The added objects are linked to the container as its children.

Two apartment models added to a container
Transform the container.
Any changes made to the container affect its contents as well.

Container contents repositioned in a scene
On the Manage Container rollout, turn on Auto Update When Closed, and then close the container and save it as Block_A.maxc.
Although the container contents are still visible in the viewports, effectively they are removed from the scene (for example, attempting to select the contents selects the container instead). The scene now references the Block_A.maxc file from its saved location.
Make two copies of the container, then reposition each copy where needed in the scene.
All containers reference the same Block_A.maxc file.

The original Block_A container (far left) and its two copies (middle and right)
Open one of the containers, and then try to open a second one.
A message appears informing you that the container can’t be opened while you’re editing its definition in another container. This helps prevent accidental overwriting of changed containers.
Create a new object in the scene, add it to the open container, and click Save.
Because the other containers reference the same MAXC file, they update as well.

All containers receive the added object
Select the open container copy and use Save As on the Local Content rollout to save it under a different name: Block_B.maxc.
The Block_B container is now branched off for its own development. Any further changes to it are not applied to the copies.

Block_B container (far right) is branched off. It is unaffected by updates to Block_A containers (left and middle).

Using Containers to Share and Edit Externally-Created Content (In-Place Editing)

Workflow: Inherit content from others, pass changes back to the original creator, and branch off from referenced containers for local development.

User B goes to the Container Explorer, clicks Inherit Container, and uses the Inherit Container dialog to open the Block_A.maxc file from the preceding procedure.
The container appears in the location in which it was saved from User A’s scene. At this point, user B can work with the container but cannot access its contents.

Container from User A (left) is inherited by User B (right)
User A makes changes to a building in the container and turns on Auto Update When Closed.
Changes to User A’s building (left) before closing the container
User A closes the container. User B turns on Auto Update When Closed and then automatically inherits the latest changes.
The container is automatically saved as it closes. Any time the container is saved and Auto Update When Closed is on for the inherited container, User B inherits changes to the content, whether User A closes it or not.

User B’s container (right) after inheriting changes from User A
User A is now ready to make his container editable by others. On the Rules rollout, he sets When Inherited, Allow Only Edit In Place, and then closes the container.
A warning icon next to the Update button for user B’s container notifies him that an update is required. Auto Update applies to changed content, but not changed settings for the container itself.
User B goes to the Manage Container rollout and clicks Update.
The Edit In Place button becomes available, so user B clicks it.

Note: In order for User B to edit the container, User A must have closed it. An Edit In Place container is available to only one user at a time.
User B makes her edits and clicks Edit In Place again to exit Edit In Place mode.
The container is closed and User A’s source definition is overwritten. The next time the author (or anyone else referen cing the container) loads the container, they will see the changes made by User B.

User A inherits changes made by User B

Note: When you use Edit In Place, the Container feature provides an automatic locking function to prevent people who are editing the same container from overwriting changes made by each other.
User B needs to make a copy of the container and use it for another project.
On the Inherited Content rollout, she clicks Merge Source Definition. The content is now local and behaves as if it was created from scratch in the current scene, rather than inherited from an external source. The container is now branched off; access is not limited by any rules.

Copied container (right) branched off and used in a different project

Using Containers to Manipulate Content and Set Visibility in a Complex Scene

Workflow: Close a container, unload the container to remove its contents from the scene, move the container helper to another area in the scene, and reload the container so its contents display in their new location.

Create three containers in a scene, close them, and save each with a unique name.
The containers are saved to disk and their contents, while still visible in the viewports, are removed from the scene. Scene performance is improved: It now takes less time to autosave, as well as to save and reload the scene file.

City scene with three saved local containers
Click Unload to remove the selected container’s contents temporarily.
City scene with one unloaded container
Move the unloaded container helper to a new position, and then click Load.
The container contents reappear at their new location.

Container moved down the street

Container contents reloaded

This is a fast way to toggle content in and out of a complex or data-heavy scene.

Using Containers to Control Content Editability (Manage Merge and Make Unique)

Workflow: Create a container and place second container inside it, allow edits to the main container, then inherit the nested container to prevent edits by others.

User A creates a container and adds the contents of a city block to it.
Container (right) with the objects of one city block added to it
User A creates a second container, adds a skyscraper to it, saves the container, and adds it to the first container.
User A now has a parent container, with another container nested inside.

Main container (right) with a Skyscraper container (left) nested inside
User A selects the parent container. Next, on the Rules rollout, he chooses Only Edit In Place, and then saves the container.
User A wants to protect the Skyscraper container from edits by others, so he selects the Skyscraper container, uses Inherit Content and picks the source definition, and saves the main container again.
Now the Skyscraper container is inherited into the main container, and access to its contents is prevented.
User B inherits the main container in her scene, then clicks Merge Source Definition. This places the container in the same state as it is in the author’s scene: The open container is editable, but the closed nested container is referenced and therefore uneditable.
User B (bottom) inherits Containers from User A (top)
User B decides she also needs access to the uneditable container, so she clicks Make All Content Unique.
The previously uneditable container opens but it no longer references the author’s source container. User B can now modify its contents locally for her own scene.

User B continues to work locally, building upon the work of User A

Using Containers to Control the Display of Objects In a Scene

Workflow: Set up container display so you can work on specific containers and hide the rest of the scene contents. Change the display setup without permanently changing the display organization of the scene.

For each container in the scene, turn on Display rollout Expand Bounding Box.
This makes it easier to identify which objects belong to which Container.

Three containers and their bounding boxes, showing the extent of their contents
Open the Manage Layers dialog and use it to set object display properties so that only certain types of objects can be viewed and worked on.
Scene with a layer of lamp objects visible
Right-click a container and set its Object Properties to By Layer.
With the container still selected, turn on Override Object Properties.
Far left Container’s display properties override other hidden object layers
Turn on Override Object Properties for all containers.
You can easily override object properties of selected containers from the Container Explorer or the Tools Containers submenu.
Right-click a container, choose Object Properties, then set Display Properties to By Object and See-Through.
Left container object display properties set to See-Through, in order to see objects behind it
In the Manage Layers dialog, click Render to turn off the renderability of the containers to the left and right, so you can quickly render only the part of the scene.
Renderability of left and right containers turned off

The renderable content of the scene is determined not by individual object or layer settings, but by container.

Parallel Referencing

Workflow: User A inherits a container from User B, User B inherits a container from User A, each user clicks Update to keep abreast of the other’s work. They click Allow Edit In Place to their own containers to permit changes by an external user.

User A is modeling a group of buildings in one container. User B is working on vehicle animation in a different container.
User A’s scene (top) and User B’s scene (bottom)
Both users inherit one another’s containers.
Users A and B can now work in parallel. They are developing their own components of a scene, while at the same time being able to see the progress of their colleague’s work.

User A (top) and User B (bottom) inherit one another’s scene components
User A selects his local container and on the Rules rollout, sets When Inherited, Allow Only Edit In Place, and then saves the container.
User B selects the container inherited from User A, and clicks Update. She then adds keys to User A’s container to sync the movement of the animated cars.
User B adds keys to extend animation into User A’s part of the city.
User A clicks Update to see the recent changes made by User B.
User A inherits the changes made by User B.