Please enable JavaScript to view this site.

Clarisse 5.0 Reference Guide

Navigation: Using Clarisse

Understanding the Workflow

Scroll Prev Top Next More

Clarisse is a powerful 3D DCC offering features ranging from scene assembly, set-dressing, lookdev, lighting, rendering to nodal compositing. These features are fully integrated within a single integrated 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.

 

* 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.

Items 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.

Items path

While user created items are always stored in the build, Clarisse supports a rather advanced 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:

item = resolver://path

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:

build://project/assets/environments/buildingA/windowB

Path Resolvers

The role of the resolver is to translate a given path into the 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.

Note

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

build://my_scene/box

build://box

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.

Note

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.

Note

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

A simple scene in Clarisse

 

 

Dependency graph of the simple scene

Dependency graph of the simple scene

 

 

If we look at the dependency graph of that simple scene, we can clearly see the relationship of all the objects. The Layer Scene (defining a render scene in a layered image) is composed of a material assigned to a box, a light, a camera and a renderer connected to a Layer Scene. 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. For example, 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. The image object, then evaluates (if it didn't already) its image layers which is a Layer Scene in this case. The Layer Scene then requests to the input Renderer to render the scene as an image from the input Camera. 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. 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.

 

Isotropix

Copyright (C) 2009-2022 Isotropix. All rights reserved.