> 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/overview.md).

# Overview

## Applications

The same Grid Studio spatial-processing tools can be combined in very different ways depending on the experience you want to create.

This section focuses on common **application architectures** rather than repeating the complete setup process from the Project Guide.

Each application starts with a specific goal and shows which parts of the spatial tracking pipeline are typically required to achieve it.

***

## Start with the Desired Result

When designing an interactive tracking project, the most important question is usually not:

**Which sensor technology am I using?**

Instead, start with:

**What should the system detect, and how should that result be used?**

A project designed to track complete people across a large venue has very different requirements from a touch surface that needs to detect small interactions close to a wall.

The same sensor technology can therefore be used for different applications, while different sensor technologies can also contribute to the same tracking result.

For example, aligned 2D and 3D LiDAR sensors can contribute to the same Point Cloud Volume when their measurements support the same detection goal.

***

## People & Object Tracking

People and object tracking typically uses one or more sensors to cover a larger physical environment.

A common architecture is:

**Spatial Sensors → Point Cloud Volume → Tracking Area → Point Filtering → Clustering → Cluster Tracking → Cluster Filters**

The final tracked objects can then be used for:

* Presence Zones
* Occupancy and Cluster Count
* Global position output
* External tracking systems
* Local interactive areas

Large installations may combine several sensors to improve coverage and reduce occlusion.

The emphasis is usually on reliable clustering, stable IDs, and consistent tracking throughout the complete environment.

Continue with **People & Object Tracking** for common architecture and setup considerations.

***

## Touch Surfaces

Touch applications focus on much smaller spatial interactions.

Examples include:

* Interactive walls
* Screens
* Tables
* Floors
* Other physical surfaces

These applications often use dedicated sensors positioned specifically for the interaction surface.

The general pipeline remains familiar:

**Sensor → Point Cloud Volume → Tracking Area → Point Filtering → Touch Clustering → Position Output**

The main difference is the type of interaction the clustering is expected to detect.

A high-resolution 2D scan can, for example, be particularly useful when very small interactions need to be detected along a defined plane.

The result can be used as direct touch or interaction coordinates for another system.

Continue with **Touch Surfaces** for typical sensor placement and processing architectures.

***

## Local Interactive Areas

A large tracking environment does not mean every connected system needs the complete global tracking result.

For example, an installation may track an entire venue while individual areas require their own local data:

* An LED floor
* A projection
* A stage section
* An interactive table
* Separate installation zones

Instead of creating another tracking pipeline, the final clusters from the global Point Cloud Volume can be passed into a local **Volume** Object.

A typical architecture is:

**Global Point Cloud Volume → Final Clusters → Volume Map Input → Local Volume → Clipping → Local Map Output**

Each local Volume can then provide:

* Local Cluster Count
* Global coordinates
* Relative coordinates
* Normalized UV coordinates

This allows one reliable global tracking system to serve many independent interactive applications.

Continue with **Local Interactive Areas** for common local-output architectures.

***

## Depth Images & Content-Reactive Workflows

Not every application needs structured cluster positions.

Sometimes an external visual system benefits more from an image representation of the spatial data.

Grid Studio can render the processed point cloud into a real-time depth or point-based image.

A typical workflow is:

**Point Cloud Volume → Image Rendering → Image Provider → Media Output → External Real-Time System**

The resulting image can be sent through systems such as:

* NDI
* SDI

and used by external applications for:

* Content-reactive visuals
* Depth-based effects
* Image-based interaction
* Masks and silhouettes
* Additional blob or touch analysis
* Custom real-time processing

This also provides a useful alternative when the same spatial environment needs additional processing that is not part of the main Grid Studio clustering pipeline.

Continue with **Depth Images & Content-Reactive Workflows** for common image-based architectures.

***

## Combine Applications

These architectures are not mutually exclusive.

A single project may, for example:

* Track people globally
* Use Presence Zones for internal Grid logic
* Send global tracking positions over OSC
* Extract local UV positions for an LED floor
* Generate a depth image for an external visual system

All of these applications can originate from the same spatial tracking environment.

The key is to avoid duplicating processing unnecessarily.

Use the **Point Cloud Volume** for the main detection goal, then branch from the final result using Zones, Maps, local Volumes, and Image Rendering where appropriate.

{% hint style="info" %}
Use the **Project Guide** when you need step-by-step instructions for building the tracking pipeline.

Use the **Applications** pages when you already understand the basic workflow and want to decide how to structure a particular type of installation.

Use the **Reference** section when you need detailed information about a specific object, filter, clustering method, or parameter.
{% endhint %}