Logo
Overview
Senspace & Beyond

Senspace & Beyond

May 18, 2026
2 min read
index

About

Senspace & Beyond is a project progress journal and a direct continuation of Senspace Capstone. Because of unforeseen circumstances (US & Iran War), the project came to a halt over the course of February to May 2026. The goal of this journal is to show how the project evolves from its digital form to a proper installation.

Project Revamps

Following our discussion that the visuals needs to have more narrative, I began with the simple ones and asked myself: how does two different behavior tell a story?

This leads me to think the beginning of Senspace experience (Idle State) by attracting users from far away & remember that it’s supposed to feel like a living environment. In a general umbrella, it is the prologue for next visuals & transitions.

Subtleness is key, we want audience to realize difference but not feel too unsettling

Implementing GLSL Foundation for Senspace Visuals

GLSL (OpenGL Shading Language) is a high-level, C-based programming language used to write custom shader programs that run directly on a computer’s graphics processing unit (GPU). The core concept of GLSL are:

  • Shaders: Small programs executed by the GPU to control the rendering pipeline. Common types include Vertex Shaders (which transform 3D shape positions) and Fragment/Pixel Shaders (which compute final pixel colors and lighting).
  • Strongly Typed: Every variable must have an explicitly declared data type before use, and implicit conversions are generally not allowed.
  • No Recursion: Function recursion and goto statements are strictly forbidden to ensure predictable GPU execution time

As we are aiming to install multiple projectors for the physical installation, using this programming language allows us to bypass the stacking layers and filters of TouchDesigner and ensure lighter performance for the machine.

Why Shaders?

Previous version of the project duplicates the base Voronoi cell visuals into each state.

  • This causes several issues:
  • Performance is very expensive and requires re-rendering frames, wasting resources
  • Disjointed and noticeable difference when transitioning into each visuals, meaning the behavior of the cells are different each time the Controller snaps to another state
WS Test
Voronoi Duplication

Thus what I implemented is a singular Voronoi cell that is distributed into different visual states, saving cook times & reducing VRAM and GPU Overhead massively

Behavior Variance

With the various data that are being transmitted by the sensor, I wanted to have a variation in how the visuals looked. Thus, I implemented a simple switch system to allow multiple visual parameters. Using logic CHOP , it is controlled in a 60 second timer, that is split 50/50 meaning every 30s it switches back-and-forth.

This will allow me to have different behaviors for the visuals

Behavior I: Heartbeat

Heartbeat-like motion translating randomized CHOP data

Behavior II: Jittery Cells

Randomized data translated to jitters