Search Tips

Search is based on keyword.

`Ex: "Procedures"`

Do not search with natural language

`Ex: "How do I write a new procedure?"`

Give Feedback Support Portal

# Guidelines for using CEL

#### Use CEL to Specify Light Lists in the LightLink Node.

There is only one node that does a collect operation while actually evaluating the Katana recipe: the LightLink node.

LightLink allows you to use a CEL statement to determine which lights to link to, which allows a lot of flexibility in selecting which lights are linked, but involves running a collection operation at runtime. How the CEL statements are used to specify the lights (and where those lights are in the scene graph) should be set up carefully to maximize efficiency and avoid having to evaluate too many scene graph locations. In general it is most efficient to use a list of explicit paths for the light list. If you need to use more general CEL expressions, such as those that use wild cards, it is best to make sure these only need to run to a limited depth in the scene graph. The worst case is an expression with recursion that potentially needs every scene graph location to be tested.

#### 'Find and Select' Isn't a Good Test for Efficiency.

It's inadvisable to run a Find and Select to test the efficiency of a CEL statement that is only going to be used for matching. For instance, the CEL statement //myGeoShape that only matches with locations called myGeoShape is very fast to run as a match when evaluating any location, but takes a very long time to collect because it has to expand the whole scene graph looking for locations with that name.

#### Make CEL Statements as Specific as Possible.

The expense is generally in running operations at nodes rather that evaluating if a location matches a CEL expression, so it's good make sure that nodes only run on the locations really necessary.

For instance: it's most efficient if a CEL statement can be made to only run on the correct locations, based on looking at the path name of the location. If the attribute values have to be tested, such as tests for the type of location, these tests are more expensive, as it requires the attributes at that location to be calculated as well.

Another typical case is using the CEL expression //*, which is a very fast expression to match but usually means that a node runs at far more locations than it needs to.

#### Avoid Extensive Use of Deep Collections.

Collections brought in by a Look File are defined at the root location that the Look File is assigned to. If those collections are only used in the hierarchy under the location they are defined at evaluation is efficient. However, if you refer to that collection in other parts of the scene graph then there is a cost as the scene graph has to be evaluated at the location the collection is defined.

A example where this can be a problem is if you've got collections defined at /root that reference a lot of other collections defined deeper in the scene graph. This means that to just evaluate /root you need to examine the scene graph to all those other locations as well.

#### Avoid Complex Rules in Collections at /root

Collections of other collections are useful and are efficient if all the collections are defined using explicit paths. If these collections are created using more complex rules, in particular recursive rules, you can run into efficiency problems.

#### Avoid Using '*' as the Final Token in a CEL Statement

There are optimizations in CEL to first compare the name of the current location against the last token in the CEL statement. For this reason, it's advisable to have a specific last token in a CEL statement, instead of using '*' as a wildcard. For instance, if you've got a rule to only run on geometry locations that end with the string Shape it's more efficient to have a cell expression such as:

/root/world/geo//*Shape

rather than

/root/world/geo//*.

#### Paths versus Rules

CEL has a number of optimizations for dealing with explicit lists of paths. This means using paths are the best way of working in many cases, and matching against paths is generally very efficient as long as the list of paths isn't too long.

As a general rule it's more efficient to use explicit lists of paths than active rules for up to around 100 paths. If you have explicit lists with many thousands of paths you can run into efficiency issues where it may be very worthwhile using rules with wildcards instead.

Select and Collect operations are always more efficient with an explicit path list.

#### Use Differences Between CEL Statements Cautiously

Taking the difference between two CEL statements can be expensive. In particular if two CEL statements are made up of paths when you take the difference it's no longer treated as a simple path list so won't use the special optimizations for pure path lists. Single nodes with complex difference based CEL statements can often be more efficiently replaced by a number of nodes with simpler CEL statements.

Note: Find out more about CEL in the Katana Developer Guide: CEL Reference.