User guide

46
CEL In the User Interface
In the UI a standard CEL Widget interface is provided for CEL expressions. For the convenience of users this allows
users to build CEL expressions out of three different types of component (called statements):
• Paths – these are explicit lists of scene graph paths.
If you drag and drop locations from the Scene Graph view onto the 'Add Statements' area of the CEL widget you
will be automatically given a CEL expression that based on those paths.
• Collections – a pre-defined named collection of scene graph locations.
Essentially these are arbitrary sets of locations that are handed off for use downstream in the pipeline. Collections
can be created in a Katana scene using the 'CollectionsCreate' node, and can also be passed from one Katana
project to another using Look Files.
• Custom – These allow complex rule based expressions, such as using patterns with wildcards in the paths, or 'value
expressions' that specify values that attributes must have for matches.
Please see the Katana User Guide for a more complete description of how to use the user interface to specify CEL
expressions.
Guidelines for Using CEL
Using 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.
'Collect and Select' isn't a Good Test of Efficiency
It's wrong to run a 'Collect 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 will take a very long time to collect because it will have
to expand the whole scene graph looking for locations with that name.
7 SCENE ATTRIBUTES AND HIERARCHY | CEL IN THE USER INTERFACE