COPYRIGHT © SONICJAM ALL RIGHTS RESERVED.
2015
17
NOV
CATEGORY:
あれどうやってるの?
Bot & Dolly "Box" (後編)

みなさんこんにちは!研究開発部 泉田です。

世の中の有名デジタル施策を勝手に技術解説するこのコーナー、「あれどうやってるの?」。 連載第4回目です! 今回は前回に引き続き「Box」の仕組みに注目してみましょう!

※ 例の通り、ここに書かれているのはあくまで私の"推測"になります。間違っている部分があるかもしれませんのでご了承の上お読みください。

Box 解説

さて、前回の記事の最後の方で、重要なのは「視点の位置」「立体物の位置」「平面の位置」だ、と述べました。

この3点の位置が把握できていれば、どのようにプロジェクションすれば立体物として見えるようになるか、を計算によって割り出すことができるということでした。

ここで再度、「Box」の映像を見てみましょう。

{v:75260457}

写したい映像コンテンツの内容については3Dソフトなどで制作を行っているはずなので、「立体物の位置」については自由に設定することができるかと思います。

そして、プロジェクションされる先である「平面の位置」に関してはロボットアームにより正確に制御されています。

問題は、「視点の位置」です。

「Box」の映像をよく見てみると、微妙に手振れがあったりして、一見すると人手によるカメラワークのように感じます。

仮に人手によってカメラワークしている場合、「視点の位置」を把握するにはリアルタイムでカメラ位置を検出する必要があります。またその検出した位置情報を元に描画する絵をリアルタイムに計算で求めなければいけません。

私は当初、上に書いたようにリアルタイム検出+描画を行っているものとばかり思っていました。ところが、メイキング映像を見てこれとは異なる方法で解決していることに気が付きました。

{v:102776011}

※ 1:03 あたりに注目!

なんと「Bot & Dolly」のメンバーが選択したのは

1. あらかじめ人手によってカメラワークした際のカメラ位置をトラッキング

2. トラッキングした位置情報を元に描画する映像をあらかじめ計算して作りこむ

3. 本番のカメラワークは位置情報を元にロボットアームで行う(!)

というとんでもない方法でした!


いやー、これは意表をつかれました!まさかカメラワークですらロボットアームで行っていたとは。しかもこの方法、ただ突飛な方法というだけではなくある面ではとても理にかなっているんです!

利点1:レイテンシーを気にしなくて済む

リアルタイム検出+描画を行うためには、カメラ位置の検出やそれを元にした描画の計算までを文字通りリアルタイムに行う必要があります。

ところがカメラ位置の検出にも描画の計算にも相応の処理時間が必要となります。

そうなると、検出したカメラ位置とその時描画されている絵にズレが生じてしまうんですね。このズレ(遅れ)のことをレイテンシーと言います。

リアルタイムシステムを組む際、このレイテンシーのせいで見え感が悪くなったり、システム上の制約が発生することが非常に多いです。そのためシステム構成を決定する際やソフトウェアシステムを組む際には、レイテンシーをいかに少なくするかが重要になることが多く、エンジニアの腕の見せどころだったりします。

ところが、今回のように事前に取得した位置データを使用して描画する映像を制作する場合、描画計算のための処理時間は映像の制作時にかかってくるため、この部分の本番時でのレイテンシーはなくなります。また、カメラの位置検出にかかるレイテンシーについても、動画制作時に考慮することによって無視することができるようになります。

利点2:レンダリングに凝れる

レンダリングとは3Dモデルの光の反射や映り込みなどを計算する処理のことです。

もしリアルタイム検出+描画を行う場合、リアルタイムにカメラ位置が変化するため、レンダリングもその都度リアルタイムに行う必要があります。

レンダリングについては様々な方法があるのですが、描画のクオリティを上げるためにはより多くのレンダリング時間を要するのが一般的です。しかし、リアルタイムにレンダリングを行う場合、前述したようにレイテンシーをなるべく少なくしなければならないので、結果として簡易的なレンダリングしか行うことができなくなります。

その点、今回の手法のように描画される映像を予め作りこむことができる場合には、時間をかけてレンダリングを行うことができるため、よりクオリティの高い動画を制作することができます。

利点3:ソフトウェアシステムの簡易化

「Box」では、プロジェクタからの映像投影と各ロボットアームの動作を完全に連動させています。この部分だけ考えても相応のソフトウェアシステムを組む必要が出てきます。

コレに加えて更に、カメラのトラッキングシステムとの連動や描画計算などをリアルタイムに行おうとすると、必然的に製作しなければいけないソフトウェアシステムの規模が膨れ上がります。

ソフトウェアシステムの規模が大きくなればなるほど製作難易度は上がりますし、前述のレイテンシーなどの問題が発生する余地も大きくなります。

今回のように、映像作品として作ることがあらかじめ決まっている作品(リアルタイムなインタラクション性を持たせる必要がない作品)については、できるだけリアルタイム処理を省きシステム規模を最小化するのが得策です。

いかがでしょうか?以上3つの利点からもわかるように、今回の方法はとーっても有用なんですね!Bot & Dolly センパイさすがです!

締めくくり

ということで今回は「Box」の立体系プロジェクション部分について解説しました!

ちなみに、コレ以外にも動的なプロジェクションマッピングの手法ですとか、ロボットアームと連動するシステム部ですとか、語れば語るほどすごい部分が盛りだくさんなんですよ!この作品は!

これらの解説についてはいつか機会がくると信じて取っておきましょう!

次回はどんなテーマに取り組もうかまだ考え中ですが、ぜひ楽しみにお待ちいただければ幸いです!

それではまた次回!

CATEGORY

×
CATEGORY
COPYRIGHT © SONICJAM ALL RIGHTS RESERVED.