The table below contains a list with all available LPE events in Karma’s CPU and XPU render engines. “Terminating event” means that the event is expected to be at the end of a Light Path Expression. Here’s a common definition for a fully described event - the individual components are discussed in the following chapters of this guide:

<event_type scatter_type['tag'['bsdf_label']]>

Brackets are used to combine events and there’s a difference between angle brackets, squared brackets and events without brackets.

• Angle brackets are used for fully describing an event. Even if the brackets contain multiple tokens, they're considered a single event. For example, <RD> matches only diffuse reflection.

• Symbols without angle brackets are shorthand tokens. For example D includes diffuse scatter events meaning [<RD><TD>].

• Square brackets match any event within the brackets. For example, [LO] matches either light or emission.

• [^DG] would match anything except diffuse or glossy scattering.

• Expressions without brackets require all events in the given order. For example, RD means that D must follow R.

The image below shows the difference of an LPE with angle brackets (C<RD>.*[LO]) and without brackets (CRD.*[LO]).

Wildcards and quantifiers let you define repetitions or you can limit the result to certain events. Wildcards are perhaps the most abstract part in conjunction with LPEs, because it’s often not obvious how to use them. When you read about wildcards, you typically get descriptions like “matches zero or more repetitions of an event”. Since LPEs are about the interaction of light rays with surfaces, you can translate the above term into “hits zero or more surfaces”.

The ! operator negates the LPE’s output and must appear in front of the entire expression. You can find an example below.

The following table shows all relevant symbols in the overview.

However, even the longest list can be incomplete. For custom LPEs, open the Extra Render Vars section and increase Render Vars. You’ll then see a set of parameters where you can define a new AOV. Only when Source Type is set to LPE, you can add a custom LPE to the Source Name input field.

Here you’ll extract the transmissive part of a glass object. When you look at the first table above, the expression should be straightforward, because the path is camera → glass transmission → light source. According to the table, the LPE is CTL and this is already a valid expression, but not very specific.

Let’s try a more sophisticated example. Imagine a glass sphere that occludes several objects and your LPE should detect only scene elements behind the sphere. The CTL expression will fail here, because the light path has to go through the glass surface at least twice to reach a light source. The current expression only has a single transmission event before reaching a light, which matches none of the existing light paths. To include paths that have arbitrary number of events, you need wildcards and quantifiers. The most obvious LPE is therefore C<TG>.*L. This will match any path that initially goes through glossy transmission, then goes through any number of events, and eventually reaches a light.

Now you can also include emissive objects. LPE are always evaluated from the camera in direction of a light source - the end point. The path can end at a “traditional” light source or an emissive object, so both sources are considered. You need square brackets for this kind of differentiation: C<TG>.*[LO].

Alpha transmission is a good example for the negate operator. The following expression creates an alpha plane from transmissive objects. The syntax for this LPE is exactly the same as with the Transmission example in the previous chapter. The only difference is that the terminating event is not a light source, but the background B. So, you can write C<TG>*B.

For compositing, it’s necessary to invert the result and you can do that with the ! operator. Remember that ! must always stand in front of the entire expression. The final LPE is therefore!C<TG>*B.

In this example we want to catch light that’s reflected from diffuse surfaces: direct diffuse reflection. When you look at the first table, the required events are C, D and L. The most obvious first solution is therefore CDL. The D event, however, includes both diffuse reflection and diffuse transmission. So, you’ll end up including even SSS which might not be desired.

The LPE has to be more specific and to consider diffuse reflection, replace D with <RD>. The correct expression is then C<RD>L.

If you change you change the LPE to C<RD>.*L, you’ll get one or more events followed by diffuse reflection before reaching the light, and therefore the indirect diffuse reflection.

Caustics are any paths that interact with a rough (or diffuse) surface followed by a glossy surface before hitting a light source. Let’s try to extract the refractive caustics from the glass sphere. Note that the expression only works with caustics that are directly visible by the camera. Caustics behind a glass pane, for example, won’t be detected.

• Everything starts with a camera C.

• The first part here is the diffuse scatter event D when a ray hits the floor.

• The key event is that such a diffuse hit has gone through a transmissive object T one or more times (+).

• The light source L is the end point.

The complete LPE for caustics from the glass sphere is therefore CDT+L. This expression will strictly detect rays from transmissive objects. If you want to consider all types of caustics (reflective or refractive), you need a more robust expression like CDG+L.

A volume → glossy → light path is also considered a caustic path. If you want to capture diffuse surfaces or volumes, change the expression to C[DV]T+L.