3Dディスプレイ用レンダリング（Unity編）

最終的に目指しているプロダクト「3Dディスプレイドングル」についてはこちら。
　３Dディスプレイドングルについて

　3Dディスプレイ用レンダリング（基本編）で、3Dディスプレイ用の画像がどんなものかを説明し、3Dディスプレイキャリブレーションツール制作で実際に画像を合成するプログラムを作ってみました。
　今回は、静止画だけでなく初音ミクを踊らせるためにUnityで実装していきます。

●まずはそのまま移植

　まずは順当に、キャリブレーションツールのロジックをそのまま移植しました。
マゼンタとイエローの画像だった部分は、12個のRenderTextureに変更しました。
12個のカメラのレンダリング結果を受ける寸法です。
しかし、まぁ遅い。すごく遅い。6FPS？くらい。
テレビが30FPS、映画が24FPSなので、映画の1/4です。
しかもダンスモーションは30FPSで作られているので、通常の1/5くらいのスピードで踊ります。カクカクです。
　その後、PITCHを掛け算するのではなく足し算にしたりとか、計算結果を配列に保持して使いまわしたりとか計算量を減らす工夫を施して施して、11FPS。限界です。通常の1/3のスピードで踊るミクさんです。
　休みが挟まったりしましたが、これだけで大体１年です。ファイルの最終更新日は2017/7/15まで来ました。この時点でカクツキはするものの、一応初音ミクを踊らせることには成功しました。動画、撮っておいたらよかったんですけどね。

●ComputeShaderを用いた性能改善

　次に30FPSを目指した性能改善です。
ここで私はComputeShaderに乗り出しました。
CPU処理に見切りをつけ、GPU処理を目指したわけです。
　両者の違いはざっくり言って、複雑な計算をこなせる代わりに同時に行えるタスク量は少ないCPU処理、簡単な計算しかできない代わりに同時に大量のタスクを行えるGPU処理、くらいの理解で大丈夫です。
　今回は1200*3*1920に毎フレームアクセスし続けるので、GPU処理の方が早くなると踏みました。
12個のRenderTextureでカメラのレンダリング結果を受けるのはそのままですが、開始直後にサブピクセル位置の計算をCPU処理ですべてやり切ります。
　コメントによるとこう。
 そしてこう。

ここで、さもわかっている風に解説しだすのは私という人物を知っていただくにおいてフェアではありません。私にも過去の私がなにをやりたかったのかさっぱりわかりません。
　少しソースを読んで、考えます。
…
……
………
ディスプレイピクセルに対する3次元ピクセルの図
　まず、3Dディスプレイで見えるピクセル(3次元ピクセル)に通し番号を振ります。
この番号ごとに、構成するRGBのディスプレイ上の位置（X,Y）を配列に格納します。
０であればR=(0,1),G=(1,3),B=(2,5)、１であればR=(0,0),G=(1,2),B=(2,4)となります。
　ここのポイントはPITCHが出てこない点です。
PITCHに関わらず、3次元ピクセルに対するディスプレイピクセルの対応を配列に格納しています。
これによって、PITCHの端数によってズレが生じてもこの配列の数字の繰り上げで対応できるようになります。

　次に、PITCHに従って3次元ピクセルに画像ピクセルを割り当てます。
　
　すると、先ほどの3次元ピクセルとディスプレイピクセルの対応配列を用いて、ディスプレイピクセルに対する画像ピクセルの対応配列を作れます。
例えばディスプレイピクセル(0,0)はR=1(0,0),G=3(0,0),B=5(0,0)となります。
ディスプレイピクセルに対する画像ピクセルの図

　ここまでやったら、GPUでタスクを1200*1920個起動し、このディスプレイピクセルー画像ピクセル対応配列とRenderTextureを渡します。
　
GPUで起動されたタスクは、配列を読んで、指定された画像ピクセルのRGBをRenderTextureから取り出して、合成して出力画像に格納して返します。
　例えば、0*0番目のタスクは配列の(0,0)番目を読みます。
そこで得られた(1(0,0), 3(0,0), 5(0,0))という情報を元に、1枚目の画像の(0,0)のR、2枚目の画像の(0,0)のG、3枚目の画像の(0,0)のBを合成して出力画像の(0,0)に格納して返します。
このタスクが1200*1920個あるので、画像全体が一気に合成されます。

　正直、GPU処理は奥が深すぎて入り口にちょっと足を入れて引っ込めたくらいでしかありません。多分、というより確実にもっと効率よく合成できるのでしょうが、どこまでできるのかわからないため、やっていません。
　そもそも12枚のRenderTextureを作る時点でGPUでピクセル単位に色を入れてるんだから、そのタイミングで出力画像にはできないのか？とかは常々思っていますが、やり方がわからないので、保留してあります。
　
　さて、この実装によって、40FPS程度出せるようになったので、レンダリング編は以上です。

●立体感の正体

　実はここでもうひとつ問題です。実は、あまり立体的に見えないのです。
これが後述といった部分です。
テストでは立体的に見えましたが、それとは違いがありすぎて原因を特定できていません。
1.ライティングが違うために立体感を覚えづらい
　　→マシ。立体的なライティング方法を探す。
2.カメラ配置が違うために立体感を覚えづらい
　　→まだマシ。レンチキュラー向けの撮影方法の情報を漁る必要がある。
3.ピクセル配置が設計と異なってしまっているため立体感が得られない
　　→バグ潰し、ロジック直し。グロッキー。
4.立体感を得るために適切なピクセル配置がある
　　→設計直し。絶望。
5.そもそも動くと立体感を覚えづらい
　　→企画終了。

とりあえず、１、２だと思うことにして、保留中です。
そのあたりの細かい部分はコンテンツ編で。

コメント

コメントを投稿

このブログの人気の投稿

3Dディスプレイの仕組み（発展編）

イメージ
最終的に目指しているプロダクト「3Dディスプレイドングル」についてはこちら。 　 ３Dディスプレイドングルについて この記事ではこちらの動画を元にして解説しています。 　 【36視差】裸眼3Dディスプレイを自作してみた【立体映像】 3Dディスプレイの仕組み（基本編） では、なぜレンチキュラーレンズで3Dディスプレイが作れるのか、どのくらいの視点数ができるのかの基本を解説しました。 しかし、動画で作っていた36視点は到底及びませんでした。 以下では、視点数を飛躍的に増加させるテクニックと、もう１つ実際に作る時に気にしなければならない焦点について解説していきます。 ●レンチキュラーレンズを斜めにする理由 どうやって36視点にしているか。 動画中で、「レンズのラインが画面に対して斜めになるようにカットするのが視差数を増やすポイントです。」「独自の計算により9.46度の角度を付けました。」と言っていますが、なぜレンチキュラーレンズを斜めにすると視点数が増えるのか。あと9.46度ってなに？ 　基本編でディスプレイの色を出せる最小面積であるといった１ピクセルですが、これは赤、緑、青（RGB）の３つのライトが組み合わさって１つの色を出しています。 小さいとき、テレビ画面を虫眼鏡で拡大したりしなかったでしょうか。 横６ピクセル、縦６ピクセルの拡大図 １ピクセルはこの３つが組み合わさって正方形になるようになっています。 実はディスプレイごとにこのRGBが横に並んでいたり、縦に並んでいたり違うのですが、普通に使う分には全然意識しませんね。 ここに基本編に出てきた台形のレンチキュラーレンズをそのまま置いてみます。 すると、左から見えるのはこの部分です。 赤だけ。 しかし、レンチキュラーレンズを斜めに置いてみます。 すると、左から見えるのはこうなります。 RGBがきれいに入ります。 RGBの並びが横でも縦でも気にならないように、同じ方向にRGBさえ出力されていればちゃんと色を認識することができます。 これで、同じレンチキュラーレンズ、同じディスプレイでも視点数が増やせるというわけです。 そして、上記の図で使っている角度が大体9.46度です。 横１ピクセル、縦６ピクセルで１つの組になるように斜めに置...
続きを読む

20190804：成果報告

対象バージョン：TCPClientTest8 　今日はUnityから画面のレンダリング結果をUDPで送信し、pythonで受信する部分を作成。 python側、バインドするIPアドレスにgethostbynameでローカルホスト名から取得したIPアドレスを使っていたが、UDPを受信できていなかった。 127.0.0.1を直接指定したところ、受信処理が走るようになった。 今後、ホストを切り離した際に影響が出る可能性があるため、要注意。 また、レンダリング結果をsendしている部分で、 「SocketException: データグラム ソケットで送信されたメッセージが、内部のメッセージのバッファーまたはほかのネットワークの制限を超えています。または、データグラムの受信に使われるバッファーがデータグラムより小さく設定されています。」というエラーメッセージが出力される。 バッファサイズごとに分割して送信するよう変更したが、改善せず。 受信側で、まずは先頭８バイトを受信してPNG形式のデータか判定、などとしているのが問題か。 毎フレームでの受信であるため、受信と判定を別スレッドに分けて並列処理する必要があるかも。
続きを読む

3Dディスプレイの仕組み（基本編）

イメージ
最終的に目指しているプロダクト「3Dディスプレイドングル」についてはこちら。 　 ３Dディスプレイドングルについて 　まずはじめに、本ブログで「3Dディスプレイ」と呼んでいるものより厳密に言うと「レンチキュラーレンズを使った裸眼立体視ディスプレイ」のことを指します。 　こちらの動画を参考にして作成しましたので、まずはご覧ください。 【36視差】裸眼3Dディスプレイを自作してみた【立体映像】 ●3Dに見える理由 　まず、なぜ3Dに見えるのか、です。 人間がなにかを見た時に3Dだ！と感じる理由には複数あると言われていますが、一番簡単なものは 「左目と右目で見え方が違うこと」 「左や右に動いた時に見え方が変わること」 です。 　この二つは同じことを言っています。 つまり、「角度によって見え方が変わること」です。 30度右から見たら30度右からの見え方、40度左から見たら40度左からの見え方で見える。 これによって、3Dに見えるわけです。 　でも、テレビもディスプレイも、下からのぞき込んでもスカートの中なんて見えないですよね。 テレビもディスプレイも、角度によって見え方を変えることができないからです。 それを可能にしているのがレンチキュラーレンズです。 ●レンチキュラーレンズで絵が変わる理由 　動画内で「ディスプレイからの光を特定方向に曲げて～」と言っていますが、これを具体的に。 まず、これがレンチキュラーレンズ。 これを説明のために単純化するとこう。 かまぼこ型から三角柱型に単純化しました。 これの下にディスプレイを置くと、こうなります。 三角の左半分から出た光は左方向に、右半分から出た光は右方向に向かって曲げられます。 上の組み合わせを大量に横に並べると、左から見たら赤く、右から見たら青く見えるディスプレイが出来上がります。 １面増やして台形だとこうなります。 左から見たら赤く、右から見たら青く、正面から見たら緑に見えるディスプレイが出来上がります。 上記の面を増やして増やして、半円になったものがレンチキュラーレンズです。 ●レンチキュラーレンズを使って表示できる絵の枚数 　上の図だと面が増えたら見える色が増えたのだから、半円なら無限じゃん！とは...
続きを読む