こんにちわ。Qawasakiです。

今回は「Vincent」という作品の中身について説明をしたいと思います。
Vincentは元々、インタラクティブ閃光玉（天）で行った立体造形物へのマッピングがひと段落したところで、あるコンペティション向けに違うプロトタイプを作るというところから始まりました。

◼︎インタラクティブ閃光玉（天）

テントは独自製作（プロトタイプはIKEAの天蓋）で、そこに対して間に分配器挟んだ２台のRICHOの超単焦点プロジェクターで投影してます。中にも入って体験できるように背面投影と透過スクリーンです。
造形物投影に合わせるのはMadMapperを使っております。
（作る段階で細かく設定しないと明るさによっては映像綺麗に出ないという課題はあるです）

余談ですが最近、分配器の代わりにTripleHead2Goというものを手に入れた（遅い）のでちょっとした建売住宅とか中規模ライブハウスくらいまでならばマッピング出来る気持ちではあります。
この流れだと確かにOputiTrackさえあれば規模問わないインタラクティブ可能だな、と。持ってないけど。

序盤から話は逸れましたが、この次の作品という位置付けでVincentがあります。

アイデアとして、アナログなイラストとデジタル技術を組み合わせたハイブリッドアートの分野で、人をセンシングしてイラストにインタラクションが起きるというアイデアを少しずつ昇華させて進めているものです。

最初に作ったプロトタイプはこちら。
（ムービー用の曲もオリジナルですよー）

◼︎Vincent -Approach the World Truth-

フェルメールの絵画を真っ白なキャンバスにプロジェクションして投影します。
そこに距離センサを設置して人が近づいたのを検知してグリッジのエフェクトがかかり、別の絵に変わります。

通常、絵画を見るときに人は「見る」という行為、つまり視覚でコミュニケーションしますが、それに加えてさらに詳細な絵画の情報得るために「近づく」という行為が発生します。
Vincentのプロトタイプでは「近付くことで見える真実がある」というコンセプトを元に人が絵画に近寄るとフェルメールと同じ時代に別の画家が描いた貧困をテーマとした絵に切り替わり、最終的には元となる真珠の耳飾りの少女の絵が涙を流す、というインタラクションが発生します。

ここに至るまでにイラスト（絵画）を動かすっていう視点で幾つかサンプルも作ったりしてます。

こんなとか、

こんなのとか。

実際の絵になるべく馴染むようにCG合体したらどんなになるかなーと思って試したものの、ただ絵を動かすだけだと体験は弱い。。こういう動くプロトをラピッドで数パターンか作っては捨て作っては捨て、考えて、いまの状態に至ってます。

◼︎システム構成

Vincentのシステム構成は下記になります。

割とシンプルで、超音波センサーが拾った値を制御用PCにシリアル通信で送って演出に反映させています。
基本、インタラクティブ閃光玉（天）の構成にセンサーが入った感じです。
閃光玉（天）はセンサーの代わりにMIDIによるリアルタイム演出操作が出来ます。

今回の展示はプロトのように２つの絵画の切り替わりではなく、アニメーションという要素を加えました。
アニメーションといってもデジタルなものではなく、いわゆるセルアニメの手法である「コマ割り」です。

◼︎ILLUST

今回は手書きのイラストをこうやって18枚くらい用意しました。

Unity側でテクスチャを距離に応じて切り替えていくのですが、コマ割りだけに順番がおかしくなるわけにはいきません。なので、距離も絶対値じゃなくていくつかの閾値を設けて達したらアニメーションとして0.1秒くらいで自動アニメするようにしています。

◼︎CODE

参考までにUnityのスクリプトを載せるとこんな感じ。

_Distance変数がセンサー値で、これは「ツチボタル」や「Siricon」去年展示の「ランドリーバード」などのArduinoのセンサーで有名なMaker番長の茶谷くんが作ったモジュール使わせてもらってます。

Arduinoからシリアル通信を受け取るマネージャーなど、いくつかのスクリプトがあってシングルトンクラスになっていてどこからでも参照出来るので、とっても便利です。これをテクスチャ変更するスクリプト内で呼び出して値を調整していたりします。

ただ、センサー値の取得を秒間1000回やってパーティクルを500以上同時に動かすとなると処理落ちして辛いので、結局秒間１０回にしてます。今回は10回/秒のセンサー値でも対応出来るのですが、もっとリアルタイム性の高いコンテンツの場合、ここは検討しないといけないところです。

あと、Arduinoやセンサースペックの影響だと思うのですが、値のブレは結構あります。今回はセンサー値はそのままにVincent用のローパスフィルターを別で作成して精度を上げてます（独自ローパスは秘密）。
演出の限界はシングルトンのせいなのか、単純にCPU性能高めれば良いのかは謎。

本当は絶対値に応じたスムーズなアニメーション変化が出来れば良いのですが、時間の都合で上記のコードのようなテクスチャ切り替えを愚直に繰り返してます。。

仕上げにMainCameraにImageEfectでBlurを少しかけてスムーズに見えるようにしていて、この辺りはUnityの恩恵で楽にはなっているものの、現状の仕組みのままならば環境はopenFrameworksの方が向いているなぁと思ったりしています。そういう意味ではUnityとoFは両方使って初めて意味があるなーという気づきがありました。

Unityは表現が多彩で扱いやすいです。でも複数のアプリを連結させてバックエンドで動かしたりコードから直接描画する分にはoFの方が有利です。プログラマ界隈の外人風に言うとC++はパワフルだね！という感じです。
厳密にはUnityでJSでスクリプト書いても最終的には変換されるのですが、そこの段取りの分、遅い的な。

でも、最近oF使うことも多いのですが画像系をたくさん描画すると結局、ガタガタすることはある。
参考までにこちらも軽くプロトタイプしたマイク音量拾ってサークル描画するやつ。

1000個まではMacbookProでも余裕。

UnityもoFも表面上使うだけだとどっちでもダメですね。
差別化はかるためにもunityではシェーダーくらいかけるようにしよう。
そんな感じで色々気づくことあるのでUnityとoF、どっちかしかやってない人はどっちもやったほうがいいと思います。

展示後にセンサー使わないでポリゴンをバリバリ使うコンテンツを作ったら結局、限界を迎えたのでそもそものUnity内のプログラム構造に問題あるのかもとか思ってて、プロトタイピングはこういう積み重ねが割と大事だなーと思っております。

展示みていただいた方の中には「KINECTとかで深度とればもう少し精度上がるのでは」というコメントをいただきましたが、Vincentは今の使い方だけでなく汎用的に使えるものを目指しているので、安価なセンサーを使っている、という感じです。PCも小型のMINI PCにすればコストは低く、持ち運びも簡単になるなと思ってます。

KINECTとMacbookProのままだとスペックも余剰でコストも高く応用利かないので、そういうのはVincentの思想と合わないという理由で採用していないです。

◼︎まとめ

Vincentは、取り立ててすごい技術を使ってるわけでも無く、超新しいテクノロジーでもないです。
理由は前述したような近付くことでのハイブリッドアートの体験の実現をターゲットにしてた、というところが大きいですが、技術的な側面として、全体的な構成が「スケーラブルであること」は気にしています。いわゆる仕組みとして横展開出来るものをつくっています。今後は実運用で使ってもらえるところを探して根本はブレずに少しずつ状況に応じたブラッシュアップはしたいなーと思っています。

以上、全体を通して雑文的になって「わけわかんねーこと言ってるな、こいつ」という感じだと思いますが、要はこういうテクノロジー全般を俯瞰しつつ日々、生きておりますのでこういうのイベントで使いたいとか、同じ仕組みで独自のもの使いたいとかあればお気軽にお声がけくださいという感じで締めのご挨拶と代えさせていただきます。

ArtDirection/Illust/Design: Eri Hosokawa
Programming: Junpei Qawasaki
Sensor: Akihiro Chaya

では。