Traditionally, materials are explicitly assigned to sets of primitives defined by geometries and called shading groups. This type of workflow makes it very difficult to replace geometries in shots or to switch their set of materials. To resolve these issues, Clarisse introduces Shading Layers.

Shading Layers are items dedicated to dynamically assign materials in renders. They've been designed with this simple idea: instead of explicitly storing material assignations at the geometry level, assignations should be stored in a high level item to make them geometry-independent and re-usable.

## Overview#

Shading layers are based on rules that each define corresponding rendering properties: materials, shading variables, displacements, clip maps. They are managed by the Shading Layer Editor. In shading layers, rules are used to identify items in the render. More importantly, rules are soft links: this means properties set in shading layers are not transferred to items. For example, if one of your geometry has already a material applied using either an Override Material or the Material Linker, its properties won't be physically modified. The soft link is only resolved as a pre-process when the render starts during the evaluation.

To create an empty shading layer use Create > Shading Layer. You can also create a pre-filled one from the selection (single or multiple) by using the Edit > Create Shading Layer menu from the main application menu. If you select Create Shading Layer > Use Relative Names, the shading layer rules will be defined with relative paths. Using Create Shading Layer > Use Absolute Names will define rules with absolute paths.

Note

When creating a shading layer from a selection, the resulting shading layer contains all extracted shading group and material associations so that it's ready to use. |

Shading Layers are assigned to the attribute Shading Layer in Layer Scenes or Render Scenes. You can also assign shading layers to the 3D View which obviously works when rendering mode is set to at least Previz.

On typical production scenes, shading layers can be easily made of several thousands of rules. Having thousands of rules in a single shading layer can get very difficult to manage. For this reason, Shading Layers have been designed to support the concept of hierarchy. This way, you are free to fragment your work in any numbers of shading layers you like. Then, assemble your final shading layer by parenting shading layer fragments.

Please note the shading layer hierarchy is completely unrelated to the scene hierarchy. The simplest way to fragment shading layers is to define a single shading layer for each geometry.

## Understanding Rules#

A rule defines an item path and a set of properties such as visibility or material assignment, shading variables definition... The item path of a rule locates one or multiple geometries or geometry components such as shading groups.

Now let's say we have an object named project://f40_layer0 in the scene and we would like to assign a material project://normal to all of its shading groups. To do that, we would just need to create a new rule in the shading layer where we would set the filter to project://f40_layer0 and the material to project://normal.

One fundamental thing to understand about shading layers is that rules act as overrides. When shading layer rules don't target items, they are left unchanged. In other words, such items still have their materials as defined in the Material Linker or Material Override.

### Rules Evaluation Order#

Rules are evaluated using a top down scheme. The first rule is evaluated before the second one and so on. Rule evaluation stops when no more items are available. Basically, the first rule gathers all items in a list. When the rule is processed the remaining unprocessed items are passed to the next rule and so on until no more item or rule are in the list.

For example, if you have 10 different rules with the first one being * the 9 others won't be even processed. In this example, the first rule affects all items in the project. Now if the * rule comes in second position, the first and the second rules are processed and the evaluation stops at the third one.

### Override Order#

By default, shading layers override any settings defined by items. For example, if you set a rule to * all items get overridden by the rule. However, it is possible to change this behavior so that only items not defining settings get overridden.

To change the override behavior, select the shading layer and using the Attribute Editor set Data Source Priority attribute to Objects data has priority. To set the shading layer behavior back to default, set Data Source Priority to Rules data has priority.

### Item Paths#

Unless specified otherwise (project:// or *), all input paths are relative. You may explicitly set a relative path by starting the path with ./

#### Relative Paths#

A path is relative when it is relative to the shading layer location in the project. For example, when your shading layer name is:

project://asset/geometry/f16/f16_shading_layer


When expanding the item path the shading layer will consider its root to be:

project://asset/geometry/f16


Relative paths are extremely useful as they are project location independent: you can freely move the context f16 anywhere else in the project and rules won't be affected.

##### Search Paths#

Clarisse introduces a powerful item called the Search Path. The Search Path allows you to specify a search path which will be used when resolving Shading Layer or rule-driven group relative paths. Instead of systematically resolving the path from the project location of the shading layer or the group, it is possible to set one or multiple root context that will be used for resolving relative paths.

Let's imagine we have a shading layer in project://scene/lookdev which defines a single rule ./box*. This rule means that everything named after box something in the current context of the shading layer (located in project://scene/lookdev) will pickup the material defined by our rule. Before Clarisse 3.0, we were forced to set our box in project://scene/lookdev. We couldn't move them, for example, in a more convenient location such as project://scene/assets without editing our rules.

Using a Search Path it is possible to have all our boxes in a custom context, project://scene/assets/ for example, without the need of modifying/editing the rules of our shading layer.

We just have to create a Search Path item, set its path to project://scene/assets and connect it to the Search Paths attribute of the shading layer. When the rule gets resolved it will use the path specified in the Search Path to locate the items.

Thanks to multiple paths support, we can also put our boxes in multiple contexts. For example, project://scene/assets/part1 and project://scene/assets/part2. To do this we just need to set the Paths attribute of our Search Path to:

project://scene/assets/part1;project://scene/assets/part2


Note

Search path also supports relative path such as ./ When using relative paths, they resolve to the location of the shading layer. For example, in our previous example our shading layer was located in project://scene/lookdev. If the Search Path is set to ./ for our shading layer, it will then logically resolve to project://scene/lookdev as it is the context where our shading layer lies. Search paths also support world space based path using the prefix world://

#### Absolute Paths#

Absolute path always starts by either project:// or the wildcard *. Absolute paths starting with project:// are recommended when the context hierarchy structure of your projects is static. Indeed, if you define a rule starting with project://shot001 and you move shot001 context into project://seq001, then all rules starting with project://shot001 won't find any item unless you explicitly edit them.

#### World Paths#

Instead of using project paths to locate objects, you can use world path (parenting animation hierarchy). World paths always starts by world://

The general syntax is very straight forward. If you wish to locate child

world://grandfather/father/child


If you want to locate only grandfather:

world://grandfather


If you want to locate recursively every single child of grandfather (father and child):

world://grandfather/*


World paths are recommended when the hierarchy structure of your project is meaningful shading wise. They can be very useful as they let you organize your project freely. Context hierarchy is not taken into account for world path resolution.

A shading group is an item component. To specify a component in a path you need to use the character >. For example, if you wish to specify a rule locating a specific shading group, you would write:

project://f40_layer0>car_paint


#### Wildcards#

Item paths support wildcards. The wildcard character is *. * and means literally everything so that the simplest valid item name path is *. For example, if you wish to assign the same material to every single item in your project you would create a rule with * as item name path.

You can use as many wildcards as you want in an item name path.

• */scene/*item locates any item which name ends with item and that is in a context named scene somewhere in the project.
• */scene/*item* locates any item which name has item in it and that is in a context named scene somewhere in the project.
• */scene/*item*>*paint* locates any item which name has the word item with a shading group name having the word paint and that is in a context named scene somewhere in the project.

Performance Tip

Favor relative rules and avoid using rules that start with a wildcard *. The closer the wildcard is to the beginning of the rule, the more potential items the rule will be tested upon for pattern matching. To keep performance high, try narrow down the rule so that the wildcard is located at the end of the rule: project://test/my/asset*