Verwendung von Palette-Beleuchtungstricks auf dem Nintendo 64

 (30fps.net)
2 Punkte von GN⁺ 2025-05-19 | 1 Kommentare | Auf WhatsApp teilen
  • Dieser Artikel erklärt palettenbasierte Beleuchtungs- und Normal-Mapping-Techniken, die im Entwicklungsprozess einer Nintendo-64-Demo eingesetzt wurden
  • Statt Beleuchtung direkt und sofort in die Textur einzurechnen, wird eine Methode vorgestellt, bei der nur die Palette verändert wird, um der gesamten Textur einen Beleuchtungseffekt zu geben
  • Dabei kommen verschiedene Optimierungstechniken zum Einsatz, darunter Diffuse-/Normal-Palettenkompression und Object-Space-Normal-Mapping
  • Dieser Ansatz ist nur für gerichtete Beleuchtung effizient und hat Nachteile wie Shading-Diskontinuitäten
  • In der Demo werden Reflexionslicht/direktes Licht/Umgebungslicht kreativ kombiniert, um innerhalb der N64-Grenzen beeindruckende Visuals zu erzeugen

Einführung und Zielsetzung

  • Dieser Artikel ist eine Fortsetzung des auf Bluesky gestarteten Threads und teilt fortgeschrittene Beleuchtungstechniken, die in einer Demo für den Nintendo 64 (Revision 2025) verwendet wurden
  • Die Demo enthält verschiedene Effekte wie Normal Mapping mit Reflexionslicht und Echtzeit-Reflexionsbeleuchtung; die Musik wurde von noby komponiert, Moloko spielte Gitarre

Möglichkeiten von Normal Mapping auf dem Nintendo 64

  • Unter Bezug auf Experimente von Homebrew-Entwicklern wie WadeTyhon und Spooky Iluha wurde geprüft, ob sich Normal Mapping auf dem N64 umsetzen lässt
  • Der grundlegende Ansatz besteht darin, zur Laufzeit auf der CPU die Beleuchtung direkt in die Textur zu berechnen
  • Auch ohne Hardware-Unterstützung kann auf der CPU benutzerdefinierter Shading-Code ausgeführt werden, allerdings mit erheblichen Geschwindigkeitseinbußen

Palettenbasiertes Shading

  • Statt Texture-Space-Shading direkt anzuwenden, wird nur die Palettendaten einer Palettentextur aktualisiert, sodass die gesamte Textur Helligkeitsänderungen in Echtzeit widerspiegelt
  • Da der N64 häufig Palettentexturen verwendet, lässt sich dies oft nutzen
  • Schon durch das Aktualisieren der Palette erscheint sofort der Effekt, als wäre auf jedes Texel echte Beleuchtung angewendet worden
  • Die ursprüngliche Palette wird durch eine geschattete Palette ersetzt, und die bestehende Palettentextur wird als normale Textur auf das Objekt gemappt
  • Schon die Anwendung von reinem Diffuse-(dot(N,L)) Lighting liefert bemerkenswert gute Ergebnisse

Object-Space-Normal-Mapping

  • Normal Mapping wird üblicherweise im Tangent Space durchgeführt und eignet sich gut für wiederholte Texturen und natürliche Oberflächenkorrekturen
  • Bei Object-Space-Normal-Maps enthält jedes Texel exakte Oberflächennormalen, was die Berechnung vereinfacht, aber die Nutzung wiederholter Texturen erschwert
  • Selbst wenn eine hochauflösende Normal Map auf eine 32-Farben-Palette komprimiert wird, können ähnliche Eigenschaften wie beim Original erhalten bleiben

Entwurf einer gemeinsamen Palette für Diffuse und Normalen

  • Ein Objekt besitzt eine Diffuse-Textur (basecolor * ao) und eine Normal Map
  • Beide Texturen sind so aufgebaut, dass sie dieselben Palette-Indizes teilen, die mit dem K-means-Clustering-Algorithmus erzeugt wurden
  • Dabei wird das Bild als 6-Kanal-Bild betrachtet und entsprechend geclustert
  • Im Beispiel werden RGB-Diffuse + Normal Map auf eine 16-Farben-Palette komprimiert, sodass in den Bilddaten nur 4bpp gespeichert werden müssen
  • Beim Shading werden für jede Palettenfarbe Normalen- und Oberflächenfarbinformationen über den Index nachgeschlagen und daraus neue RGB-Farben erzeugt
  • Dieser Ansatz unterstützt praktisch nur gerichtetes Licht korrekt, und Schatten allein über die Palette zu realisieren ist schwierig

Gebackenes gerichtetes Umgebungslicht/Sonnenlicht

  • Um realistische Beleuchtung für Gebäude zu erreichen, werden RGB und Alphakanal der Vertex-Farben jeweils für Umgebungslicht und Sonnenlicht verwendet

  • Das Umgebungslicht (ambient) wird in Richtungsintensität (Graustufen-Environment-Map) und Farbe (RGB, mit verstärkter Sättigung) aufgeteilt

  • Das Sonnenlicht (direct) wird im Vertex-Alpha übergeben

  • Die grundlegende Beleuchtungsformel lautet wie folgt

    ambient = vertex_rgb      * grey_irradiance_map(N) 
direct  = vertex_alpha    * sun_color * dot(N, sun_dir)
color   = diffuse_texture * (ambient + direct)

  • Die einzelnen Terme werden kombiniert und ergeben die endgültige Farbe

  • Gerichtetes Umgebungslicht erzeugt einen kräftigen natürlichen Lichteffekt und sorgt trotz des Palettenansatzes für hochwertig wirkende Texturen

  • Zur Vereinfachung verwendet die Environment-Map eine equirectangular projection

Shading großer Modelle mit wiederholten Texturen

  • Der ursprüngliche Algorithmus ist für ein einzelnes Objekt gedacht, bei großen Schloss-Meshes traten durch wiederholte Texturen jedoch Probleme auf
  • Als Lösung wurde Blender verwendet, um das Mesh je nach Flächenausrichtung und Material in Submeshes aufzuteilen
  • Der Computer berechnet für jede Gruppe mithilfe der Polygonnormalen eine World-to-Model-Matrix (ein angenäherter Tangent Space)
  • Jede Gruppe teilt sich eine Palette, wodurch insgesamt eine durchschnittlich gute Beleuchtungsqualität sichergestellt wird
  • Da der Tangent Space zur Laufzeit nicht interpoliert wird, entsteht als Nachteil ein facettiert wirkendes Lighting

Specular-Shading

  • Da mehrere Oberflächenpunkte dieselbe Palettenfarbe teilen, ist präzises Shading mit Point Lights oder Specular Highlights nicht möglich
  • Die Technik im Palettenraum ist nur für gerichtetes Diffuse-Lighting effizient
  • Dennoch wird unter Annahme kugelförmiger Objekte jeder Punkt näherungsweise als p = radius * normal behandelt, um einen Specular-Highlight-Effekt mit Gewalt zu erzeugen
  • Das Ergebnis ist etwas diskontinuierlich, kann sich während des Spielens aber dennoch ziemlich natürlich anfühlen

Grenzen und Zukunft

  • In der Demo wurden Grenzen wie Shading-Diskontinuitäten, Unterstützung nur für Graustufentexturen und fehlende Unterstützung für Point Lights so gut wie möglich kaschiert

  • Aufwendiges Preprocessing ist zwingend erforderlich

  • Eine Methode, die sowohl ambientes als auch direktes Licht ohne Shading-Diskontinuitäten unterstützt, bleibt weiterhin eine Herausforderung

  • Die Experimente betonen die neuen Möglichkeiten und die Faszination solcher Ideen

  • Es wurde auch eine PAL-kompatible N64-ROM veröffentlicht. Sie ist allerdings instabil und stürzt häufig ab

Sonstiges

  • Der Autor erwägt auch, ein Buch zu schreiben; wer Interesse hat, kann hier Neuigkeiten erhalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-19
Hacker-News-Kommentar

  • Mit dem Eindruck, dass es wirklich beeindruckend sei, auf dem N64 „realistische“ Grafik zu sehen, und dass diese Demo an „ICO“ auf der PS2 erinnere. Es wird die Frage aufgeworfen, ob man ein SDK bauen könnte, das die Grafik-Hardware des N64 abstrahiert und moderne Primitive-, Lighting-, Shading- und Baked-Lighting-Tools bereitstellt. Außerdem wird erwähnt, dass die N64-Hardware eine für ihre Generation einzigartige Struktur hatte, und ein Link mit detaillierten Hardware-Informationen wird geteilt

    • Es wird erwähnt, dass das N64 von SGI entworfen wurde und wie stark SGI die 3D-Grafik beeinflusst hat. Daraus wird geschlossen, dass das N64 innerhalb seiner Generation eher die standardmäßigste Hardware gehabt haben dürfte. Es wäre vielmehr überraschend, wenn es keine OpenGL-Bibliothek gegeben hätte. Als Nachteil wird angeführt, dass man die Konsole als Grafikkarte mit angeflanschtem CPU betrachten müsse und dass das Grafiksystem direkt offengelegt sei. Die Architektur von Grafikchips sei untereinander nicht kompatibel, Hersteller vermieden die Offenlegung solcher internen Strukturen und böten nur APIs wie OpenGL oder DirectX an, was kreative Designs ermögliche, direkten Hardwarezugriff aber sehr schwierig mache. Ergänzend wird erklärt, dass OpenGL von SGI stammt und Nvidia ebenfalls von ehemaligen SGI-Mitarbeitern gegründet wurde

    • Erwähnung von „Shadow of the Colossus...“ zusammen mit einem passenden YouTube-Link

  • Begeisterung darüber, dass der Haupttext über N64-Grafiktricks mit der Frage „Ist das die Zukunft?“ endet

    • Es wird erklärt, dass die Indie-N64-Entwicklung derzeit enorm belebt ist. Dutzende populäre Spiele wurden dekompiliert und als Source Code veröffentlicht, wodurch PC-Portierungen leichter geworden sind, und es entstehen vielfältige Mods, die auf echter Hardware laufen. Anschaulich beschrieben werden Fan-Remakes von Zelda sowie vollständige Spiele mit neuen Dungeons und Stories, die aktive technische Optimierung in der Mario-64-Community, Kazes eigene Engine und seine Fortsetzungsprojekte sowie Empfehlungen für technische Deep-Dive-Videos. Außerdem werden absurde Demos wie Portal erwähnt und die Geschichte, dass Valve rechtliches Interesse daran zeigte. Auch Rares unveröffentlichtes Dinosaur Planet wird genannt, das nach einem Leak dekompiliert, restauriert und in der Indie-Szene wiederbelebt wurde, zusammen mit vielen detaillierten Links

  • Ausdruck der Bewunderung für die Genialität von Game-Engineers, die auf begrenzter Hardware kreative Lösungen erschaffen haben

    • Es wird das Prinzip geteilt, dass unter Einschränkungen Kreativität auf höchstem Niveau entsteht. Genau darin liege das Geheimnis von pico8, Animal Well und vielen anderen beeindruckenden Spielen. Dazu die bedauernde Bemerkung, dass einem für das selbst entwickelte 2d-pixel-art-game-maker-maker an diesem Wochenende eine große Architekturverbesserung eingefallen sei und sich der Release wohl erneut um einen Monat verschieben werde

    • Es wird klargestellt, dass das hier vorgestellte Werk kein Produkt aus der N64-Hochzeit ist, sondern ein aktuelles neues Werk

    • Hinweis darauf, dass es sich nicht um N64-Technik von damaligen N64-Entwicklern handelt, sondern um neue Technik aus der Demoscene nach Stand von 2025

  • Rückblick darauf, dass heutige schnellere Systeme zwar angenehm seien, das Überwinden von Grenzen in älteren Spielen und die Zufriedenheit, wenn man es wirklich geschafft habe, aber etwas Besonderes gewesen seien. Mit dem Hinweis, dass Hacker-News-Leser vermutlich mit den Konzepten „Raster Interrupts“ und „racing the beam“ vertraut seien, wird eine Anekdote erzählt, wie auf dem Atari 800 mit solchen Techniken Dinge möglich wurden, die eigentlich unmöglich waren. Weiter heißt es, man habe erst vor Kurzem gelernt, wie stark Atari-2600-Spiele von solchen verrückten Methoden geprägt waren, verbunden mit einem YouTube-Hinweis. Selbst wenn die Hardwareentwicklung künftig stillstehen sollte, sei man sicher, dass wir noch jahrzehntelang neue interessante Tricks entdecken würden

  • Erinnerung daran, in den 90ern in einem Shareware-Spiel palettenbasiertes Lighting eingesetzt zu haben. Die VGA-256-Farben-Palette sei so angeordnet gewesen, dass jede Farbe stufenweise Helligkeitsvarianten hatte, sodass sich Beleuchtung einfach durch Addieren oder Subtrahieren von Farbindizes darstellen ließ

  • Beobachtung, dass Demoscene-Arbeiten und ähnliche Projekte zwar auf beeindruckendem Niveau seien, aber oft zu einfachen, leeren Szenen tendierten. Die Einschätzung lautet, dass solche Techniken meist eher für Hintergründe oder begrenzte Gameplay-Funktionen geeignet seien. Viel beeindruckender seien Versuche wie FastDoom oder Optimierungsprojekte für Mario 64, die auf alter Hardware die Performance massiv steigern und dabei sogar Inhalte und Funktionen erweitern. Es wird die Vermutung geäußert, dass es vielleicht Verbindungen zwischen der Demoscene und solchen stärker ausgearbeiteten Projekten gibt

  • Nostalgie für die Optimierungstechniken der PS1- und PS2-Ära. Die meisten Spiele sähen selbst dann noch großartig aus, wenn man sie per Emulation auf 1080p oder 4k und mehr hochskaliere. Jemand meint, die 4k-Grafik von Halo 2 reiche völlig aus, und führt als Beispiel den tatsächlich umgesetzten „Hitzeflimmern“-Effekt in GT3 an, mit dem Zitat eines Entwicklers, dass so etwas auf der PS3 nicht so schnell umsetzbar gewesen wäre wie auf der PS2. Nicht der heutige realistische Hitzeflimmer eines UE5, sondern ein Trick mit geringer Performance-Belastung sei eher vorzuziehen. Lieber alte Tricks als Framedrops durch RTX, heißt es. Es wird daran erinnert, dass auf einer 299-MHz-MIPS-CPU gewaltige Spiele wie Shadow of the Colossus, GoW2, FFXII, GT4, Black, Valkyrie Profile 2, Rouge Galaxy, Burnout 3, Jak and Daxter und Ratchet liefen; dazu werden auf dem GameCube RE4, Metroid und Zelda genannt. Der Abschnitt endet mit ausdrücklicher Bewunderung und Respekt für die Fähigkeiten klassischer Game-Entwickler

    • Es wird angemerkt, dass das GoW2-Video wahrscheinlich mit dem PCSX2-Emulator aufgezeichnet wurde und Upscaling sowie andere Enhancement-Effekte enthalten habe. Trotzdem sei GoW2 auf der PS2 eine enorme Leistung gewesen

    • Zur PS2 stimme man zu, bei der PS1 sei die Performance aber nur mittelmäßig gewesen. Die Leistung der PSX liege ungefähr auf Pentium-90- bis Pentium-100-Niveau, aber ein MMX-Pentium mit 3DFX habe das N64 erreicht oder übertroffen. Als Beispiele für starke Leistung von MIPS-CPUs bei niedrigem Takt werden PSP, SGI Irix und PS2 genannt. Es wird erklärt, dass die GPU der PS2 vom R4k-CPU getrennt sei, und aus eigener Erfahrung berichtet, dass der Deus-Ex-Port für PS2 der PC-Version unterlegen gewesen sei und die Unreal Engine nicht vollständig bewältigt habe. Zwar habe die PS2 erstaunliche Spezialeffekte gezeigt, doch bei Ports wie Deus Ex seien die Karten sehr klein gewesen

    • Die feste Überzeugung, dass die Grafik von Halo 3 besser aussehe als die vieler aktueller Spiele. Blur, Bloom und Effekte wie wegfliegendes Gras und Laub, die heute häufig ergänzt würden, sorgten eher für ein schlechteres visuelles Erlebnis. In schnellen FPS-Spielen spiele eine feine Polygonzahl kaum eine Rolle, und auch die Texturauflösung sei einfach gut genug. Spürbar seien in der Praxis vor allem die Hardwareanforderungen, so die eigene Erfahrung