> For the complete documentation index, see [llms.txt](https://stage-precision.gitbook.io/grid/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stage-precision.gitbook.io/grid/spatial-interactive-experiences/applications/trigger-based-interactions.md). # Trigger-Based Interactions Many interactive installations do not need continuous position data. Sometimes the important information is simply: **Did something enter this area?** **Is somebody currently present?** **Did a tracked object arrive or leave?** Grid Studio provides two Zone types for these kinds of interactions: * **Trigger Zone** — reacts directly to point-cloud points * **Presence Zone** — reacts to final tracked clusters Both can generate Workflow Events and can therefore be used to connect spatial sensing directly to application logic. This page focuses on how to design reliable trigger-based interactions. For the step-by-step creation and configuration of Zones, see **Building an Interactive Tracking Project**. *** ### Choose the Right Type of Zone The first decision is whether the interaction should react to raw spatial measurements or to tracked objects. #### Trigger Zone A Trigger Zone evaluates points from the point cloud. It does not require clustering. This makes it useful when the question is simply: **Is there enough physical activity inside this area?** Typical applications include: * Breaking an invisible spatial boundary * Detecting interaction with a physical area * Simple proximity interactions * Detecting something entering a defined space * Applications where object identity is irrelevant A Trigger Zone can generate: * **Occupied** * **Empty** #### Presence Zone A Presence Zone evaluates the final clusters produced by the Point Cloud Volume. This makes it useful when the interaction depends on detected objects rather than individual sensor points. Typical applications include: * Detecting people inside an area * Room or area occupancy * Triggering content when a tracked object arrives * Reacting when individual tracked objects enter or leave A Presence Zone can generate: * **Occupied** * **Empty** * **Object Entered** * **Object Left** {% hint style="info" %} Use a Trigger Zone when the presence of point-cloud data is enough. Use a Presence Zone when the interaction should depend on the tracked objects produced by the clustering pipeline. {% endhint %} *** ### Design the Zone Around the Interaction A Zone should represent the physical interaction that the user understands. For example, if someone is expected to trigger an effect by walking through a doorway, the Zone should represent the useful interaction area around that doorway rather than a large arbitrary volume. The same principle applies to: * Entrances * Stage positions * Interactive exhibits * Product areas * Projection regions * Waiting areas * Restricted areas Smaller and more intentional Zones usually make the resulting logic easier to understand and tune. The Zone can use either a **Cube** or **Sphere** shape depending on the physical interaction. *** ### Do Not Make the Boundary Too Precise Real sensor data is not perfectly static. A person standing close to the edge of a Zone may produce measurements on both sides of the boundary as they move, change pose, or become visible from different sensors. Avoid designing interactions that depend on millimeter-precise Zone boundaries unless the sensing system and application specifically support that requirement. Where possible, allow some physical tolerance around the intended interaction. This is particularly important for: * Doorways * Walking triggers * Areas where people stop close to the edge * High-traffic environments *** ### Use Different Enter and Exit Conditions Both Trigger Zones and Presence Zones provide: * **Enter Threshold** * **Exit Threshold** These values can be used to make the transition into and out of a Zone more stable. For a Trigger Zone, the thresholds represent point counts. For a Presence Zone, they represent cluster counts. Using separate values for entering and leaving allows the interaction to tolerate small fluctuations around the activation boundary. For example, a Trigger Zone may require a meaningful number of points before becoming occupied while allowing the point count to drop further before becoming empty again. This prevents the state from repeatedly switching because of small changes in the sensor data. *** ### Use Smoothing for Stable Interaction The **Smoothing** parameter controls how quickly the Zone reacts to changes. This is useful when the underlying measurement briefly fluctuates around a threshold. A very immediate trigger may respond quickly but can also react to short or accidental measurements. More smoothing can provide a more stable interaction but also makes the response less immediate. Tune the value according to the experience. For example: * A fast interactive effect may require a very responsive trigger. * Room occupancy can usually tolerate a slower and more stable transition. * An installation where people repeatedly move around the boundary may benefit from additional stabilization. *** ### Use Timing When the Interaction Requires It Zones also provide additional timing controls through their **Advanced** settings. These include: * **Min Enter Time** * **Max Enter Time** * **Cooldown** These parameters can be used when the spatial condition alone is not enough to describe the intended interaction. For example, an installation may need to: * Ignore extremely short activations * Control when an activation becomes valid * Prevent repeated triggers within a short period Use these settings only when the interaction actually requires additional timing behavior. For detailed parameter behavior, see the corresponding **Zones Reference**. *** ### Occupancy and Events Are Different Concepts A Zone has an ongoing state, but it can also generate events when that state changes. This distinction is useful when designing application logic. For example: **Occupied** can be used to start an experience when somebody enters the area. **Empty** can stop or reset the experience when everybody has left. With Presence Zones: **Object Entered** and: **Object Left** can be used when each individual tracked object should create its own interaction event. The correct event depends on whether the application cares about the overall state of the area or individual tracked objects. *** ### Design Around State When Possible For many installations, the most reliable interaction is based on state rather than repeated impulses. For example: **Zone Occupied → Content Active** **Zone Empty → Content Inactive** This is often easier to reason about than continuously retriggering an effect while somebody remains inside the area. Workflow logic can then decide what should happen when the state changes. Typical examples include: * Start content * Stop content * Recall a Preset * Change a State Machine state * Enable an effect * Trigger external protocol output * Start a timer or sequence The Zone should describe the spatial condition. The Workflow or State Machine should describe what the application does with that condition. *** ### Use Trigger Zones Without Unnecessary Clustering Not every interaction needs object tracking. If the application only needs to know whether something has entered a defined region, creating a complete clustering pipeline purely for that trigger may add complexity without improving the result. A simple architecture can be: **Sensor Data → Point Cloud Volume → Trigger Zone → Workflow Event** This can be useful for simple spatial triggers where identity, position, or object separation is not required. *** ### Use Presence Zones When Tracking Already Exists When a project already produces reliable people or object clusters, Presence Zones can reuse that result. A typical architecture is: **Sensors → Point Cloud Volume → People Tracking → Presence Zone → Workflow** The Zone then reacts to the same final objects that are already being used elsewhere in the installation. This keeps the spatial logic consistent across: * Presence detection * Position output * Occupancy * Local tracking areas * Other cluster-based interactions *** ### Combine Multiple Zones More complex interactions can be built by combining several Zones. For example: #### Directional Interaction Two neighboring Zones can indicate movement through an area. Conceptually: **Zone A → Zone B** can represent a different interaction from: **Zone B → Zone A** The Workflow can evaluate the resulting event order and decide how to respond. #### Staged Interaction A larger outer Zone can detect approach while a smaller inner Zone represents active interaction. For example: **Approach Zone Occupied** → prepare content **Interaction Zone Occupied** → start experience **All Zones Empty** → reset #### Multiple Independent Areas Several Zones can represent different parts of an installation while sharing the same global tracking system. For example: **Global People Tracking** → Zone A → Content A\ → Zone B → Content B\ → Zone C → Content C There is no need to duplicate the tracking pipeline simply because several interactions use the result. *** ### Avoid Overlapping Logic That Is Hard to Understand Multiple overlapping Zones can be useful, but they can also make application behavior difficult to debug. If several Zones trigger the same system, define clearly: * Which Zone has which responsibility * Whether several Zones may be active simultaneously * What happens when one Zone becomes empty while another remains occupied * Whether an event should occur once or repeatedly * Which part of the logic controls the final application state Keep the spatial structure understandable from the Project Tree whenever possible. *** ### Test the Boundary, Not Just the Center The most important part of a Zone is often its boundary. During testing, deliberately: * Approach the Zone slowly * Stop directly at the edge * Move repeatedly across the boundary * Enter only partially * Leave slowly * Walk through quickly * Test with several people * Remain inside for an extended period Observe whether the Zone: * Activates at the expected location * Remains stable while occupied * Becomes empty reliably * Produces unwanted repeated events * Reacts quickly enough for the experience Adjust the Zone geometry, thresholds, smoothing, and timing based on this behavior. *** ### Common Failure Patterns #### Zone Rapidly Switches Between Occupied and Empty Check: * Enter Threshold * Exit Threshold * Smoothing * Zone boundary * Stability of the underlying point cloud or clusters Avoid solving every fluctuation through timing alone if the spatial data itself is unstable. #### Trigger Zone Activates Without a Real Interaction Check whether permanent geometry or sensor noise exists inside the Zone. Correct the Tracking Area or Input Filters where appropriate before increasing the Trigger Zone threshold excessively. #### Presence Zone Does Not Detect a Person Check whether the person exists as a final cluster. A Presence Zone can only react to the clustering result it receives. If the cluster disappears before reaching the Zone stage, correct the earlier tracking pipeline. #### Object Entered / Object Left Behaves Unexpectedly Inspect the cluster IDs. If identities change while people move through the area, the Zone may correctly see the new ID as a different tracked object. In this case, investigate Cluster Tracking rather than the Presence Zone itself. #### Interaction Retriggers Too Often Consider whether the application should react to the Zone state instead of repeatedly reacting to events. If repeated triggering is required, use the available timing and Cooldown controls to match the intended behavior. *** ### Keep Spatial Detection and Application Logic Separate A useful design principle is: **Zones determine where something happens.** **Workflows and State Machines determine what happens.** Keeping these responsibilities separate makes the installation easier to understand, test, and modify later. The same Zone can then drive different application logic without changing the underlying spatial tracking configuration. For the practical process of adding and configuring Trigger Zones and Presence Zones, see **Add Zones and Interaction Logic** in the Project Guide. For detailed information about Zone parameters and behavior, see the corresponding **Zones Reference**.