> 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/local-outputs-for-interactive-areas.md). # Local Outputs for Interactive Areas A large spatial tracking system often serves several independent interactive areas. For example, the same venue may contain: * An LED floor * A projection wall * Several interactive stage areas * Individual exhibits * Separate media installations These systems usually do not need the complete global tracking result. Instead, each application needs to know: **Which tracked objects are inside my area?** and: **Where are those objects relative to my surface or installation?** Grid Studio can create these local views from the final clusters of a larger Point Cloud Volume by using **Volume** Objects. This allows one global tracking system to serve many independent applications without duplicating the complete sensor and clustering pipeline. *** ### Track Globally, Distribute Locally A useful architecture for larger installations is: **Sensors → Global Point Cloud Volume → Final Clusters** The final clusters can then be distributed into several local areas: **Final Clusters → Volume A → LED Floor** **Final Clusters → Volume B → Projection** **Final Clusters → Volume C → Interactive Installation** Each Volume receives the same global tracking result but only exposes the objects relevant to its own physical area. {% hint style="success" %} A useful design principle is: **Track once globally, then create as many local views of the result as required.** {% endhint %} This keeps the main tracking result consistent while allowing each application to use its own coordinate system and spatial boundaries. *** ### Use a Volume as a Local View A **Volume** Object does not perform another clustering pass. Instead, it receives the already processed final clusters from a Point Cloud Volume and creates a local selection from them. Conceptually: **Point Cloud Volume** → Final Clusters\ → Volume Map Input\ → Local Clipping\ → Local Output This distinction is important. The Point Cloud Volume remains responsible for: * Sensor data * Tracking Area * Input Filters * Clustering * Cluster Tracking * Cluster Filters The local Volume is responsible for: * Selecting a smaller spatial area * Reporting the number of objects inside that area * Creating a useful local coordinate system * Sending the result to the application *** ### Do Not Recluster for Every Installation If several interactive areas all work with the same type of tracked object, they normally do not require separate Point Cloud Volumes. For example, if the global system already produces reliable people clusters, an LED floor does not need another people-clustering pipeline simply because it only covers one part of the room. Instead: **Global People Tracking** → Local Volume\ → LED Floor and: **Global People Tracking** → Local Volume\ → Projection Area can reuse the same final clusters. This reduces: * Duplicate processing * Configuration work * Differences between tracking results * Maintenance complexity It also means that a person keeps the same tracked identity while moving between different local applications. *** ### Know When a Local Volume Is Not Enough A local Volume only selects and transforms the **existing final cluster result**. It does not change how those clusters were originally detected. If an interactive area requires fundamentally different detection behavior, a local Volume may therefore not be sufficient. For example: **Global application:** detect complete people **Local application:** detect individual fingers These require different clustering goals. In that case, a dedicated sensor group and Point Cloud Volume may be more appropriate. Use local Volumes when the question is: **Which of my existing tracked objects are inside this area?** Use a separate tracking pipeline when the question is: **Can I detect a fundamentally different type of object or interaction here?** *** ### Define the Local Area Physically The position, orientation, and size of the Volume define the physical area that belongs to the application. Examples include: * The dimensions of an LED floor * The active area of a projection * A stage section * An exhibit * A rectangular interaction space Only final cluster points inside the configured Volume remain available to that local processing path. This creates a clear relationship between the physical installation and the data sent to the receiving system. *** ### Keep the Incoming Tracking Data Global The incoming cluster positions should normally remain in the global project coordinate system while the local Volume is positioned around them. This allows the Volume itself to become the spatial reference. Conceptually: **Global tracked objects remain fixed** while: **The Volume moves and rotates around the desired interaction area** This is why the Position and Rotation interpretation of the Volume Map Input should normally use **Global**. Otherwise, moving the Volume can also transform the incoming tracking data and make the local selection difficult to reason about. {% hint style="warning" %} The Volume should define the local area around the global tracking result. Moving the Volume should not move the incoming tracked objects with it. {% endhint %} *** ### Choose the Coordinate Space the Application Needs Once the local area is defined, its output can use different coordinate representations. #### Global Global coordinates preserve the original project position. Use this when the receiving system already works in the same global coordinate space. For example: **Person Position → 12.4 m, 3.7 m, 0.0 m** This is useful when several systems share the same venue coordinate system. *** #### Relative Relative coordinates express the tracked position relative to the local Volume. This is useful when an application only needs its own local coordinate system. For example, a projection system may not care where its interaction area is located inside the complete venue. It only needs: **Where is the person relative to my installation?** Moving the complete local installation can then change its position in the global project without requiring the receiving application to understand the global room coordinates. *** #### UV UV coordinates normalize the local area into a `0–1` coordinate system. For example: **Bottom-left → 0, 0** **Center → approximately 0.5, 0.5** **Top-right → 1, 1** This is particularly useful for: * LED surfaces * Projection surfaces * Interactive graphics * TouchDesigner * Notch * Media servers * Other normalized content systems The receiving application can work with the same `0–1` range regardless of the physical dimensions of the installation. *** ### The Volume Defines the UV Orientation UV coordinates are derived from the orientation of the Volume itself. There are no separate XY, XZ, or YZ projection selections. The local orientation of the Volume determines how the physical area maps into UV space. For a horizontal surface such as an LED floor, the Volume can be positioned directly over the physical area. For a vertical interaction surface, rotate the Volume so that its local top plane corresponds to the physical surface. The Volume then becomes both: * The spatial clipping area * The coordinate reference for the output {% hint style="info" %} If the UV direction is wrong, first inspect the orientation of the Volume rather than trying to correct the coordinates later in the receiving application. {% endhint %} *** ### Use Local Cluster Count Each local Volume provides its own read-only **Cluster Count**. This indicates how many final tracked objects currently remain inside that local area. This can be useful independently of position output. For example: **Cluster Count = 0** → Installation idle **Cluster Count > 0** → Activate interactive content or: **Cluster Count = 5** → Adjust content based on occupancy The same local Volume can therefore provide both: * Continuous position data * A simple occupancy value *** ### One Global System Can Feed Many Areas A large installation can use many local Volumes simultaneously. For example: **Global People Tracking** → `Volume_LED_Floor`\ → UV Output → `Volume_Left_Projection`\ → Relative Output → `Volume_Right_Projection`\ → Relative Output → `Volume_Stage`\ → Global Output Each area can have its own: * Position * Rotation * Size * Clipping * Coordinate representation * Protocol output while all of them continue to use the same global tracked objects. *** ### Design Local Areas Around the Physical Installation The local Volume should normally correspond closely to the area where the receiving application actually reacts. For an LED floor, match the usable floor area. For a projection, match the physical projection region. For an exhibit, include only the space belonging to that exhibit. Avoid making local Volumes unnecessarily large simply to make sure the tracking data gets through. A precisely defined local area provides: * Clearer interaction boundaries * More predictable coordinates * More useful Cluster Count values * Easier testing * Easier debugging *** ### Consider Overlapping Local Areas Local Volumes are allowed to represent overlapping parts of the global tracking environment. This can be useful when one physical position should affect several systems. For example: A person may simultaneously be inside: * A large stage Volume * A smaller projection Volume * A local LED surface Volume Each application then receives the same tracked object through its own local interpretation. This is different from Zones controlling exclusive states. A local Volume is simply another view of the global tracking data. *** ### Keep Coordinate Conversion in Grid When Possible It can be tempting to send global coordinates everywhere and convert them individually in TouchDesigner, Notch, a media server, or another application. For simple installations this may be acceptable. For larger systems, defining the physical coordinate conversion in Grid Studio has an important advantage: The spatial relationship is stored together with the tracking environment. The receiving system can then simply receive: **0–1 UV** instead of also needing to know: * Where the installation is located * How it is rotated * Its physical dimensions * How global coordinates should be converted This keeps spatial calibration centralized. *** ### Typical Architecture: LED Floor A global people-tracking system can feed a local LED floor: **Global People Tracking** → Final Clusters\ → LED Floor Volume\ → Local Clipping\ → UV Coordinates\ → Protocol Output\ → Real-Time Content System The content system receives normalized positions representing where each tracked person is located on the floor. The global location and physical dimensions of the LED floor remain defined inside Grid Studio. *** ### Typical Architecture: Multiple Projection Areas A venue may contain several projections that use the same people-tracking system. For example: **Global People Tracking** → Projection Volume A\ → Relative / UV Output\ → Content System A → Projection Volume B\ → Relative / UV Output\ → Content System B Each projection receives only the people relevant to its own physical area. No additional sensor alignment or clustering is required. *** ### Typical Architecture: Local Occupancy Not every local output needs continuous positions. A Volume can also provide a simple local occupancy value through its Cluster Count. For example: **Global People Tracking** → Local Volume\ → Cluster Count\ → Workflow This can be used for: * Activating content * Changing system states * Occupancy displays * Enabling other processing * Controlling external systems The same Volume can still provide position output at the same time if required. *** ### Common Failure Patterns #### Objects Move When the Local Volume Is Repositioned Check the Transform interpretation of the Volume Map Input. The incoming Position and Rotation should normally use **Global** so that repositioning the Volume changes the local area rather than transforming the incoming tracking result. *** #### The Correct People Are Tracked Globally but Missing Locally Check: * Volume position * Volume size * Volume orientation * Local clipping Also compare the local **Cluster Count** with the final Cluster Count of the Point Cloud Volume. *** #### UV Coordinates Are Rotated or Reversed Check the orientation of the Volume. The Volume defines the UV coordinate frame. Rotate the Volume so that its local orientation matches the intended physical surface. *** #### UV Values Are Correct but Do Not Match the Physical Edges Check the physical size and position of the Volume. The Volume should match the actual interaction area as closely as practical. Test known positions near: * Bottom-left * Bottom-right * Top-left * Top-right * Center and compare the resulting coordinates. *** #### A Local Area Needs Different Object Detection A Volume cannot change the clustering result it receives. If the global system tracks complete people but the local application needs hands, touches, or another fundamentally different detection type, consider a separate Point Cloud Volume with an appropriate sensor and clustering configuration. *** #### Several Applications Produce Different Positions for the Same Person First determine whether the difference is intentional because the outputs use different coordinate spaces. A global position, relative position, and UV position represent the same tracked object differently. If the underlying global position is inconsistent, investigate the global tracking pipeline rather than the local Volumes. *** ### Keep Tracking and Application Coordinates Separate A useful architectural distinction is: **The Point Cloud Volume determines what and where the tracked object is globally.** **The local Volume determines what that position means for a particular application.** Keeping these responsibilities separate makes large interactive installations much easier to scale. One reliable global tracking system can then become the spatial foundation for many independent interactive areas. For the step-by-step process of creating and configuring a local Volume, see **Create Local Tracking Areas** in the Project Guide. For detailed information about Volume Map Inputs, Volume Filters, coordinate modes, and Volume Map Outputs, see the corresponding **Volume Objects** and **Data Mapping & Output** Reference pages.