Palette-Lighting-Tricks auf dem Nintendo 64 verwenden

 (30fps.net)
2 Punkte von GN⁺ 2025-05-19 | 1 Kommentare | Auf WhatsApp teilen
  • Die für Revision 2025 erstellte Nintendo-64-Demo erzielt Effekte nahe an Normal Mapping, gebackener Beleuchtung und Echtzeit-Specular, indem sie nur die Palette aktualisiert, ohne die gesamte Textur neu zu berechnen
  • Wenn die CPU für jeden Palettenindex Normalen und Diffuse-Farbe ausliest und daraus eine neue RGB-Palette erzeugt, reagiert die Palettentextur so, als hätte jedes Texel eigene Beleuchtung erhalten
  • Diffuse-Textur und Normal Map teilen sich dieselben Palettenindizes und werden per K-means clustering aus scikit-learn erzeugt, als wären sie ein 6-Kanal-Bild
  • Die Gebäudebeleuchtung kombiniert Ambient-Farbe aus Vertex-RGB, Sonnensichtbarkeit aus Vertex-Alpha, eine graue irradiance map und dot(N, sun_dir) für gerichtetes Sonnenlicht
  • Für gerichtetes Diffuse-Licht ist das effektiv, hat aber große Einschränkungen bei Schatten, Point Lights, präzisem Specular und großen Modellen mit wiederholten Texturen; diese Grenzen müssen durch Preprocessing kaschiert werden

Shading durch reines Aktualisieren der Palette

  • Die Nintendo-64-Demo wurde für Revision 2025 erstellt und nutzt Effekte, die gebackener Beleuchtung, Normal Mapping und Echtzeit-Specular-Shading nahekommen
  • Auf dem N64 war Normal Mapping durch frühere Homebrew-Experimente bereits als möglich bekannt; diese Demo entscheidet sich dafür, zur Laufzeit nicht die Textur, sondern die Palette mit den Beleuchtungsergebnissen zu berechnen
  • Ohne spezielle Hardwareunterstützung kann die CPU beliebigen Shading-Code ausführen, die Berechnung ist aber langsam
  • Bei Palettentexturen reicht es, nur die Palette zu ändern, nicht alle Texel, damit die gesamte Textur so aussieht, als wäre eine Beleuchtungsberechnung angewendet worden
    • Die ursprüngliche Palette wird durch eine schattierte Palette ersetzt
    • Die Palettentextur wird wie eine normale Textur auf das Objekt angewendet
    • Schon einfaches Diffuse-Licht mit dot(N,L) liefert ziemlich gute Ergebnisse
  • Ein frühes Beispiel machte die Gammakorrektur der Farbtextur rückgängig und shadete im linearen Raum; in der finalen Demo konnte das jedoch nicht eingesetzt werden, weil Ambient- und Direktlichtanteile getrennt werden mussten, um sie per Hardware in der RDP-Einheit des N64 zusammenzusetzen

Normal Mapping im Objektraum

  • Übliches Normal Mapping wird im Tangentenraum ausgeführt
    • Wiederholte Texturen können verwendet werden
    • Detailnormalen können sanft variierende Vertex-Normalen korrigieren
    • Eine einfarbige Tangent-Space-Normal-Map beschreibt eine glatte Oberfläche
  • Objektraum-Normalen sind einfacher zu berechnen, bringen aber starke Einschränkungen mit sich
    • Texel der Normal Map beschreiben nicht eine Abweichung von der Vertex-Normale, sondern die absolute Oberflächennormale
    • Die Laufzeitberechnung wird so simpel wie das Auslesen einer Farbe aus einer Textur
    • Jeder Oberflächenpunkt braucht wie bei einer Lightmap ein eigenes Texel

Gemeinsame Palette für Diffuse-Textur und Normal Map

  • Das Objekt besitzt sowohl eine Diffuse-Textur basecolor * ao als auch eine Normal Map
  • Beide Texturen teilen sich dieselben Palettenindizes; diese Indizes werden mit K-means clustering aus scikit-learn erzeugt
    • Die Bilder werden wie ein einziges 6-Kanal-Bild interpretiert
    • Über einen einzelnen Index lassen sich sowohl Normale als auch Oberflächen-Diffuse-Farbe abrufen
  • Beim Laden oder in jedem Frame wird über die Palettenfarben iteriert
    • CPU-Shading-Code erzeugt für jeden Index eine neue RGB-Farbe
    • Das Ergebnis der Schleife wird zur neuen Palette mit angewendeter Beleuchtung
  • Dieser Ansatz passt in der Praxis am besten zu gerichteter Beleuchtung
  • Effekte wie Schatten lassen sich allein mit einer Palette nur schwer ausdrücken, daher muss sie mit gebackener Beleuchtung kombiniert werden

Gebackenes gerichtetes Ambient-Licht und Sonnenlicht

  • Für realistischere Beleuchtung speichert die Demo bei den Gebäuden Ambient- und direktes Sonnenlicht getrennt in Vertex-Farben
    • Vertex-RGB: Ambient-Farbe
    • Vertex-Alpha: Sonnensichtbarkeit
  • Der Ambient-Term wird in gerichtete Intensität und Farbe aufgeteilt
    • Die gerichtete Intensität ist eine Graustufen-irradiance map
    • Die Farbe ist Vertex-RGB mit erhöhter Sättigung
  • Die Sonne ist ein gerichtetes Licht, die Sichtbarkeit wird über Vertex-Alpha übergeben
  • Die Shading-Formel lautet wie folgt
ambient = vertex_rgb      * grey_irradiance_map(N)
direct  = vertex_alpha    * sun_color * dot(N, sun_dir)
color   = diffuse_texture * (ambient + direct)
  • Unsaubere Vertex-Farben für die Sonnensichtbarkeit werden durch die N.L-Berechnung maskiert und erscheinen im finalen Direktlicht sauberer
  • Gerichtetes Ambient-Licht kann selbst bei grob gebackener Beleuchtung dank Texturdetails hochwertig wirken
  • Für die unscharfe Environment Map wird wegen der Einfachheit eine equirectangular projection verwendet
    • Polyhaven-HDRIs verwenden diese Projektion bereits
    • Da das Shading bereits beim Laden vorberechnet wurde, ist komplexe Sampling-Mathematik kein Problem

Große Modelle mit wiederholten Texturen verarbeiten

  • Der ursprüngliche Shading-Algorithmus wurde für ein einzelnes Objekt entwickelt und anfangs nur mit potato_rock.obj getestet
  • Beim Burgmauer-Mesh der Demo traten wegen wiederholter Texturen Probleme auf
  • Der Workaround besteht darin, das große Mesh in mehrere Submeshes aufzuteilen und jedes Submesh konzeptionell dieselbe Objektraum-Normal-Map teilen zu lassen
    • In Blender wird die Geometrie manuell nach Material und Oberflächenausrichtung gruppiert
    • Auf Basis der Polygon-Normalen jeder Gruppe wird eine World-to-Model-Matrix berechnet
    • Diese Matrix ist grob einem Tangentenraum ähnlich
  • Da jede Gruppe die Palette teilt, stimmt die Gesamtbeleuchtung nur im durchschnittlichen Sinn
  • Der Tangentenraum wird zur Laufzeit nicht interpoliert, sodass es wie flächenweises Lighting aussieht; das ist einer der größten Nachteile der Technik

Annäherung von Specular Shading

  • Da mehrere Oberflächenpunkte dieselbe Shading-Farbe teilen, lassen sich Point Lights oder Specular Shading nur schwer exakt berechnen
  • Der Palettenraum-Ansatz eignet sich gut für diffuse gerichtete Beleuchtung, die keinen to camera-Vektor V benötigt
  • Der Specular-Effekt wird versucht, indem das Objekt als Kugel angenähert wird
    • Der zu schattierende Punkt p wird als p = radius * normal gesetzt
    • Weil viele Oberflächenpunkte denselben Palettenindex teilen, wirkt das Ergebnis zwangsläufig kantig
  • Die Specular-Highlights der Demo sahen etwas seltsam aus, funktionierten aber gut genug, um die meisten Leute zu täuschen

Grenzen und verwandte Materialien

  • In der Demo werden die wichtigsten Grenzen durch Preprocessing und Szenenaufbau kaschiert

    • Beleuchtungsunstetigkeiten und Darstellungsbereich

      • Es werden nur Graustufentexturen unterstützt
      • Es gibt keine Point Lights
      • Diese Technik ist nur mit sorgfältigem Preprocessing praktisch nutzbar
      • Die Technik von Spooky Iluha hat kein Problem mit Beleuchtungsunstetigkeiten, aber es ist unklar, ob sich dasselbe Problem lösen lässt, während sowohl Ambient- als auch Direktlicht erhalten bleiben

    • ROM und frühere Arbeiten

Verwandte Beiträge

1 Kommentare

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

  • Auf dem N64 realistische Grafik zu sehen, ist wirklich beeindruckend, und diese Demo erinnert an "ICO" auf der PS2
    Ich habe mich schon länger gefragt, ob man ein SDK bauen könnte, das die Grafik-Hardware des N64 abstrahiert und moderne Primitive, Beleuchtung, Shading und Tools bereitstellt, die wie in dieser Demo Beleuchtung vorab einbacken
    Das N64 hatte für seine Generation ziemlich einzigartige Hardware, Details dazu gibt es auf Copetti.org: https://www.copetti.org/writings/consoles/nintendo-64/

    • Das N64 wurde von SGI entworfen, und wenn man bedenkt, welchen Einfluss SGI auf 3D-Grafik hatte, würde ich eher sagen, dass das N64 in seiner Generation der standardnahesten Hardware entsprach
      Ich wäre eher etwas überrascht, wenn es keine OpenGL-Bibliothek gegeben hätte
      Es gibt allerdings zwei große Vorbehalte: 1) Man muss dieses System wie eine Grafikkarte mit angeschlossener CPU betrachten, und 2) das Grafiksystem ist direkt exponiert
      Die Architektur von Grafikchips wird am Ende leicht zu einem chaotischen, untereinander inkompatiblen Durcheinander, daher veröffentlichen Beschleunigerhersteller meist lieber Zwischen-APIs wie OpenGL, DirectX, CUDA oder Vulkan statt Referenzdokumentation
      So können sie die interne Implementierung weiterhin in inkompatiblen Strukturen halten. Wenn man keine Referenzdokumentation veröffentlicht, muss man auch keine Hardware-Abwärtskompatibilität wahren; der Vorteil ist, dass man neue Designs entwickeln kann, der Nachteil ist jedoch, dass kaum jemand sie direkt verwenden kann
      Deshalb zuckt man instinktiv zusammen, wenn man wie bei Konsolen dieser Generation direkten Zugriff bekommt
      Nebenbei: OpenGL stammt von SGI, und Nvidia wurde ebenfalls von ehemaligen SGI-Ingenieuren gegründet
    • Es erinnert auch an Shadow of the Colossus: https://www.youtube.com/watch?v=xMKtYM8AzC8

  • Mir gefällt, dass der Artikel über N64-Grafiktricks am Ende mit der Frage "Is this the future?" abschließt

  • Ich bin jedes Mal erstaunt, wenn ich sehe, wie genial diese Spieleingenieure waren
    Unter enormen Beschränkungen haben sie einfallsreiche und großartige Lösungen hervorgebracht

    • Beschränkungen verlangen und erzeugen außergewöhnliche Kreativität
      Darin liegt das Geheimnis von pico8, Animal Well und zahllosen anderen erstaunlichen Spielen
      Hätte ich mir dieses Wochenende doch bloß nicht eine viel bessere Architektur für mein Making-of zu meinem 2D-Pixelart-Spiel ausgedacht. Jetzt sieht es so aus, als würde sich der Release wieder um einen Monat verschieben :(
    • Das ist keine Technik aus der Blütezeit des N64, sondern neue Arbeit
    • Die Ingenieure damals waren sicher auch großartig, aber das hier ist, wie ausdrücklich gesagt wurde, Arbeit aus dem Jahr 2025 und eher der Demoszene als der Spieleentwicklung zuzuordnen

  • Es ist zwar wirklich schön, heute schnellere Systeme zu haben, aber es machte früher Spaß, die Beschränkungen alter Spiele zu umgehen, und es war ungemein befriedigend, wenn es gelang
    HN-Leser dürften mit Raster-Interrupts (https://en.wikipedia.org/wiki/Raster_interrupt) und Beam Racing vertraut sein. Ich habe das persönlich immer mit dem Atari 800 verbunden
    Eigentlich sollte so etwas wie https://youtu.be/GuHqw_3A-vo?t=33 nicht möglich sein, aber dank Display List Interrupts ging es doch
    Was ich bis vor Kurzem nicht wusste: wie stark Atari-2600-Spiele auf genau diese Art von Wahnsinn angewiesen waren: https://www.youtube.com/watch?v=sJFnWZH5FXc
    Wenn man so etwas sieht, bekommt man das Gefühl, dass wir selbst dann noch jahrzehntelang immer interessantere Dinge finden könnten, wenn der Hardware-Fortschritt zum Stillstand käme

  • Die Demoszene und solche Arbeiten sind beeindruckend, aber sie tendieren meist zu einfacheren, leereren Szenen.
    Es wirkt eher wie etwas, das als Teil eines Spielhintergrunds oder einer Spielmechanik eingesetzt werden könnte. Bei den meisten Techniken fühlt es sich so an, als reichten die Ressourcen nicht aus, um ein vollständiges Erlebnis zu schaffen.
    Noch beeindruckender ist es, auf alter Hardware deutlich bessere Performance herauszuholen, wie bei FastDoom oder diversen Mario-64-Optimierungsprojekten.
    Manchmal sogar, während gleichzeitig Inhalte und Funktionen hinzugefügt werden. Ich frage mich, ob es Berührungspunkte zwischen Demoszene-Entwicklern und solchen umfassenderen Arbeiten gibt.

  • In Shareware-Spielen der 90er wurde eine ähnliche palettenbasierte Beleuchtungs-Technik verwendet.
    Im Grunde wurde beim Aufbau der VGA-256-Farben-Palette für jede unterstützte Farbe ein Helligkeitsverlauf mit N Stufen dieser Farbe mit abgelegt.
    Dadurch konnte man die Helligkeit jeder Farbe einfach ändern, indem man nur Farbindizes addierte oder subtrahierte.

  • Ich vermisse die Optimierungen aus der PS1- und PS2-Zeit.
    Das meiste sieht wirklich großartig aus, wenn man es per Emulation auf 1080p oder 4K und höher hochskaliert. Für mich persönlich reicht es völlig, Grafik aus der Halo-2-Ära in 4K zu sehen.
    Natürlich ist Halo 2 ein Xbox-Spiel, aber wenn man Halo 2 in Halo MCC mit klassischer Grafik spielt, sieht es immer noch erstaunlich gut aus.
    Der Hitzeflimmer-Effekt in GT3 fasst das gut zusammen.
    „Im GT3-Demo wurde der Seattle-Kurs bei Sonnenuntergang gezeigt, und man sah, wie Hitze vom Boden aufstieg und flimmerte. Auf der PS3 kann man diesen Hitzeflimmer-Effekt nicht reproduzieren. Der Grund ist, dass read-modify-write nicht so schnell ist wie damals, als wir die PS2 verwendet haben. Solche Dinge gibt es.“
    https://old.reddit.com/r/ps2/comments/1cktw88/gran_turismos_...
    https://youtu.be/ybi9SdroCTA?t=4103
    Statt wie bei neuen Engines wie UE5 echte Hitzewellen zu emulieren, wurde das als Trick umgesetzt, damit die Framerate nicht einbricht. Ehrlich gesagt finde ich solche billigen Tricks besser, wenn ich sehe, wie stark RTX die Framerate drückt.
    299MHz MIPS bringt so etwas zum Laufen.
    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 (beim Boot-Bildschirm werde ich ganz sentimental)
    Black, Renderware war eine wahnsinnige Engine: 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
    Dazu noch Jak and Daxter, Ratchet.
    Auf der GC-Seite sehen natürlich RE4, Metroid, die Zelda-Spiele usw. ebenfalls unglaublich gut aus.
    Man kann da nur niederknien.

    • Für die PS2 stimmt das, aber bei der PSX ist es fraglich.
      Mit einem Pentium 90, also fast 100, konnte sie vielleicht mithalten, aber ein MMX-Pentium mit 3DFX hätte die PSX übertroffen und wäre auf dem Niveau des N64 gewesen oder besser.
      Die MIPS-CPU war hervorragend und konnte selbst bei niedrigem Takt Erstaunliches leisten. Man muss sich nur PSP oder SGI Irix ansehen.
      Außerdem ist die „GPU“ der PS2 nicht dasselbe wie eine R4k-CPU.
      Nebenbei bemerkt war der Deus-Ex-Port für die PS2 im Vergleich zur PC-Version miserabel und kam mit der Unreal-Engine überhaupt nicht zurecht.
      Dass die PS2 verrückte Effekte hinbekommen hat, stimmt zwar, aber in diesem Port waren die Levels wirklich winzig. Man muss auch bedenken, dass Deus Ex zu großen Teilen fast schon Open World war.
    • Ich finde immer noch, dass Halo 3 viel besser aussieht als manche modernen Spiele.
      Dinge wie Blur, Bloom und Pop-in bei Gras und Vegetation sehen eigentlich nicht gut aus, sondern wirken einfach schlechter, als wenn man sie komplett abschaltet.
      In einem schnellen Ego-Shooter hat man ohnehin keine Zeit, hochpolygonale Modelle zu bewundern, daher weiß ich nicht, was das überhaupt bringen soll.
      Für meine Augen reicht die Texturauflösung von Halo 3 völlig aus. Selbst wenn Texturen doppelt oder viermal so groß wären, würde ich es wahrscheinlich nicht bemerken — auffallen würden nur die höheren Hardware-Anforderungen.
    • Die Aussage „299MHz MIPS bringt das zum Laufen“ stimmt nur teilweise.
      Das GoW2-Video wurde in PCSX2 aufgenommen, und in diesem Clip profitiert man wahrscheinlich von Upscaling und anderen Komfortfunktionen.
      Ich habe die übrigen Videos nicht alle gesehen, aber unabhängig davon war das, was GoW2 auf der PS2 erreicht hat, beeindruckend.