水道橋重工の「クラタス」にプロジェクションマッピングしてみた
本記事は2015年4月12日に投稿されたものです
引きつづき事例の棚卸し。一昨年(2013年)、某イベントでクラタスにプロジェクションマッピングしました。
投影映像シーケンス。実際には8箇所の装甲部のみをレンダリングしクラタスに投影する
開発方針
次のような要件がありました。
開発期間は実質1ヶ月ほど
実物での事前テスト不可、搬入するまでポーズおよび一部装着パーツ未定
クラタス全身に鮮明に投影できるクラスのプロジェクターを使うのは厳しい
できるだけ早く実装でき、現場で柔軟かつ速やかに調整でき、なおかつ小型のプロジェクターで投影できる設計にしなければなりません。クラタスをよく見ると、主要な装甲板はすべて長方形です。曲面や多少の凹凸はあっても、輪郭はそうです。
肩の装甲。湾曲しているが長方形である。ちなみに重機のような色をしてるのは某映画出演のため。投影においてはこの色も悩ましかった
そこで、次の方針であたることにしました。
姿勢等変更可能な仮想クラタスモデルを3D空間に構築し、その各装甲板映像をUnityでリアルタイムレンダリングする（ポーズ／パーツ変更対策）
装甲板は長方形に単純化する（演出処理の簡素化）
実物の各装甲板に一対一でプロジェクターを配置し、各々用の映像を正面から投影する（投影調整機能／作業の簡略化、小型プロジェクター対応）
演出方針
装甲板に投影するのはベタに「変化する模様」です。いろいろ要望はあったものの、限られた資源と時間とでは危険を冒せず割り切るしかありませんでした。
表示する模様は主に迷彩と電子的な発光パターン。あとハイトマップ。なんだかんだでこうしたテクスチャも自分で用意する破目になり、とはいえ絵なんて（ましてシームレステクスチャなど）描けないので、テクスチャ生成プログラムを急遽こしらえることに。
左が各種迷彩模様、右上が電子（基板）パターン、右下がハイトマップ（実際にはそれぞれ別テクスチャ）。いずれもProcessingで生成。迷彩／基板テクスチャはRGB各チャンネルをグレイスケールのレイヤーとして扱い、シェーダで色や輝度を設定し合成表示する仕組み。無数の色彩や発光パターンを表現できる（配色もアルゴリズムで自動生成）。Unity内部で生成せず外部テクスチャを読んでいるのは、もともと素材をもらえる前提で開発してたから…
トランジション
迷彩模様が変化する際のトランジションはこれまたベタに「デコボコして変わる」のが基本です。具体的には長方形を立方体の集まりで構成し（立方体の数は長方形サイズに応じて自動的に決まる）、これらが回転や上下動することで模様が変化します。ほかに発光して変わる場合もあります。
各立方体は衝突判定をトリガとして変化を始めます。たとえば右から左へ徐々に模様を変化させるには、十分な大きさの衝突用メッシュを右から左に移動させすべての立方体にぶつけていきます。この衝突用メッシュの形や動きや数によってあらゆるパターンを作れる仕組みですが、結局は時間の都合で数パターンのワイプを表現するにとどまりました。
衝突の様子を可視化した様子。巨大な赤い球が衝突用メッシュ（通常は不可視）。装甲板をなす立方体がこれにぶつかると変化を始める
発光
基板のような模様が上から下へ発光していく演出があります。テクスチャのRGBチャンネルそれぞれに格納した模様を、ワールド座標（絶対座標）に応じて専用シェーダで輝度変化させています。
トランジションもそうでしたが、個々の要素にタイムラインで指示するのではなく、共通の座標系やメッシュを基準に受け身で変化させることで、空間的に一貫性のある演出を簡単に実現しています。このことは現場で柔軟に調整するために（今回の要件にないがインタラクティブにする場合も）とても重要です。Unityのような3Dゲームエンジンにおいてはむしろ当然の方法ではありますが。
荒い発光パターンの上に細かい発光パターンが「絶対座標で」降りてくる。発光パターンが達するタイミングは装甲板の位置で自然に決まり、何も指定する必要はない
レンダリング
方針に述べた通り、各装甲板の正面にカメラを据えて同時にレンダリングし、結果を実物の各装甲板の正面に設置されたプロジェクターで投影します。ソフトウェア的にはきわめて単純になるものの、プロジェクターの台数や設置といった物理的な問題から、普通はまず採らない方法です。事前テストも出来ずどうなるか心配でしたが、凄腕の専門家が現場で見事に設置してくれました。
装甲板に対応するカメラたち。右側に各カメラのプレビューがあり、それぞれ長方形を正面に捉えていることがわかる（実際には周囲は黒くマスクされる）。このカメラと同じようにプロジェクターを実物の周りに配置し、対応するカメラのレンダリング結果を投影する
パーティクル
光の柱や火花はパーティクルです。冒頭の映像のように3D空間上では派手に飛んでいますが、実際には装甲板の上にかかる部分しか投影されません。にもかかわらず、現物を見るとちゃんと空間を飛んでいるかのような印象を受けました。投影面の密度も関係するでしょうが、空間的な一貫性があると補完されて見えるようです。
照明演出
シーケンスに合わせて周囲の照明とクラタスの“眼”（顔面の平板なカメラアイ的部分）も光ります。照明はDMX対応で、以前に使ったことのあるArduino用DMXシールドで制御。クラタスの眼はじつは小型液晶ディスプレイなので、Mac Bookをつないで白黒高速点滅する全画面プログラムを現場で作って表示。これらは当時当社にいたNが引き受けてがんばってくれました。プロジェクションマッピングシステム本体と直接関係ない（シーケンスを同期するくらい）ので分担できたのです。
顔面の黒い板が液晶ディスプレイ
システム構成
最後にシステム構成を説明すると、4台のプロジェクターが接続されているレンダリングPCが2台あり（プロジェクター計8台）、タイムテーブルに沿ってそれらへ制御命令を送るシーケンサーPCが1台あります。それと照明制御用Arduino、投影調整用のiPhone／iPod Touch（TouchOSCを使用）など。
で、機器間のプロトコルはOSCだったのですが、このときUnityで利用したC#用OSCライブラリにパケットを取りこぼす致命的バグがあり、本番中に事故発生。後でよくよく調べてみると、処理が追いつかずオーバーフロー、とかじゃなく高密度なパケットを単に漏らしてしまう造りだったのでびっくり。テスト不足がもちろんいけないのですが、巷のライブラリを過信してはダメだと深く反省しました。
最終版（会期中もシーケンスをアップデートしていた）の実物映像は残念ながら残っておらず、そもそも映像では伝わりにくい。最終日見られた人はラッキー？