つぶやく［GTMF］シリコンスタジオ、グラフィックスミドルウェアをStadia対応へ
 |
シリコンスタジオは日本を代表するゲーム開発支援ミドルウェアを提供しているソフトウェア開発企業である。とくに業界で有名なのはゲームグラフィックス関連のミドルウェアで，中でも「YEBIS」「Mizuchi」は有名でゲーム開発用途に留まらず，映像制作現場から建築産業，自動車産業といったノンゲーム活用にまで採用事例を広げている。
 ポストエフェクトミドルウェアYEBIS |
 物理ベースリアルタイムレンダリングエンジンMizuchi |
このほかにも，家庭用ゲーム機からアーケードゲームまで幅広く対応する純国産ゲームエンジン「OROCHI」，英国生まれのリアルタイム大局照明ミドルウェア「Enlighten」なども，国内外に数多くの採用実績を誇つ。ちなみに，Enlightenはもともと，英国Armの完全子会社だったGeomericsが開発したものだったが，2017年にシリコンスタジオが開発および提供/サポートのライセンスを獲得しており，現在は，事実上，シリコンスタジオの製品となったという経緯がある。
 「純国産」というキーワードで訴求されるスイート型ゲーム開発エンジンOROCHI |
 定番の大局照明ミドルウェアEnlighten |
このセッションは，シリコンスタジオのミドルウェア製品群をStadiaに対応するにあたって得られた知見を日本のゲーム開発者達に提供しようとする目的で行われている。
Stadiaにおけるグラフィックス開発
現時点では，Googleは日本におけるStadiaサービス開始を正式アナウンスしておらず，多くの日本のゲーム開発スタジオからすれば未知のプラットフォームである。
今回の発表は，シリコンスタジオが日本の一般的なゲーム開発スタジオよりも先行してStadia対応実験を試みたことの体験談に相当するわけで，日本のゲーム業界関係者達からは大きな関心が寄せられていたように思えた。
まず，Stadiaプラットフォームの基本情報だが，OSはLinuxベースとなる。となれば，グラフィックスAPIはDirectX系ではなくOpenGL系のVulkanとなる。
 Stadiaの基本情報 |
Stadiaはクラウドゲームサービス，つまりはサーバーで実行しているゲームの映像をネットワークをとおしてストリーミングする必要があり，開発環境にはStadia環境を再現するためのサーバーが必要になる。この開発機サーバー（テストサーバー）は，すでにGoogleとやり取りすることでゲーム開発側に導入可能な体勢になっており，シリコンスタジオでも1台実機を設置したとのことだ。ただ，その冷却システムの騒音がとても大きかったそうで，設置場所には防音装備の設置が必要になったとのこと。
 シリコンスタジオでは会議室の隣に設置したところ，会議室利用者から「うるさい」というクレームがきたのだとか。結局，素置きではなく，追加の防音対策を余儀なくされたという |
開発にはVisual Studio VSI（※Visual Studio用Stadiaプラグイン）が利用できるのだが，まだファーストバージョンということもあり，現時点では「開発ツールがもたつく」「開発ツールが想定外の動作をする」といった状況に遭遇することもあり，その際にはこまめにサポートを受けたほうがよいとのことであった。そうしたトラブルの解決策の多くが「独特な縁起担ぎ」だったそうで，世界中のStadiaプラットフォーム向けにコンテンツを開発しているスタジオは，そうした知見を蓄積している最中のようである。なお，辻氏によればStadiaサポートチームの対応は手厚く，概ね不満なしとのことであった。
 開発フレームワークはVisual Studio VSIベースだが「特定のウィンドウを閉じる」といったような「縁起担ぎ」が必要な局面も多々あったとか |
結局のところ，Stadiaはまだ開発フレームワーク自体の歴史が浅いため，製品開発はStadia向けの開発フレームワークでゼロから行うのではなく，完成度の高いPC版をVulkanベースで開発しておき，これをStadiaに持っていくという流れのほうがよいかもしれないと辻氏は述べていた。
 PC版を開発し，これをStadiaに移植するという流れのほうがトラブルなく開発できるようだ |
ただ，同じVulkanベースのグラフィックス開発でも，PC版とStadia版とでは，利用できるバッファフォーマットに差異があるなど，方言的な差異は少なからずあるのでポーティング（移植作業）にはそれなりのトライアンドエラーが必要になるようではある。
 PC版の開発にあたってもVulkanベースでの開発が奨励されるが，それでもStadiaへの移植の際には追加の対応は必要になるようだ |
気になるStadiaのパフォーマンスについては，契約等の都合上で詳細を述べることはできないとのことだったが，グラフィックスに関しては「4K/60fpsは何も最適化しなくても出るわけではなく，PS4 Pro的なチェッカーボードレンダリング（関連記事）などのテクニックも引き続き有効でしょう」という，やや含みのある説明をしていた。
 Stadiaの「4K対応」に偽りはなさそうだが，GPUパフォーマンスにそれほど余裕があるとも言えなさそうである |
YEBISのStadia対応の場合
このあと，辻氏は，実際に開発チームが同社のポストエフェクトミドルウェアYEBISをStadiaに対応した際の裏話を紹介した。
現在，シリコンスタジオでは，このYEBISと，物理ベースレンダリングエンジンMizuchiの両者を同時に導入しやすくするために基本アーキテクチャの改良に取り組んでいる。具体的にはさまざまなプラットフォームごとのAPIの仕様の相違を吸収するため抽象化レイヤーの最適化を進めているというのだ。
 シリコンスタジオはYEBISとMizuchiのグラフィックス抽象化レイヤー（GHI）の統合に取り組み始めた |
シリコンスタジオではこの抽象化レイヤーを「GHI」（Graphics Hardware Interface）と呼称しており「このGHIのリファイン開発の一環としてStadia対応が盛り込まれた」というのが実情のようだ。
このGHIリファインに際しては，従来のYEBISでサポート対称としていたDirectX 9世代GPU，PS3，PSVITA，Xbox360，Wii Uなどがサポート外となった。逆に新GHIではDirectX 12，Vulkan，Switch，まだ見ぬ次世代機などをサポート対称とできるように開発が進められている。そう，まだ見ぬ次世代機への対応」のところに，次世代PSや次世代Xboxに加えてStadiaも入っているわけである。
 従来YEBISの対応プラットフォーム。GHIもこれらに対応したものとして設計されていた |
 新世代GHIはYEBISとMizuchiとで共通設計となる。新規設計のこのタイミングで対応プラットフォームのバリエーションも再考がなされたという流れである |
この「Stadia対応」とは，事実上，Vulkan対応の延長線上にあるわけだが，シェーダプログラムは，従来GHI同様にオリジナルはHLSLで記述されているものの，これをVulkanの「SPIR-V」エコシステムで利用できるようにリライトが行われている。
 |
ちなみにSPIR-VとはOpenGL/Vulkanの規格策定を行っているKhronosグループが推進しているシェーダの中間言語仕様のことだ（関連記事）。本来OpenGL/Vulkan系プラットフォームではシェーダ言語としてGLSLを利用すべきなのだが，このSPIR-Vエコシステムが成熟してきたおかげで，DirectX系シェーダ言語のHLSLも利用しやすくなってきている。ただ，辻氏によれば「SPIR-Vエコシステムに通りやすい記述規則を意識してシェーダプログラムを書き換える必要はあった」と述べていた。
 SPIR-Vを基盤としたAPI環境を示したスライド。SPIR-Vがさまざまな言語や開発環境とAPIを結んでいる |
また，今回のStadia対応に際して（というよりもこのリファイン版GHI開発に際して）は，描画コマンド形成処理にあたっては近代的なマルチスレッド処理最適化を推し進めたとのこと。
その最適化術の大枠はこんな感じだ。
まず，描画パス種別ごとに「見積もりコスト」的な「想定描画アイテム数」を設定しておく。この「想定描画アイテム数」は，描画コマンド形成処理にかかるおおよそのCPUコストに相当するので，全描画パスのこの「想定描画アイテム数」の総和量を求めてやれば，もし，シングルスレッドで描画コマンド形成処理を行ったとしたら，どれくらいのCPUコストがかかる」というトータルCPUコストが求められる。
そして，このトータルコスト値を「描画コマンド形成処理に取りかかれるCPUスレッド数」で割って求めた値分だけ，各CPUスレッドで描画コマンド形成を担当するように割り当てれば，理屈上は，最短時間で描画コマンド形成が終了できるのだ。
 DirectX12/VULKAN環境では描画コマンド形成処理をマルチスレッド化するのがトレンドである。その取り組みに際してまず「トータルコスト」を求め，それをこの処理に割り当てられるスレッド数で割り，その解の個数分の描画コマンド形成を1タスクとして各CPUスレッドに割り当てる設計とした |
 各グラフィックス描画処理のコストの一例。これらをいっぺんに行った場合のトータルコストは353と想定できる |
 このコスト353の描画コマンド形成を4スレッドに割り当てる場合，1スレッドあたりは約88のコストごとを割り当てれば，理屈上は最短時間で描画コマンドの成形が行えることを期待できる |
リファインされたGHIでは，この仕組みがYEBISやMizuchiを利用した場合にも効率的に働くので，CPUボトルネックが発生しにくくなったというわけである。
 現状，この方針でDirectX12VULKAN向けの新GHI開発が行われている |
ところで，ある描画パスの出力を，それに続く描画パスに入力するようなステート変更を伴う描画コマンド形成においては，描画コマンド形成処理がマルチスレッドで並列進行する関係で，そのステート変更のコマンドの挿入位置の確定ができない。
 |
そこで，すべての描画パスに対して起こりうるステート変更を調査する前処理を，実際のマルチスレッドベースの描画コマンド形成処理の前に実践するようにしたとのこと。なお，この前処理はシングルスレッドで行われる。そして，実際のステート変更コマンドの挿入は，この調査結果に基づいて後段のマルチスレッドによる描画コマンド形成処理時に行われるのだ。
 |
Stadia対応とは話題が少しずれるが，辻氏は，今回のStadia対応以降のYEBIS，Mizuchiの今後の機能強化についても語っていた。
現在，進行しているのはシェーディング計算の解像度を可変とする「VARIABLE RATE SHADING」への対応，機械学習ベースの「超解像処理」などだそうだ。
前者は，被写界深度処理（ピンボケ処理）やモーションブラー処理など，フル解像度のシェーディングが必要ない条件下や特定領域に対して有用だとのことである。後者はNVIDIAが提供しているDLSS（Deep Learning Super Sampling）のようなAI処理を組み合わせたポストエフェクト処理の機能開発を指しているようである。
 |
EnlightenのStadia対応は新版3.10リリース後に提供を予定
シリコンスタジオではEnlightenについてもStadia対応の計画を進めている。
Enlightenは，事前計算フェーズおよびランタイムフェーズにおいてもCPUメインで動作するアーキテクチャとなっていて，ランタイム時は光の伝搬ネットワーク的な情報などを3Dテクスチャで表したボリュームデータをGPUに受け渡すだけなので，プラットフォーム依存した対応作業は少ないと目論んでいる。
しかも，最新版の3.09までにLinux対応は終えているため，事実上，Stadia対応はStadia環境下におけるVulkan API経由でのEnlighten3Dテクスチャデータの受け渡し処理系の実装だけで済むようだ。
シリコンスタジオでは，現在，Enlightenについては，新バージョンの3.10の開発を進めており，Stadia対応の実作業は，この3.10のリリース後に行われるようである。
 |
それでは，その2019年後半にリリース予定とされる3.10では何がどう変わるのか，これについても辻氏は解説を行った。
現在のEnlightenは，Unreal Engine4（UE4）に組み込んだ状態で使う分には十分に扱いやすいミドルウェアとなっているが，ゲーム開発スタジオ独自の開発ツールへの統合や，ゲーム開発スタジオ独自のグラフィックスエンジンに組み込むためのプロセスには「難しさ」が残っていたという。3.10ではこの「難しさ」を低減させるための改善を進めているというのだ。具体的には「Visual Studio 2017への対応」や「各ゲームスタジオのツールやグラフィックスエンジンに組み込むための簡易抽象化層（いわゆるWrapper）の開発」や「サンプルの充実化」などが新規開発案件として挙げられていた。
 |
 |
機能面では，各種マイナーな不具合修正のほか，大規模シーンへの対応も3.10でのホットトピックとなるそうである。
大規模シーンとは，プレイヤーキャラクタの移動に連動して新たに見えてくるシーンを動的に読み込んでいくような，オープンワールドタイプのゲームによくあるマップ（レベル）システムのことだ。これまでのバージョンでは，光の伝搬ネットワークを計算する事前計算フェーズを，大規模シーンで行うと必要以上に時間が掛かってしまっていた。そこで，読み込まれているシーンと，これから動的に読み込まれるシーンとの依存関係にまつわるパラメータを設定することで，この問題を低減したという。
 |
 |
辻氏は，Enlightenの3.10版リリース，Stadia対応に続くプロジェクトとしてEnlightenのメジャーバージョンアップ版の開発についても言及した。
基本的には「Enlightenのアーキテクチャを最新ハードウェア環境に対応させる」という方針のようで，具体的には「CPUベースで行われている事前計算フェーズのGPU対応」「レイトレーシング対応GPUのサポート」などが新機能の代表格として挙げられていた。
 |
AIやプロシージャルの活用も検討中
辻氏は，シリコンスタジオの今後の製品開発ロードマップを示してセッションを締めくくった。
上で，YEBISにAIベースの超解像機能の実装計画があることに触れているが，シリコンスタジオではそうしたポストエフェクト処理以外にも，機械学習とレンダリング技術を関連させた新しい基礎技術の開発を行っているそうだ。辻氏は「まだ生き物の表現に違和感を感じる局面が多い。これをミドルウェアの力で改善できればと考えている」と述べていたことから考察するに，その適用先を描画結果だけに留まらず，アニメーションなどにも適用範囲を広げることを考えているのかもしれない。
また，昨今では採用事例が増えている自動車業界，建築業界，映像制作業界などのノンゲームジャンルの顧客に向けた新しい取り組みも進めているそうだ。
自動車業界では，試作車両のデザインCGモデルを街中や海辺，森林など，さまざまな環境下でレンダリングして評価を行うが，現状は，そうした環境データは事前に作り込んだ限られた個数の3Dシーンや，あるいは手持ちの360°映像/写真を使うだけで，バリエーション数が限られていることが多い。近年，盛り上がりを見せている自動運転技術開発におけるAI向け走行教材データも同様だ。
シリコンスタジオでは，こうした素材（アセット）製作を，同社のリアルタイム技術の強みを活かして提供していくような取り組みを考えているという。具体的には，街並みや森林を初めとした様々な景観を昼夜・雨晴れといった天候表現も絡めつつアルゴリズム生成（プロシージャル生成）するようなシステムを，YEBISやMizuchiの組み合わせで実現するもののようだ。
実際，AIとCG技術を連携させるシステム」「アセットのプロシージャル制作」「自動運転技術開発の教材データにゲームグラフィックス技術を応用するアイデア」は，NVIDIAやEpic Gamesなども積極的に取り組んでいる技術テーマであり，世界中の研究者達からも熱い視線が送られ始めている。シリコンスタジオが，こうしたホットな研究テーマに目を向けたことはごく自然な流れだといえよう。
辻氏の講演後，GTMF2019のシリコンスタジオブースで話を聞いた感じでは，今年9月4日から開幕する日本最大級のゲーム開発者向けカンファレンス「CEDEC 2019」の同社ブースにて，そうしたテーマに関連した新しい展示などを見せられるかもしれない，というコメントももらったので，期待しておきたい。
