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

 (30fps.net)
2 पॉइंट द्वारा GN⁺ 2025-05-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह लेख Nintendo 64 demo development process में लागू की गई palette-आधारित lighting और normal mapping तकनीकों की व्याख्या करता है
  • texture पर सीधे तुरंत lighting लागू करने के बजाय, केवल palette बदलकर पूरे texture पर lighting effect देने की विधि प्रस्तुत करता है
  • diffuse/normal palette compression और object-space normal mapping जैसी विभिन्न optimization techniques का उपयोग किया गया है
  • यह तरीका directional lighting तक सीमित होने पर प्रभावी है, और shading discontinuity जैसी कमियाँ मौजूद हैं
  • demo में specular/direct/ambient जैसे कई तत्वों को रचनात्मक रूप से जोड़कर N64 की सीमाओं के भीतर प्रभावशाली visuals दिखाए गए हैं

परिचय और लक्ष्य

  • यह लेख Bluesky पर शुरू हुए thread का विस्तार है, जिसमें Nintendo 64 के लिए बने demo (Revision 2025) में उपयोग की गई उन्नत lighting techniques साझा की गई हैं
  • demo में specular के साथ normal mapping, real-time reflective lighting जैसे कई effects शामिल हैं, और संगीत noby ने तैयार किया है, जबकि Moloko ने guitar बजाया है

Nintendo 64 पर normal mapping की संभावना

  • WadeTyhon और Spooky Iluha जैसे homebrew developers के experiments का संदर्भ लेकर N64 पर normal mapping लागू करने की संभावना की जाँच की गई
  • बुनियादी तरीका runtime पर CPU से texture पर सीधे lighting की गणना करना है
  • hardware support के बिना CPU पर custom shading code चलाया जा सकता है, लेकिन speed गिरने की समस्या बड़ी है

palette-आधारित shading

  • texture space shading सीधे लागू करने के बजाय, palette texture के palette data को ही update करने पर पूरा texture real-time में brightness बदलाव दिखाता है
  • N64 में palette textures का उपयोग आम है, इसलिए यह तरीका व्यापक रूप से इस्तेमाल किया जा सकता है
  • सिर्फ palette update करने से भी हर texel पर मानो असली lighting लागू हुई हो, ऐसा effect तुरंत दिखता है
  • मूल palette को shading लागू किए गए palette से बदल दिया जाता है, और मौजूदा palette texture को object पर सामान्य texture की तरह map किया जाता है
  • केवल diffuse (dot(N,L)) lighting लागू करने पर भी काफी शानदार परिणाम मिलते हैं

object-space normal mapping

  • सामान्यतः normal mapping tangent space में की जाती है, जो tiled textures के support और प्राकृतिक surface correction के लिए उपयुक्त है
  • object-space normal map में हर texel के पास सटीक surface normal की जानकारी होती है, इसलिए गणना सरल होती है, लेकिन tiled texture का उपयोग कठिन हो जाता है
  • high-resolution normal map को 32-color palette में compress करने पर भी मूल जैसी विशेषताएँ बरकरार रखी जा सकती हैं

diffuse और normals के लिए shared palette design

  • object के पास diffuse texture (basecolor * ao) और normal map होता है
  • दोनों textures को K-means clustering algorithm से बने एक ही palette index को साझा करने के लिए तैयार किया जाता है
  • image को 6-channel image मानकर clustering की जाती है
  • उदाहरण में RGB diffuse + normal map को 16-color palette में compress किया गया है, इसलिए image data में केवल 4bpp लिखना पर्याप्त है
  • shading के समय, हर palette color के लिए normal और surface color information को index से lookup करके नया RGB color बनाया जाता है
  • यह तरीका केवल directional light को ठीक से support कर सकता है, और सिर्फ palette के आधार पर shadow लागू करना कठिन है

baked directional ambient/sunlight

  • इमारतों में यथार्थवादी lighting लागू करने के लिए vertex color के RGB और alpha channel का उपयोग क्रमशः ambient और sunlight के लिए किया गया है

  • ambient को directional intensity (grayscale environment map) और color (RGB, saturation बढ़ाकर) में अलग किया गया है

  • direct sunlight को vertex alpha में रखा गया है

  • मूल lighting formula नीचे दिया गया है

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

  • ये सभी terms मिलकर अंतिम color बनाते हैं

  • directional ambient lighting भरपूर प्राकृतिक प्रकाश जैसा प्रभाव देती है, और palette-आधारित होने के बावजूद उच्च-गुणवत्ता वाली texture feel पैदा करती है

  • सरलता के लिए environment map में equirectangular projection का उपयोग किया गया है

tiled textures वाले बड़े model की shading

  • शुरुआती algorithm एक single object के लिए था, और बड़े castle mesh में tiled textures के कारण समस्या आई
  • समाधान के लिए Blender का उपयोग कर surface direction/material के आधार पर mesh को submesh units में बाँटा गया
  • कंप्यूटर प्रत्येक group के लिए polygon normal का उपयोग कर world-to-model matrix निकालता है (एक तरह का approximate tangent space)
  • हर group एक palette साझा करता है, इसलिए कुल मिलाकर औसत lighting quality बनी रहती है
  • runtime पर tangent space interpolate न होने से तराशे हुए face जैसी lighting दिखाई देने की कमी रहती है

specular shading

  • कई surface points एक ही palette color साझा करते हैं, इसलिए सटीक point light/specular shading संभव नहीं है
  • palette-space technique directional diffuse lighting तक ही कुशल है
  • फिर भी spherical object मानकर, हर point को p = radius * normal से approximate करके specular highlight effect को किसी तरह लागू किया गया है
  • परिणाम कुछ हद तक discontinuous है, लेकिन gameplay के दौरान यह काफी स्वाभाविक महसूस हो सकता है

सीमाएँ और भविष्य

  • demo में shading discontinuity, केवल grayscale textures का support, point light support का अभाव जैसी सीमाओं को यथासंभव छिपाया गया है

  • elaborate preprocessing अनिवार्य है

  • shading discontinuity के बिना ambient/direct दोनों lighting को support करने का तरीका अब भी एक चुनौती है

  • प्रयोग के परिणामों के बारे में नई संभावनाओं और ideas की रोचकता पर जोर दिया गया है

  • PAL compatible N64 ROM फ़ाइल भी उपलब्ध कराई गई है। हालांकि, यह अस्थिर है और अक्सर crash हो जाती है

अन्य

  • लेखक पुस्तक लिखने पर भी विचार कर रहे हैं, और रुचि हो तो यहाँ अपडेट प्राप्त किए जा सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2025-05-19
Hacker News राय

  • N64 पर "realistic" ग्राफिक्स देखना वाकई बहुत प्रभावशाली अनुभव लगता है, और यह डेमो PS2 के "ICO" की याद दिलाता है। N64 ग्राफिक्स हार्डवेयर को abstract करके modern primitives, lighting, shading, baked lighting tools आदि देने वाला कोई SDK बनाया जा सकता है या नहीं, इस पर जिज्ञासा जताई गई। साथ ही यह भी कहा गया कि N64 हार्डवेयर की अपनी पीढ़ी के लिए एक अनोखी संरचना थी, और विस्तृत हार्डवेयर जानकारी का लिंक साझा किया गया

    • N64 को SGI ने डिज़ाइन किया था, और SGI ने 3D ग्राफिक्स पर कितना असर डाला यह भी बताया गया। अनुमान है कि N64 शायद अपनी पीढ़ी का सबसे standard हार्डवेयर था। बल्कि अगर उसमें OpenGL लाइब्रेरी न हो तो यह हैरानी की बात होगी। कमी यह बताई गई कि इस console को graphics card पर CPU जोड़कर बने सिस्टम की तरह समझना चाहिए, और graphics system सीधे expose होता है। graphics chip architectures एक-दूसरे से compatible नहीं होते, और कंपनियाँ ऐसे आंतरिक ढाँचे को सार्वजनिक करने से बचती हैं; वे सिर्फ API (OpenGL, DirectX आदि) देती हैं ताकि रचनात्मक डिज़ाइन संभव हो, लेकिन hardware तक सीधी पहुँच बहुत कठिन रहती है। अतिरिक्त जानकारी के रूप में बताया गया कि OpenGL की शुरुआत SGI से हुई थी, और nvidia भी SGI के पूर्व कर्मचारियों ने स्थापित की थी

    • "Shadow of the Colossus..." का ज़िक्र करते हुए संबंधित YouTube लिंक साझा किया गया

  • यह बात पसंद आई कि N64 graphics tricks पर लेख का अंत "क्या यही भविष्य है?" जैसे सवाल से होता है

    • आजकल indie N64 development में जबरदस्त ऊर्जा है। कई लोकप्रिय गेम decompile होकर source code के रूप में उपलब्ध हो चुके हैं, जिससे PC port बनाना आसान हुआ है, और hardware पर चलने वाले कई तरह के mods भी बन रहे हैं। Zelda fan remake, नए dungeon और story वाले पूर्ण गेम, Mario 64 community की सक्रिय technical optimization, Kaze नाम के व्यक्ति का अपना engine बनाना और sequel तैयार करना, तथा technical deep-dive videos की सिफारिश—इन सबका ज़िक्र हुआ। Portal जैसे हैरतअंगेज़ demos बनने और Valve की कानूनी दिलचस्पी की कहानी भी आई। Rare की अप्रकाशित कृति Dinosaur Planet जैसी चीज़ें leak होने के बाद decompile और restore की गईं, और फिर से indie scene में जीवित हो उठीं—ऐसा विस्तार से कई links के साथ बताया गया

  • सीमित hardware पर रचनात्मक समाधान निकालने वाले game engineers की प्रतिभा पर गहरा सम्मान व्यक्त किया गया

    • यह सिद्धांत साझा किया गया कि सबसे बड़ी रचनात्मकता अक्सर constraints के भीतर ही निकलती है। pico8, Animal Well और कई प्रभावशाली games का रहस्य भी यही है। इस सप्ताहांत अपने बनाए 2d-pixel-art-game-maker-maker की architecture में बड़ा सुधार करने का विचार आने से release फिर एक महीने टल जाएगा, इस पर हल्की निराशा भी जताई गई

    • यह स्पष्ट किया गया कि यहाँ दिखाया गया काम N64 के स्वर्णकाल का नहीं, बल्कि हाल में बना नया काम है

    • यह भी बताया गया कि यह उस दौर के N64 developers का काम नहीं, बल्कि 2025 के demoscene से जुड़ी नई तकनीक है

  • अब तेज़ systems आ जाने से सुविधा है, लेकिन पुराने games में सीमाएँ तोड़ने का आनंद और उसे सच में कर दिखाने की संतुष्टि कुछ अलग थी—ऐसी याद साझा की गई। कहा गया कि Hacker News के पाठकों को 'raster interrupts' और 'racing the beam' जैसी अवधारणाएँ परिचित होंगी। Atari 800 पर ऐसी तकनीकों से असंभव लगने वाली चीज़ें संभव की गई थीं, ऐसा एक अनुभव बताया गया। हाल ही में पता चला कि Atari 2600 games भी इस तरह की पागलपन भरी तकनीकों से बहुत प्रभावित थे, और इस पर YouTube सामग्री साझा की गई। यह भरोसा भी जताया गया कि अगर hardware प्रगति रुक भी जाए, तब भी हम दशकों तक नए और दिलचस्प tricks खोजते रहेंगे

  • 90 के दशक में palette-based lighting technique को अपने shareware game में इस्तेमाल करने का अनुभव याद किया गया। VGA 256-color palette को इस तरह व्यवस्थित किया गया था कि हर रंग के कई क्रमिक brightness स्तर हों, और सिर्फ color index को जोड़-घटाकर आसानी से lighting effect बनाया जा सकता था

  • demoscene और इस तरह के काम बेहद प्रभावशाली हैं, लेकिन यह भी देखा गया कि वे अक्सर सरल और खाली scenes तक सीमित रह जाते हैं। विश्लेषण यह था कि ऐसी techniques आम तौर पर background या सीमित gameplay features के लिए ही उपयुक्त लगती हैं। FastDoom या Mario-64 optimization projects की तरह पुराने hardware पर performance बहुत बढ़ाकर content और features भी जोड़ने वाली कोशिशें कहीं ज़्यादा प्रभावशाली लगती हैं। ऐसा भी सोचा गया कि demoscene और इन अधिक पूर्ण परियोजनाओं के बीच शायद कोई संबंध हो सकता है

  • PS1 और PS2 दौर की optimization techniques को याद किया गया। कहा गया कि ज़्यादातर games आज emulation के जरिए 1080p या 4k से ऊपर upscale करने पर भी शानदार दिखते हैं। एक राय यह थी कि Halo 2 का 4k graphics ही काफ़ी है, और GT3 में बनाए गए वास्तविक 'heat haze' effect का उदाहरण देते हुए एक निर्माता की टिप्पणी उद्धृत की गई कि PS3 पर उसे PS2 जितनी तेजी से लागू नहीं किया जा सकता। आज के UE5 जैसे engine वाले realistic heat haze की बजाय, performance पर कम भार डालने वाले पुराने tricks ज़्यादा अच्छे लगते हैं। RTX इस्तेमाल करके frame drop झेलने से बेहतर वे पुराने tricks बताए गए। 299MHz MIPS CPU पर Shadow of the Colossus, GoW2, FFXII, GT4, Black, Valkyrie Profile 2, Rouge Galaxy, Burnout 3, Jak and Daxter, Ratchet जैसे बड़े games का चलना, और GameCube पर RE4, Metroid, Zelda जैसे games का चलना—इन सबका उल्लेख करते हुए पारंपरिक game developers की क्षमता के प्रति सम्मान व्यक्त किया गया

    • यह इंगित किया गया कि GoW2 का वीडियो PCSX2 emulator से capture किया गया था, इसलिए उसमें upscale और अन्य enhancement effects शामिल रहे होंगे। फिर भी PS2 पर GoW2 एक बहुत बड़ी उपलब्धि थी

    • PS2 के बारे में सहमति जताई गई, लेकिन PS1 के बारे में कहा गया कि उसकी performance बस ठीक-ठाक थी। राय यह थी कि PSX की क्षमता Pentium 90~100 जैसी थी, लेकिन MMX Pentium पर 3DFX जोड़ने से N64 जैसी या उससे बेहतर क्षमता मिल जाती थी। कम clock पर भी MIPS CPU अच्छे performance दे सकता है—इसके उदाहरण के रूप में PSP, SGI Irix और PS2 का ज़िक्र हुआ। यह भी बताया गया कि PS2 का GPU, R4k CPU से अलग था। PS2 पर Deus Ex port, PC संस्करण की तुलना में कमजोर था और Unreal engine को पूरी तरह संभाल नहीं पाया—ऐसा वास्तविक अनुभव साझा किया गया। PS2 ने अद्भुत special effects ज़रूर दिखाए, लेकिन Deus Ex जैसे ports में map size बहुत छोटा था—यह पृष्ठभूमि भी जोड़ी गई

    • यह निजी राय भी रखी गई कि Halo 3 के graphics कई आधुनिक games से बेहतर लगते हैं। blur, bloom, घास-पत्तों के उछलने जैसे आधुनिक effects कभी-कभी दृश्य अनुभव को और खराब कर देते हैं। तेज़ FPS genre में बहुत सूक्ष्म polygon count का विशेष महत्व नहीं लगता, और texture resolution भी बस पर्याप्त होना चाहिए। व्यावहारिक रूप से जो चीज़ सबसे ज़्यादा महसूस होती है, वह सिर्फ hardware requirement है—ऐसा व्यक्तिगत अनुभव साझा किया गया