Scene Assembly Nodes#

The Scene Assembly nodes are a set of nodes used to generate, manage organize and edit scene content. There are 3 categories of Scene Assembly nodes:

1. Scene Generator nodes to generate items or bring assets/scenes (USD, ABC, Clarisse projects…) into the build assembly.
2. Editing nodes to perform editing and overriding type of operations on items
3. Item Management nodes to filter, merge, prune items.

Scene Generator Nodes#

Scene Generators are nodes which provide a collection of scene items. They are typically containers that can be used to directly create scene items or to bring assets such as Alembic or USD caches and Clarisse projects into the build. With the exception of Context and Reference nodes, Scene Generators support lazy evaluation and provide on-demand partial asset loading.

For example, depending on the rule set on an Isolate node connected to a Read Abc, the Read Abc, may be requested on a small part of the asset it defines. In that case only the request and needed part of the Alembic cache scene ends up being loaded.

Context#

The Context is the simplest scene generator available in Clarisse. It’s a very flexible container on which you are free to create, edit and remove any number and any type of items.

However, unlike most other scene generators, contexts don’t specify any filename. Their content is directly saved in the build file. As a result, the content of contexts is always loaded upfront at the same time as the build. In other words, the content of contexts isn’t loaded on an as-needed basis.

Read Abc#

The Read Abc node brings an Alembic cache in the build. The node is only evaluated when setting the node or a downstream dependency as vizroot or if part of an evaluation during rendering. In other words, the content of the Alembic cache is only read when needed.

This node status bar displays useful information in the Build View.

Read Usd#

The Read Usd node brings an USD cache in the build. The node is only evaluated is only evaluated when setting the node or a downstream dependency as vizroot or if part of an evaluation during rendering. In other words, the content of the USD scene is only read when needed.

This node status bar displays useful information in the Build View.

Read Project#

The Read Project node brings a Clarisse project in the build. The node is only evaluated when setting the node or a downstream dependency as vizroot or if part of an evaluation during rendering.

In other words, the content of the Clarisse project is only read when needed.

External Dependencies#

Sometimes input projects can have external dependencies. This typically happens if the project was exported while it was using items defined in another file such as described here.

In that case, you need to use a Merge node to locate and resolve external dependencies.

This node status bar displays useful information in the Build View.

Reference#

The Reference node brings a Clarisse project as a reference. As a result, the content of the node is always loaded upfront at the same time as the build so unlike Read Project it isn’t loaded on an as-needed basis. Unlike Read Project nodes, items are not read-only. It is possible to directly edit items in the reference without the need of Edit or Override nodes. We strongly recommend you not to use Reference nodes in your build but use Read Project ones instead.

This node status bar displays useful information in the Build View.

Editing Nodes#

In the build assembly, you can’t directly modify attributes of items coming from Scene Generators or Item Management nodes. Only items created at the top level of the build assembly can be freely modified. If you set a node as vizroot, and select an item in the Explorer, you’ll notice that you can’t edit its attribute via the Attribute Editor because they are read-only. This is perfectly normal because the workflow has been designed to be a flow of successive operations where you explicitly have to use nodes to perform specific operations at one point of your build. Editing is one of them, so you must use an editing node to set at which point of the build the modification on the item occurs. As a result, items can have multiple representations throughout their life in the build assembly.

The build assembly provides a set of specialized editing nodes to either edit items individually or apply edits on multiple items at the same time.

Edit#

The Edit node applies a set of modifications on items coming from an input Scene Assembly node. The Edit node also can be used to create new items and remove existing ones without the need of using additional set of nodes.

Unlike in Clarisse iFX References, you can’t directly modify an item located in a Edit node. Indeed, if you display an item of an Edit node in the Attribute Editor, its attributes will be displayed as read-only. To edit an item you must explicitly mark it as editable.

Editing items#

To edit items, you must first explicitly set your Edit node as vizroot. Then using the Explorer, for example, Right Button on the item you wish to edit and choose Edit on the popup menu. Once the item is marked as editable you can freely modify its attribute values.

Creating new items#

Just set the Edit node as vizroot and create the item the way you normally would in Clarisse. If you select the Edit node in the Attribute Editor, it is possible to see the list of newly created items via Added Items attribute.

Deleting items#

Just set the Edit node as vizroot and delete the item the way you normally would in Clarisse. If you select the Edit node in the Attribute Editor, it is possible to see the list of deleted items via Removed Items attribute. To bring back a removed item, just remove the entry from the Remove Items list.

Clearing all edits#

To clear all edits of your Edit node in place while preserving your build assembly, select your Edit node and press on Remove All Edits in the Attribute Editor.

This node status bar displays useful information in the Build View.

Override#

The Override node applies modifications to a set of item attributes using by a rule. The Override node is useful when you want to apply a specific edit to a group of items at once. For example, you would create an Override node to toggle the Display Visible attribute of all incoming items.

Adding Overrides#

There are two ways to add an attribute overrides. The first one is by Right Button on the attribute name you wish to override in the Attribute Editor and select Override in the pop-up menu.

This will create a new attribute override in the Override node. To view the newly created attribute override, just select the Override node so that the Attribute Editor lists all available attribute overrides.

The second way of creating attribute overrides is by using the Override Creation Window. To add a new override, select the Override node to display it in the Attribute Editor. Then on the Override tab, Right Button and select Override > Create.... A window should popup letting you create your override.

Once you’ve set your override, press Ok and your override will appear in the Attribute Editor.

Editing Overrides#

To edit an existing override, select the Override node to display it in the Attribute Editor. Then Right Button on the override you wish to edit and select Override > Edit.... A window will popup letting you edit your override.

Removing an Override#

To remove an override, select the Override node to display it in the Attribute Editor. Then Right Button on the override you wish to remove and select Override > Remove.

Removing all overrides#

To clear all overrides of your Override node in place while preserving your build assembly, select your Override node and press on Remove All Overrides in the Attribute Editor.

This node status bar displays useful information in the Build View.

Item Management Nodes#

Item Management nodes are a set of nodes that allows you to procedurally manipulate scenes using rules in order to define, in a non destructive way, the content of render scenes. Item Management nodes can operate on two distinct hierarchies at the scene time during scene assembly:

• The traditional kinematic (or parenting) hierarchy where items are parented to each other and generally meaningful to animators.
• The context hierarchy which is an asset based hierarchy designed to help you organize your render scenes specially for rendering and layering visibility while being free of the constraints of an existing kinematic hierarchy.

Merge#

The Merge node merges multiple inputs together in order to assemble scenes. For each input, the Merge node allows you to specify locations where the merge should be performed for both context and kinematic hierarchies. In the event the specified context or kinematic locations do not exist, the Merge node automatically inserts missing contexts or locators respectively.

Base input#

The Base input defines the root of the merge node so that all merging operations are performed into the Base input. For example, if you connect a context1 with a box inside as Base of a merge node, the resulting location of the box will be in the root of the merge node.

Please note that you can omit to set a Base input as it is possible to set the location of each input node so that they their content is merged into the root of the merge node for example.

<Input> tag#

By default input contexts item locations are preserved in merge nodes. So, when you connect a context1 with a box inside, as input of a merge node, the resulting hierarchy of the merge node contains context1/box located at the root of the merge node.

However, it is possible to change this behavior by removing the <Input> tag of the input’s Context location. When no location is provided, the merge node merges the content of the input in its root.

Item collision handling and importance of the order of merge inputs#

It is possible to have inputs for which contents may collide with each other when merged. This can happen in the event your Merge node has two inputs that are defining items with same names merged in the same destination.

For example, let’s say you have a two contexts context1 and context2 both defining an item named box. Let’s imagine that the box in context1 is translated in to (-5, 0, 0) and the one in context2 translated to (5, 0, 0). Finally let’s say context1 is the first input of our Merge node and context2 the second one and both locations are empty so that the content of each input is merged to the root of our node.

We get a collision between the two box here and to solve this collision the Merge node always favors the last input over others. In other words, the resulting box in the Merge node is the one located in context2 (context2/box). As a matter of fact this behavior is very useful because it allows you to work in layers of modifications.

Merging External Dependencies#

When you assemble projects through ReadProject nodes you may see a question mark icon located in the bottom left of a vizroot node:

This indicates that at least one of the inputs of the merge node is defining external items. Note that you can also visualize the external items using the Explorer by simply setting the vizroot to the merge node.

Externals will always be displayed within the ext:/ root:

When that happens, you can use the Dependencies input of the merge node to resolve them by simply plugging contexts or projects defining dependencies into Dependencies.

Please note that it is also possible to specify a mount point path for each dependency in order to relocate them before being merged when necessary.

Mount Point#

Specifying a Mount Point is useful to resolve external paths in some cases. Let's say for example that in one of the merge input we have a scatterer needing an external assets/rock.

The idea is to bring the project defining the missing assets/rock external dependency using a ReadProject.

Then to relocate the external, we need to plug it to the Dependencies attribute of the merge node and set its Mount Point to assets using the Attribute Editor.

Destination#

Specifying a Destination is useful to bring the resolved external dependencies into a destination context. Indeed, this is useful since resolved external items are always hidden as if they were isolated (see Isolate).

Transmit Externals#

When Transmit Externals is enabled, external items are transmitted down the scene assembly graph so that they can be resolved later on, in the graph, using another edit node. This is the default mode.

However, when Transmit Externals is disabled, external items no longer exists after the merge node. In fact, items with externals are then no longer connected to their external dependencies as if they didn't exist.

For example, let's say we have a combiner combiner with its Objects list linking to a external box item. In an edit node set up with Transmit Externals off, the Objects list would be empty (once output from the edit node) as if that connection to box never existed.

Isolate#

The Isolate node isolates the content of an input based on rules. The Isolate node is meant to filter out part of an incoming scene or asset. Note that Isolate is a non-destructive operation. Connection to items from the incoming scene are still kept even if they are not part of the isolate selection. These item are simply hidden at the output of the Isolate node. In other words, Isolate can be used to filter out a complex setup to expose in the build only the items you want.

For example, let’s say you bring a Clarisse project describing a complex environment made with scatterers using a lot of geometries that are already lookdeved. If you use an Isolate node to filter out everything except the scatterer, the scatterer will still render fine even if its dependencies are not exposed to downstream nodes in the build.

Isolate Mode#

The Isolate Mode allows you to control the resulting or destination path of the isolated sub-scene. It is very useful to relocate part of your scene in a specific context using a merge node. For example, let's say we have isolated the following asset: /path/to/my/asset/final_version/my_asset

By default, Isolate Mode is set to Keep Full Parent Context Hierarchy, so original paths of items are kept. This means that if you are then merging /path/to/my/asset/final_version/my_asset to a /asset context, you will get the following hierarchy: /asset/path/to/my/asset/final_version/my_asset

Fortunately Clarisse provides you with several modes to control the path after an isolation:

Prune#

The Prune node removes the content of an input scene assembly node based on rules. Unlike the Isolate node, the rule of the Prune node targets the elements you want to remove. Moreover, the difference doesn’t only stop there as pruning is a destructive operation. When you prune elements that are connected to each other the connection are severed as if the dependency didn’t exist.

For example, let’s say you bring a scene that has a box and a material. When you prune, the material, the resulting box has no more material assigned. The pruning operation acts as if you had removed the items using an Edit node.