- Revision 2025向けのNintendo 64デモは、テクスチャ全体を再計算せず パレットだけを更新 することで、ノーマルマッピング、ベイクド照明、リアルタイムスペキュラーに近い効果を実現
- CPUが各パレットインデックスから ノーマルと拡散色 を読み取り、新しいRGBパレットを作ることで、パレットテクスチャがテクセルごとに照明を受けたかのように反応
- 拡散テクスチャとノーマルマップは同じパレットインデックスを共有し、scikit-learnの K-means clustering により6チャンネル画像のようにまとめて生成される
- 建物の照明は、頂点RGBのアンビエント色、頂点アルファの太陽可視性、グレースケールの irradiance map、方向性太陽光の
dot(N, sun_dir) を組み合わせている
- 方向性拡散光には効果的だが、影、ポイントライト、正確なスペキュラー、繰り返しテクスチャのある大きなモデルでは制約が大きく、前処理で限界を隠す必要がある
パレットだけを更新してシェーディングする
- Nintendo 64デモは Revision 2025 向けに制作され、ベイクド照明、ノーマルマッピング、リアルタイムスペキュラーシェーディングに近い効果を使っている
- N64でのノーマルマッピングは既存のホームブリュー実験で可能性が知られており、このデモではランタイムにテクスチャではなく 照明結果のパレット を計算する方式を選んだ
- 専用のハードウェア支援なしでもCPU上で任意のシェーディングコードを実行できるが、計算速度は遅い
- パレットテクスチャでは、テクセル全体ではなく パレットだけを変えても テクスチャ全体が照明計算を受けたように見える
- 元のパレットはシェーディング済みパレットに置き換えられる
- パレットテクスチャは通常のテクスチャのようにオブジェクトへ適用される
- 単純な拡散光
dot(N,L) だけでも結果はかなり良く見える
- 初期の例では色情報テクスチャのガンマ補正を戻して 線形空間 でシェーディングしていたが、最終デモではアンビエント項と直接光項を分離し、N64のRDPユニットでハードウェア合成する必要があったため適用できなかった
オブジェクト空間ノーマルマッピング
- 一般的なノーマルマッピングは タンジェント空間 で行われる
- 繰り返しテクスチャを使える
- ディテールノーマルで滑らかに変化する頂点ノーマルを補正できる
- 単色のタンジェント空間ノーマルマップは滑らかな表面を表す
- オブジェクト空間ノーマル は計算が単純な代わりに制約が大きい
- ノーマルマップのテクセルは頂点ノーマルからの偏差ではなく、絶対的な表面ノーマルを表す
- ランタイム計算はテクスチャから色を読む程度まで単純化される
- すべての表面点にライトマップのような固有のテクセルが必要になる
拡散テクスチャとノーマルマップが共有するパレット
- オブジェクトは拡散テクスチャ
basecolor * ao とノーマルマップの両方を持つ
- 2つのテクスチャは同じ パレットインデックス を共有し、このインデックスは scikit-learn の K-means clustering で生成される
- 画像群は1つの 6チャンネル画像 のように解釈される
- 1つのインデックスでノーマルと表面の拡散色の両方を取得できる
- ロード時または毎フレームごとにパレット色を走査する
- CPUシェーダーコードが各インデックスに対して新しいRGB色を作る
- ループの結果が照明適用済みの新しいパレットになる
- このアプローチは実際には 方向性照明 に最も適している
- パレットだけでは影のような効果を表現しにくいため、ベイクド照明と組み合わせる必要がある
ベイクド方向性アンビエントと太陽光
- デモの建物には、より現実的な照明を入れるため、アンビエントと直接の太陽光を頂点カラーに分離して保存している
- 頂点RGB: アンビエント色
- 頂点アルファ: 太陽可視性
- アンビエント項は方向性の強度と色に分かれる
- 方向性の強度はグレースケールの irradiance map
- 色は彩度を高めた頂点RGB
- 太陽は方向性ライトであり、可視性は頂点アルファで渡される
- シェーディング式は次の通り
ambient = vertex_rgb * grey_irradiance_map(N)
direct = vertex_alpha * sun_color * dot(N, sun_dir)
color = diffuse_texture * (ambient + direct)
- 粗い太陽可視性の頂点カラーは
N.L 計算でマスクされ、最終的な直接光の結果では整理されて反映される
- 方向性アンビエントは、ベイクド照明が粗くてもテクスチャディテールのおかげで高品質に見せられる
- ぼやけた環境マップには、単純さから equirectangular projection を使用している
- Polyhaven HDRI はすでにこの投影を使っている
- シェーディングはロード時に事前計算していたため、複雑なサンプリング数学は問題にならなかった
繰り返しテクスチャのある大きなモデルの処理
- 元のシェーディングアルゴリズムは単一オブジェクト向けに設計され、初期は
potato_rock.obj だけでテストされていた
- デモの城郭メッシュには 繰り返しテクスチャ があり、問題が生じた
- 回避策は、大きなメッシュを複数のサブメッシュに分割し、各サブメッシュが概念的に同じオブジェクト空間ノーマルマップを共有するようにする方法だった
- Blenderで材質と表面方向を基準にジオメトリを手動でグループ化した
- 各グループのポリゴンノーマルに基づいて world-to-model 行列を計算した
- この行列はおおよそタンジェント空間に近い
- 各グループはパレットを共有するため、全体の照明は平均的な意味でしか正しくならない
- タンジェント空間はランタイムで補間されないため、面単位の照明 のように見え、これがこの手法の最大の欠点の1つになっている
スペキュラーシェーディングの近似
- 複数の表面点が同じシェーディング色を共有するため、ポイントライトやスペキュラーシェーディングを正確に計算するのは難しい
- パレット空間アプローチは、
to camera ベクトル V を必要としない 拡散方向性照明 に向いている
- スペキュラー効果は、オブジェクトを球として近似する方法で試みられている
- シェーディングする点
p を p = radius * normal と置く
- 多くの表面点が同じパレットインデックスを共有するため、結果はどうしても角張って見える
- デモのスペキュラーハイライトはやや不自然に見えたが、大半の人をごまかせる程度には機能した
限界と関連資料
- デモでは主な限界を前処理とシーン構成で隠そうとしている
-
照明の不連続性と表現範囲
- グレースケールテクスチャしか対応しない
- ポイントライトはない
- この手法は精密な前処理がある場合にのみ実用的
- Spooky Iluha の手法には照明の不連続性の問題がないが、アンビエントと直接光の両方を維持しつつ同じ問題を解決できるかは不明
-
ROMと先行研究
1件のコメント
Hacker News のコメント
N64でリアルなグラフィックを見るのは本当に印象的で、このデモはPS2の「ICO」を思い出させる
以前から、N64のグラフィックスハードウェアを抽象化して、現代的な基本図形、ライティング、シェーディング、このデモのようにライティングを事前に焼き込むツールなどを提供するSDKを作れるのか気になっていた
N64は同世代の中ではかなり独特なハードウェアを持っていて、詳しい内容はCopetti.orgにある: https://www.copetti.org/writings/consoles/nintendo-64/
OpenGLライブラリがなかったとしたら、むしろ少し驚く
ただし大きな但し書きがあって、1) このシステムはCPU付きのグラフィックスカードのように見るべきで、2) グラフィックスシステムが直接露出している
グラフィックスチップの構造は結局、汚く相互互換性のない混沌になりがちなので、アクセラレーターメーカーは通常、リファレンス文書を公開するよりも、OpenGL、DirectX、CUDA、Vulkanのような中間APIを公開することを好む
そうすれば内部実装を互換性のない構造のまま保ち続けられる。リファレンス文書を公開しなければ、ハードウェアの後方互換性を守る必要もなく、利点は新しい設計を作れることだが、欠点は誰も直接使いにくいことだ
だから、その世代のコンソールのように直接アクセス権が得られると、本能的にぎょっとしてしまう
付け加えると、OpenGLはSGIから生まれ、Nvidiaも元SGIエンジニアたちが創業した
N64のグラフィックストリックを扱った記事が最後に「Is this the future?」という問いで終わるのが気に入っている
人気作十数本が読めるソースファイルにデコンパイルされており[1]、エミュレーターなしでPC移植しやすくなり、実機で動く数多くのMODも可能になった
Zeldaのファンリメイクも複数あり[2]、新しいダンジョンやストーリーを備えた完成度の高いゲームもある
Mario 64界隈は特に熱く、Kazeはゲームを徹底的に最適化し[3]、自分のエンジンや続編も作っている。レトロ技術の深掘りが好きなら、彼のチャンネルは本当に宝の山だ
Portalのようなとんでもないデモも登場し[4]、残念ながらValveの法務チームの関心を引いてしまった
RareのDinosaur Planetのような失われたゲームも、流出後にほぼリリース可能な状態まで磨き上げられ、デコンパイルされ、独自のインディー再興を迎えている[5]
[1] https://wiki.deco.mp/index.php/N64
[2] https://m.youtube.com/watch?v=bZl8xKDUryI
[3] https://m.youtube.com/channel/UCuvSqzfO_LV_QzHdmEj84SQ
チャンネル全体が素晴らしく、こうした深掘りも何十本もある: https://m.youtube.com/watch?v=DdXLpoNLywg
彼のゲームとエンジンも美しい: https://youtu.be/Drame-4ufso
[4] https://m.youtube.com/watch?v=yXzoZ2AfWwg
[5] https://m.youtube.com/watch?v=s0QSiPRmWaI
こうしたゲームエンジニアたちがどれほど天才的だったのかを見るたびに驚かされる
途方もない制約の中で、想像力に富んだ優れた解法を生み出していた
pico8、Animal Well、そして数多くの驚くべきゲームの秘密がまさにそれだ
この週末に、自分の2Dピクセルアートゲーム制作ツール制作記のための、はるかに良い構造を思いつかなければよかったのに。これでリリースまでまた1か月は余計にかかりそうだ :(
今はより高速なシステムがあるのは本当にありがたいが、昔のゲームには制約を回避しなければならない面白さがあり、うまくやり遂げたときの満足感は本当に大きかった
HN読者ならラスタ割り込み（https://en.wikipedia.org/wiki/Raster_interrupt）とビームレーシングにはなじみがあるだろう。個人的にはAtari 800と結びつけて考えてきた
本来ならhttps://youtu.be/GuHqw_3A-vo?t=33のようなことはできないはずだったが、Display List Interruptsのおかげで可能だった
最近まで知らなかったのは、Atari 2600のゲームがこうした狂気にどれほど大きく依存していたかだ: https://www.youtube.com/watch?v=sJFnWZH5FXc
こういうものを見ると、ハードウェアの進歩が止まったとしても、何十年もの間ずっと、さらに面白いものを見つけ続けられるのではないかと思う
デモシーンやこうした取り組みは印象的だが、全体としては、より単純で空っぽなシーンに流れがちなように見える
ゲームの背景やゲームメカニクスの一部として入るようなものに近い。大半の手法では、完全な体験を作るほどのリソースは十分ではないように感じる
より印象的なのは、FastDoom や複数の Mario 64 最適化プロジェクトのように、古いハードウェアからはるかに良い性能を絞り出す取り組みだ
ときにはコンテンツや機能を追加しながらそれをやっている。デモシーン開発者たちと、こうしたより包括的な取り組みとの間に接点があるのかも気になる
90年代のシェアウェアゲームでは、似たような パレットベースのライティング 手法が使われていた
基本的には、VGA 256色パレットを構成するときに、対応する各色について、その色の N 段階の明るさグラデーションを入れておく方式だ
そうすれば、カラーインデックスを足したり引いたりするだけで、各色の明るさを簡単に変えられた
PS1 と PS2 時代の 最適化 が懐かしい
ほとんどはエミュレーションで 1080p や 4K 以上に上げて見ると本当に格好いい。個人的には Halo 2 時代のグラフィックを 4K で見るくらいで十分だと思う
もちろん Halo 2 は Xbox のゲームだが、Halo MCC で Halo 2 をクラシックグラフィックで遊ぶと、今でも驚くほどよく見える
GT3 の陽炎エフェクトがそれをよく要約している
"GT3 のデモでシアトルのコースを夕暮れ時に見せていたが、地面から熱が立ち上って揺らめく場面があった。PS3 ではその陽炎エフェクトを再現できない。read-modify-write が PS2 を使っていた頃ほど速くないからだ。そういうものがある。"
https://old.reddit.com/r/ps2/comments/1cktw88/gran_turismos_...
https://youtu.be/ybi9SdroCTA?t=4103
UE5 のような新しいエンジンみたいに実際の熱波をエミュレートしようとするのではなく、フレームレートを壊滅させないように トリック で処理していたのだ。正直、RTX がフレームレートを大きく削るのを見ると、こういう安価なトリックのほうがいい
299MHz の MIPS がこれを動かしている
Shadow of the Colossus: https://www.youtube.com/watch?v=xMKtYM8AzC8
GoW2: https://youtu.be/IpKLwIIdvuk?si=TjifKmlYsUuvhk0F&t=970
FFXII: https://youtu.be/NytHoYOs_4M?si=jE1Fxy40khEvV6Bn&t=51
GT4: https://www.youtube.com/watch?v=F6lZIxk_h9g（ブート画面を見てぐっと来る）
Black、Renderware は狂ったエンジンだった: https://youtu.be/bZBjcwyq7fQ?si=Pev5ifpksJm4X6Oi&t=356
Valkyrie Profile 2: https://youtu.be/9ScjO4NuUtA?si=Z29cR-hLsT2pnP2I&t=38
Rouge Galaxy: https://youtu.be/iR1evzyl-7Q?si=fldm3-NnuFxOITMn&t=624
Burnout 3: https://www.youtube.com/watch?v=_r5r0nE1sA4
Jak and Daxter、Ratchet もある
GC 側は RE4、Metroid、Zelda たちなど、当然ながらものすごく良く見える
ひれ伏すしかない
Pentium 90、ほぼ 100 くらいとは張り合えただろうが、3DFX を載せた MMX Pentium なら PSX を圧倒し、N64 と同等かそれ以上だったはずだ
MIPS CPU は優秀で、低クロックでも驚くようなことをやってのける。PSP や SGI Irix を見てもそうだ
それに PS2 の「GPU」は R4k CPU と同じものではない
ついでに言うと、PS2 の Deus Ex 移植版は PC 版に比べてひどく、Unreal エンジンを完全には扱いきれていなかった
PS2 がとんでもないエフェクトを出していたのは確かだが、その移植版ではレベルが本当に小さかった。Deus Ex は、ゲームの大きな部分がほぼオープンワールドに近かったことも考慮する必要がある
ブラー、ブルーム、草や植生のポップインのようなものは実際には見栄えが良くなく、単に全部オフにするより悪く見える
高速な一人称シューティングでは高ポリゴンモデルを鑑賞する暇もないのに、それに何の意味があるのかも分からない
私の目には Halo 3 のテクスチャ解像度で十分だ。テクスチャサイズが 2倍や4倍になっても気づかないだろうし、目立つのはハードウェア要件だけだ
GoW2 の動画は PCSX2 でキャプチャされたもので、そのクリップではアップスケーリングや他の便利機能の恩恵を受けていた可能性が高い
残りの動画は全部見ていないが、いずれにせよ GoW2 が PS2 で成し遂げたことは大したものだった