Skip to content

Working With Items#

Clarisse Workflow#

Clarisse is a powerful 3D DCC offering features ranging from node-based scene assembly1, set-dressing, lookdev, lighting, rendering to node-based compositing1. These features are fully integrated within a single unified workflow that relies on a procedural object model-based approach, very similar to a node-based workflow where you connect nodes to each other.

The main difference between the node-based workflow is that instead of connecting nodes you connect Items which are nodes defining attributes driving an engine. The complete workflow of Clarisse is then extremely simple and straight forward since you just create items, modify their attributes and connect them to each other. As a matter of fact, when you work in Clarisse, you are technically building a giant dependency graph of items connected to each other that only gets evaluated when needed.

What are items?#

There are two types of Items to consider in Clarisse: Objects and Contexts. While items can both define user-modifiable attributes, Objects define single concepts such as lights, materials, renderers, widgets... whereas Contexts are containers or generators of items containing both objects and sub-contexts. Ultimately, the general user workflow of Clarisse is basically to create and organize items using the Browser or the Explorer widgets*. Item attributes are displayed and manipulated using the Attribute Editor widget and scene items are displayed using in the 3D View. Finally renders are triggered and visualized via the Image View.

* In Clarisse, a widget is a user interface element designed to let the user display and manipulate items such as a 3D View or an Attribute Editor. For more information about widgets please refer to Viewports and Widgets


For more information about contexts, objects and classes make sure to read Contexts, Objects and Classes section.

Item organization#

In the same way you would create files and folders in a physical drive, items live in a global repository that is called the build. The build is the top most context of the application where all items are created and organized and like in a filesystem, items are identified by paths. To reuse, the filesystem analogy, the build can be seen as a drive.

Item path#

While user-created items are always stored in the build, Clarisse supports a rather sophisticated path system which offers different path resolvers to identify items. The syntax of paths in Clarisse is very simple. It always follows this construction scheme:


where resolver is the name of the Path Resolver that is used to interpret the path which is a sequence of item names separated by a slash / that defines a hierarchy.

For example:


Path Resolvers#

The role of the resolver is to translate a given path into an actual Clarisse item. While the native internal hierarchy is created through the build, Clarisse offers several standard path resolvers to identify items that are more suitable for certain types of tasks:

Resolver Description
build This is the native path to items which reflects the actual way items are stored in the global repository of the application.
project Identify items relatively to their root context which is the top most context located in the build. For example: project://box can either resolve to build://scene/box or to build://my_other_scene/box. Since project paths are always resolved relatively to a root context of the build, a project path always ensures to identify a unique item in an evaluation.
world Identify items based on the kinematic hierarchy. The kinematic hierarchy is the standard animation hierarchy found in traditional 3D animation packages. It is defined by the value of the Parent attribute of Scene Items.
default Used internally to identify persistent and read-only items that are shared across the application. This is where the default material is defined for example.
tools Used internally to identify instances of Tools.
widgets Used internally to identify instances of Widgets.
ext Used internally to identify external items which are missing/unknown because they are defined in a file that hasn't been loaded in the build yet.


It is possible to extend Clarisse resolvers to support custom path/hierarchies using the API.

Path Examples:

  • build://box identifies an item named box in the build
  • project://box identifies an object named box that is located in any contexts that is a direct child of the build.
  • build://scene/box identifies an item named box located in a context named scene in the build.
  • default://material identifies the default material of the application which is a material object located in default.
  • world://locator/box identifies an object named box that is parented to an object named locator in the 3D scene.

Items name limitations#

Item names can't start with a digit and only support underscores and alphanumeric characters.

For example:

  • "3D Box" will be automatically converted to _3D_Box

Also, since items are always owned by a parent context, they always have a unique name within their parent. In other words, there can't be 2 items with the same name in a given context.

In the event of a name collision, items get automatically renamed by the parent context to ensures that each child has a unique name in the context. However, nothing prevents items to share the same name as long as they belong to different contexts.

For example:

  • build://my_assets/box and build://my_scene/boxbuild://box are both valid names.

File Output#

Clarisse generates many different types of files like Alembic, USD or images but the actual work created during a session of Clarisse is either saved as a project file or a build file.

Project File#

The project file is the file resulting from a Clarisse iFX session. It contains the entire content of the root project context and also includes user interface layout and preferences.


It is possible to export a project file from a non scene assembly context of the build in Clarisse BUiLDER. When you export such context from Clarisse BUiLDER, you lose the procedurality of the build. This is still handy to output project files that are meant to be used by Clarisse iFX.

Build File#

The build file is a superset of the project file. It is the most complete representation of a Clarisse session since it describes a complete procedural graph of atomic operations defined using the build assembly workflow of Clarisse BUiLDER.


While Clarisse BUiLDER can both load project and build files, Clarisse iFX is unable to load build files.

Simple Example#

Let's see a concrete example with a very simple scene.

What's a scene?#

In Clarisse, a scene is an item defined by a camera, a renderer (defining render settings) and a list of lights and scene objects. While Clarisse can be extended by 3rd party renderers that can declare their type of scenes, Clarisse comes by default with its own internal render scene definition defined by its built-in rendering engine. For more information about render scenes please refer to Rendering in Clarisse.

A simple scene in Clarisse

Below is the actual dependency graph of all the items and their connection to display the rendered box in an image.

flowchart LR
B-->C(Layer Scene)
C-->H(3D View)
G-->I(Image View)

If we look at the dependency graph above, we can clearly see the relationship of all the objects. The Layer Scene (defining a render scene in a layered image) is composed of:

The Layer Scene is connected to both a 3D View and an image which is itself connected by the Image View. What's interesting here is that it's only when the image is displayed in the Image View or when the 3D View displays the scene that Clarisse triggers an evaluation.

How does Clarisse evaluation engine work?#

One very important aspect of Clarisse's workflow is that evaluations are automatically triggered when needed. There's no "Render button" or any user actions involved to render an image:

Renders are automatically triggered when an Image object is displayed in the Image View. This is very important since by design data is always loaded and computed on an as-needed basis following a pull pattern. In other words, it's only when a scene is displayed in the 3D View or a render is viewed in the Image View that the evaluation starts.

Evaluation Breakdown#

If we look at our previous example, when we display the image object in the Image View, the Image View pulls the image data from the image object:

  1. The image object, then evaluates (if it didn't already) its image layers which is a Layer Scene in this case.
  2. The Layer Scene then requests to the input Renderer to render the scene as an image from the input Camera.
  3. The Renderer launches rays from the Camera, eventually hits the Box which gets dynamically loaded from disk if not in memory. The Renderer then computes the pixel color evaluating both the material and the light and this operation is repeated for each pixel of the image.
  4. The Layer Scene gives the result back to the Image object which in turn gives it back to the Image View to display it!

All this is happening automatically under the hood without any user interventions besides displaying the image object in the Image View.


By default, Clarisse engine uses all the available threads of the system. To maximize performance, the evaluation engine of Clarisse utilizes up to all the CPU cores available on the hardware it is running on.

Under the hood, evaluations are split into tasks that are broken down into jobs. These jobs are then asynchronously processed by the number of worker threads available in the application.

Limiting the number of worker threads#

It is possible to limit the number of worker threads in the Application Preferences. Go to Edit > Preferences... The maximum number of cores Clarisse is allowed to use for its evaluation is controlled by the Max Core Count setting found in the Application/Evaluation section of the preferences. Simply set it to the number of cores you wish to allocate to Clarisse.


This setting can be changed at any time. The effect is immediately taken into account even when there's a running evaluation in the background

  1. Only available in Clarisse BUiLDER.