- RemedyのNorthlightチームは、Alan Wake 2のためにエンジン構造からレンダリングまで中核技術を新規開発または大幅に刷新し、より大きく複雑なワールドを扱うための基盤を整備
- 新しいECSベースのゲームオブジェクトモデルは、メモリ効率と安全な並列実行を高め、CPUコア数が異なるさまざまなハードウェアで、より動的なワールドを実現できるようにした
- ボクセルベースのキャラクターコントローラーとアニメーションベースのNPC移動は、狭く複雑な空間でもキャラクターが自然に動けるよう支援し、Scatteringツールは密度の高い植生制作を支援
- レンダリングは、GPU駆動パイプラインとmesh shader、meshletカリング、GPUベースの植生アニメーション、HDR、MBOIT透明レンダリングにより、より多くのジオメトリと霧・透明効果を処理
- PC版は、ハードウェア構成が許す場合にDLSS Frame Generation、DLSS Ray Reconstruction、Path Traced Indirect Lightingを活用し、Controlよりも正確で堅牢なレイトレーシングを提供
Northlightエンジンとゲームプレイ基盤技術
- Alan Wake 2の開発過程で、Northlightは完全に新しいデータ指向ゲームオブジェクトフレームワークへ移行
- 新モデルはエンティティ・コンポーネント・システム（ECS）をベースにしている
- ECSはメモリ効率の高い保存と、効率的かつ安全な並列実行を可能にする
- さまざまな対象ハードウェアのコア数を効率的にサポートし、より大きく動的で豊かなワールドを作れるようにする
- 大規模な植生配置用のScatteringツールもECSの利点を活用
- ワールドにより多くのエンティティを配置できる
- オブジェクト散布のための個別のカスタムソリューションを作る必要が減る
- ゲームプレイ実装でもECSが反復作業の速度を向上
- Sagaが証拠を集める視覚的なストーリーボードであるCase Boardの実装に使用
- 新しいシステムやゲームオブジェクトの追加・修正が容易に
- Case Boardの保存とロードで性能向上を確認
キャラクター制御とNPC移動
- Alan Wake 2は、Northlightのキャラクター制御を再設計させた作品
- 新しいボクセルベースのキャラクターコントローラーは、狭く複雑で動的な環境での滑らかなナビゲーションを可能にする
- キャラクターの動きがより自然で流動的に変化
- 狭い空間でキャラクターがオブジェクトにぶつかったり挟まったりする問題を減らすことに焦点を当てている
- NPC移動も大幅に刷新
- すべてのNPCは、アニメーションベースの移動と新しい距離ベースのMotion Matchingを併用
- 移動品質が高まり、アニメーションがいつどのように使われるかをより適切に制御できる
風、植生、スクリプティングツール
- Alan Wake 2のリアルな風は、物理、パーティクル、布に影響を与える
- ゲームデザイナーは屋内と屋外領域に異なる風速を簡単に定義できる
- 2つの領域間の遷移は、滑らかで状態を保存しない方式で行われる
- SagaとCaseyが乗る車内には、動くwind boxを適用し、車内を無風の屋内領域として指定
- 風システムは**Signed Distance Fields（SDF）**方式の上に構築
- wind boxは、滑らかなグローバル風力フィールドを定義するプリミティブとして使われる
- 各領域の風の強さを決める基本ブロックのように動作し、屋内と屋外の間の風のパターンを滑らかにする
- 新しいScatteringツールは、大規模な植生と環境小物の制作のために開発
- Alan Wake 2の、より密で豊かで生き生きとした環境制作に使用
- 以前より長い**可視距離（draw distance）**と併用され、プレイヤーがより遠くのオブジェクトやディテールを見られる
- スクリプティング言語は、独自言語からRobloxがLuaから派生させた組み込みスクリプティング言語Luauへ移行
- Luauは幅広いエンジン機能を公開し、ライブ編集をサポート
- レベルスクリプティングや武器アップグレードシステムなど、複数のゲームプレイシステムで使用
- ゲームチームはエンジンプログラマーの助けなしに、さまざまなゲーム機能やVFX効果をプロトタイピングし実装できた
- Remedyは独自のVS Code言語サーバー拡張を作成し、開発パイプラインに統合
- Luau導入により、保守が不要になったコード約80,000行を削除
GPU中心のレンダリングと植生アニメーション
- Alan Wake 2は、Northlightの新しいGPU駆動レンダリングパイプラインを示している
- パフォーマンスを犠牲にせず、ワールドにより多くのジオメトリを入れられる
- mesh shaderを使うGPU駆動レンダリングにより、単一ピクセル精度のオクルージョンカリングが可能
- シーン内のすべての要素を遮蔽物として使える
- 見えるものだけを描画する能力により、Alan Wake 2のワールドは過去の発売作品より多くの幾何学的ディテールを持つ
- レンダリングパイプラインはmeshだけでなくmeshletもカリング
- meshletはmeshから抽出した、より小さく最適化された三角形グループ
- Cauldron Lakeのコンビニ位置の例でmeshlet構造を確認できる
- 広大な原生林環境は、新しいシェーダーベースの植生システムで実装
- このシステムは、完全にGPU上で実行される新しいスキニングシステムを基盤にしている
- アート主導のbone shaderアニメーションをサポート
- Alan Wake 2では、環境に見えるすべての植生にキャラクター形式のリグを使用できるようにした
- bone shaderは、アーティストが直接シェーダーコードを書いて基盤システムに接続できるAPIを公開
- 植生だけでなく、水上で揺れるオブジェクト、風に揺れる電線のような対象にも技術的に適用可能
- Cauldron Lakeでは、ほぼ300,000本のboneが毎フレーム処理される
HDR、透明レンダリング、VFX、レイトレーシング
- Alan Wake 2はHDRを完全にサポート
- デフォルト設定だけでもSDRとHDRディスプレイの両方で見栄えが良いよう調整
- HDR対応はトーンマッピングへの新しいアプローチを必要とした
- カラーグレーディングは実際のカラリストがHDR基準で行い、HDRとSDRの両方で独自のアートスタイル、雰囲気、ストーリーテリングを生かすよう制作
- 濃い霧のシーンは透明レンダリング改善を基盤としている
- NorthlightはAlan Wake 2開発中に透明レンダリングを完全に刷新
- **MBOIT（Moment-Based Order-Independent Transparency）**を使い、異なる詳細度を持つ透明サーフェスも滑らかに混ざるようにした
- 透明要素を3つの解像度でMBOITにより描画
- 霧、透明ジオメトリ、効果を途切れなくブレンドできる
- ワールド内の霧配置をより細かく制御するパイプラインも改善
- ピクセル単位の透明ライティングと霧の影響を受ける反射を組み合わせ、不透明要素と透明要素が過去プロジェクトよりよくなじむ
- 霧は多重光散乱を近似し、厚みのあるリアルな雰囲気を作る
- NorthlightのノードベースのVFXツールは、サポート機能とランタイム性能の面で大きく進化
- 雨、濡れ、水シミュレーション、キャラクターの傷のような複雑で動的な効果をVFXアーティストが制作できる
- VFXツールもGPU駆動レンダリングの利点を受け、GPUを通じて多くのジオメトリを処理できる
- 例えば、屋内や覆いの下に雨が見えないようにする動的マスクにrain blockerオブジェクトをレンダリングする際に活用
- レイトレーシングは完全なray-traced direct lightingをサポート
- Nvidiaとともに改善したノイズ除去と間接照明アルゴリズムを組み合わせる
- Alan Wake 2のレイトレーシングは、Controlで見られたものより正確で堅牢
- すべての植生ジオメトリアニメーションがスキニングで制作・シミュレーションされるため、レイトレーシングによりアニメーション植生がより良く見える
- PCプレイヤーはGPUとCPU構成が許せば、最新のNvidia DLSS技術を利用できる
-
DLSS Frame Generation
-
DLSS Ray Reconstruction
- Path Traced Indirect Lighting
1件のコメント
Hacker News の意見
Remedy は、スタジオ全体でも数百人規模であることを考えると、グラフィックスでは常に規模以上の成果を出している会社だと思う
新興勢の中では、Remedy と CD Projekt Red くらいしか、画質と性能の面で Unreal、Unity、EA Frostbite のような大規模エンジンと競えるようには見えない
コンピュータグラフィックスやテクニカルアートに興味があるなら、彼らの GDC/SIGGRAPH 発表は素晴らしい
Alan Wake 2 は技術的には史上最も美しいゲームの一つで、個人的には芸術的にもそうだと思う。設定をすべて低くしてもなお見栄えがよいというのは本当に大きな成果で、古いハードウェアにまでスケールさせつつ見栄えを保つのは難しい
ただし Digital Foundry のような分析者たちが述べているように、GPU が メッシュシェーダー をサポートしていないと性能は非常に悪い。この記事でもカリングにメッシュシェーダーを使っていると言及しているが、そのおかげでコーヒーカップやタイヤのような物体を完全に丸くしつつ、Cities Skylines 2 の性能を台無しにした「NPC ごとに口の中に1万ポリゴンの歯がある」式の問題を避けられる。Unreal 5 の Nanite が提供する大きな利点の一つもこの部分だ
1993年の驚異的なデモ Second Reality から、30年後の Alan Wake 2 まで、かなりはっきりした線を引くことができる
https://www.youtube.com/watch?v=iw17c70uJes
性能問題は単に「見えない歯をレンダリングしている」よりはるかに大きい: https://blog.paavo.me/cities-skylines-2-performance/
例としては分かりやすいが、より大きな問題は LOD の欠落 と カリング不足 だ
CD Projekt Red は今後の作品を UE5 に移行しているところではなかったか？ 残念だ。Cyberpunk は本当に美しかったし、あのエンジンで作られたマルチプレイヤーゲームを見てみたかった
CDPR は1236人、Frostbite を作った DICE は714人、Epic は最近のレイオフ前で2200人だ
いずれも Wikipedia 基準の数字だ
現代のコンピュータグラフィックスを定義し普及させた人々でなければ、誰が GPU を限界まで押し込めるというのか？
最初の例でも、足が床の上で滑ったり、物体に阻まれて前に進めないのにその場歩きのように滑ったりするのがかなり気になる
こういう問題がいつ頃解決されるのか気になる
もちろんエンジン自体は驚異的で、視覚効果とシステムはこれまで見た中でも最高水準だ
RDR2 はアニメーションが非常に現実的な代わりに、操作感が少し「ふわふわ」している
個人的には、左を押したら画面内のキャラクターが即座に左へ動くようなキビキビした動きのほうが好みだ。より現実的に見えるアニメーションシステムは、足のアニメーションがプレイヤー入力に「追いつく」まで遅延を生むことになる
ただし継続的なレイキャストと IK 計算は無料ではないため、性能との引き換えにもなるし、レスポンスとも衝突する
多くのゲームはより速い移動と操作の反応性を選ぶ。結局、技術的には何年も前から解決されている問題だが、ゲームデザインのあらゆる要素と同じく、選択とトレードオフだ
Naughty Dog をはじめ多くのところが使っている方式だ。ただし他のコメントにもあるように、反応性とアニメーションの正確さの間にある根本的な緊張関係は依然として残っている
Northlight の以前の作品である Control では、これはそれほど目立たなかった [2]
[1] https://youtu.be/jQb07FHJ-bQ?t=628
[2] https://youtu.be/fcDK6tnx4vM?t=6700
実際には、アニメーションをブレンドして遷移が自然に見えるようにする アルゴリズム についての内容だった
また別の Unreal Engine ベースのゲームではなく、別のものを見られるのは新鮮だ
独自の 社内エンジン を持つのは途方もなく難しいはずで、エンジン自体も問題だが、レベルやアニメーションなどを作るツール側のほうが、もしかするとさらに難しいかもしれない
それでも利点もありそうだ。低レベルのアーキテクチャをより多く制御できれば、最適化の機会も増える。Unreal のような汎用エンジンではより難しい
このゲームを早くプレイしてみたい
シェーダーコンパイルのせいでカクつきが生じる理由がいまだに理解できないし、他のほとんどの社内エンジンにはそういう問題がない。なぜまだ改善されていないのかも分からない。たとえ明日改善アップデートが出たとしても、ゲームがそれを活用するまでには何年もかかるだろう
大きなコミュニティが付いた既製エンジンがこれほど多い中で、自前でやるには本当に 完全な制御権 が必要でなければならないはずだ
文章のトーンが気に入った
たとえばマーケティングチームなら「キャラクターはこれまで以上に反応がよく、生き生きしている」と言うだろうが、内部の開発ノートには「キャラクターが狭い空間で物体にぶつかったり、引っかかったりしない」と書かれている、という部分がよかった
文全体がマーケティングであり、その中のコメディもマーケティングなのだ
Remedyがエコシステム内で D言語 を使っていることについて、今はどう考えているのか気になる。まだ使っているなら、AW2の開発中にどんな困難を経験したのかも見てみたい
参考資料: Using an Emerging Language in Quantum Break (https://ubm-twvideo01.s3.amazonaws.com/o1/vault/gdceurope201...)
DConf 2016: Quantum Break: AAA Gaming With Some D Code -- Ethan Watson (https://www.youtube.com/watch?v=7YjLW7anNfc)
今Dプログラマーを探してもいないのは確かだ
出典を掘り下げたいなら、出発点としてこのリンクが使える: https://forum.dlang.org/post/lymybpygzfalbdgoaizr@forum.dlan...
その発表をした人はもうそこで働いておらず、Facebookのような大手もDの利用をやめたことを考えると、もう使っていないのではないかと思う。それでも、間違いだったと分かればうれしい
その人が去ったり、貢献・保守できる立場から外れたりすると、残りのチームとスタジオの支持と受容がない限り、徐々に置き換えられ始める
聞いたところでは、Dで書こうと推していた人が1人いたらしいが、まだ残っているかは分からない
Unreal Marketplaceで最高水準のコンテンツを作っていたチームの一部が、このゲームにも参加していたと記憶している
https://mawiunited.com/
素晴らしいコンテンツだ。こういう形で UE5コンテンツ を作るスタジオがもっと増えるといい
スクリプティング環境としてRobloxの Luau を使う方向に移行したというのが興味深い
ゲーム技術で、なぜこれほど多くのところがスクリプティングにLuaを使うのか、いつも不思議に思っている。特に最初から設計する場合でもそうだ
Cランタイムを使えるものなら、何にでもLuaスクリプティングを組み込める
だからBaldur’s Gate 1からWarcraft III、Robloxのような現代のタイトルまで、標準的な選択肢のように使われてきたのだ
キャラクターの動きが、いまだにかなり 不気味の谷 のように感じられる
「ボクセルベースのキャラクターコントローラー」の動画での歩き方は滑っているように見えるし、「NPC移動」の最初の数秒も歩き方がぎこちなく見える
各ステップが完全に同じで、すべて同じ歩幅を使っているからだと思う。そのためキャラクターたちが不自然なほどぴったりそろって動く
動画の後半でキャラクターたちが個別に歩行と走行を切り替えるときは、より多様な動きが見えて、ずっと現実的に見える。動きの細部の違いを全体的にもっと入れるのが、なぜこんなに難しいのか気になる
ただ、その点を補強するなら、友好的なNPCはほとんど全員が立ち止まっている。敵対エリアで敵が押し寄せてくると、歩き方は見なくなるし、そもそも霧に隠れている
個人的には、Controlはこれらすべての 技術デモ だったと思う。敵の数がはるかに少なく、ホラー寄りの物語として構成されていた理由も説明がつく
つまり彼らは ECSゲームエンジン、AAA級レンダラー、Naniteに似た技術、Luaベースのスクリプティングエンジン、ハリウッド級の顔アニメーションを全部持っているということか？
エンジンをリリースすべきだ。Unrealの強力な競合になり得る。ECSのおかげでよりスケーラブルで、Luauで書くのもより簡単だ
Linuxでゲームを買おうとして、つらい形で知った。だからUnrealと競合すると、そちらとの関係が悪化する可能性が高い
ただし 社内ソフトウェア を他人が使う製品に変えるのは、まったく別の話だ
Remedyが メッシュレットパイプライン を採用したのは確かだが、最先端のレンダリングでは今や主流に近い。Naniteのように小さな三角形を実際にレンダリングするためにコンピュートシェーダーを使うという言及は見ていないが、私が見落としているのかもしれない
今ではAlan Wake 2はレイトレーシングを切ってもHigh設定がかろうじて動く程度だ
視覚的には驚異的なエンジンだが、個人的には 要求スペック が高すぎる
エンティティ・コンポーネント・システム（ECS）アーキテクチャは、Bevy[1] のような若いオープンソースゲームエンジンでも使われている
ゲーム開発からは長く離れていたが、ゲームでよく見かけた重く複雑なオブジェクト指向を取り払うアーキテクチャの話を聞くと、また足を踏み入れてみたくなる
[1]: https://bevyengine.org/
2000年代初頭から勢いがつき始め、今では普遍的とまではいかなくても、長いあいだ基本技術のように使われてきており、一部のオープンソースエンジンでも同様だ
たとえば https://github.com/Adelost/entity-component-systems-study#re... を見るとよい