画面を越える：TouchDesignerとセンサーで挑む空間インスタレーション

ブラウザの中で動くスケッチを、展示空間で人の身体に応答する作品へ拡張したいとき、何から設計し、現場のどこでつまずくのでしょうか。Webの矩形を脱してインスタレーションへ挑む際、センサーの選定やTouchDesignerとの通信プロトコル、会場の照明や鑑賞者の予期せぬ動きといった摩擦は避けて通れません。この記事では、センサーの選択眼からWebSocket連携、現場トラブルへの備えまで、画面の外へ表現を踏み出すための実装手順と考え方を具体的に整理します。

二次元の矩形（フレーム）を脱ぎ捨てる：空間展示におけるコードの役割

ブラウザの canvas には、幅と高さと背景色があります。作者はその矩形の内側を完全に支配できます。空間インスタレーションでは、この前提が崩れます。壁には凹凸があり、床は光を反射し、鑑賞者は予告なく視界を横切ります。コードは「絵を描く命令」から「場を調律する仕組み」へ役割を変えます。

この転換は、作る順序にも影響します。画面内の作品は見た目から入れますが、空間では先に 身体がどう動くか を考えるほうが進めやすいです。入口で立ち止まる人、壁沿いを歩く人、子どもの低い視点。そうした振る舞いを想像し、次にそれを受け止めるセンサーを置き、最後に光や映像の質感を決めます。順序を逆にすると、美しいビジュアルが誰にも届かない場所で光ることになりがちです。

私はここに、クリエイティブコーディングの新しい居場所があると感じています。コードは目に見えないまま、人の歩幅や気配を光へ翻訳します。鑑賞者はアルゴリズムを読みませんが、応答の遅れや揺らぎとして、その性格を体感します。

身体と対話するインターフェース：LiDAR・カメラ・深度センサーの選択眼

センサー選びは、「何を測りたいか」を言葉にすることから始まります。人の位置が知りたいのか、手の形か、人数か、あるいは動きの量だけでよいのか。これによって選択肢はかなり絞れます。

大まかな傾向として、次のように整理できます。

1. 通常のカメラ：安価で扱いやすく、動き検出や色の追跡に向きます。照明条件に弱く、暗い展示室では精度が落ちやすいです。
2. 深度カメラ：奥行きを直接得られるため、身体の輪郭や距離を扱いやすいです。TouchDesigner には Kinect Azure TOP などの入力が用意されています。ただし Azure Kinect DK は生産終了となっているため、Orbbec などの代替ハードウェアを含めて入手性や対応状況を確認してください。
3. 2D LiDAR：床面に近い高さで水平に走査し、人の足元の位置を安定して拾えます。広い空間の位置追跡に向きますが、姿勢や手の動きは分かりません。

赤外線を使う方式は、太陽光や反射の強い素材の影響を受けやすいです。窓のある会場では、時間帯によって挙動が変わるケースがあります。仕様書の数値だけで判断せず、会場と同じ条件で試すことを勧めます。

もう一つ大切なのは、取得するデータを少なく保つ ことです。人の骨格をすべて追えるセンサーでも、作品が必要とするのが「誰かが近づいた」という事実だけなら、その単純さが作品の強度になります。精密に測れることと、精密に測るべきことは別です。

空間を統調するプロトコル：TouchDesignerとWeb技術を繋ぐOSC／WebSockets

センサー処理、映像合成、プロジェクターへの出力をリアルタイムでまとめる場として、TouchDesigner は展示制作で広く使われています。一方、p5.js や Three.js で書いた表現を活かしたい場面もあります。両者の橋渡しになるのが OSC と WebSocket です。

OSC は UDP 上で動く軽量なメッセージ形式で、TouchDesigner の OSC In CHOP / DAT で受信できます。ただしブラウザは UDP を直接扱えないため、Web 側と OSC を繋ぐには中継が必要です。Node.js 上で動かす osc-js などのライブラリを使い、WebSocket から OSC へ変換する構成が一般的です。一方で、TouchDesigner と Web との通信だけなら、Web Server DAT を使って WebSocket で直接やり取りする方法が手軽です。

たとえば p5.js から、マウス位置を JSON で TouchDesigner へ送る最小の例です。Web Server DAT 側でポートを 9980 に設定した場合を想定しています。

let ws;

function setup() {
  createCanvas(400, 400);
  ws = new WebSocket('ws://localhost:9980');
}

function draw() {
  background(20);
  circle(mouseX, mouseY, 24);
  if (ws.readyState === WebSocket.OPEN) {
    ws.send(JSON.stringify({ x: mouseX / width, y: mouseY / height }));
  }
}

TouchDesigner 側では、Web Server DAT のコールバック (onWebSocketReceiveText) で文字列を受け取り、JSON を解析して CHOP や変数へ流し込みます。値を 0〜1 に正規化して送っておくと、解像度の異なる出力先へ差し替えるときに楽です。

この構成の利点は、役割を分けられることです。センサー処理と投影は TouchDesigner、挙動のロジックや軽い描画は Web 技術という分担ができます。逆に、通信が増えるほど遅延と故障点も増えます。会期中に止まらないことを最優先するなら、構成要素は少ないほうが堅実です。

現場で立ち現れる摩擦：照明環境、プロジェクター投影、鑑賞者の予期せぬ振る舞い

制作室で完璧に動いていた作品が、会場に入った途端に思わぬ顔を見せることは珍しくありません。摩擦は主に三か所に現れます。

1. 光：プロジェクターの明るさ（ルーメン）は、環境光との比で見え方が決まります。照明を落とせない会場では、映像のコントラストを大きく設計し直す必要があります。同時に、投影光そのものがカメラ入力に混入し、センサーが映像に反応してしまうフィードバックが起きます。赤外線フィルターや、投影と検知の波長を分ける工夫が役に立ちます。
2. 幾何：投影面が完全な平面であることはまれです。台形補正やプロジェクションマッピングの調整に、想像以上に時間がかかります。設営日のスケジュールには、調整のための余白を多めに確保してください。
3. 人：鑑賞者は、作者が想定した動きをしてくれません。走る、動かない、センサーを覆う、複数人で同時に触れる。こうした振る舞いに備えて、入力が途絶えたときの待機状態や、値が極端になったときの上限を決めておきます。

現場で私がよく思い返すのは、「想定外」を排除するのではなく、作品の一部として受け入れる姿勢です。誰も来ない時間帯に作品がどう呼吸しているか。大勢が集まったときにどう崩れ、どう持ちこたえるか。そこまで設計に含めると、作品は展示室の時間を生きはじめます。運用面では、再起動後に自動で立ち上がる設定や、ログの記録、予備機の用意といった地味な備えが、作品の静けさを守ります。

秋のメディアアート展に学ぶ：空間に宿る「沈黙」と「応答」のディレクション

秋は各地でメディアアート展示やフェスティバルが開かれる季節です。10月に入った今、足を運ぶ機会がある方も多いでしょう。ここでは特定の作品を論じるかわりに、現場で観察できる視点をいくつか挙げます。

過去の作例でいえば、Random International の《Rain Room》は、降り続ける水が鑑賞者の動きに応じて止まる作品として知られています。身体の位置を検知して環境を変える構造は、本記事の話題と重なります。応答が「見せ場」ではなく、歩くという行為に静かに寄り添っている点が印象的です。こうした先例は、技術的な仕組みを超えて、応答の質をどう設計するかを教えてくれます。

展示を見るときは、次の問いを手元に置いてみてください。

1. 作品は何もしていない時間、どう振る舞っているか（沈黙の設計）
2. 近づいてから反応までの遅れは、何秒くらいか（応答の間）
3. 自分の動きと光の変化は、一対一か、それとも曖昧に重なっているか
4. 複数人がいるとき、誰に反応しているのか

沈黙のない作品は、鑑賞者を疲れさせます。応答のない作品は、ただの映像です。その間を行き来する速度と余白に、作者の思想が現れます。メモを取り、可能なら作者や運営の方が公開している制作解説も読んでみてください。センサーや使用ソフトの種類が分かれば、体験との対応が見えてきます。

画面の外へ出るというのは、コードが手を離れるということでもあります。光がどこまで届き、誰がそこに立ち、何が起きるのか。そのすべてを制御できないところに、空間の作品の面白さがあります。次の制作では、まず小さな一歩として、部屋の床に1台のセンサーを置き、あなたが歩いた軌跡だけを光にしてみてください。そこから、空間の彫刻は始まります。