- Daniel Schroederは、90年代の3Dゲームに見られるピクセル化された表面の質感を、小さなボクセル表面ディテールへと拡張するリアルタイムレンダラーを開発中であり、入力アセットには馴染みのあるローポリ三角形メッシュとテクスチャを使用する
- シーン全体をボクセルグリッド化するのではなく、ディスプレースメントマップによって表面だけをボクセル風に見せることで、Doom、Quake、Duke Nukem風の静的環境に合ったビジュアルスタイルを狙っている
- CPUは三角形メッシュと制限付きのディスプレースメント情報をGPU向けジオメトリデータへ変換し、テクスチャを前処理し、フレーム描画はGPUがほぼ独立して処理する
- デモはRadeon RX 5700 XTで1440p時に4〜9msのフレームタイムを示し、Steam Deck OLEDの800pでは60FPS超を維持し、多くの場面で90FPS固定に到達している
- 環境は引き続き三角形メッシュとして扱えるため、衝突判定、キャラクターコントローラー、経路探索は既存の物理ライブラリとメッシュベース処理で解決でき、必要な一部のシステムだけがボクセルの細部形状を意識すればよい
90年代3D美学をボクセル表面へ拡張
- 目標は、90年代のクラシックな3Dゲームにおけるシンプルな環境ジオメトリと鮮明なテクスチャ境界を保ちながら、表面にブロック状の3Dディテールを加えること
- Doom、Quake、Duke Nukemのような初期〜中期90年代の3Dゲームは、技術面とゲームプレイ面の両方に大きな影響を与え、近年では当時の視覚的制約そのものがレトロな魅力として受け取られている
- 出発点は「ピクセルの代わりにボクセルで表面ディテールを作ったらどうなるか」という問い
- たとえば石畳の壁は、近くで見てもピクセル化された印象を保ちながら、幾何学的な奥行きを持たせられる
- 結果は、90年代ゲームの外観と、より現代的な表現との中間に位置するよう設計されている
一般的なボクセル方式の制約
- 一般的なボクセルメッシュは、各キューブ状セルが埋まっているか空かを表す3次元グリッドである
- Minecraftのように大きなボクセルへテクスチャを貼ることもできる
- Teardownのように小さく単色のボクセルを使うこともできる
- ボクセルベースの環境を作るには、すべてのジオメトリを共有グリッドに配置するか、複数の独立したボクセルメッシュを同じ空間に配置する必要がある
- ボクセルジオメトリを直接制作するツールはあるが、制作工程に時間がかかり、小さなメッシュ制作に制限されることも多い
- タイル状の壁や床のようなビルディングブロックを作って大きな構造物を組み立てることはできるが、グリッド整列した建物には向いていても、自由な地形にはあまり向かない
- 手続き生成は自然環境やビルディングブロックの組み合わせに有用だが、それ自体に難しさがあり、特定の種類のゲームにしか適さない
- 既存の三角形メッシュをボクセルグリッドへラスタライズすることもできるが、結果のジオメトリが単一のボクセルグリッド上に載ることで、望まない美学的結果を生むことがある
- 軸に整列した面は平らなボクセル板のように見え、45度の面は階段状に見えることがある
- シーンの正式な表現がボクセルになると、レンダリングだけでなく、物理、キャラクターコントローラー、NPCの経路探索といったゲームロジックもボクセル単位で動作する必要が出てくることがある
- 一方でMinecraftやTeardownのように、ボクセルメッシュではジオメトリの追加や削除をしやすい利点がある
一般的なディスプレースメント方式の限界
- ディスプレースメントマッピングは、テクスチャとともにディスプレースメントマップを使い、テクスチャの各ピクセルがメッシュ表面から内側または外側へどれだけ移動するかを定義する
- 3Dモデリングソフトウェアでは、メッシュを細分化したうえで新しい頂点を動かし、ディスプレースメントを実際のジオメトリにできる
- この方式は物体のシルエットにも影響する
- 結果メッシュのポリゴン数は大きく増加する
- 硬いエッジやコーナーを持つ入力メッシュは、良い結果を得るために修正が必要となる
- リアルタイムグラフィックスでは、parallax occlusion mappingのような表面シェーディング効果により、実際の形状を変えずに細かなジオメトリがあるように見せられる
- 大きな床や壁では見栄えが良い場合がある
- 物体の縁ではジオメトリが依然として平坦なままなので、錯覚が破綻する
- shell mapping は、高度に細分化されたメッシュなしでも物体のシルエット上でディスプレースメントを見せられる中間的アプローチである
- 入力メッシュの曲率が高い領域では扱いが難しい
- 硬いエッジやコーナーを持つ入力メッシュをこの手法に合わせるのも容易ではない
実装方式: ボクセルとディスプレースメントマッピングの結合
- このレンダラーは、クラシックな3Dゲームのような環境をローポリ三角形メッシュで作り、ディスプレースメントマップでボクセルスケールの表面ディテールを定義したうえで、実際にボクセルで組み上げられているかのようにレンダリングする
- 建物の角のように鋭いエッジが多い環境を対象としているため、一般的なディスプレースメントマッピングが苦手とする領域でもボクセルらしい結果が必要になる
- 現在の実装はスタンドアロンのC++ / Vulkanプロジェクトである
- インフラは3つの主要な処理を行う
- 三角形メッシュと制限付きディスプレースメントマップ情報を受け取り、GPUが変形後のメッシュを描画する際に使うジオメトリデータへ変換する
- この処理はフレーム描画前にCPUで実行される
- 製品版ゲームでは結果をディスクへベイクできる
- 動画のデモ環境全体の変換は、単一スレッドで0.5秒かかる
- テクスチャを前処理し、レンダリング中に必要なノーマルマップのような情報を生成する
- 生成されたメッシュとテクスチャ状態を使って、GPU上でボクセル・ディスプレースメント・ジオメトリを描画する
- 性能はすでに実用的な水準にある
- Radeon RX 5700 XTでは、デモシーケンスが1440pで4〜9msのフレームタイムでレンダリングされる
- これは250〜110FPSに相当する
- Steam Deck OLEDのネイティブ800pでは60FPS以上を維持し、多くの場面で90FPSに張り付く
アートアセット制作方法
- コンテンツ制作には、テクスチャとメッシュの2種類のアセットが必要である
- 各テクスチャはalbedo mapとdisplacement mapで構成される
- albedoはレトロゲームの限られたパレットを模倣すると、ビジュアルスタイルの説得力を高めやすい
- displacement mapは細かな高さ情報を提供し、レンダラー側でスケールを調整して強度を変えられる
- スケール調整後の高さ単位は、表面を内側または外側へ何ボクセル移動させるかを意味する
- レンダラーは最も近い整数ボクセル単位にしか変位させないが、正確な高さ値はノーマルマップ計算に使われる
- 1ボクセル未満の特徴でもライティングには影響しうる
- メッシュは、シェーディングノーマルを持つ一般的なローポリのテクスチャマッピング済み三角形メッシュである
- ノーマルは、どの部分が滑らかに曲がった表面で、どのエッジが鋭いエッジなのかを示す
- レンダラーは鋭いエッジで良い結果を出すために追加処理を行う
- ビジュアルスタイルのため、テクスチャマッピング時にはボクセルサイズを一定に保つようにしているが、必須条件ではない
- メッシュ構造とテクスチャマッピングには制限がある
- 一部の制限は今後取り除ける可能性がある
- 一部の制限はレンダラーの動作方式上、避けられない
- アセットは専用のボクセル表現ではなく三角形メッシュなので、さまざまなツールで作成できる
- デモ環境はBlenderでモデリングされている
- 現在Blenderからデモへエクスポートする形式はOBJファイルである
ゲーム制作における利点と適用範囲
- この方式では、特殊なボクセル編集ツールではなく、馴染みのあるワークフローでコンテンツを作成できる
- 良いテクスチャ制作は難しい場合があるが、一度作れば複数のジオメトリに再利用しやすい
- 動画デモのジオメトリのかなりの部分は、3色の単一石材ブロックテクスチャを使っている
- 環境は三角形メッシュとして制作され、ボクセルの特徴は表面装飾なので、都合のよい場面では環境をポリゴンジオメトリとして扱える
- デモアプリケーションは、一人称視点での移動、衝突判定、階段の上り下り、壁との衝突をサポートしている
- 独自の物理エンジンやキャラクターコントローラーは作成していない
- オープンソースの Jolt Physics を統合している
- 元の三角形メッシュを衝突ジオメトリとして使っている
- 敵の移動や経路探索も同じメッシュ基準で解決できる
- 一部のゲームプレイシステムだけがボクセルを意識すればよい
- たとえば一人称シューティングでは、弾丸が変位したジオメトリの正確な形状に従うよう、displacement-aware raycast関数を実装できる
- 多くのボクセルベースゲームは複数のゲームシステムを専用実装する必要があるため独自エンジンを使うが、このアプローチではレンダリング以外の大半のロジックがボクセルスケールの細部を知らなくてもよい
- 既存エンジンにこのレンダリング技法を統合する道筋が、最も現実的な方向性である
残された課題と次のステップ
- 現在の実装はレベルジオメトリ制作にはよく合うが、ゲーム環境には小さなオブジェクト、装飾、敵のような動的要素も必要になる
- 今後は、小物オブジェクトやアニメーションオブジェクトをこのアートスタイルへ統合する方法を追加する予定である
- デモのライティングはすでに見栄えが良いが、現在の実装には制限がある
- 少数のライトしかサポートしない
- シャドウ、アンビエントオクルージョン、より高度な機能はない
- このレンダラーは、一般的なボクセルゲームのような非常に動的なジオメトリではなく、多くのゲームが持つおおむね静的な環境を対象としている
- 特定のアプリケーション要件に応じて、ベイク方式などを含むさまざまなライティング処理の余地がある
- 現在はアンチエイリアシングがなく、特に遠景の床で目立つ
- プロジェクトの今後の計画と、開発者・スタジオ向けの議論は2本目の記事へ続く
1件のコメント
Hacker Newsのコメント
2400 baudモデムでゲームを受け取っていた時代を覚えているくらいの年齢だからか、この美学には本当に魅力を感じる。
動画も素晴らしかったし、個人的には雰囲気を強く呼び起こされた。
屋根が低すぎる区間では閉所恐怖や息苦しさまで感じたし、岩と砂地の洞窟、岩のある洞窟は本当に美しくて、このレンダラーで作ったMystやLucasArts風のアドベンチャーゲームを遊んでみたくなった。
洞窟探検や考古学発掘のような題材に合いそう。
落下砂エンジンを3Dに拡張するなら、スムーズ粒子流体力学のような手法も使えそう。
低い天井の部分では、屋根からぶら下がったブロックが物理法則に逆らっているように見えた。
https://web.archive.org/web/20240524065427/https://blog.dani...
https://www.youtube.com/watch?v=1xFEbXWstCM
別のアプローチとしてDeep Bumpがある。同じ問題をまったく別のやり方で扱っている。
Deep Bumpはテクスチャ画像からもっともらしい法線マップを生成する機械学習ツールだ。
このボクセル変位レンダラーが使う石やレンガのテクスチャには特によく合うし、布のテクスチャでもしわ・ポケット・襟をある程度認識して、深さを表現する法線を与えてくれる。
樹皮にはそこそこ、植物にはあまり向いていないが、おそらく学習データセットの影響だろう。
Doom/Wolfenstein系ゲームを現代化するなら、使えそうなオープンソースツールはすでにある。
[1] https://github.com/HugoTini/DeepBump
この記事は変位マップを小さなボクセルベース表現として扱う方向に近く、Deep Bumpのようなツールは、ここで述べられているシステム向けのテクスチャ資産を作る際に補助的に使えるかもしれない。
実際のジオメトリを変えるのではなく、ライティングと立体感の錯覚だけを変えるので、メッシュの縁から見るとやはり変位のほうが高品質な選択肢になる。
ただDeepBumpは、従来の変位に使う1次元の高さマップ、つまり完全な3Dベクトル変位ではなく高さだけのマップを抽出する用途には使えるかもしれない。
かっこいいが、このアプローチがアニメーションする3Dモデルにどれくらい合うのか気になる。
うまくいってもDoomの「Voxel Doom」モードのような見た目になりそう。
[1] https://media.moddb.com/cache/images/mods/1/55/54112/thumb_6...
[2] https://media.moddb.com/cache/images/mods/1/55/54112/thumb_6...
「ここまででこの文脈を一通り説明できたので、クラシックDoom向けのVoxel Doomモッドに賛辞を送りたい。モッド作者はゲーム中のモンスターやその他のスプライトをボクセルメッシュに置き換えて奥行きを加えており、本当に印象的な仕事だった。その後、2022年末にはレベルジオメトリにボクセルのディテールを加えるため、視差マッピングの実験も始めた。私にはこの部分はあまり良く見えなかったが、それは作者のアートワークのせいではなく、視差マッピングでレンダリングする際に生じる根本的な限界によるものだった。このモッドが私のプロジェクトの着想元だったわけではない。私はすでに作業中だった。しかし、そのモッドがオンラインで好意的に受け止められているのを見て、自分の作業を続ける大きな後押しになった。↩」
アプローチ自体はアニメーションするドアのようなものもサポートするとあるので、メッシュとテクスチャのフリップブックを組み合わせれば、元のDoomのような見た目のモンスターにも使えるかもしれない。
ただ、鋭い曲率の領域ではシェルマッピングのアーティファクトが最もひどくなりそうだし、レベルのメッシュ化の限界にも触れているので、難しいかもしれない。
Notchが取り組んでいるものとかなり似て見える。彼のTwitterフィードを見ると、別種のボクセルレンダリングをやっている。
ただ、こちらはC++/Vulkanを使っていて、本当に見事だ。
このアプローチがUnreal Engine 5 Naniteとどう比較されるのか気になる。もしかするとUnreal Engineも似たようなことをしているのかもしれない。
昔のゲーム、たとえばComanche[1]のような作品でボクセルが使われた動機の1つは、三角形メッシュでモデリングすると同等のハードウェアではもっと高コストになっていたであろう複雑な地形を、それらしく表現できたからだったと記憶している。
筆者はRX 5700 XTで110FPSに言及しているが、ほかのアプローチと比べてどの程度なのかはよく分からない。
[1] https://en.wikipedia.org/wiki/Comanche_(video_game_series)
Naniteは高ポリゴンオブジェクトの制作を前提にしており、レンダリングされる三角形がピクセルより小さくならないよう、簡略化されたチャンクをストリーミングする。
ジオメトリを自然に非常に細かくできるので、変位マップはやや冗長で、わざわざテクスチャマップとして扱う理由がない。
もちろん地形については別の事情があるが、それは特殊なケースだ。
この記事の方式は、変位と低ポリゴンメッシュを使って、ロード時に高ポリゴンだが「ボクセル化された」ジオメトリを生成するものに見える。
記憶では、Comancheは地形レンダリングにレイトレーシング的なアプローチを使っていた[1]
本当のボクセルではなく、サンプリングされる2Dハイトマップだった
名前を「VoxelSpace」と呼んでいたので、混同しても無理はない
[1] https://github.com/s-macke/VoxelSpace
一般的な思い込みとは異なり、あのゲーム群は本当の3Dボクセルを使っておらず、地形テクスチャに色と高さの値を保存したハイトマップをレイマーチングで描画していた
シェーダーでテクスチャに向けてレイマーチングすれば同じ見た目を再現でき、ブログ記事で得られた結果と非常によく似たものになるはずだ
一方でNaniteは、目標品質に合わせて三角形密度を調整するGPU主導のレンダリング技術だ
Naniteも変位マップとテッセレーションを使うことはできるが、高ポリゴン資産をそのまま投入してレンダリングするより必ずしも効率的ではない別経路を使っている
ボクセル分野の新しい手法を見るのはいつでも良い
ただ、記事がボクセルと特定のレンダリング技法を混同して語っているのは少し残念だ
ボクセルは単に3Dグリッドを使うということで、中ほどを見ると著者はボクセルの使用をキューブ式レンダリング、一般にはMinecraft風のブロクセルレンダラーと呼ばれるものと同一視しているように見える
三角形ジオメトリを持ち込んでエンジンで直接使えるとも述べているが、ブロクセルでも事実上どのようなレンダリングパイプラインでも同じことができる点を見落としているようだ
別のスタイルを使う一般的なボクセルレンダリングプラグインが既存エンジンでファーストクラスのサポートを受ける仕組みも、まさにこれと同じだ
これがオープンソースだったらいいのに。本当にそうあってほしい
本当に気に入った。Ultima Underworldを思い出す
これこそレトロ3Dゲーム現代化の未来であるべきだ。本当に美しい