メタバースは、仮想空間での体験やコミュニケーションの場として注目されています。
建築の3Dモデルは、その精密さから、メタバース構築に役立つと考えられがちです。
しかし、現実的にはそのままでは使えないケースがほとんどです。
この記事では、Unityでのビジュアライズを前提に、その理由と背景について解説します。
一般的な問題としてデータの重さとパフォーマンスの問題
総ポリゴン数の縛り
建築モデルはフェイズによって詳細度がまちまちであるため、リアルタイムレンダリングの要件を満たすポリゴン数であることはほぼ無いと思います。
初期段階であれば簡易的に作られすぎていてレンダリングに耐えなかったり、実施設計レベルになると逆に詳細に作られるため、ポリゴン数が増えすぎていて扱いづらい等の問題があります。
一方、メタバースプラットフォーム（例：ClusterやVRChat）では、リアルタイムレンダリングのパフォーマンスが重視されるため、必要な部分にポリゴンを割きつつも全体では軽量化が必須となります。
ポリゴンの割き方の強弱
メタバースでは、グラフィックを綺麗に見せるために必要な個所に十分にポリゴンを割く必要があるため、見えないところは簡略化するなど、体験個所から逆算した強弱をつけた戦略的ポリゴン数のコントロールが求められます。
例えばグラウンドレベルの体験メタバースの場合、一階部分のディテールレベルと、最上階レベルのディテールレベルに強弱をつけて、良く見える部分を細かく、遠い部分を粗く作る必要があります。
高解像度モデルをそのまま遠景に使用すると、描画負荷が大きくなり、動作が遅くなる原因になりますし、逆に近景がローポリ過ぎても綺麗には見えません。
体験部分に対して、ポリゴン数に強弱をつけたモデリングをしてある建築モデルはまずないと思います。大抵の場合は体験位置に対してはディテールが一定になっている事が多いです。
メッシュの命名規則の想定
初期にある程度命名規則を確立した上でメッシュのヒエラルキー構造を考えないと、新しい名前のメッシュができると様々な設定を個別に反映し直す手間が発生します。
ある程度最終形を見据えたメッシュ命名規則を使う事で、インポート時に確実にメッシュが上書きされてUnity側の設定が継承されるようにすることが望ましいです。
モデル更新時に、新しいメッシュが頻繁に表れたり消えたりすると、再設定の手戻りと見直しが頻発しミスやエラーの原因になります。
最初から完璧にはできませんが、まったく命名規則がない状態で始めるよりかはある程度想定して規則を作っておいた方が手戻りが少なく済むと思います。
原点の設定
建築の大型案件のモデルになると、原点の設定がサイトの外にあったりして、メッシュやグループ、コンポーネント、ブロック等のピボットが画面外のとんでもない所や意味のない所にあるモデルが良くあります。
他街区との位置合わせのためにそうなっている等の理由があるとは思いますが、メタバースではゲームエンジンを挟むため、ピボットの設定し直しが発生します。
メタバースでは、動的なインタラクションを入れる事も加味すると体験位置がピボットの原点であった方が、計算上のロジックがシンプルになる傾向があります。
正しく原点設定をし直して最小限で効率的なスクリプティングができる環境を整えることで、エンジニアに余計な負担を掛けないようにすべきです。
メタバース独自の要件
メタバースを含むゲームエンジンにおけるリアルタイムレンダリングでは、モデルの作り方に特殊なルールがあります。
３角形か４角形のメッシュで全てのメッシュを構成する
５角形以上のメッシュはどのように３角形化して良いかゲームエンジン側で判断できないため、フリッカー（チラチラ点滅する）が起きたり、その前の段階でUV展開（テクスチャを当てるための座標情報を設定）に失敗するなどの問題が起きます。
必ず３角形もしくは４角形で構成することで、デザイナーのセンスで明示的に、最適な分割をする必要があります。
もちろん、元のモデルがメッシュではない場合、（Nurbsやサーフェスの場合等）レンダリングの際にどのように分割するべきかをデザイナーがきちんと考え最適な分割数にしないと、パフォーマンスを無駄なところに割いてしまったり、粗く見えたりします。
又、想定外のところにエッジが出たりでなかったりする場合もあるので、スムージンググループや、後述のベベルの入れ方についても把握しておく必要があります。
面の重複を許さない
例えば柱と梁が取り合うところで、同じ幅の柱と梁が交差しているシチュエーションを考えます。
建築モデルでは柱部分と梁の部分が重なっていることが良くありますが、これは正しくレンダリングされません。
面が重なっているとフリッカーが起こるためどちらかを消去しなければなりません。
また面の勝ち負けがあっても、面が近すぎるとフリッカーが起きる可能性があるので、それも注意です。
不要なメッシュを残さない
また、上記の例でどちらかを十分な距離を持たせて勝たせたとしても、負けた方のメッシュを一部消去する必要があります。
数ミリ差し込むくらいなら大丈夫ですが、面積が大きかったり、不要な面がある場合は、はポリゴン数の削減に加えて、UVを節約するために処理が必要不可欠です。
特に手摺等の小口面などが残っていると大量のメッシュ面によってポリゴン数が増加するので注意したいところです。
柱と梁等の別オブジェクトで頂点を共有しない
スケッチアップ等で作成したモデルで良く起こるのは、別オブジェクトなのに頂点を共有して作ってしまうケースです。
頂点が共有されてしまうと、５角形のメッシュができたり、メッシュの切り離しがきちんとできておらずUV展開が出来ない、ベベルを一様に入れたいができない、マテリアルの切り分けができない等、後の工程で多様な不具合が生じます。
後に別オブジェクトをまとめ直す際にも頂点連結が邪魔で作り直す必要が出たりするので、最初から綺麗にしておく方が賢明です。
ホール（穴）を分割する
ありがちなミスとして、ブーリアン等で穴をメッシュに開けた時に、多角形ができてしまう事があります。
これはきちんと４角形で分割しないと正しくレンダリングされません。
モデルに穴をあけるという事はどのようなメッシュ分割になるという事か、どのくらいの頂点の増加があるか分かった上でモデルする必要があります。
細かい穴であれば、テクスチャのアルファで抜いたりする方が向いていたりするので、マテリアル側で対応するべきディテールと、モデリングで対応すべきディテールと、振り分けも重要になってきます。
法線の向きが正しく揃っていない（裏面のメッシュ等）
建築モデルではメッシュの裏表が反対になっても大きな問題にはなりませんが、メタバースでは裏面は描画されませんし、ライトマップも正しく計算されません。
裏面を描画する設定にすることはできますが、ごく少数のメッシュの裏表を正すために両面描画のコストを払うのはパフォーマンスにおいてあってはならないことです。
まず、裏表がきちんと整合している必要があります。それに加え、正しくエッジを出したりスムーズに見せたりするためには、法線方向を正しく設定する必要があります。
特にメッシュをアタッチしたり分離したり、ブーリアンしたりした場合には、元のモデルのNormal情報が正しく継承されていない場合が多くあるので、最後に設定しなおす必要がある場合がほとんどです。
建築モデルではそもそも法線を適切に設定するという文化はほぼ無いので、形状を整えて最後にやり直すことが多いと思います。
曲面は適正な分割でスムージンググループ分けする
曲面は分割が目立たない粗さかつ、ポリゴン数が増えすぎないバランスのメッシュで構成する必要があります。
そして、スムージンググループを適正に設定することで曲面のエッジを立てるのか和らげるのか等の調整をします。
片面だけの大きなメッシュがある
片面だけのメッシュが露出してあると、スタティックメッシュ（静的なオブジェクト）のライトマップの計算時に周辺のメッシュのAmbientOcclusionが正しく計算されません。
これは一方方向からしか見えないメッシュにやりがちなので、きちんと押し出して、裏側も作る必要があるという事を認識しておきましょう。
（一方、Unlitシェーダーを利用する等の、スタティックではないモブなどはその範疇ではありません）
ベベルが入っていない
十分に近い部分のモデルではベベルが入っていないとCGっぽさが出てしまいます。
どんな角も、１００％尖っていることはあり得ないので、必ずベベルが必要です。
遠景でない限り、必ずベベルを入れてWeightedNormal（面の大きさによる重み付けのある頂点法線）を掛け、スペキュレーションを入れる事で、CG臭さをある程度和らげることができます。
ベベルの入れ方が一様でない
ベベルを入れるエッジが部分的にしか入っていない場合、ベベルエッジ以外のエッジがWeightedNormalによって滑らかにレンダリングされてしまい、本来の形状と異なって見える場合があります。
ベベルエッジは均等に入れて変なエッジが消えないように気を付ける必要があります。
Unityにおけるビジュアライズ前提でのバランス感覚
適切にメッシュをまとめる
メッシュが一つ一つバラバラな状態だと、そこに多くのリソースが割かれてしまいます。
まとめて問題のないメッシュは物理的に繋がってなくとも一メッシュとして扱う事でパフォーマンスを節約できます。
同じマテリアルのメッシュをまとめる（Textureの節約）、同じ方角のメッシュをまとめる（OcclusionCullingを効かせる場合）、距離に応じてメッシュをまとめる（ディテールレベルやテクセル数を落とす場合）、インタラクティブ部分をまとめる（動かすモデルの場合）等、適切なシチュエーションに応じてメッシュのまとめ方を工夫し、無駄なく最適なメッシュ構成を目指すべきです。
動かすメッシュはワンマテリアルとする
動的なメッシュをマテリアル毎に分割したり、複数マテリアルとすると、テクスチャが多くなり、又、それを動かすためのロジックも複雑になる傾向があります。
この場合は、適切にアトラス化した複数マテリアルをまとめたTextureを用意し、UVの設定で正しいマテリアルが正しいメッシュにあてがわれるようにすることが推奨されます。
同じようなオブジェクトが多数ある場合にStaticBatchingを効かせてパフォーマンスの節約を行う場合も有効な手です。
UV1，UV2を適正に設定する。
上記のメッシュ割りに応じてひとまとまりのメッシュを一つのUVに重ねたり、並べたり、マテリアルのタイリングを気にしながら適切にUV1の設定をします。
また、UV2については重複を許さず、ライトマップベイクの際のテクセル密度を考慮した解像度の強弱をつけたUVアイランドの大きさにする必要があります。
ベイクをしながらある程度の試行錯誤を前提に、UV1、UV2を設定することになります。
全体の最適化
ライトマップベイクの際の結果に応じてメッシュ分けを見直したりすることもあるでしょう。
想定していたテクセル数では綺麗に見えないために、UVを調節することもあると思います。
ディテールを入れてた部分をテクスチャにしてしまうといった簡略化等を行ってパフォーマンスを節約したり、逆にディテールレベルを上げて見栄えをよくする等、テストを何度も行い、調整を繰り返します。
そういった細やかな対応が綺麗な画を作るためには欠かせないと考えています。
まとめ
以上のことを踏まえると、建築モデルはメタバース内でそのまま使える事はほぼ無く、メタバースモデル用のガイド程度に考えておくと良いかと思います。
最低でも３次元できちんと整合性が取れているという事が確認できるだけでもモデルがあった方がもちろん良いです。
ただし、建築モデルをメタバースで活用するには、それを流用するのではなく、「目的に応じたモデルの最適化」が必要です。
建築モデル側で設計の際に最初からその対応をすることはナンセンスだと思いますので、設計に都合の良い状態のモデルを作成できていれば良いと思います。
それを参考にメタバース側ではゲームエンジン前提のビジュアライズに特化した翻訳を行い、再構築するというのが必要な流れだと思います。
以上、本日は建築モデルのメタバース化に関する記事でした！
