Cómo usar trucos de iluminación por paleta en Nintendo 64

 (30fps.net)
2 puntos por GN⁺ 2025-05-19 | 1 comentarios | Compartir por WhatsApp
  • Este artículo explica las técnicas de iluminación basada en paleta y normal mapping aplicadas durante el desarrollo de una demo para Nintendo 64
  • En lugar de reflejar la iluminación directamente sobre la textura en tiempo real, presenta un método para aplicar efectos de iluminación a toda la textura cambiando solo la paleta
  • Aprovecha varias técnicas de optimización, como la compresión de paletas diffuse/normal y el normal mapping en espacio de objeto
  • Este enfoque es eficiente solo para la iluminación direccional y tiene desventajas como las discontinuidades de sombreado
  • En la demo se combinan de forma creativa varios elementos como reflejos especulares / luz directa / luz ambiental, logrando visuales impresionantes dentro de los límites de la N64

Introducción y objetivos

  • Este artículo es una continuación del hilo que empezó en Bluesky y comparte una técnica avanzada de iluminación utilizada en una demo para Nintendo 64 (Revision 2025)
  • La demo incluye varios efectos, como normal mapping con reflejos especulares e iluminación reflectiva en tiempo real; la música fue compuesta por noby y Moloko tocó la guitarra

Posibilidades del normal mapping en Nintendo 64

  • Tomando como referencia experimentos de desarrolladores homebrew como WadeTyhon y Spooky Iluha, se comprobó la viabilidad de implementar normal mapping en N64
  • El método básico consiste en calcular la iluminación directamente sobre la textura desde la CPU en tiempo de ejecución
  • Aunque es posible ejecutar código de sombreado personalizado en la CPU sin soporte de hardware, el problema es la gran pérdida de rendimiento

Sombreado basado en paleta

  • En lugar de aplicar sombreado directamente en el espacio de textura, si se actualizan solo los datos de la paleta de una textura paletizada, toda la textura refleja cambios de brillo en tiempo real
  • Como en N64 el uso de texturas con paleta es común, este método puede aprovecharse con frecuencia
  • Incluso actualizando solo la paleta, aparece de inmediato un efecto como si se hubiera aplicado iluminación real a cada texel
  • La paleta original se reemplaza por una paleta con sombreado aplicado, y la textura paletizada existente se mapea al objeto como una textura normal
  • Incluso aplicando solo iluminación difusa (dot(N,L)), se logran resultados bastante notables

Normal mapping en espacio de objeto

  • Normalmente el normal mapping se realiza en espacio tangente, lo que lo hace adecuado para soportar texturas repetidas y correcciones naturales de superficie
  • Un normal map en espacio de objeto hace que cada texel tenga información de la normal exacta de la superficie, por lo que el cálculo es más simple, aunque dificulta reutilizar texturas repetidas
  • Incluso comprimiendo un normal map de alta resolución a una paleta de 32 colores, es posible conservar características similares al original

Diseño de una paleta compartida para diffuse y normal

  • El objeto tiene una textura difusa (basecolor * ao) y un normal map
  • Ambas texturas están configuradas para compartir los mismos índices de paleta generados con el algoritmo de clustering K-means
  • La agrupación se realiza tratando la imagen como una imagen de 6 canales
  • En el ejemplo, el diffuse RGB + el normal map se comprimen en una paleta de 16 colores, por lo que los datos de imagen solo necesitan almacenar 4bpp
  • Durante el sombreado, para cada color de la paleta se consultan por índice la normal y la información de color de superficie para generar un nuevo color RGB
  • Este método solo puede soportar bien luz direccional, y es difícil implementar sombras usando solo la paleta

Luz ambiental direccional / luz solar horneadas

  • Para lograr una iluminación realista en los edificios, se usan el RGB del color de vértice y el canal alfa, respectivamente, para la luz ambiental y la luz solar

  • La luz ambiental (ambient) se separa en intensidad direccional (mapa de irradiancia en escala de grises) y color (RGB, con saturación reforzada)

  • La luz solar (direct) se transmite en el alfa del vértice

  • La fórmula básica de iluminación es la siguiente

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

  • Cada uno de estos términos se combina para producir el color final

  • La luz ambiental direccional genera un efecto de luz natural muy potente y, aunque se basa en paleta, produce una textura de alta calidad

  • Para simplificar, el mapa de entorno usa proyección equirectangular

Sombreado de modelos grandes con texturas repetidas

  • El algoritmo inicial era para un solo objeto, y la gran malla del castillo presentaba problemas por el uso de texturas repetidas
  • Para resolverlo, se usó Blender para dividir la malla en submallas según la dirección de la superficie y el material
  • Luego la computadora calcula una matriz world-to-model para cada grupo usando las normales de los polígonos (un espacio tangente aproximado)
  • Cada grupo comparte una sola paleta, por lo que en conjunto se garantiza una calidad de iluminación promedio aceptable
  • Como el espacio tangente no se interpola en tiempo de ejecución, existe la desventaja de que aparece una iluminación con aspecto facetado en las caras

Sombreado especular

  • Como varios puntos de la superficie comparten el mismo color de paleta, no es posible hacer un sombreado especular o con point lights preciso
  • La técnica en espacio de paleta solo es eficiente para iluminación difusa direccional
  • Aun así, suponiendo un objeto esférico, se fuerza un efecto de reflejo especular aproximando cada punto como p = radius * normal
  • El resultado es algo discontinuo, pero durante el juego puede sentirse bastante natural en la práctica

Limitaciones y futuro

  • En la demo se ocultaron lo mejor posible limitaciones como discontinuidades de sombreado, soporte solo para texturas en blanco y negro y falta de soporte para point lights

  • Es indispensable un preprocessing elaborado

  • Sigue siendo un reto encontrar un método que soporte tanto iluminación ambiental como directa sin discontinuidades de sombreado

  • Se subraya lo interesantes que fueron los resultados experimentales y las nuevas posibilidades e ideas que surgieron

  • También está disponible el archivo ROM de N64 compatible con PAL. Eso sí, es inestable y se cae con frecuencia

Otros

  • El autor también está considerando escribir un libro y, si te interesa, puedes recibir noticias aquí

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-19
Opiniones de Hacker News

  • Comentario de que ver gráficos "realistas" en N64 es una experiencia realmente impresionante, y que este demo transmite una sensación que recuerda a "ICO" de PS2. También comparte curiosidad sobre la posibilidad de crear un SDK que abstraiga el hardware gráfico de N64 y ofrezca primitivas modernas, herramientas de iluminación, sombreado y baked lighting. Menciona además que el hardware de N64 tenía una estructura única, muy propia de su generación, y aporta un enlace con información detallada del hardware

    • Menciona que la N64 fue diseñada por SGI y cuánto influyó SGI en los gráficos 3D. Supone que, de hecho, la N64 probablemente tenía el hardware más estándar de su generación. Incluso opina que sería sorprendente que no existiera una biblioteca OpenGL. Como desventaja, señala que hay que pensar en la consola como una tarjeta gráfica con una CPU añadida, y que el sistema gráfico está expuesto de forma muy directa. Explica que las arquitecturas de chips gráficos no son compatibles entre sí, que las empresas evitan revelar estas estructuras internas y solo ofrecen APIs como OpenGL o DirectX, lo que permite diseños creativos pero hace muy difícil el acceso directo al hardware. Como contexto adicional, aporta que OpenGL se originó en SGI y que Nvidia también fue fundada por personas provenientes de SGI

    • Menciona "Shadow of the Colossus..." y comparte un enlace relacionado de YouTube

  • Expresión de entusiasmo porque el artículo sobre trucos gráficos de N64 termina con la pregunta "¿Es este el futuro?"

    • Explica que el desarrollo indie para N64 está viviendo un enorme auge hoy en día. Destaca que decenas de juegos populares han sido decompilados y publicados como código fuente, lo que ha facilitado los ports a PC, y que también se crean muchos mods que corren en hardware real. Presenta con mucho detalle, junto con varios enlaces, casos como remakes hechos por fans de Zelda, juegos completos con nuevos dungeons e historias, la activa optimización técnica en la comunidad de Mario 64, el desarrollo de motores propios y secuelas creadas por Kaze, recomendaciones de videos técnicos en profundidad, demos insólitos como Portal y la historia de cómo atrajeron la atención legal de Valve. También menciona cómo obras inéditas de Rare como Dinosaur Planet se filtraron, fueron decompiladas y restauradas, y ahora resurgen dentro de la escena indie

  • Expresa admiración por la genialidad de los ingenieros de videojuegos al encontrar soluciones creativas en hardware limitado

    • Comparte la idea de que el nivel más alto de creatividad aparece cuando hay restricciones. Dice que ese es el secreto detrás de pico8, Animal Well y varios juegos impresionantes. También lamenta que este fin de semana se le ocurrió una gran mejora para la arquitectura de su 2d-pixel-art-game-maker-maker, así que probablemente volverá a retrasar el lanzamiento otro mes

    • Aclara que lo mostrado esta vez no es algo de la época dorada de N64, sino una obra nueva hecha recientemente

    • Señala que no se trata de desarrolladores de N64 de aquella época, sino de nueva tecnología relacionada con la demoscene en 2025

  • Recuerdo de que ahora es bueno tener sistemas más rápidos, pero que la diversión de superar límites en los juegos antiguos y la satisfacción de lograrlo bien eran algo especial. Explica que a los usuarios de Hacker News probablemente les resulten familiares los conceptos de "raster interrupts" y "racing the beam", y cuenta una anécdota sobre cómo hizo posible en Atari 800 cosas que parecían imposibles usando esas técnicas. Comenta que solo recientemente descubrió cuánto influyeron estos métodos demenciales en los juegos de Atari 2600, y comparte material de YouTube. Añade que, incluso si el avance del hardware se detuviera en el futuro, está convencido de que seguiríamos descubriendo nuevos trucos interesantes durante décadas

  • Recuerdo de haber usado en los 90 una técnica de iluminación basada en paleta en un juego shareware propio. Explica que en la paleta VGA de 256 colores habían ordenado cada color con variaciones graduales de brillo, de modo que bastaba con sumar o restar índices de color para producir iluminación fácilmente

  • Observación de que la demoscene y este tipo de trabajos son impresionantes, pero suelen inclinarse hacia escenas simples y vacías. Analiza que estas técnicas normalmente parecen útiles para fondos o funciones de juego limitadas. Considera mucho más impresionante cuando, como en FastDoom o en proyectos de optimización de Mario 64, se logra aumentar enormemente el rendimiento en hardware viejo y además añadir contenido y funciones. Piensa que quizá exista una conexión entre la demoscene y estos proyectos más completos

  • Nostalgia por las técnicas de optimización de la era de PS1 y PS2. Comenta que incluso al reescalar por emulación a 1080p o 4k, o más, la mayoría de esos juegos siguen viéndose muy bien. Opina que los gráficos de Halo 2 en 4k le bastan, y pone como ejemplo un demo del efecto de "heat haze" que realmente lograron en GT3, citando a un creador que dijo que en PS3 no podría implementarlo tan rápido como en PS2. Piensa que, a diferencia del heat haze realista de motores actuales como UE5, los trucos de antes que casi no afectaban el rendimiento eran mejores. Dice que prefiere esos trucos del pasado a sufrir caídas de frames por usar RTX. Menciona que en una CPU MIPS de 299MHz corrían juegos enormes como Shadow of the Colossus, GoW2, FFXII, GT4, Black, Valkyrie Profile 2, Rouge Galaxy, Burnout 3, Jak and Daxter y Ratchet, además de RE4, Metroid y Zelda en GameCube. Cierra con una expresión de asombro y respeto hacia la habilidad de los desarrolladores tradicionales de videojuegos

    • Señala que el video de GoW2 fue capturado con el emulador PCSX2 y probablemente incluía reescalado y otras mejoras. Aun así, cree que GoW2 en PS2 fue un logro enorme

    • Dice que está de acuerdo con lo de PS2, pero que en PS1 el rendimiento era simplemente regular. Opina que la PSX rendía más o menos como un Pentium 90~100, pero que un Pentium con MMX y una 3DFX igualaba o superaba a N64. Menciona PSP, SGI Irix y PS2 como ejemplos de CPUs MIPS con gran rendimiento a bajas frecuencias. Explica también que la GPU de PS2 estaba separada de la CPU R4k, y comparte la experiencia real de que el port de Deus Ex para PS2 quedaba por debajo de la versión de PC y no lograba manejar por completo el Unreal Engine. Añade como contexto que PS2 mostraba efectos especiales asombrosos, pero que en ports como Deus Ex el tamaño de los mapas era muy pequeño

    • Afirma con convicción que los gráficos de Halo 3 se ven mejor que los de juegos actuales. Piensa que efectos añadidos hoy, como blur, bloom, y el rebote de pasto y hojas, más bien empeoran la experiencia visual. Cree que en FPS rápidos el conteo fino de polígonos casi no importa, y que la resolución de texturas simplemente ya es suficiente. Comparte que, en la práctica, lo único que realmente percibe son los requisitos de hardware