Comment utiliser des astuces d’éclairage par palette sur Nintendo 64

 (30fps.net)
2 points par GN⁺ 2025-05-19 | 1 commentaires | Partager sur WhatsApp
  • Cet article explique les techniques d’éclairage par palette et de normal mapping appliquées au cours du développement d’une démo Nintendo 64
  • Au lieu de répercuter immédiatement l’éclairage directement dans la texture, il présente une méthode qui consiste à ne modifier que la palette afin d’appliquer un effet d’éclairage à l’ensemble de la texture
  • Il exploite diverses techniques d’optimisation, comme la compression de palette diffuse/normale et le normal mapping en espace objet
  • Cette méthode n’est efficace que pour un éclairage directionnel et présente des inconvénients, notamment des discontinuités d’ombrage
  • Dans la démo, reflets spéculaires / lumière directe / lumière ambiante sont combinés de manière créative pour produire des visuels impressionnants malgré les limites de la N64

Introduction et objectifs

  • Cet article prolonge un thread lancé sur Bluesky et partage une technique d’éclairage avancée utilisée dans une démo pour Nintendo 64 (Revision 2025)
  • La démo inclut divers effets, comme du normal mapping avec reflets spéculaires et un éclairage par réflexion en temps réel ; la musique est composée par noby et la guitare est jouée par Moloko

Possibilités du normal mapping sur Nintendo 64

  • En s’appuyant sur les expérimentations de développeurs homebrew comme WadeTyhon et Spooky Iluha, l’auteur a vérifié la faisabilité du normal mapping sur N64
  • L’approche de base consiste à calculer directement l’éclairage sur les textures au runtime, côté CPU
  • En l’absence de support matériel, il est possible d’exécuter du code de shading personnalisé sur le CPU, mais les problèmes de performance sont importants

Shading basé sur la palette

  • Au lieu d’appliquer directement un shading dans l’espace texture, il suffit de mettre à jour les données de palette d’une texture indexée pour que toute la texture reflète en temps réel les variations de luminosité
  • Comme la N64 utilise fréquemment des textures à palette, cette méthode est souvent exploitable
  • Le simple fait de mettre à jour la palette produit immédiatement un effet semblable à un véritable éclairage appliqué à chaque texel
  • La palette d’origine est remplacée par une palette ombrée, puis la texture indexée existante est mappée sur l’objet comme une texture normale
  • Même avec un éclairage diffus limité à dot(N,L), les résultats sont déjà remarquablement bons

Normal mapping en espace objet

  • En général, le normal mapping se fait en espace tangent, ce qui convient bien aux textures répétées et aux corrections naturelles de surface
  • Une normal map en espace objet fournit à chaque texel l’information de normale de surface exacte, ce qui simplifie les calculs, mais rend l’usage de textures répétées plus difficile
  • Même compressée en palette de 32 couleurs, une normal map haute résolution peut conserver des caractéristiques proches de l’original

Conception d’une palette partagée entre diffuse et normales

  • L’objet possède une texture diffuse (basecolor * ao) et une normal map
  • Les deux textures sont conçues pour partager les mêmes indices de palette, générés par un algorithme de clustering K-means
  • Le clustering traite les images comme une image à 6 canaux
  • Dans l’exemple, la diffuse RGB + la normal map sont compressées dans une palette de 16 couleurs, si bien que les données d’image ne nécessitent que 4 bpp
  • Lors du shading, pour chaque couleur de palette, les informations de normale et de couleur de surface sont récupérées via l’index afin de générer une nouvelle couleur RGB
  • Cette approche ne prend correctement en charge que la lumière directionnelle, et il est difficile d’implémenter des ombres à l’aide de la seule palette

Lumière ambiante directionnelle / lumière solaire précalculées

  • Pour obtenir un éclairage réaliste des bâtiments, les composantes RGB et le canal alpha des vertex colors sont utilisés respectivement pour la lumière ambiante et la lumière solaire

  • L’ambient est séparé entre intensité directionnelle (environment map en niveaux de gris) et couleur (RGB, avec saturation renforcée)

  • La lumière directe du soleil est transmise dans l’alpha des sommets

  • La formule de base d’éclairage est la suivante

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

  • Chacun de ces termes se combine pour produire la couleur finale

  • L’éclairage ambiant directionnel donne un effet de lumière naturelle très riche et, malgré l’approche par palette, produit une texture de haute qualité

  • Pour simplifier, l’environment map utilise une projection équirectangulaire

Shading de grands modèles avec textures répétées

  • L’algorithme initial visait un objet unique, et le grand mesh du château posait problème à cause de l’usage de textures répétées
  • Pour résoudre cela, Blender a été utilisé afin de séparer le mesh en sous-meshes selon l’orientation des surfaces et les matériaux
  • Pour chaque groupe, l’ordinateur calcule une matrice world-to-model à partir des normales de polygones, ce qui revient à un espace tangent approximatif
  • Chaque groupe partage une palette, ce qui garantit globalement une qualité d’éclairage moyenne satisfaisante
  • Comme l’espace tangent n’est pas interpolé au runtime, cela entraîne un éclairage avec un aspect facetté

Shading spéculaire

  • Comme plusieurs points de surface partagent la même couleur de palette, un shading précis pour les point lights ou les reflets spéculaires est impossible
  • La technique en espace de palette n’est réellement efficace que pour le lighting diffus directionnel
  • En supposant malgré tout des objets sphériques, l’auteur force un effet de reflet spéculaire en approximant chaque point par p = radius * normal
  • Le résultat est quelque peu discontinu, mais pendant l’utilisation réelle, le rendu peut sembler assez naturel

Limites et avenir

  • Dans la démo, des limites comme les discontinuités d’ombrage, la prise en charge des seules textures en niveaux de gris et l’absence de point lights ont été masquées autant que possible

  • Un elaborate preprocessing (prétraitement complexe) est indispensable

  • Trouver une méthode qui gère à la fois l’éclairage ambient/direct sans discontinuités d’ombrage reste un défi

  • L’auteur souligne l’intérêt de ces résultats expérimentaux ainsi que les nouvelles possibilités et idées qu’ils ouvrent

  • Un fichier ROM N64 compatible PAL est également disponible, mais il est instable et plante fréquemment

Divers

  • L’auteur envisage aussi d’écrire un livre ; si cela vous intéresse, vous pouvez recevoir des nouvelles ici

À lire aussi

1 commentaires

 
GN⁺ 2025-05-19
Commentaires Hacker News

  • Voir des graphismes « réalistes » sur N64 est vraiment impressionnant, et cette démo donne une impression qui rappelle "ICO" sur PS2. Question partagée sur la possibilité de créer un SDK qui abstrairait le matériel graphique de la N64 et fournirait des outils modernes pour les primitives, l’éclairage, le shading, le baked lighting, etc. Mention aussi du fait que le matériel de la N64 avait une structure unique, typique de sa génération, avec un lien vers des informations matérielles détaillées

    • Mention du fait que la N64 a été conçue par SGI, et de l’influence immense de SGI sur la 3D. Hypothèse selon laquelle la N64 était peut-être au contraire le matériel le plus standard de sa génération. Avis qu’il serait presque surprenant qu’elle n’ait pas eu de bibliothèque OpenGL. Inconvénient signalé : il faut considérer la console comme une carte graphique à laquelle on a ajouté un CPU, et le système graphique est exposé très directement. Explication que les architectures des puces graphiques ne sont pas compatibles entre elles, que les fabricants évitent de dévoiler ces structures internes et ne fournissent que des API (OpenGL, DirectX, etc.), ce qui permet des conceptions créatives mais rend l’accès direct au matériel très difficile. Rappel complémentaire qu’OpenGL vient de SGI et que nvidia a aussi été fondée par d’anciens de SGI

    • Mention de "Shadow of the Colossus..." avec partage d’un lien YouTube associé

  • Exclamation admirative sur le fait que l’article consacré aux tricks graphiques de la N64 se termine par la question « Est-ce le futur ? »

    • Explication de l’énorme dynamisme actuel du développement indé sur N64. Des dizaines de jeux populaires ont été décompilés et publiés en code source, ce qui a facilité les portages PC, et de nombreux mods fonctionnant sur le matériel réel sont aussi créés. Mise en avant de fan remakes de Zelda et de jeux complets avec nouveaux donjons et nouvelles histoires, de l’optimisation technique très active dans la communauté Mario 64, du développement par Kaze de son propre moteur et de suites originales, avec recommandation de vidéos de deep dive technique. Présentation vivante, avec liens détaillés, de cas de démos improbables comme Portal, de l’histoire de l’attention juridique de Valve, et du phénomène de renaissance dans la scène indé après la fuite, la décompilation et la restauration de titres inédits de Rare comme Dinosaur Planet

  • Expression d’admiration pour le génie des ingénieurs jeu qui ont trouvé des solutions créatives sur un matériel limité

    • Partage du principe selon lequel c’est sous contrainte que la créativité atteint son plus haut niveau. Le secret de pico8, d’Animal Well et de plusieurs jeux marquants serait précisément là. Regret exprimé qu’une idée venue pour grandement améliorer l’architecture de son propre 2d-pixel-art-game-maker-maker risque encore de repousser la sortie d’un mois ce week-end

    • Précision que ce qui est présenté ici n’est pas un développement datant de l’âge d’or de la N64, mais une création récente

    • Note indiquant qu’il ne s’agit pas d’une technique d’époque réalisée par des développeurs N64 de l’époque, mais d’une nouvelle technologie liée à la demoscene en 2025

  • Aujourd’hui, c’est appréciable d’avoir des systèmes plus rapides, mais le plaisir de repousser les limites dans les anciens jeux, ainsi que la satisfaction quand on y arrivait vraiment, avaient quelque chose de spécial. Explication que les lecteurs de Hacker News connaissent probablement les concepts de "raster interrupts" et de "racing the beam", avec un souvenir d’exploits réalisés grâce à ces techniques sur Atari 800 pour rendre possible l’impossible. Remarque disant qu’on n’a réalisé que récemment à quel point les jeux Atari 2600 avaient été influencés par ce genre d’approches folles, avec partage de ressources YouTube. Conviction affirmée que même si les progrès matériels s’arrêtaient demain, on pourrait encore découvrir pendant des décennies de nouveaux tricks passionnants

  • Souvenir d’avoir utilisé dans les années 90, dans un jeu shareware, une technique d’éclairage basée sur la palette. La palette VGA 256 couleurs était organisée de manière à offrir, pour chaque teinte, des variations progressives de luminosité, ce qui permettait de produire facilement des effets de lumière simplement en ajoutant ou retirant des indices de couleur

  • Observation que la demoscene et ce type de travaux sont impressionnants, mais donnent souvent l’impression de se concentrer sur des scènes simples et vides. Analyse selon laquelle ces techniques servent surtout pour des arrière-plans ou des fonctionnalités de jeu limitées. Avis que des tentatives comme FastDoom ou les projets d’optimisation de Mario 64, qui tirent beaucoup plus de performances du vieux matériel tout en ajoutant du contenu et des fonctionnalités, sont bien plus impressionnantes. Idée qu’il existe peut-être un lien entre la demoscene et ces projets plus aboutis

  • Nostalgie des techniques d’optimisation de l’ère PS1 et PS2. Impression que la plupart des jeux restent superbes même via l’émulation avec upscale en 1080p ou en 4K et plus. Opinion qu’un Halo 2 en 4K suffit largement, avec comme exemple une démo de l’effet de « vague de chaleur » réellement produit dans GT3, accompagnée d’une citation du créateur disant qu’il n’aurait pas pu l’implémenter aussi vite sur PS3. Idée que, contrairement aux effets de chaleur réalistes sous UE5 aujourd’hui, ces tricks peu coûteux en performances étaient en fait préférables. Déclaration qu’il vaut mieux les astuces d’autrefois que subir une baisse de framerate à cause du RTX. Rappel qu’un CPU MIPS à 299 MHz faisait tourner des jeux énormes comme Shadow of the Colossus, GoW2, FFXII, GT4, Black, Valkyrie Profile 2, Rouge Galaxy, Burnout 3, Jak and Daxter, Ratchet, etc., ainsi que RE4, Metroid et Zelda sur GameCube. Conclusion pleine d’admiration et de respect pour le talent des développeurs de jeux traditionnels

    • Remarque que la vidéo de GoW2 a été capturée avec l’émulateur PCSX2 et qu’elle inclut probablement de l’upscale et d’autres améliorations visuelles. Cela dit, GoW2 sur PS2 reste considéré comme une réalisation énorme

    • Accord concernant la PS2, mais avis que la PS1 avait des performances seulement moyennes. Selon cette opinion, la PSX se situait autour d’un Pentium 90~100, alors qu’un Pentium MMX avec une 3DFX égalait ou dépassait la N64. Mention de la PSP, de SGI Irix et de la PS2 comme exemples de CPU MIPS capables d’excellentes performances à basse fréquence. Explication que le GPU de la PS2 est distinct du CPU R4k, et partage d’une expérience concrète selon laquelle le portage PS2 de Deus Ex était inférieur à la version PC et ne parvenait pas à absorber complètement l’Unreal Engine. Contexte supplémentaire : la PS2 montrait des effets spéciaux incroyables, mais les cartes restaient très petites dans des portages comme Deus Ex

    • Conviction que les graphismes de Halo 3 paraissent meilleurs que ceux de nombreux jeux récents. Idée que des effets modernes comme le blur, le bloom, ou l’animation de l’herbe et du feuillage détériorent plutôt l’expérience visuelle. Sentiment que, dans un FPS rapide, le nombre exact de polygones compte peu et que la résolution des textures est simplement suffisante. Partage de l’expérience personnelle selon laquelle ce qu’on ressent vraiment, au final, ce sont surtout les exigences matérielles