VMT TECH BLOG
UnityのHDRPでリアルタイムレンダリングに挑んだ話
どうもMonacaソムリエです。
もう年の瀬ですね、急に寒くなったので皆さん体調を崩さないように
してくださいね。
今年も第4回専門学校HTML5作品アワード（https://html5award.com/）の協賛企業として
参加いたします。企業賞として選定も致しますので、参加されている専門学生の方々は
ぜひ頑張ってください！！（企業賞ではなく、グランプリ目指してくださいねｗ。）
さて、VMTは今年、３Ｄのソリューションとして下記実績を作ることが出来ました。
Pixage（https://www.valtes-mt.co.jp/result/result-07-pixage.html）
メガソフトVRソリューション（https://www.valtes-mt.co.jp/result/vrsolution.html）
Unityのエンジンを使って、既存の建築データを「より綺麗に」「より速く」をテーマに
開発を進めていきました。
今回はそこでの苦労話というか、我々が挑んできた内容を語ろうと思います。
より綺麗に
CGの世界で「綺麗」と言ってしまうと色々あり、人によって捉え方が様々なので
一概には言えませんが、私たちが挑んでいったのはアーティスティックな綺麗ではなく
フォトリアリスティック＝写実的
を目指してきました。
リアルタイムでフォトリアルに挑む
リアルタイムでフォトリアルというのは３Ｄの世界では
はっきり言ってかなりのメモリ、CPU/GPUリソースを使います。
３Ｄのパフォーマンスを大きく影響を及ぼす要素は下記です。
・データ数（ポリゴン数、マテリアル数）
・光源の計算
・影の計算
このうち、光源の計算、影の計算を事前に計算することによって
負荷減らすことが出来ます。
この手法をライトマップ（ベイク）といいます。
ベイク＝焼き付ける。
つまり、事前に光の当たり方と影を計算して、データに焼き付ける
っといったものです。
ライトマップのメリット
・事前に光源と影の計算をするので、パフォーマンスを軽減できる
・光の複雑な計算（直接光、間接光）が表現できるので、フォトリアルな表現ができる
・静的なデータの作成に向いている
ライトマップのデメリット
・計算に時間がかかる。
・光源の位置を変えても、光の反射角度や影の位置が変わらない。
・汎用的なデータでは使えない。
・ランタイムで使えない。
画像比較
ライトマップなし【LightMap_OFF.png】
ライトマップあり【LightMap_ON.png】
単純にこの画像を比較すると、ライトマップがあったほうが良いに決まっています。
しかし、「汎用的なデータでは使えない」「ランタイムで使えない」これが致命的だったのです。
なぜ致命的だったのか？
理由は簡単です。扱うデータが静的なデータ（システム内だけで使うデータ）ではなく
ユーザーが作るデータ、過去に作ったデータを読み込んで表示する必要があったからです。
つまり、どんなデータが来るかはわからないので、事前に光源や影の計算ができないのです。
やりたい事はどんなデータでもUnityのシーン上に展開できるように変換し、光源、影、マテリアルを
設定してフォトリアルに表現したかったのです。
なので、ライトマップはこのソリューションには不向きだったということです。
どのようにしてアプローチしていったか？
まず、フォトリアルな表現をしていく上で必須のレンダリングパイプラインHDRPを使いました。
HDRPに関してはこちらを参照（https://www.valtes-mt.co.jp/vmt-tech-blog/event/20201125/980/）
このHDRPを使って、フォトリアルな表現を行う上で欠かせない機能が３つあります。
・グローバルイルミネーション（以下GI）
・アンビエントオクルージョン（以下AO）
・物理ベースレンダリング（以下PBR）
ただし、ここで想定外なことが起こりました。
これまでUnityの標準搭載だったGIのミドルウェアEnlighten（エンライトゥン）が非推奨となり、
ランタイムで使えなくなってしまいました。
※ライトマップでは使えますが、後々使えなくなるらしいです。
正直、いやいや勘弁してくださいと。。
一番重要な機能が使えないとは。。
そこで、GIを表現するためにいろんな手を尽くしました。
明るすぎず、暗すぎず、光りすぎると白飛びするし、濃淡（コントラスト）が
なくなると、奥行き感、立体感が出ないと。
それはまぁ、苦労しました。。
なぜかというと、ユーザーの作るパターンは一つではないからです。
細かいことは言えませんが、あるパラメータを強くするといい感じと思ったデータが
ほかのデータでみると全然だめだったり。。。
要するにいろんなデータがある中で、バランスを整えるのに非常に苦労しました。
光過ぎず、暗すぎず、偏らなすぎず、且つフォトリアル。
それを表現するために、疑似的に光源と濃淡表現できる機能を自作し、
絶妙なバランスでGIを表現するようにしました。
GI効果がないとき【GI_OFF.png】
GI効果があるとき【GI_ON.png】
質感表現へのアプローチ
質感とは、金属や木材、ガラス、ゴム、水等、物体の表現をより
リアルに行うことです。その手法はHDRPにはPBRという機能が備わっています。
じゃあそのまま使えばいいじゃないか？と単純に思われてしまいますが。。。
残念ながら、そうではありません。
既存のデータはHDRPのPBRに沿って作られていません。
つまり、PBR出来るようにデータを自動的に変換しないといけないからです。
しかも、いろいろな素材があり、その素材にあった変換をしないといけないので、
既存データをPBR用に変換できる仕組みを作って、半自動で変換できるようにしました。
さすがにAIとは言えませんがｗ。
PBR用のデータを作るうえで重要なデータはテクスチャです。
PBRテクスチャと言って、質感を表現するうえで非常に重要な要素となります。
なぜかというと、物理ベースレンダリングとは、現実世界で必要な物理計算を
正しく行うための手法なので、その法則に沿ってデータを作らないといけないからです。
ちょっと難しいですが、簡単に言うと平べったいテクスチャだとリアル感がでません。
そこで、元のテクスチャから情報を抽出して、自動的にPBRテクスチャを生成しました。
詳しいことは言いませんが、1つのテクスチャからPBRの表現に必要な数種類のテクスチャ
を同時に作成し、質感にあったパラメータを自動で変換して設定しました。
質感設定がないとき【PBR_OFF.png】
質感設定があるとき【PBR_ON.png】
やっぱり出た問題、パフォーマンスと画質はトレードオフの関係
以前の記事でも言いました通り、３Ｄの世界ではパフォーマンスと画質はトレードオフの関係です。
片方を強化すれば、片方が落ちる。
残念ながらこの法則は不変です。
綺麗にすればするほど、パフォーマンスが下がります。
パフォーマンスを上げれば上げるほど、画質が下がります。
このお互いの劣化を最小限に抑えなければなりません。
これは永遠のテーマであり、３Ｄシステムを作るうえで常に付きまとう問題です。
ですが、UnityはSRP Batcherという優れものがあります。
※詳細はこちらの記事を参考にしてください。
（https://www.valtes-mt.co.jp/vmt-tech-blog/event/20201001/930/）
まぁこれだけではないのですが、Unityシーンに変換するときのデータの持ち方
レンダリングタイミング等、色々なことを考慮して画質を落とさずに
パフォーマンスを上げることをやりました。
Pixageはそんな汗と涙の結晶！！
ほんとはもっと色々あったのですが、終わらないので。。。
こうした苦労を重ねてようやくリリースできたのがPixageとVRソリューションです。
作ったデータをより綺麗に速く表示する。
過去に作ったデータも綺麗に表示できる。
これがようやく実現できました。
もちろんこれはゴールではありません。あくまで通過点です。
またまだ、綺麗に速くできますのでこうご期待！！
それでは皆さんよいお年を！
【3D開発エンジニアを募集中】
当社で開発している3D・VR・ARアプリケーションの開発エンジニアを募集中です。
詳しい求人内容はバルテスグループ採用サイトをご覧ください。
画像をクリックいただきますと詳しい求人内容をご覧いただけます。
VMTのInstagramでは社内xR, 3D技術勉強会のコンテンツを配信中です！
是非フォローや「いいね！」をお願いいたします！
公式アカウントはこちら
新着ブログ
