つぶやく［SIGGRAPH］Khronosグループ，Amazonなどのネット通販向けの3Dグラフィックス制作パイプラインの規格策定に着手
 |
今回も，例年どおり，Khronosグループのプレジデントを務めるNeil Trevett氏によるKhronosグループの最新動向を説明する講演が行われた。
eコマース向け3Dグラフィックスパイプライン用ガイドライン「3D Commerce」プロジェクトがスタート
あまりゲーム産業とは関係はないが，非常にユニークで興味深いプロジェクトがKhronosグループでスタートしたので，それから取り上げることにしたい。
Khronosグループは，Amazonなどのネット通販に代表されるeコマース分野における3Dグラフィックスの取り扱いガイドライン「3D Commerce」の策定に着手したというのだ。
ECサイトでは360度回転できる商品画像を使うことで業績を大きく伸ばしたところもあり，昨今ではさらに3Dデータを使って自由な方向から商品を眺められるようにしようという流れも始まっている。そこで使われるさまざまなデータの取り扱いを標準化しようというのだ。
「それってKhornosの仕事？」と思った人もいるかもしれないが，eコマース系ビジネスが浸透・巨大化する中で，eコマース業界側から「そろそろなんとかしたい」という意見が上がり，2019年3月にGoogle， Unity，IKEA，Wayfair，Targetという業界大手が，Khronosに「このテーマ」の取り扱いを打診してきたというのである。
 |
eコマース業界で，いったい何が起きているのか。
例えば，アメリカ大手スーパーマーケットのWalmartのネット通販サイトでは，800万種類の商品を取り扱っているが，その商品ページに掲載する商品画像素材（写真，3Dグラフィックスなど）の多くが人力による写真撮影や3Dスキャンを行っているのだという。
ただ，取り扱い商品の出入りが早いため，もはやこのスタイルでは間に合わなくなってきている。しかも，この商品素材画像制作に従事する人間が，その商品それぞれに知見があるわけではないので，例えば民族楽器とか，斬新な発明グッズ系など，見た目でそれが何かよく分からないものについては，上下や正面裏面の向きを間違えて掲載してしまったりすることもありうる。こうしたミスが頻発すればその商品価値を下げてしまったり，あるいはそれを欲している顧客にリーチできない場合すらある。
となれば，例えば，そうした写真のような2D画像素材に対して「被写体の向き」に関する属性情報の規格があれば，その素材の取り扱いがグッと合理的に進められる。そう，実質的にその商品に理解がなくても，プログラム的に画像素材を取り扱って問題がなくなるわけである。そのような決まりを3Dデータで規格化しようというのが今回の動きだ。
最近は，自動車のような大型のものから，キッチン用品の小物に至るまでが，CADベースで設計されており「3Dグラフィックスのデータ」が存在する。それこそ，この3Dグラフィックスデータのジオメトリデータ（≒ポリゴンデータ）は，ほぼそのまま通販サイトで利用できるだろう。その商品の各部位ごとのテクスチャ，材質の種類などを設定するガイドラインがあれば，その商品の3Dモデルが通販サイトに掲載されたときに，ユーザー側で色を変えたり，視点を変えたり，視点を変えてみたり……といったことが，フォトリアルに楽しめるようになる。
「いまや，自動車のCMは大半がCGベース。これに対して腹を立てている人は少ない。CGは商品のイメージを伝える手段として浸透している。であれば，写真素材だけでなくCG素材までを取り扱うeコマース向けのガイドラインについて業界全体で取り決めていこう流れが出てきても不思議ではない」とTrevett氏は語る。
確かに，1社がデファクトスタンダードを決めてしまうと，そこにライセンス費用などが発生してしまったり，ややこしいことになる。その前に，ロイヤリティ不要のKhronosグループの規格として取り仕切ってもらおう，ということで業界団体がKhronosの門を叩いたというわけだ。
そこでKhronosグループは，2019年7月にはこの分野についての技術要件調査グループを発足した。この調査グループに対する参加を要請したところ，なんとあっという間に70社が手を上げたという。
その手を上げた企業ラインナップはAmazonなどは想像どおりといった感じだが，Microsoft，Googleのようなプラットフォーム企業，Unityなどのゲームエンジン企業，NVIDIAやQualcommのような半導体企業など，細かく見ていくと興味深い企業名が列んでいることに少々驚く。
 |
このKhronos 3D Commerceが取り扱いパイプラインとしては，以下のようなものを現在は想定しているという。
パイプラインの最上流は3DグラフィックスソフトやCADソフトなどのデザインツールだ。ここで制作されるグラフィックスコンテンツに対して，eコマースで使いうる属性データの埋め込みの形式などを規定しようということだ。下流ではそれの属性データに基づいて動作プラットフォームに合わせた適切な表示を行ったり，ユーザーに対してのインタラクティビティを提供するわけである。
 |
なお，このパイプラインを実現するにあたって，別に新しいAPIなどを立ち上げる必要はない。このKhronos 3D Commerceのパイプライン案を実現するにあたっては，既存のKhronosのAPIなどを流用すればいいのだ。具体的にはグラフィックスについては「Vulkan」や「OpenGL」を，3Dコンテンツ素材のやり取りには「glTF」を，Webブラウザにおけるグラフィックス表示には「WebGL」を，VRアプリへの展開は「OpenXR」を，そして写真素材のスキャニングやARアプリへの展開には「OpenVX」を使えばいいと開発グループは考えているようだ。つまり，取り決めるべきは「どういう写真/3Dデータにどんな属性データを仕込めばいいのか」といったフォーマットやガイドラインといったものが中心となる。
 |
プロジェクトはまだ今年始まったばかりであり，実際の規格としてのリリースはまだ少し先になりそうだが，前述したように要素技術は既存のKhronosグループのものを流用できるので「これから半年後くらいには，大枠が固まるのではないか」とTrevett氏は述べていた。
最後に，Trevett氏は「日本企業の参加表明がまだないのが寂しい」と嘆いていたことを付け加えておこう。日本市場でもネット通販は盛んなので，関心は高いはず。今後の動きの活発化に期待したいところだ。
 |
OpenXRがバージョン1.0としてリリースへ〜Hololens2やOculus Questも対応表明
AR，MR.VRをすべてひっくるめて「XR」と呼ぶようになってきているが，このXRに関連するオープンなAPI規格が「OpenXR」である。
現在，UnityやUnreal Engineなどの多様なゲームエンジンやゲーム開発フレームワークがあり，それぞれがXRに対応している。一方で，HMD（ヘッドマウントディスプレイ）に代表されるXRデバイスにも，Oculus，Windows MR，SteamVR，Google Daydreamなどがあり，一つのアプリを多様なXR-HMDに対応しようとすると大変な開発労力が掛かってしまう。ゲームエンジンメーカーも同様だ。
一方，視点を変えて，XR-HMDメーカーからすると，自分のXR-HMDに対応アプリを出してもらうためには，上で挙げたような大手のOculus，Windows MR，SteamVR，Google DaydreamといったXRデバイスとの互換性を考えなければならなくなる。互換性を実現するためにはそうした大手XR-HMDのように振る舞えるラッパーソフトウェア（≒ドライバ）のようなものを開発しなければならない。こちらも複数のXR-HMDプラットフォームに対応させるにはラッパーをたくさん開発しなければならなくなる。
そう，ソフトウェア開発側，ハードウェア開発側の双方に効く，新しいXR向け抽象化レイヤーが「OpenXR」なのだ。OpenXRそのものについての詳細はこちらを参照していただきたい。
 |
このOpenXRの最初のバージョンがついにそのSIGGRAPH2019のタイミングで正式リリースがアナウンスされたのだ。
ニュースとしては「OpenXR 1.0リリース」ということになるのだが，「これを踏まえつつ，業界においていくつかの大きな動きがあった」とTrevett氏は語る。
その一つは，まずMicrosoftから。Windows環境下で強力なWindows MRプラットフォームを有するはずのMicrosoftが「Hololens 2」においては，Open XR対応を表明し，OpenXRランタイムのリリースを確約したというのだ。Hololens 2の独特な視線追跡機能，ジェスチャーハンドトラッキング，空間認識機能関連についても，OpenXR 1.0ランタイム対応とするというのだからかなり力が入っている。
このほか，Oculus VRのRift，Oculus QuestもOpenXR 1.0への対応が発表されており，Unreal Engine4の次期バージョンである4.23にはOpenXR 1.0プラグインが提供されるとのことである。
この流れが加速すると，これまで以上に任意のXR-HMDで多様なXRアプリが楽しめるようになるかもしれない。
 |
「Blender 2.80」がglT2.0をフルサポート。KTX2でBinomial社の「Basis Universal」が利用可能に
「OpenGL Transmission Format」こと「glTF」については，規格そのもののアップデートはないが，採用事例に動きがあったとTrevett氏。
glTFについての詳しい解説は，筆者の過去記事を参照してほしいが，簡単に言えばglTFとは，クロスプラットフォームに対応した3Dグラフィックスアセットのフォーマットである。3Dグラフィックス関連のアセット（≒データ類）を自在に出し入れ（Transmit）できるフォーマットだから，「OpenGL Transmission Format」という名前が付いている。
そのglTFの最新版のglTF2.0を，フリーの3Dグラフィックス制作ツール「Blender 2.80」がフルサポートしたというのだ。フルサポートということは，Autodesk Mayaなどのほかの有料商業3Dグラフィックス制作ツールで制作したコンテンツをフルスペックでやりとりできると言うことだ。
また，このタイミングでBlender 2.80では，最近ではglTFとセットで利用されることの多いGoogleが開発したライセンスフリーの3Dモデル圧縮技術「DRACO」（参考記事）にも対応している。
 |
また，OpenGLやVulkanといったKhronosのグラフィックスAPIの標準テクスチャのコンテナフォーマッである「KTX」（参考URL）の最新版「KTX2」において，Binomialの「Basis Universal」技術が利用できるようになった。
Basis Universalは，GPUで利用される任意のテクスチャフォーマットに対しオンザフライで直接変換することを可能にするソフトウェア技術だ。
この技術により，KTX2コンテナの中にある超高画質で圧縮したテクスチャを，任意のプラットフォーム（≒携帯機器向けSoC内GPUからハイエンドGPU）に対して変換して取り扱えるパイプラインを構築できるようになる。この仕組みをKhronosでは「Universal Textres for glTF」と命名している。
 |
 |
WebGL 2.0でCompute Shaderサポートの計画がスタート
改めて言うまでもないかもしれないが，2020年にAdobeがFlash Playerの更新と配布を完全に終了する（関連記事）。これに伴って近年は，Web上のインタラクティブコンテンツ制作のためのフレームワークとして「WebGL」への関心が高まってきている。
WebGLの現在の最新版は2017年にリリースされた「WebGL 2.0」である。
WebGLは，イメージ的にはOpenGL ES 3.0相当のグラフィックスAPIをウェブブラウザ上で提供するものになるが，毎年，「拡張機能の拡充」という形でマイナーチェンジは継続的に行われている。
今年はWebGL 2.0に対して「マルチコアCPUにて非同期に並列コンパイルできるシェーダコンパイラの提供」や「インスタンスベースのマルチ描画用拡張APIの実装」「HDR対応テクスチャを含むBC4〜BC7までのテクスチャフォーマットの対応」などの新機能搭載が行われたという。
 |
今後の大きなアップデート計画としては，Trevett氏は「WebGL 2.0でのCompute Shaderへの対応」を挙げていた。
Webブラウザ上のインタラクティブコンテンツ制作においてCompute Shaderを活用したいというニーズが高まってきていることから，WebGL 2.0の拡張仕様の形でCompute Shaderを提供しようという動きが出てきたというわけである。
分かりやすく言えば「WebGL 2.0そのものは，Compute Shader未対応のOpenGL ES 3.0ベースなので，OpenGL ES 3.1から導入されたCompute ShaderをWebGL 2.0の拡張仕様の形でサポートしましょうか」という動きが始まったということである。
現在はスペックの策定が始まったばかりとのことで，規格として定まるのはもう少し先になる見込みである。
 |
Vulkan 1.1に線描機能の拡張機能が新設へ
肥大化しすぎてしまったOpenGLに対する，もう一つの選択肢として登場したローレベルグラフィックスAPIの「Vulkan」。その最初のバージョンがリリースされたのは2016年のことだった。この最初のVulkanは，AMDが開発したグラフィックスAPI「Mantle」をベースとして開発されたのは有名な話である。
2018年にはこのVulkanのバージョンアップ版であるVulkan 1.1がリリースされた。
「いまや，非Windows系プラットフォーム向けまでを想定して開発されるゲームタイトルの多くで，Vulkanの採用率は高まっている。今年，最大のVulkan採用ケースのビッグネームはGoogleのクラウドゲームサービスのStadiaだろう」とTrevett氏は語る。
 |
 |
Vulaknは，リアルタイム性を重視したアプリ開発のために誕生したことから，ゲーム開発における引き合いが強かったわけだが，Trevett氏によれば，直近ではノンゲーム分野からの引き合いも急激に強まっているのだとか。
中でも目立つのがCAD業界からだという。
CAD業界では，いまや手がけるデザインのポリゴン数が5000万ポリゴンを越えることもあるそうで，これをCAD画面上でストレスなく動かすには，OpenGLではCPUボトルネックが大きすぎて力不足になってきているというのだ。そこでいくつかCAD開発メーカーがVulkan対応の検討を開始したというのだが，いきなり基本的なところでつまずいてしまった。
それは「線描」だ。
OpenGLにはある，線を引くための線描関連APIが，Vulkanには実装されていなかったのだ。
この要望を受けて開発されたのがVulkan 1.1向けの新しい拡張仕様（参考URL）というわけである。
実際には，線描画だけでなくベクトルグラフィックス機能全般がVulkanでサポートされようになるので，イラスト制作ソフトなどをはじめとして，CADソフト以外のアプリでもVulkan化が推進され，そのパフォーマンス向上が期待できそうだ。
 |
このほか，Vulkanがらみの新しい動きとして，Trevett氏は「DXVK」（参考URL）を挙げていた。
DXVKとは，Valveのサポートを受けてPhilip Rebohle氏が開発した「Vulkan上で動作するDirect3D 10/Direct3D 11シミュレータ」である。
簡単に言えばDXVKとは「DirectXベースのゲームなどのアプリを，ちょっと仕立て直すだけで，非Windows環境下のVulkan上で動作させられるフレームワーク」ということになる。
直接的には「DirectXベースのゲームアプリを非Windows環境下へ移植する際に便利なもの」ということになるが，Trevett氏によると，業界では，Stadiaをはじめとした「Linux×Vulkan」ベースのクラウドゲームサービス上でDirectXベースのゲームを動かすための最短メソッドとして注目されているそうである。
 |
最後に「OpenGLやVulkanにおけるレイトレーシングサポートの方針」について触れておこう。
Trevett氏によれば「OpenGLでレイトレーシングをサポートする予定はない」とのことだった。
一方，Vulkanについてはどうかというと，方針の明言はなし。現在，NVIDIAが，自社のGeForce RTX/Quadro RTXのみで動作するVulkan 1.1向けの拡張仕様として「VK_NV_ray_tracing」（参考URL）を提供しており，これが業界で広く活用されつつあることを考えると，いずれ，これがベースとなって将来のVulkanにおける標準レイトレーシング専用APIが構築される可能性は高い。もともと，DXRもNVIDIA主導で設計されたものなので，Vulkanにおいてもそうなったとしても不思議なことではない。まあ，現実問題として，VulkanにおいてGPUメーカーに依存しない標準的なレイトレーシングサポートが組み込まれるのは，AMDが対応GPUを出したあとからになるだろう。
 |
