Nintendo 64でパレット照明トリックを使う方法
(30fps.net)- この記事は Nintendo 64デモ開発過程 で適用した、パレットベースのライティングおよびノーマルマッピング技術を説明する
- テクスチャ自体に即座にライティングを反映 する代わりに、パレットだけを変更してテクスチャ全体に照明効果を与える方法を紹介する
- diffuse/normalパレット圧縮 やオブジェクト空間ノーマルマッピングなど、さまざまな最適化手法を活用する
- この方式は 方向性ライティング に限って効率的であり、シェーディングの不連続性 などの欠点がある
- デモでは 反射光/直接光/環境光 など複数の要素が創造的に組み合わされ、N64の限界の中で印象的なビジュアルを見せる
紹介と目標
- この記事はBlueskyで始まった スレッド の延長として、Nintendo 64向けデモ（Revision 2025）で活用した高度なライティング手法を共有する
- デモには反射光付きノーマルマッピング、リアルタイム反射ライティングなど多様な効果が含まれ、音楽はnobyが作曲し、Molokoがギターを演奏した
Nintendo 64でのノーマルマッピングの可能性
- WadeTyhonやSpooky Iluhaといったホームブリュー開発者たちの実験を参考に、N64で ノーマルマッピング を実装できる可能性を検証した
- 基本的な方式は、実行時にCPUでテクスチャへ直接ライティングを計算 することだ
- ハードウェア支援なしでもCPUでシェーディング用のカスタムコードを実行できるが、速度低下の問題が大きい
パレットベースのシェーディング
- テクスチャ空間シェーディングを直接適用する代わりに、パレットテクスチャ のパレットデータだけを更新すれば、テクスチャ全体がリアルタイムで明るさの変化を反映する
- N64ではパレットテクスチャの使用が一般的なので、広く活用できる
- パレットだけを更新しても、各テクセルごとに実際のライティングを適用したかのような効果が即座に現れる
- 元のパレットをシェーディング適用済みパレットに置き換え、既存のパレットテクスチャをオブジェクトに通常のテクスチャとしてマッピングする
- ディフューズ（dot(N,L)）ライティングだけを適用しても、かなり優れた結果が得られる
オブジェクト空間ノーマルマッピング
- 一般にノーマルマッピングはタンジェント空間で行われ、繰り返しテクスチャへの対応や自然な表面補正に適している
- オブジェクト空間ノーマルマップは各テクセルが 正確な表面ノーマル 情報を持つため計算は単純だが、繰り返しテクスチャの活用が難しい
- 高解像度ノーマルマップを32色パレットに圧縮しても、元の特性に近い性質を維持できる
ディフューズとノーマルで共有するパレット設計
- オブジェクトはディフューズテクスチャ（basecolor * ao）とノーマルマップを持つ
- 両方のテクスチャが K-meansクラスタリングアルゴリズム によって生成された同一のパレットインデックスを共有するよう構成する
- 画像を6チャンネル画像と見なしてクラスタリングを行う
- 例ではRGBディフューズ + ノーマルマップを16色パレットに圧縮し、画像データには4bppだけを記録すればよい
- シェーディング時には、各パレット色についてノーマルと表面色の情報をインデックスで参照し、新しいRGB色を生成する
- この方式は方向光しか適切にサポートできず、パレットだけでシャドウを実装するのは難しい
ベイクされた方向性環境光/太陽光
-
建物の 現実的なライティング を実現するため、頂点カラーのRGBとアルファチャンネルをそれぞれ環境光と太陽光に使用する
-
環境光（ambient）は 方向性の強度（グレースケール環境マップ） と色（RGB、彩度を強化）に分離する
-
太陽光（direct）は頂点アルファで渡す
-
基本的なライティング式は以下の通り
ambient = vertex_rgb * grey_irradiance_map(N) direct = vertex_alpha * sun_color * dot(N, sun_dir) color = diffuse_texture * (ambient + direct) -
各項が組み合わさって最終的な色を作る
-
方向性環境光は豊かな自然光効果を生み、パレットベースでありながら高品質な質感を演出する
-
環境マップは簡略化のため、正距円筒図法（equirectangular projection）を利用する
繰り返しテクスチャを使う大型モデルのシェーディング
- 初期アルゴリズムは単一オブジェクト向けであり、大型のキャッスルメッシュでは繰り返しテクスチャの使用により問題が生じた
- 解決のためにBlenderを使い、各表面方向/材質ごとにメッシュをサブメッシュ単位へ分割した
- コンピュータは各グループに対し、ポリゴンノーマルを用いて world-to-model 行列を算出する（近似タンジェント空間）
- 各グループは1つのパレットを共有し、全体としては平均的なライティング品質が保証される
- タンジェント空間が実行時に補間されないため、面が削られたようなファセット状のライティング が現れる欠点がある
スペキュラー（反射光）シェーディング
- 複数の表面上の点が同じパレット色を共有するため、正確なポイントライト/反射光シェーディングは不可能である
- パレット空間の手法は 方向性ディフューズライティング に限って効率的だ
- それでも球状の物体を仮定し、各点を
p = radius * normalとして近似することで、スペキュラー反射光効果を無理やり実装した - 結果はやや不連続だが、プレイ中には実際かなり自然に感じられることがある
限界と今後
-
デモでは シェーディングの不連続性、白黒テクスチャのみ対応、ポイントライト非対応 といった限界を最大限に隠した
-
elaborate preprocessing（複雑な前処理）が必須である
-
シェーディングの不連続性なしに ambient/direct の両方の照明をサポートする方法は、依然として課題である
-
実験結果について、新たな可能性とアイデアの面白さを強調している
-
PAL互換N64 ROM ファイルも公開されている。ただし不安定で、頻繁にクラッシュする
その他
- 著者は書籍の執筆も検討しており、興味があれば こちら で知らせを受け取れる
1件のコメント
Hacker News のコメント
N64で「リアリスティック」なグラフィックを見るのは本当に印象的な体験だという感想とともに、このデモがPS2の「ICO」を思い出させる雰囲気だと述べている。N64グラフィックハードウェアを抽象化し、現代的なプリミティブ、ライティング、シェーディング、ベイクドライティングツールなどを提供するSDKを作れるのか気になるという話。N64ハードウェアはその世代特有の独特な構造を持っていたとも触れ、詳細なハードウェア情報へのリンクも共有している
N64がSGIによって設計されたこと、そしてSGIが3Dグラフィックスにどれほど大きな影響を与えたかに言及。むしろN64はその世代で最も標準的なハードウェアを持っていたのではないかと推測している。OpenGLライブラリがなかったとしたら、かえって驚くほどだという見方。欠点としては、このコンソールをCPUを付け足したグラフィックカードのように考える必要があり、グラフィックシステムがかなり直接的に露出している点を挙げている。グラフィックチップのアーキテクチャは互換性がなく、各社はこうした内部構造の公開を避け、API（OpenGL、DirectXなど）だけを提供することで創造的な設計を可能にしつつも、ハードウェアへの直接アクセスは非常に難しくしていると説明。補足として、OpenGLはSGIに由来し、nvidiaもSGI出身者が創業したという背景知識も紹介している
「Shadow of the Colossus...」に触れつつ、関連するYouTubeリンクを共有
N64のグラフィックトリックを扱う本文が「これが未来なのか？」という問いで終わっているのが気に入った、という感嘆
ゲームエンジニアたちが限られたハードウェアで創造的な解決策を生み出した、その天才性に感嘆する気持ち
制約があるときこそ最高レベルの創造性が発揮される、という原則を共有。pico8、Animal Well、いくつもの印象的なゲームの秘密はまさにそこにあるという。今週末、自分が作っている2d-pixel-art-game-maker-makerのアーキテクチャを大きく改善するアイデアを思いついてしまい、またリリースが1か月延期しそうだと惜しんでいる
今回紹介されているものは、N64全盛期当時の話ではなく、最近作られた新作だという説明
これは当時のN64開発者によるものではなく、2025年時点のデモシーンに関する新技術だと明記しておく案内
今はもっと高速なシステムがあるのでありがたいが、昔のゲームで限界を乗り越える楽しさと、それを本当にやり切ったときの満足感は特別だったという回想。Hacker Newsの読者なら「ラスタ割り込み（raster interrupts）」や「racing the beam」という概念に馴染みがあるだろうと述べ、Atari 800でそうした技術によって本来不可能だったことを可能にした逸話を紹介している。ごく最近になって、Atari 2600のゲームがこうした狂気じみた手法に大きく影響されていたと知ったとも述べ、YouTube資料も共有。仮に今後ハードウェアの進歩が止まったとしても、私たちは今後何十年にもわたって新しく面白いトリックを発見し続けられるはずだ、という確信で締めている
90年代にパレットベースのライティング技法を自分たちのシェアウェアゲームで使っていた経験の回想。VGAの256色パレットを、それぞれの色ごとに段階的な明暗変化を持つよう並べておき、色インデックスを足し引きするだけで簡単に明るさ表現ができたと説明している
デモシーンやこの種の作業は驚嘆に値するが、主に単純で空虚なシーンに偏りがちだと感じる、という観察。こうした手法はたいてい背景や限定的なゲーム機能に使われるものだという分析。FastDoomやMario-64最適化プロジェクトのように、古いハードウェア上で性能を大幅に引き上げ、しかもコンテンツや機能まで追加する試みのほうがずっと印象的だという見解。デモシーンと、こうしたより完成度の高いプロジェクトのあいだに何らかのつながりがあるのかもしれない、という考え
PS1やPS2時代の最適化技術が懐かしいという気持ち。大半はエミュレーションで1080pや4k以上にアップスケールしてもなお見栄えがいいという感想。Halo 2の4kグラフィックで十分だと感じるという意見や、GT3で実際に実現された「熱気」エフェクトのデモを例に挙げ、PS3ではPS2ほど速く実装できないという制作者コメントも引用している。今どきのUE5エンジンのような写実的な熱気ではなく、性能負荷の少ないトリック方式のほうがむしろ良いという考え。RTXの使用でフレームレート低下を味わうくらいなら、昔ながらのトリックのほうがましだと述べている。299MHzのMIPS CPUでShadow of the Colossus、GoW2、FFXII、GT4、Black、Valkyrie Profile 2、Rouge Galaxy、Burnout 3、Jak and Daxter、Ratchetなど驚くべきゲームが動いていた事実や、GameCubeのRE4、Metroid、Zeldaなどにも触れている。昔ながらのゲーム開発者たちの腕前への感嘆と敬意で締めくくられている
GoW2の映像はPCSX2エミュレータでキャプチャされたもので、アップスケールやそのほかの強化が入っていたはずだと指摘。それでもPS2上のGoW2は途方もない達成だったと思うとしている
PS2については同意するが、PS1については性能がそれほどでもなかったという見方。PSXの性能はPentium 90〜100相当だが、MMX Pentiumに3DFXを載せればN64並みかそれ以上だったという意見。低クロックでも高い性能を出すMIPS CPUの例として、PSP、SGI Irix、PS2を挙げている。PS2のGPUはR4k CPUとは別物だという説明に加え、PS2版Deus Ex移植はPC版に比べて見劣りし、Unreal Engineを完全には扱いきれていなかったという実体験も共有。PS2は驚異的な特殊効果を見せた一方で、Deus Exのような移植作品ではマップサイズが非常に小さかったという背景知識も補足している
Halo 3のグラフィックのほうが最新ゲームより良く見えるという持論。ブラー、ブルーム、草や木の葉が跳ね飛ぶような効果など、最近追加された要素はむしろ良くない視覚体験をもたらしているという考え。高速なFPSジャンルでは細かなポリゴン数に大した意味はなく、テクスチャ解像度も十分であればそれでいいと感じるという。実際に体感するのはハードウェア要求の重さだけだ、という自身の経験を共有している