NVIDIAの仮想プラットフォーム「NVIDIA Omniverse」。CGWORLDでも様々な検証を行なってきたが、今回は、多彩なモデル設定と拡張性に強みをもつHPワークステーションの複数モデルとグループワーク向けの「Omniverse Enterprise」を用いて、建築ビジュアライゼーション分野での活用方法を検証した。3ds MaxとMayaという異なるツール間でのコラボレーションなど、多人数プロジェクトにおけるワークフローの参考にしてほしい。

グループワークに対応するOmniverse Enterprise

NVIDIAが提供するOmniverseは、2019年のRTXによる衝撃的なリアルタイムレイトレースデモンストレーションの後2020年にリリースされ、オープンベータになってから2年が経過した現在、10万ダウンロードを記録している。

エンターテインメント分野にとどまらず、建築や土木、設計や工業デザインなど幅広い分野に最新のNVIDIAテクノロジーを提供するために、オープンプラットフォームとしてリリースされているのがこのOmniverseだ。

Omniverseというと、NVIDIAのRTXを活用したリアルタイムレンダリングエンジンという側面が取り上げられることが多いが、それはあくまでもビジュアライズするための機能の1つであり、その機能を提供するために多くのアプリケーションとのつながりが現在進行形で構築されている。

エンターテインメント系DCCツールから建築設計、機械設計、工業デザイン、シミュレーションにいたるまで幅広くコネクタを開発しているシステムは他に類を見ない。それだけ、RTXを主軸としたビジュアライゼーション機能が様々な分野で活用されているということだろう。

さらに今回は、エンドツーエンドのグループワーク・コラボレーションワークに対応させたプラットフォームNVIDIA Omniverse Enterpriseのシステムについて紹介したい。

OmniverseのWebサイトから無料でダウンロードできるOmniverseはこのエンタープライズ機能をもたないワークステーションタイプと呼ばれている。最大2アカウントまでのコラボレーション機能は有しているが、大人数の場合や組織の枠を超えたコラボレーションには対応していない。

具体的には、Nucleusというシステムでサーバを設定し、そこにクライアントから相互アクセスできるネットワークシステムを構築する。各端末からはNucleusサーバのデータが専用のブラウザを介して閲覧および読み書きが可能であり、Navigatorというアプリケーションを使えば、ローカルストレージとデータをやり取りすることもできる。これらは特定のOSサーバシステムに依存していないため、ネットワーク上に構築された仮想空間のようにアクセスすることが可能だ。

Omniverseはその語源となったUNIVERSE（宇宙）の集合体、より上位の概念として今流行りのメタバース（METAVERSE）と同じような仮想空間として見ることができるだろう。

建築ビジュアライゼーションにおけるワークフローを考える

まず、建築ビジュアライゼーションのワークフローで起こりがちな問題を考えてみよう。

建築物を可視化（ビジュアライゼーション）する場合、その建物の規模によって作業量が変わってくる。例えば、住宅やマンション1棟をビジュアライズする場合、その設計者自身か、もしくはCG担当者が1人いれば制作することができるだろうが、大型商業施設や都市設計をビジュアライズする場合は、多人数での制作が当たり前になる上、複数の会社間をまたいでデータをやり取りすることにもなってくる。

そういったプロジェクトチームによる長期的な制作を行う場合、密な連携が求められるにもかかわらず、作業者によって使用するアプリケーションが異なることも考えられる。そうなると、ツール間での互換性が保てなくなり、ワークフローの構築に頭を悩ませることになる。

1社内で全員が同一のツールを使用している場合であれば制作データをまとめることは容易だが、複数社間でそれぞれが異なるツールを使用している場合、どういったワークフローが考えられるだろうか？

双方向フローを実現する「USD」フォーマット

このワークフローの問題を解決できるのが、Omniverseの基盤となっているUSDフォーマットだ。USD（Universal Scene Description）とは、Pixarにより開発された非破壊的な柔軟性と双方向性をもつファイルフォーマットで、複雑なシーングラフのためのAPIとファイルフレームワークをオープンソースで提供している。

拡張性に優れ、業界ソフトウェア間のアセット交換を容易にし、コンポジションアークという新しいレイヤー概念により異なる部門の大規模チームによる同じシーン上での同時作業を可能にする。USDはM&Eから始まり、現在ではAEC、製造、製品設計、ロボットなどの業界で標準となりつつあるテクノロジーで、NVIDIAではUSDを“3D仮想世界のHTML”と呼ぶほどの可能性を秘めている。

そんなUSDを利用できることのメリットのひとつが互換性だ。

昨今、建築ビジュアライゼーション業界でも使用されることが増えているUnreal Engineと比較してみるとわかりやすい。ゲーミングテクノロジーから発展したリアルタイムレンダリングエンジンは、従来のプリレンダーを利用した方法よりもイテレーションの時間を短縮でき、形状や質感の変更も即座に反映されるため、正にビジュアライゼーションのために存在しているとも言えるだろう。

しかし、同じようなリアルタイムエンジンでもOmniverseとUnreal Engineとは大きく異なる点がある。以下の図を見てもらえるとわかりやすいが、Unreal Engineを使用したワークフローの場合、様々なDCCツールからデータをエクスポートしてUnreal Engineに取り込み、改めて質感やライティングなどを再設定し、Unreal Engine内で最後まで仕上げていく。形状やアニメーションデータの変更が生じた場合には、もう一度エクスポート・インポートをくり返す、一方通行のフローとなっている。

Omniverseの場合、DCCツールからデータをUSDに変換し、Omniverseで質感やライティングを設定した後に再びDCCツールに戻すことも可能であり、USDの強力なコンポジションアークを使うことでパーツごとの更新、追加、バリアントなどを即座に反映させることができる。

Omniverseのシーンファイル形式はあくまでもUSDなので、取り込んだらそこで最後まで仕上げなければならない他のツールとは異なり、互換性を保ったままOmniverseでイテレーションを行うことが可能になる。

現状、USDファイルをインポート可能なツールはいくつもあるが、USDそのものがネイティブファイルとなっているツールはOmniverseだけだ。

HP Zワークステーションを用いた検証用システム構築

今回の検証では複数台のマシンによるコラボレーションを行うため、HPの協力を得てZシリーズワークステーションを数種類お借りした。

Zシリーズワークステーションの特徴はIntel Xeon スケーラブルブロセッサーとNVIDIA RTX Aシリーズを搭載したワークステーションで、セキュリティ・リモートワークソリューション・安定性・冗長性に秀でている。特にNVIDIA RTX Aシリーズの新しいグラフィックボードを選択することが可能で、特に建築や機械設計のようなデータ量が多い場面で力を発揮する。

以下、それぞれの特徴を紹介しよう。

HP Z8 G4 Workstation

CPU

Intel Xeon Gold X6226R（16コア）✕2

GPU

NVIDIA RTX A6000

メモリ

96GB（16GB✕6）

ストレージ

1TB HP Zturbo Device

大きなフルタワー型筐体でデュアルCPUなどのハイエンドな構成を選択できる。重量もそれなりだが、前後に持ち手があり重い筐体でも運びやすい。マザーボードのメモリスロットに余裕があり、1.5TBまでのメモリを実装できる。


内部を見てみると、CPUとGPUでエアロフローが完全に分けられている。そのためGPUの排出した熱がCPUファンに取り込まれるということがない。

• 

• 

HP Z4 G4 Workstation

CPU

Intel Xeon W-2255 プロセッサー（10コア）

GPU

NVIDIA RTX A4500

メモリ

64GB（16GB✕4）

ストレージ

1TB HDD

ミドルタワー型筐体のサイズで普段の使用にはちょうど良い大きさに思える。さらにこのサイズで前後に持ち手があることはとても珍しく持ち運びしやすい。

構成も一般的でシングルのXeonプロセッサーにグラフィックカードが2枚搭載できる。

HP Z2 Tower G9 Workstation

CPU

Intel Core i5-12600（6コア）

GPU

NVIDIA RTX A4500

メモリ

32GB（8GB✕4）

ストレージ

1TB HP Zturbo Drive ＋ 1TB HDD

ミニタワー型筐体でかなりコンパクトで置き場所には困らない。しかも筐体は軽い。ミニタワー型なのにGPUカードスロットの前に専用吸気ファンが設けられているため、小型の筐体にハイエンドなグラフィックカードを搭載することもできる。

HP ZBook Fury 17.3inch G8

CPU

Intel Core i9-11980H（8コア）

GPU

NVIDIA RTX A5000

メモリ

64GB（16GB✕4）

ストレージ

2TB HP Zturbo Drive

17インチサイズのノート型ワークステーション。17.3型なのでフットサイズはそれなりだが、画面のベゼルも狭く、薄さ17mm重量3kgと17型ワークステーションとしてはかなり可搬性に優れている。特筆すべきは拡張性で、本体裏ふたが簡単に開閉できるため、RAMやストレージの増設が容易となっている。さらに、HP Zturbo DriveはM.2のSSDで高速な読み書きを実現する。

ベンチマーク

HPのZシリーズワークステーションはいずれもNVIDIA RTX Aシリーズを搭載しているので、そのパフォーマンスを見るためにMaya 2023 Arnoldでベンチマークをとってみた。

CPUテスト

Z8（Intel Xeon Gold 6226R）

9分43秒

Z4（Intel Xeon W2255）

1時間1分4秒

Z2（Intel Core i5-12600）

29分21秒

ZBook（Intel Core i9-11950）

35分5秒

参考値（AMD Ryzen 9 5900X）

15分43秒

GPUテスト

Z8（RTX A6000）

2分22秒

Z4（RTX A4500）

3分15秒

Z2（RTX A4500）

3分18秒

ZBook（RTX A5000）

4分17秒

参考値（RTX 3060）

7分1秒

今回の検証では、これらのHP Zワークステーションの中で最もハイエンドとなるZ8にNucleusサーバを建て、IPアドレス経由で各ワークステーションからデータを参照するミニマムなシステムを構築した。

以下の画像はZ8上に存在するNucleusサーバのデータと、それをZ4からNavigatorで閲覧している様子を表している。Omniverse専用アプリケーションのひとつNavigatorを経由すればWindowsのエクスプローラーからデータを出し入れすることも可能になるため、Nucleusシステム上に存在していないデータでも容易にやり取りすることができた。

Omniverse Enterpriseによる3ds MaxとMayaのコラボレーション検証

仮想の都市設計をビジュアライズするという用途を想定して、Omniverseを核としたコラボレーション作業を行なってみた。

基本の都市設計は建築分野で最もユーザーが多い3ds Maxを使用してモデリング及びマテリアル設定を行い、都市に暮らす市民をキャラクターアニメーションに強いMayaを使って動かしている。どちらもそれぞれの専門分野を担っているDCCツールだが、分野が異なると意外と接点は少ない。お互いのファイルフォーマットは異なり、メインレンダラも異なる場合が多い。3ds Maxの場合はV-Rayが主流であるが、MayaではArnoldが標準レンダラとなっている。

Omniverseには既存のツールと連携をとるための「Connector」と呼ばれるプラグインがリリースされている。それを導入すれば、3ds MaxやMayaのようなDCCツールや建築設計分野で使用される3D CADから直接Omniverseにデータを送ることができるようになる。データを送るといっても先に記述したようにOmniverse専用のシーンファイルを作成するのではなく、USDデータに変換することがConnectorの役割である。

Omniverseを使うことで、3ds MaxとMayaでつくられた異なる素材のコラボレーションが簡単にでき、また、その合わせたシーンをUSD経由でそれぞれのDCCツールに戻すこともできた。

建築分野にオススメのOmniverseアプリケーション「Create」

Omniverseには様々な用途に特化したいくつものアプリケーションが備わっているが、その中でも建築分野において有効に使用できるものとしては「Create」と「View」がある。

Createはインターフェイスを見てもわかる通り、Unreal Engineによく似ている。そのため、Unreal Engineを使ったことのある人ならば親しみやすさを覚えるだろう。

似ているのはUIだけでなく、その役割も同じようなことが可能だ。USDデータを読み込み、アセットライブラリから様々なものを追加し、NVIDIA PhysX 5、Blast、Flowなどの物理シミュレーションを行い、マテリアルを編集し、ライティングを調整し、アニメーションをレンダリングする。その全てをインタラクティブにリアルタイムに行うことが可能となっている。

ただし、大きく異なる点はPixarのUSDがベースとなっている点だ。レイヤー、バリアント、インスタンス化などはUSDの高度なワークフローを利用できるし、ビューアもHydraレンダーデリゲートとして構築されているので、将来的にはHydraに準拠した外部レンダラも使用できるようになるだろう。この点が相互互換性のないUnreal Engineとは大きく異なる点となっている。

現在搭載されているレンダラは標準状態で4つある。
・RTX RealTime
・RTX Interactive Path Tracing
・RTX Accurate Iray
・Pixer Storm

• 

• 

• 

• 

今回、3ds MaxからはConnector経由でUSDデータを出力している。3ds Max上ではV-Rayを使用してシーンを構築しているが、ConnectorはそのデータをUSDに変換してくれる。

V-Rayでつくられたマテリアルは自動的にNVIDIAのオープンソースMDL（Material Definition Library）に変換される。MDLとは各レンダラ固有の設定をできるだけ簡単に交換できるように、マテリアルの標準的なパラメータをUSDのカスタムスキーマで実装したGPU対応の定義言語だ。このMDLにより、異なるアプリケーション間でマテリアルをまったく同じではないにしても、似たような質感に合わせることができるようになる。

3ds Max内でMDLを割り当てることも可能だが、マテリアルグラフ上で編集をすることはできていない。V-RayからConnector経由でMDLに変換した場合、基本的な質感の設定やテクスチャマップなどはそのまま表現される場合もあるが、複雑なシェーダネットワークを組んでいる場合や、特定のプロシージャルシェーダやユーティリティなどは残念ながらまだ変換されない。

• 

• 

Omniverse Createでのデータ加工のながれ

続いて、Omniverse CreateでUSDデータをどのように加工しているかを段階的にお見せしたい。

HPワークステーションのパフォーマンスは？

今回使用したシーンの詳細は以下の通り。今回の作業は主にZ8で行なったが、挙動において気になる点はなく、快適に作業を進めることができた。

ポリゴン数

5,924,007

トライアングル数

11,034,001

ライト数

9

加えて、先ほどのシーンをムービーとしてレンダリングした際のZ8とZ4の処理時間を比較した。

レンダリングサイズ

フルHD（1,920✕1,080）

フレーム数

1,978

結果は以下の表の通り。RTX Aクラスのグラフィックボードであれば、A4500でも十分に高速に処理できると考えられる。

とはいえ、今回の作業ではGPUメモリを23.5GB使用していたので、そこそこ大きいGPUメモリをもつグラフィックカードを用意した方が良いだろう。

USDビューアの役割をもつOmniverse View

Omniverse ViewはUSDデータを可視化するビューアの役割を果たす。

Createと同じようにRTX RealTime、RTX Interactive Path Tracing、RTX Accurate Irayの各レンダラを備えているため、形状や質感を確認したり、時間により変化する環境光を再現することもできるが、アニメーションなどを設定することはできない。

しかし、Createにはない機能として、形状の断面をカットしてみることができるため、モデルの形状をよりわかりやすく確認することが可能だ。Connector経由でリアルタイムにモデルデータを取り込めるため、1人のユーザーが複数のツールを利用してシーンを構築したり、複数のユーザーが同時にコラボレーションすることもできる。合成されたシーンは、全ての参加者がインタラクティブにレビューが可能だ。

Omnivese Connectorの問題点

ConnectorはホストアプリケーションのネイティブデータをUSDデータに変換するだけでなく、インポートやライブ接続などの機能をもっているが、主にデータを変換するという機能を実際に使用した上で、現時点でまだ使いにくい点、改善を望む点を挙げておく。　

3ds Max

・日本語版のUIは使えない。

・データを変換する前にあらかじめNucleusサーバに接続しておく必要がある。

・3ds Maxからアニメーションデータが出力できない。これは致命的な問題なので早急にアップデートを望む。今回はカメラアニメーションを3ds Max → Maya → USDで変換している。

・3ds Maxから出力する際の変換スピードに時間がかかりすぎる。今回のデータを変換するために、Z8を使用しても4時間以上かかっていた。今回の検証では原因の特定にはいたらなかったが、上記のとおりアニメーションデータを出力できないため、アニメーションシーンからデータを変換していることが要因のひとつかもしれない。

・Omniverse MDLへの変換がまだまだ上手くいかない。特に3ds Maxの場合は様々なレンダラを使用するため難しい。3ds Maxの中で最初からMDLマテリアルを割り当てるという回避方法もあるが、その場合はマテリアルグラフ上での編集機能が不可欠となる。

Maya

・Autodesk USD Pluginとコンフリクトするため、先にアンインストールが必要。

・Bifrostの最新版はUSDを使いコンフリクトするため、プラグインをOFFにする必要がある。

・MayaのネイティブUSDが使えるようになるとありがたい。

・データを変換する前にあらかじめNucleusサーバに接続しておく必要がある。

・Mayaではアニメーションデータも出力できるが、様々な方法が選択できるので、変換時のパラメータ設定には注意が必要。

・ArnoldマテリアルのMDL変換の精度を上げてほしい。

建築ビジュアライゼーションにおけるOmniverseのメリットは

これまで、建築物をビジュアライゼーションする場合、どのようなワークフローが考えられただろうか。

・設計CADでレンダリング機能を使用
設計CADに備わっているレンダリング機能を使う方法は1つのソフトで全てが完結するため管理がしやすいが、機能が限られているため自由度に欠ける。

・DCCツール
DCCツールなどで改めてモデリングし、プロダクションレンダリング機能で自由度の高いアニメーションを制作することも可能だが、レンダリング時間の問題があった。

・ゲームエンジン
Unreal EngineやUnityのようなゲームエンジンを利用することで、リアルタイムかつVRへの展開など柔軟な可視化が可能となったが、Blueprintなどのゲームエンジン特有の複雑な設定を理解しなければならず、それ以後の互換性がないため、ゲームエンジンが終着点となってしまっていた。

OmniverseはUSDを中核とすることでこれらのフローとは大きく異なり、上流から下流に流れる単一のフローから、双方向であり並列して作業を進められるコンカレント型のフローとなっている。設計変更や意匠確認の回数が多くなる建築の場合は特にメリットを得ることができるだろう。

建物に不可欠なパストレーシングもリアルタイムで行うことが可能で、UIもシンプルで理解しやすく、ゲームエンジン特有のプログラムやコンパイルも必要ないので、可視化という目的を最短で達成することができるだろう。

アセットや物理エンジンを使ったシミュレーションなども充実してくれば、より簡単にリッチな画像を得られるツールとして重宝されると考えられる。しかし、そのためにはドキュメントをはじめとした理解を深めるための環境が充実していく必要があるように思う。現状ではまだまだその点が足りていない。しかし、Omniverseは一般公開されてまだ2年しか経っていない。NVIDIAのGPUと同じように毎年改良を続けてOmniverseは進歩していくだろう。これからの充実に期待している。

お問い合わせ

株式会社日本HP
URL：jp.ext.hp.com/prod/workstations