Nintendo 64 में palette lighting tricks का उपयोग कैसे करें

 (30fps.net)
2 पॉइंट द्वारा GN⁺ 2025-05-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Revision 2025 के लिए बने Nintendo 64 डेमो में पूरे texture को फिर से calculate किए बिना सिर्फ palette को update करके normal mapping, baked lighting, और real-time specular के क़रीब effects बनाए गए हैं
  • CPU हर palette index पर normal और diffuse color पढ़कर नया RGB palette बनाता है, जिससे palette texture ऐसा react करता है मानो उसे texel-दर-texel lighting मिली हो
  • diffuse texture और normal map एक ही palette index share करते हैं, और इन्हें scikit-learn की K-means clustering से एक 6-channel image की तरह जोड़कर बनाया जाता है
  • building lighting में vertex RGB का ambient color, vertex alpha की sun visibility, grayscale irradiance map, और directional sunlight के dot(N, sun_dir) को मिलाया जाता है
  • directional diffuse lighting के लिए यह काफ़ी असरदार है, लेकिन shadows, point lights, accurate specular, और repeated textures वाले बड़े models में इसकी सीमाएँ बड़ी हैं, इसलिए preprocessing से इन कमियों को छिपाना पड़ता है

सिर्फ palette update करके shading

  • Nintendo 64 डेमो Revision 2025 के लिए बनाया गया था, और इसमें baked lighting, normal mapping, और real-time specular shading जैसे effects के क़रीब पहुँचने वाली तकनीकें इस्तेमाल की गईं
  • N64 पर normal mapping की संभावना पहले के homebrew experiments से पता चल चुकी थी, और इस डेमो ने runtime पर texture नहीं बल्कि lighting result palette calculate करने का रास्ता चुना
  • dedicated hardware support के बिना भी CPU पर मनचाहा shading code चलाया जा सकता है, लेकिन calculation speed धीमी होती है
  • palette texture में पूरे texel set के बजाय सिर्फ palette बदलने से भी पूरा texture ऐसा दिख सकता है जैसे उस पर lighting calculation लागू हुई हो
    • original palette को shaded palette से replace किया जाता है
    • palette texture को सामान्य texture की तरह object पर apply किया जाता है
    • सिर्फ simple diffuse light dot(N,L) से भी result काफ़ी अच्छा दिखता है
  • शुरुआती example में color texture की gamma correction हटाकर linear space में shading की गई थी, लेकिन final demo में ambient और direct light terms को अलग करके N64 की RDP unit में hardware से compose करना पड़ा, इसलिए इसे लागू नहीं किया जा सका

object-space normal mapping

  • सामान्य normal mapping tangent space में की जाती है
    • repeated textures इस्तेमाल किए जा सकते हैं
    • detail normals smooth बदलते vertex normals को correct कर सकते हैं
    • single-color tangent-space normal map smooth surface को दर्शाता है
  • object-space normals calculation को सरल बनाते हैं, लेकिन इनके साथ बड़ी सीमाएँ आती हैं
    • normal map के texel, vertex normal से deviation नहीं बल्कि absolute surface normal दिखाते हैं
    • runtime calculation texture से color पढ़ने जितनी simple हो जाती है
    • हर surface point के लिए lightmap की तरह unique texel चाहिए होता है

diffuse texture और normal map का shared palette

  • object में diffuse texture basecolor * ao और normal map दोनों होते हैं
  • दोनों textures एक ही palette index share करते हैं, और यह index scikit-learn की K-means clustering से generate किया जाता है
    • images को एक 6-channel image की तरह interpret किया जाता है
    • एक index से normal और surface diffuse color दोनों मिल जाते हैं
  • load के समय या हर frame पर palette colors पर iterate किया जाता है
    • CPU shader code हर index के लिए नया RGB color बनाता है
    • loop का result lighting-applied नया palette बन जाता है
  • यह approach व्यवहार में directional lighting के लिए सबसे बेहतर बैठती है
  • सिर्फ palette के सहारे shadows जैसे effects दिखाना मुश्किल है, इसलिए इसे baked lighting के साथ जोड़ना पड़ता है

baked directional ambient और sunlight

  • डेमो की buildings में ज़्यादा realistic lighting देने के लिए ambient और direct sunlight को अलग-अलग vertex colors में store किया गया है
    • vertex RGB: ambient color
    • vertex alpha: sun visibility
  • ambient term को directional intensity और color में बाँटा गया है
    • directional intensity एक grayscale irradiance map है
    • color, saturation बढ़ाया हुआ vertex RGB है
  • sun एक directional light है, और उसकी visibility vertex alpha से दी जाती है
  • shading formula इस प्रकार है
ambient = vertex_rgb      * grey_irradiance_map(N)
direct  = vertex_alpha    * sun_color * dot(N, sun_dir)
color   = diffuse_texture * (ambient + direct)
  • गंदे दिखने वाले sun-visibility vertex colors को N.L calculation mask कर देता है, इसलिए final direct light result में वे साफ़-सुथरे रूप में दिखते हैं
  • directional ambient की वजह से, baked lighting थोड़ी rough होने पर भी texture detail के कारण result high-end जैसा दिख सकता है
  • blurry environment map के लिए इसकी सादगी के कारण equirectangular projection इस्तेमाल किया गया
    • Polyhaven HDRI पहले से यही projection इस्तेमाल करता है
    • क्योंकि shading को load के समय पहले से precompute कर लिया गया था, इसलिए complex sampling math समस्या नहीं बनी

repeated textures वाले बड़े models को संभालना

  • original shading algorithm एक single object के लिए design किया गया था, और शुरुआत में इसे सिर्फ potato_rock.obj पर test किया गया था
  • डेमो के castle mesh में repeated textures हैं, जिससे समस्या पैदा हुई
  • workaround यह था कि बड़े mesh को कई submeshes में बाँट दिया जाए, और हर submesh conceptually वही object-space normal map share करे
    • Blender में material और surface direction के आधार पर geometry को manually group किया गया
    • हर group के polygon normals के आधार पर world-to-model matrix calculate की गई
    • यह matrix लगभग tangent space के क़रीब है
  • हर group palette share करता है, इसलिए overall lighting सिर्फ average sense में ही सही बैठती है
  • tangent space runtime पर interpolate नहीं होता, इसलिए यह face-by-face lighting जैसा दिखता है, और यही इस technique की सबसे बड़ी कमियों में से एक है

specular shading का approximation

  • क्योंकि कई surface points एक ही shading color share करते हैं, इसलिए point lights या specular shading को accurately calculate करना मुश्किल है
  • palette-space approach diffuse directional lighting के लिए उपयुक्त है, जहाँ to camera vector V की ज़रूरत नहीं होती
  • specular effect को object को sphere मानकर approximate करने की कोशिश की गई
    • shading point p को p = radius * normal माना जाता है
    • क्योंकि कई surface points एक ही palette index share करते हैं, result का blocky दिखना लगभग तय है
  • डेमो के specular highlights कुछ अजीब दिखते थे, लेकिन ज़्यादातर लोगों को धोखा देने लायक काम कर जाते हैं

सीमाएँ और संबंधित सामग्री

  • डेमो में मुख्य सीमाओं को preprocessing और scene composition से छिपाने की कोशिश की गई

    • lighting discontinuity और expression range

      • सिर्फ grayscale textures का support है
      • point lights नहीं हैं
      • यह technique तभी practical है जब preprocessing काफ़ी sophisticated हो
      • Spooky Iluha की technique में lighting discontinuity की समस्या नहीं है, लेकिन यह स्पष्ट नहीं है कि ambient और direct light दोनों को बनाए रखते हुए वही समस्या हल की जा सकती है या नहीं

    • ROM और पिछला research

      • PAL-compatible N64 ROM उपलब्ध है, लेकिन यह अक्सर crash हो जाता है
      • 4 जून 2025 के update में यह पुष्टि हुई कि 2003 का paper Real Time, Accurate, Multi-Featured Rendering of Bump Mapped Surfaces और उसका PDF Nvidia RIVA 128 के लिए इसी palette shading technique पर चर्चा करते हैं
      • उस paper में palette को हज़ारों colors तक इस्तेमाल किया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-19
Hacker News टिप्पणियाँ

  • N64 पर यथार्थवादी ग्राफिक्स देखना सचमुच प्रभावशाली है, और यह डेमो PS2 के "ICO" की याद दिलाता है
    बहुत पहले से सोचता रहा हूँ कि क्या N64 graphics hardware को abstract करके आधुनिक primitives, lighting, shading, और इस डेमो की तरह पहले से baked-in lighting देने वाले tools उपलब्ध कराने वाला कोई SDK बनाया जा सकता है
    N64 के पास अपनी पीढ़ी के हिसाब से काफी अनोखा hardware था, और विस्तार से जानकारी Copetti.org पर है: https://www.copetti.org/writings/consoles/nintendo-64/

    • N64 को SGI ने design किया था, और 3D graphics पर SGI के प्रभाव को देखते हुए मुझे तो लगता है कि N64 अपनी पीढ़ी में सबसे standard hardware के करीब रहा होगा
      अगर OpenGL library न होती तो मुझे बल्कि थोड़ी हैरानी होती
      हालांकि एक बड़ा caveat है: 1) इस system को CPU लगे graphics card की तरह देखना चाहिए और 2) graphics system सीधे expose किया गया है
      Graphics chip architecture आखिरकार अक्सर गंदी और आपस में incompatible अफरा-तफरी बन जाती है, इसलिए accelerator बनाने वाली कंपनियाँ आमतौर पर reference documents public करने के बजाय OpenGL, DirectX, CUDA, Vulkan जैसी intermediate APIs public करना पसंद करती हैं
      इससे वे internal implementation को लगातार incompatible structure में रख सकती हैं। Reference documents public न करने पर hardware backward compatibility निभाने की जरूरत भी नहीं रहती, फायदा यह कि नए designs बनाए जा सकते हैं, लेकिन नुकसान यह कि कोई भी इसे सीधे use करना मुश्किल पाता है
      इसलिए उस पीढ़ी के consoles की तरह direct access मिल जाए तो instinctively घबराहट होती है
      और जोड़ दूँ कि OpenGL SGI से आया था, और Nvidia की स्थापना भी पूर्व SGI engineers ने की थी
    • Shadow of the Colossus भी याद आता है: https://www.youtube.com/watch?v=xMKtYM8AzC8

  • मुझे अच्छा लगा कि N64 graphics tricks पर लेख आखिर में "Is this the future?" सवाल के साथ खत्म होता है

    • आजकल indie N64 development का scale अविश्वसनीय रूप से बड़ा हो गया है, और platform में नई जान आ गई है
      करीब दर्जनभर लोकप्रिय games को readable source files में decompile किया जा चुका है [1], जिससे emulator के बिना PC ports आसान हो गए हैं और original hardware पर चलने वाले ढेर सारे mods भी संभव हो गए हैं
      Zelda fan remakes भी कई हैं [2], और नए dungeons व story वाले पूर्ण games भी मौजूद हैं
      Mario 64 side खास तौर पर बहुत सक्रिय है; Kaze ने game को गहराई से optimize किया है [3] और अपना engine व sequel भी बना रहा है। अगर आपको retro tech deep dives पसंद हैं, तो उसका channel सचमुच खजाना है
      Portal जैसे पागलपन भरे demos भी आ रहे हैं [4], जिन्होंने दुर्भाग्य से Valve की legal team का ध्यान खींच लिया
      Rare का Dinosaur Planet जैसे lost games भी leak होने के बाद लगभग release-ready हालत तक polish किए जा रहे हैं, decompile हो रहे हैं और अपनी तरह का indie revival देख रहे हैं [5]
      [1] https://wiki.deco.mp/index.php/N64
      [2] https://m.youtube.com/watch?v=bZl8xKDUryI
      [3] https://m.youtube.com/channel/UCuvSqzfO_LV_QzHdmEj84SQ
      पूरा channel शानदार है, और ऐसे दर्जनों deep dives भी हैं: https://m.youtube.com/watch?v=DdXLpoNLywg
      उसके games और engine भी खूबसूरत हैं: https://youtu.be/Drame-4ufso
      [4] https://m.youtube.com/watch?v=yXzoZ2AfWwg
      [5] https://m.youtube.com/watch?v=s0QSiPRmWaI

  • हर बार यह देखकर हैरानी होती है कि ये game engineers कितने genius थे
    उन्होंने जबरदस्त constraints के बीच बेहद imaginative और शानदार solutions बनाए

    • Constraints असाधारण creativity की मांग भी करते हैं और उसे जन्म भी देते हैं
      pico8, Animal Well, और अनगिनत अद्भुत games का secret यही है
      काश इस weekend मुझे अपने 2D pixel art game maker maker के लिए कहीं बेहतर architecture का idea न आया होता। अब release में फिर एक महीना और लगने वाला है :(
    • यह N64 के peak दौर में इस्तेमाल की गई technique नहीं है, बल्कि नई बनी work है
    • उस समय के engineers भी कमाल के रहे होंगे, लेकिन जैसा लिखा है यह 2025 का काम है और game development से ज्यादा demoscene के करीब है

  • अब हमारे पास तेज systems हैं, यह सचमुच अच्छा है, लेकिन पुराने games में constraints को bypass करने का जो मज़ा था, और सही से कर लेने पर जो संतुष्टि मिलती थी, वह बहुत बड़ी थी
    HN readers raster interrupt(https://en.wikipedia.org/wiki/Raster_interrupt) और beam racing से परिचित होंगे। निजी तौर पर मैं इसे Atari 800 से जोड़कर सोचता आया हूँ
    असल में https://youtu.be/GuHqw_3A-vo?t=33 जैसा कुछ कर पाना संभव नहीं होना चाहिए था, लेकिन Display List Interrupts की वजह से यह संभव हुआ
    हाल तक मुझे पता नहीं था कि Atari 2600 games इस तरह के पागलपन पर कितने अधिक निर्भर थे: https://www.youtube.com/watch?v=sJFnWZH5FXc
    ऐसी चीजें देखकर लगता है कि hardware progress रुक भी जाए, तो भी हम दशकों तक लगातार और दिलचस्प चीजें खोजते रह सकते हैं

  • डेमोसीन और इस तरह का काम प्रभावशाली है, लेकिन अक्सर यह ज़्यादा सरल और खाली-से scenes की ओर जाता दिखता है
    यह उन चीज़ों के ज्यादा करीब है जो game background या game mechanics के हिस्से के तौर पर फिट हो सकती हैं। ज़्यादातर techniques में ऐसा लगता है कि पूरा experience बनाने के लिए resources पर्याप्त नहीं हैं
    ज़्यादा प्रभावशाली काम तो FastDoom या कई Mario 64 optimization projects जैसा है, जो पुराने hardware से कहीं बेहतर performance निकालते हैं
    कभी-कभी वे content और features जोड़ते हुए भी ऐसा करते हैं। मुझे यह भी उत्सुकता है कि demoscene developers और ऐसे ज़्यादा व्यापक कामों के बीच कोई connection है या नहीं

  • 90s के shareware games में इसी तरह की palette-based lighting technique इस्तेमाल होती थी
    मूल रूप से VGA 256-color palette बनाते समय, supported हर color के लिए उस color की N-step brightness gradient पहले से डाल दी जाती थी
    फिर सिर्फ color index जोड़ने या घटाने से हर color की brightness आसानी से बदली जा सकती थी

  • PS1 और PS2 दौर की optimization याद आती है
    इनमें से ज़्यादातर को emulation के जरिए 1080p या 4K से ऊपर तक upscale करके देखें तो वे सचमुच शानदार लगते हैं। निजी तौर पर मुझे लगता है कि Halo 2 era graphics को 4K में देखना ही काफी है
    बेशक Halo 2 एक Xbox game है, लेकिन Halo MCC में Halo 2 को classic graphics के साथ खेलें तो आज भी हैरान कर देता है
    GT3 का heat haze effect इसे अच्छी तरह समेट देता है
    "GT3 demo में Seattle course को sunset के समय दिखाया गया था, और जमीन से गर्मी उठते हुए लहराती दिखती थी। PS3 पर उस heat haze effect को reproduce नहीं किया जा सकता। क्योंकि read-modify-write उतना तेज़ नहीं है जितना PS2 इस्तेमाल करते समय था। ऐसी चीज़ें होती हैं।"
    https://old.reddit.com/r/ps2/comments/1cktw88/gran_turismos_...
    https://youtu.be/ybi9SdroCTA?t=4103
    यह UE5 जैसे नए engines की तरह असली heat wave emulate करने की कोशिश नहीं थी, बल्कि frame rate को बर्बाद न करने के लिए trick से किया गया था। सच कहूं तो RTX जिस तरह frame rate को काफी काट देता है, उसे देखते हुए मुझे ऐसे सस्ते tricks ज्यादा पसंद हैं
    299MHz MIPS यह चला रहा था
    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 (boot screen देखकर गला भर आया)
    Black, Renderware पागलपन वाला 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
    Jak and Daxter, Ratchet भी हैं
    GC की तरफ RE4, Metroid, Zelda games आदि तो जाहिर है बेहद शानदार दिखते हैं
    घुटने टेकने पर मजबूर कर देता है

    • PS2 के बारे में यह सही है, लेकिन PSX थोड़ा ambiguous है
      Pentium 90, लगभग 100 के आसपास वाले से इसकी टक्कर हो सकती थी, लेकिन 3DFX लगे MMX Pentium ने PSX को पछाड़ दिया होता और N64 के बराबर या उससे बेहतर रहा होता
      MIPS CPU शानदार है और कम clock पर भी हैरान करने वाले काम कर लेता है। PSP या SGI Irix को ही देख लें
      और PS2 का "GPU" R4k CPU जैसा नहीं है
      साथ में, PS2 का Deus Ex port PC version की तुलना में बहुत खराब था और Unreal engine को पूरी तरह संभाल नहीं पाया
      यह सही है कि PS2 ने पागलपन भरे effects निकाले, लेकिन उस port में levels सचमुच छोटे थे। यह भी ध्यान रखना चाहिए कि Deus Ex में game का बड़ा हिस्सा लगभग open world जैसा था
    • मुझे अभी भी लगता है कि Halo 3 कुछ modern games से कहीं बेहतर दिखता है
      blur, bloom, घास और vegetation का pop-in जैसी चीज़ें सच में अच्छी नहीं लगतीं, और सब बंद कर देने से भी ज्यादा खराब दिखती हैं
      तेज़ रफ्तार first-person shooter में high-polygon models को निहारने का समय ही नहीं मिलता, तो उसका मतलब भी क्या है, समझ नहीं आता
      मेरी नजर में Halo 3 texture resolution पर्याप्त है। textures का size 2x या 4x भी हो जाए तो शायद मुझे पता न चले, और जो चीज़ दिखेगी वह सिर्फ hardware requirements होंगी
    • "299MHz MIPS यह चला रहा था" बात कुछ हद तक ही सही है
      GoW2 video PCSX2 में capture किया गया है, और उस clip में संभव है कि upscaling और दूसरे convenience features का फायदा मिला हो
      बाकी videos मैंने सब नहीं देखे, लेकिन जो भी हो, GoW2 ने PS2 पर जो हासिल किया वह शानदार था