2P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 이 글은 닌텐도 64 데모 개발 과정에서 적용한 팔레트 기반 조명 및 노멀 매핑 기술을 설명함
  • 직접 텍스처에 즉시 라이팅을 반영하는 대신, 팔레트만 변경해 텍스처 전체에 조명 효과를 주는 방법을 소개함
  • diffuse/normal 팔레트 압축 및 오브젝트 공간 노멀 매핑 등 다양한 최적화 기법을 활용함
  • 이 방식은 방향성 조명에 한해 효율적이며, 쉐이딩 불연속성 등 단점이 존재함
  • 데모에서는 반사광/직접광/환경광 등 여러 요소가 창의적으로 결합되어 N64 한계에서 인상적 비주얼을 보여줌

소개 및 목표

  • 이 글은 Bluesky에서 시작한 스레드의 연장선으로, 닌텐도 64용 데모(Revision 2025)에서 활용한 진보된 라이팅 기법을 공유함
  • 데모에는 반사광이 적용된 노멀 매핑, 실시간 반사 조명 등 다양한 효과가 포함되고, 음악은 noby가 작곡, Moloko가 기타를 연주함

닌텐도 64에서의 노멀 매핑 가능성

  • WadeTyhon과 Spooky Iluha 등 홈브루 개발자들의 실험을 참고해 N64에서의 노멀 매핑 구현 가능성을 검증함
  • 기본 방식은 실행 시간에 CPU에서 텍스처에 직접 조명을 연산하는 것임
  • 하드웨어 지원 없이 CPU로 쉐이딩 커스텀 코드 실행 가능하지만, 속도 저하 문제가 큼

팔레트 기반 쉐이딩

  • 텍스처 공간 쉐이딩을 직접 적용하는 대신, 팔레트 텍스처의 팔레트 데이터만 업데이트하면 전체 텍스처가 실시간으로 밝기 변화를 반영함
  • N64는 팔레트 텍스처 사용이 흔하므로 흔히 활용 가능함
  • 팔레트만 업데이트해도 각 텍셀별로 실제 조명을 적용한 것 같은 효과가 즉시 나타남
  • 원본 팔레트를 쉐이딩 적용된 팔레트로 교체하고, 기존 팔레트 텍스처를 오브젝트에 일반 텍스처로 매핑함
  • 디퓨즈(dot(N,L)) 라이팅만 적용해도 상당히 뛰어난 결과물을 보여줌

오브젝트 공간 노멀 매핑

  • 일반적으로 노멀 매핑은 텐전트 공간에서 이루어지며, 반복 텍스처 지원 및 자연스러운 표면 보정에 적합함
  • 오브젝트 공간 노멀 맵은 각 텍셀이 정확한 표면 노멀 정보를 가지므로 계산이 단순하지만, 반복 텍스처 활용이 어려움
  • 고해상도 노멀 맵을 32색 팔레트로 압축해도 원본과 유사한 특성을 유지 가능함

디퓨즈와 노멀이 공유된 팔레트 설계

  • 오브젝트는 디퓨즈 텍스처(basecolor * ao)와 노멀 맵을 가짐
  • 두 텍스처 모두 K-means 군집 알고리듬으로 생성된 동일한 팔레트 인덱스를 공유하도록 구성함
  • 이미지를 6채널 이미지로 간주해 클러스터링을 진행함
  • 예시에서는 RGB 디퓨즈 + 노멀 맵을 16색 팔레트로 압축해, 이미지 데이터는 4bpp만 기록하면 됨
  • 쉐이딩 시, 각 팔레트 색상에 대해 노멀 및 표면 색상 정보를 인덱스로 조회해 새 RGB 색상을 생성함
  • 이 방식은 방향광만 제대로 지원 가능하고, 팔레트만으로 섀도우를 구현하긴 어려움

굽기(baked)된 방향성 환경광/태양광

  • 건물의 사실적인 라이팅을 구현하고자, 버텍스 컬러의 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 행렬을 산출함(근사 텐전트 공간)
  • 각 그룹은 하나의 팔레트를 공유해, 전체적으로는 평균적인 라이팅 품질이 보장됨
  • 텐전트 공간이 런타임에 보간되지 않아 면이 깎인 듯한(face) 라이팅이 나타나는 단점이 존재함

스페큘러(반사광) 쉐이딩

  • 여러 표면 지점이 동일한 팔레트 색상을 공유하므로, 정확한 포인트 라이트/반사광 쉐이딩은 불가능함
  • 팔레트 공간 기법은 방향성 디퓨즈 라이팅에 한해 효율적임
  • 그래도 구형 개체를 가정해, 각 점을 p = radius * normal로 근사하여 스페큘러 반사광 효과를 억지로 구현함
  • 결과는 다소 불연속적이지만, 플레이 중 실제로는 상당히 자연스러운 느낌을 줄 수 있음

한계와 미래

  • 데모에서는 쉐이딩 불연속성, 흑백 텍스처만 지원, 포인트라이트 미지원 등의 한계를 최대한 숨겼음

  • elaborate preprocessing(복잡한 사전 처리)이 필수적임

  • 쉐이딩 불연속성 없이 ambient/direct 조명 모두 지원하는 방법은 여전히 도전 과제임

  • 실험 결과에 대해 새로운 가능성과 아이디어의 흥미로움을 강조함

  • PAL 호환 N64 ROM 파일도 공개되어 있음. 단, 불안정하여 자주 다운됨

기타

  • 저자는 책 집필도 고려 중이며, 관심이 있다면 이곳에서 소식을 받아볼 수 있음
Hacker News 의견
  • N64에서 "리얼리스틱" 그래픽을 보는 것은 정말 인상적인 경험이라는 감상 표현과 함께, 이 데모가 PS2용 "ICO"를 떠올리게 하는 느낌 전달. N64 그래픽 하드웨어를 추상화하고 현대의 프리미티브, 라이팅, 셰이딩, 베이크 라이팅 툴 등을 제공하는 SDK 제작 가능성에 대한 궁금증 공유. N64 하드웨어가 세대 특유의 독특한 구조를 가졌다는 언급과, 상세한 하드웨어 정보 링크 제공

    • N64가 SGI에 의해 설계된 점과, SGI가 3D 그래픽에 얼마나 영향을 끼쳤는지 언급. N64가 오히려 세대에서 가장 표준적인 하드웨어를 가졌을 것으로 추정. 오히려 오픈GL 라이브러리가 없으면 놀라울 정도라는 견해. 단점으로, 콘솔을 그래픽 카드에 CPU를 덧붙인 것으로 생각해야 하고, 그래픽 시스템이 직접적으로 노출되어 있다는 점을 지적. 그래픽 칩 아키텍처는 서로 호환성이 없고, 업체들은 이런 내부 구조 공개를 피하며 API(OpenGL, DirectX 등)만 제공해 창의적 설계가 가능하지만 하드웨어 직접 접근은 매우 어렵다는 설명. 부연 정보로 OpenGL이 SGI에서 유래했으며, nvidia도 SGI 출신들이 창업했다는 배경 지식 제공

    • "Shadow of the Colossus..." 언급과 함께 관련 유튜브 링크 공유

  • N64 그래픽 트릭을 다루는 본문이 "이게 미래인가?"라는 질문으로 끝나는 점이 마음에 든다는 감탄 표현

    • 요즘 인디 N64 개발이 엄청난 활기를 보이고 있다는 현황 설명. 인기 게임 수십 개가 디컴파일되어 소스코드로 공개되고 PC 포팅이 쉬워졌으며, 하드웨어에서 작동하는 모드도 다양하게 만들어진다는 부분 강조. Zelda 팬 리메이크와 새로운 던전·스토리를 가진 완성 게임 사례, Mario 64 커뮤니티의 활발한 기술적 최적화, Kaze라는 인물의 독자 엔진 개발 및 시퀄 창작, 기술적 딥다이브 영상 자료 추천. 포탈 등 기상천외한 데모 제작 사례와, Valve의 법적 관심을 받은 이야기. Rare의 미공개작 Dinosaur Planet 등이 유출된 후 디컴파일 및 복원되고 다시 인디 씬에서 부흥하는 현상 등 상세 링크와 함께 생생하게 소개
  • 게임 엔지니어들이 제한된 하드웨어에서 창의적인 해법을 만들어낸 천재성에 감탄하는 마음 표현

    • 제약이 있을 때 최고 수준의 창의력이 발휘된다는 원칙 공유. pico8, Animal Well, 여러 인상적 게임들의 비밀이 바로 그것. 이번 주말에 내가 만든 2d-pixel-art-game-maker-maker 아키텍처를 크게 개선하는 아이디어가 떠올라 출시가 또 한 달 연기될 것 같은 아쉬움 토로

    • 이번에 소개된 내용이 N64 전성기 당시가 아니라 최근 이루어진 신작이라는 사실 전달

    • 그 시절 N64 개발자가 아닌, 2025년 기준 데모신(demoscene)과 관련된 신기술임을 밝혀두는 안내

  • 지금은 더 빠른 시스템이 나와서 좋지만, 과거 게임에서 한계를 극복하는 재미와 그 과정을 제대로 해냈을 때의 만족감은 특별했다는 회상. 해커뉴스 이용자라면 '래스터 인터럽트(raster interrupts)'와 'racing the beam' 개념이 익숙할 것이라는 설명과 함께, Atari 800에서 그런 기술로 불가능했던 일을 가능하게 했던 일화를 소개. 최근에서야 Atari 2600 게임들이 이런 미친 방식의 영향을 많이 받았다는 걸 알게 되었다는 발언과 유튜브 자료 공유. 만약 앞으로 하드웨어 발전이 멈춘다 해도, 우리는 수십 년간 계속 새로운 흥미로운 트릭을 발견할 수 있다고 확신하는 자세

  • 90년대에 팔레트 기반 라이팅 기법을 우리 shareware 게임에서 썼던 경험 회상. 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 성능은 펜티엄90~100 정도지만, MMX 펜티엄에 3DFX를 얹으면 N64와 비슷하거나 능가했다는 의견. MIPS CPU가 낮은 클럭에서 뛰어난 성능을 내는 사례로 PSP, SGI Irix, PS2를 언급. PS2의 GPU는 R4k CPU와는 별도라는 설명과 함께, PS2용 Deus Ex 포팅은 PC판에 비해 부족했으며, 언리얼 엔진을 완전히 소화하지 못했다는 실제 경험 공유. PS2가 놀라운 특수효과는 보여줬지만, 디우스 엑스와 같은 포트에선 맵 크기가 매우 작았다는 배경 지식

    • Halo 3 그래픽이 최신 게임보다 더 좋아 보인다는 소신. 블러, 블룸, 풀과 나뭇잎이 튕겨나오는 효과 등 요즘 추가된 효과는 오히려 안 좋은 시각적 경험을 준다는 생각. 빠른 속도의 FPS 장르에서는 미세한 폴리곤 카운트는 별 의미 없고, 텍스처 해상도도 그냥 충분하다고 느낌. 실질적으로 느끼는 건 하드웨어 요구량뿐이라는 자기 경험 공유