User guide

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: if you've got an AttributeScript that should only run on certain types of location it is better to have that

test as part of the CEL statement so the script doesn't run at all on locations of the wrong type, instead of having a

less specific CEL statement and the test for the correct location type inside the script itself.

Another typical case is using the CEL expression //, which is a very fast expression to match but will usually mean that

a node will run at far more locations than it needs to.

Avoid Using 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. If that doesn't match we can exit very quickly as we definitely haven't got a match. For this reason it's

good if you can have a more specific last token in a CEL statement than '*'. For instance, if you've got a rule that is to

only run on geometry locations that will all end with the string 'Shape' it's more efficient to have a cell expression

such as

/root/world/geo//*Shape than /root/world/geo//*

7 SCENE ATTRIBUTES AND HIERARCHY | GUIDELINES FOR USING CEL