ग्राफ़िक्स प्रोग्रामर बनने के लिए क्या सीखना चाहिए

 (blog.demofox.org)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • रीयल-टाइम ग्राफ़िक्स में नौकरी के लिए CPU-साइड explicit graphics API और GPU-साइड lighting·shading दोनों की क्षमता चाहिए होती है, और दोनों क्षेत्रों को एक साथ गहराई से सीखना कठिन है
  • CPU-साइड में DirectX12, Vulkan, Metal जैसे आधुनिक API और asset loading·engine support कार्य आते हैं, जबकि GPU-साइड में shadows, ambient occlusion, post-processing, और GPU performance characteristics शामिल होते हैं
  • GPU सीखने का केंद्र path tracer लिखना और PBR को समझना है; शुरुआत के लिए Ray Tracing in One Weekend, LearnOpenGL PBR, Filament documentation, और PBRT उपयोगी हो सकते हैं
  • पोर्टफोलियो में C++ आधारित रीयल-टाइम renderer, फोटो जैसी इमेज बनाने वाला path tracer, और दोनों rendering outputs की तुलना·validation करने वाला code होना आदर्श है
  • ज़रूरी गणित में linear algebra, basic trigonometry, और थोड़ा calculus मुख्य हैं; game development के CPU-साइड की भाषा C++ है, और shader language के रूप में HLSL सबसे आम है

रीयल-टाइम ग्राफ़िक्स CPU और GPU, दोनों क्षेत्रों को साथ संभालता है

  • आधुनिक rendering वास्तव में लगभग दो तरह के कामों का संयोजन है
    • CPU-साइड सीखना: DirectX12, Vulkan, Metal जैसे आधुनिक explicit API, asset loading, और अन्य support कार्यों के लिए engine programming
    • GPU-साइड सीखना: आधुनिक lighting·shading math, shadows, ambient occlusion, post-processing effects, और GPU पर कौन-से काम तेज़ या धीमे होते हैं
  • दोनों क्षेत्रों को एक साथ सीखना बहुत कठिन है
    • अगर GPU-साइड पर ध्यान देना हो, तो OpenGL, WebGL, DirectX11, या मौजूदा engines जैसे ऐसे tools इस्तेमाल किए जा सकते हैं जिनमें CPU-साइड का बोझ कम हो
    • अगर CPU-साइड पर ध्यान देना हो, तो पहले स्क्रीन पर triangle दिखाने से शुरू करें, फिर mesh दिखाएँ; आउटपुट कितना सुंदर है, इस पर बहुत ध्यान देना ज़रूरी नहीं

path tracing और PBR

  • GPU-साइड सीखने में path tracer लिखना शामिल है
    • Path tracing वह तरीका है जो फ़िल्म rendering में इस्तेमाल होता है, और आधुनिक रीयल-टाइम rendering techniques उसी का approximation करने की कोशिश करती हैं
    • शुरुआत के लिए मुफ़्त online book Ray Tracing in One Weekend उपयुक्त है; यह काफ़ी सुलभ है और फोटो जैसी rendering बनाने की प्रक्रिया दिखाती है
  • Physically Based Rendering(PBR) lighting, खासकर specular लागू करने के तरीके से जुड़ा है
    • PBR एक principle-based approach है, जिसमें नियमों का पालन करने पर अच्छे परिणाम मिलते हैं
    • PBR से पहले lighting के लिए अक्सर मनमाने formulas, tweaks, और hacks इस्तेमाल किए जाते थे, इसलिए जो asset एक lighting environment में अच्छा दिखता था, वही दूसरे environment में बहुत अँधेरा या बहुत चमकीला लग सकता था
    • नतीजतन, अलग-अलग lighting conditions के लिए asset के अलग versions बनाने पड़ते थे, जिससे बहुत समय और मेहनत लगती थी
  • PBR assets को कई lighting conditions में अधिक consistent दिखाने में मदद करता है, और version-wise asset production पर लगने वाला समय व मेहनत कम करता है
    • फिर भी asset creation का समय, लागत, और मेहनत आज भी game development का बड़ा bottleneck है

सुझाए गए learning resources

  • PBR की शुरुआत के लिए LearnOpenGL का PBR Theory सेक्शन और उसके subsections उपयुक्त हैं
  • और गहराई में जाने के लिए Filament documentation अगला चरण हो सकता है
    • PBR को जितनी गहराई से पढ़ेंगे, उतना ही calculus और statistics ज़्यादा सामने आएँगे
  • इसके आगे मुफ़्त online book Physically Based Rendering: From Theory To Implementation उपलब्ध है
  • machine learning से अभी उतने नतीजे मिलने की संभावना नहीं दिखती जितना उसके hype में कहा जाता है, लेकिन computer science के toolbox में fitting और optimization techniques सीखना फिर भी मूल्यवान है

पोर्टफोलियो में दिखाने लायक code

  • hiring manager को अपना ज्ञान साबित करने के लिए GitHub जैसी जगह पर share किया जा सकने वाला source code रखना और उसे resume से लिंक करना आदर्श है
  • उदाहरण पोर्टफोलियो:
    • एक engine-style renderer जो model और texture जैसे assets लोड करे और उन्हें स्क्रीन पर रीयल-टाइम render करे
      • इसमें lighting, shadows, depth of field, area lights, tone mapping, ray traced shadows जैसे कुछ effects शामिल हों
      • यदि संभव हो तो PBR-based lighting, user-controlled camera, DX12·Vulkan जैसे API, और C++ का उपयोग करें
    • एक path tracer जो फोटो जैसी images तैयार करे
      • यदि संभव हो तो C++ बेहतर है, लेकिन यह बिना window वाला सिर्फ PNG output देने वाला program भी हो सकता है
      • इसका रीयल-टाइम होना ज़रूरी नहीं है
    • यदि path tracer, engine-style renderer का अलग mode हो, तो और भी बेहतर है
      • इससे path traced result और रीयल-टाइम PBR rendering की तुलना करके accuracy validate की जा सकती है
      • अगर आप यह दिखा सकें कि दोनों renderings कहाँ मेल नहीं खातीं, क्यों अलग हैं, और रीयल-टाइम बनाए रखते हुए उन्हें और करीब कैसे लाया जा सकता है, तो इसका और अधिक अच्छा मूल्यांकन होगा

गणित, algorithms, और language selection

  • ऊपर की चीज़ें खुद करके देखने पर ज़रूरी गणित से स्वाभाविक रूप से सामना हो जाता है
    • मूल रूप से ज़रूरी चीज़ें हैं linear algebra में matrix multiplication, cross product, dot product, basic trigonometry, और थोड़ा calculus
    • graphics और game development में न्यूनतम आवश्यक गणित अपेक्षाकृत कम है, लेकिन उपयोगी गणित की सीमा लगभग असीम है
  • algorithms के साथ भी कुछ ऐसा ही है
    • linked list, hash table, sorting, searching जैसे बुनियादी abstract data types और algorithms जानना ज़रूरी है
    • सबसे तेज़ algorithms कई बार साधारण होते हैं, और array, linked list की तुलना में बहुत तेज़ होती है
    • अधिक advanced algorithm concepts तब मदद करते हैं जब सचमुच किसी नए और customized समाधान की ज़रूरत हो
  • game development में सीखने लायक भाषा C++ है
    • कुछ लोग Rust भी इस्तेमाल करते हैं और उसका कुछ हिस्सा है, लेकिन यह वह standard language नहीं है जिसकी आम तौर पर अपेक्षा की जाती है
    • WebGPU में WebGL की तुलना में कई अतिरिक्त features हैं और यह एक अधिक गंभीर platform बन रहा है, जिससे CPU-साइड का काम JavaScript में किया जा सकता है
    • लेकिन WebGPU jobs और web पर WebGPU content अभी बहुत अधिक देखने को नहीं मिला है
  • shader language के रूप में HLSL सबसे आम है
    • कुछ लोग GLSL का उपयोग करते हैं
    • multi-platform games में कई बार shaders को दूसरी shader languages में translate किया जाता है

LLM और ML के उपयोग की सीमा

  • अभी की ML technology को बेचने के लिए बताए जाने वाले अधिकांश use cases के लिए पर्याप्त नहीं माना गया है
  • Claude से गणित, papers, और unfamiliar algorithms पर बात करने में मदद मिल सकती है
    • ऐसे मामलों में यह जाँचना आसान होता है कि वह बातें गढ़ रहा है या नहीं, और दूसरी sources से उसकी validity cross-check करना भी आसान है
  • programming में यह बहुत उपयोगी नहीं है
    • चाहे यह आपकी इच्छा के अनुसार चलने वाला code दे भी दे, उस code को समझने में आपको समय लगाना ही पड़ेगा
    • ऐसे में सीधे खुद लिखना बेहतर माना गया है
  • छोटे उपयोगों में यह काम आ सकता है
    • उदाहरण के लिए, अगर पूछा जाए “क्या इस file में bug दिख रहा है?”, तो yes मिलने पर उसकी जाँच की जा सकती है, और no मिलने पर भी पूछने की लागत लगभग नहीं के बराबर होती है
  • यह माना गया है कि कभी न कभी मानवता human-level intelligence बनाएगी और उससे भी आगे जाएगी, लेकिन यह अपने जीवनकाल में होगा या नहीं, यह कहना कठिन है
    • मौजूदा LLM युग को बाद में आने वाली “वास्तविक” चीज़ के लिए एक तरह की rehearsal के रूप में देखा जा सकता है

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • पहले यह अलग करना ज़रूरी है कि आप गेम बनाना चाहते हैं, या 3D इंजन प्रोग्रामिंग करना चाहते हैं
    अगर आप गेम बनाना चाहते हैं, तो Unreal Engine, Unity, Godot, Bevy जैसे मौजूदा engines का इस्तेमाल करना बेहतर है, और तब आप pixels को सीधे push करना सीखने के बजाय graphics के higher-level issues सीखेंगे। असली मुश्किल चीज़ उसे मज़ेदार बनाना है
    अगर आप 3D इंजन बनाना चाहते हैं, तो यह जानना चाहिए कि खराब game engines पहले से ही बहुत ज़्यादा हैं। सिर्फ Rust ecosystem में भी 3 failed renderers, 1 incomplete renderer, और Bevy के अंदर का renderer मुख्य projects हैं, और “मैं game engine बनाऊँगा” जैसे projects तो उससे भी ज़्यादा हैं। सिर्फ “पहला renderer” स्तर तक पहुँचने में भी लगभग 2 साल लग जाते हैं, और बड़े, detailed, dynamic scenes तक पहुँचना उससे कहीं बड़ा काम है
    अगर लक्ष्य नौकरी पाना है, तो game industry में न salary अच्छी होती है न working hours, project खत्म होते ही नौकरी भी खत्म हो सकती है, और Hollywood की तरह अंदर आने की चाह रखने वाले लोगों की भीड़ लगी रहती है। ऊपर से Metaverse collapse की वजह से अभी experienced लोगों की भी oversupply है
    मोबाइल में display, compute performance, GPU, battery सबकी कमी होती है, इसलिए यह compression का काम है, और इसी वजह से आजकल ज़्यादातर indie games 2D हैं। वही अपेक्षाकृत संभव है, और अक्सर HTML/JavaScript में भी बनाए जाते हैं

    • लगता है कि यह मान लिया गया है कि ज़्यादातर लोग Unreal के साथ visual competition करना चाहते हैं, और वह तो स्वाभाविक रूप से लगभग असंभव है
      लेकिन एक basic renderer और game loop बनाना इतना मुश्किल नहीं है, और संभव है कि वह game code का बड़ा हिस्सा भी न हो। किसी simple game के लिए for loop में सिर्फ drawObject() करना भी काफी हो सकता है, और resource streaming, binding optimization, parallelism जैसी चिंताओं की ज़रूरत बाद में पड़ने पर ही होती है
      “पहले renderer तक 2 साल” वाला मानदंड किस starting point और किस success condition को मानकर कहा गया है, यह जानने की उत्सुकता है। लगभग 1 साल पहले मैंने free time के 1 महीने में, full-time हिसाब से 1 हफ्ते से भी कम समय के बराबर मेहनत में dynamic lighting, shadow mapping, और कुछ post-processing वाला deferred renderer बनाया था
      2D को कमतर देखने की भी कोई वजह नहीं है। काफी गंभीर काम 2D interfaces में होता है, और WebGL तथा पुराने 2D canvas भी आजकल काफ़ी powerful हैं। हिट हुए indie games में भी 2D बहुत हैं
      यह सही है कि game industry बहुत अच्छी नहीं है, लेकिन आजकल लगभग हर चीज़ GPU इस्तेमाल करती है। machine learning workloads लिखने और debug करने, data visualization, HUD, और सामान्य user interface में भी अक्सर graphics की समझ की ज़रूरत पड़ती है
    • game industry का औसत भले अच्छा न हो, लेकिन मुझे नहीं लगता कि graphics programming जैसी niche पर यह लागू होता है
      games के अलावा visualization, simulation जैसी graphics इस्तेमाल करने वाली बहुत-सी fields हैं, और अच्छे graphics programmers बेहद दुर्लभ हैं, इसलिए यह उम्मीद से बेहतर career हो सकता है। यह इस बात के काफी विपरीत है कि game developers या artists के लिए अच्छी नौकरियाँ पाना अधिक कठिन लगता है। हाँ, demand और supply दोनों छोटे हैं, इसलिए job switch करना आसान न हो
      अगर सिर्फ job stability देखनी हो तो मैं game development को career बनाने से मना करूँगा, लेकिन graphics programming अलग है
    • यह अफ़सोस की बात है कि Unity या Unreal Engine की वजह से मूल रूप से अच्छे games भी performance issues झेलते हैं। काश इन्हें इतनी आसानी से recommend न किया जाता; Godot और Bevy बेहतर हैं या नहीं, यह अभी पता नहीं
      पिछले कुछ सालों में जो games मैंने खेले, उनमें Core Keeper (Unity), WORMHOLE (Unity, खासकर endless mode में lag), Crab Champions (UE4, 1920x1200 पर 60fps बनाए रखने के लिए screen को बदसूरत बनाने वाली upscaling इस्तेमाल करनी पड़ती है) में performance issues गंभीर थे
      दूसरी ओर Terraria, Necesse, Barony अपने खुद के engines इस्तेमाल करते हैं और शानदार चलते हैं, और जितने पुराने होते जाते हैं, उतने बेहतर लगते हैं
      निष्पक्षता से कहूँ तो Tiny Rogues (Unity) मेरी याद के अनुसार ज़्यादातर ठीक चला था, लेकिन developer आगे चलकर Unity छोड़ने पर काम कर रहा है, तो लगता है उसे भी खुद समस्या दिखी
      मैं game बनाने और engine बनाने के फर्क, और वास्तव में चीज़ को पूरा करके ship करने की अहमियत समझता हूँ, लेकिन अगर आप कूड़ा बाहर निकालेंगे तो अच्छा legacy छोड़ना मुश्किल है। मुझे लगता है कि लंबा रास्ता लेकर भी एक निश्चित quality level सुनिश्चित करना बेहतर है। games release के दशकों बाद तक भी खेले जाते हैं, और अगर उनमें bugs या lag है, तो लोग उसे लगातार झेलते रहेंगे
    • अगर आप engine बनाना शुरू करते हैं, खासकर सीखते हुए, तो बहुत संभव है कि आप game बना ही न पाएँ। तकनीकी रूप से दोनों में सफल होना संभव है, लेकिन मैंने खुद पहले यह झेला है और Poland की hobby game dev community में दर्जनों लोगों को देखकर कह सकता हूँ कि सफलता की संभावना 5% से कम के करीब थी
      “अगला game आसानी से बनाने के लिए पहले मैं अपने game के लिए engine बनाऊँगा” एक हैरान कर देने वाला मजबूत trap है। वजह यह है कि इसमें आप वास्तव में महत्वपूर्ण चीज़ें सीखते हैं और हर दिन छोटी-छोटी जीतें भी मिलती हैं। scene को smooth दिखाने के लिए एक और unroll कर लेते हैं, scene बनाना आसान हो इसलिए config format में एक और logical layer जोड़ देते हैं, या एक और SIGGRAPH paper पढ़ लेते हैं
      सुधारने लायक महत्वपूर्ण चीज़ें हमेशा होती हैं, लेकिन वे मिलकर एक finished game नहीं बनतीं। पीछे मुड़कर देखें तो अपना engine इस्तेमाल करना उस कठिन लेकिन ज़रूरी हिस्से—यानी “मज़ेदार बनाना”—को टालने का परफेक्ट तरीका है, जिसका सपना तकनीकी लोग अपने game के बारे में देखते हैं। आप प्रभावशाली video game code करने की skill तो सीख लेते हैं, लेकिन game बनाना नहीं सीखते
      इसका एक sub-trap भी है। आप real-time में smoothly चलने वाले सुंदर visual effects बनाना सौ तरीकों से सीख लेते हैं, लेकिन उनका उपयोग कला के रूप में करना नहीं सीखते
      यह “Enterprise Java” वाले trap से भी बहुत मिलता-जुलता है। बस यह और भी चालाक है, क्योंकि यह concrete terms से deal करता है। आपको लगता है कि आपके Scene Graph में Factory Factory Interface नहीं है, इसलिए आपने उस गोली से बचाव कर लिया, लेकिन असल में आप यह चूक जाते हैं कि screen पर bitmap दिखाने और key input पर प्रतिक्रिया देने के काम के लिए वही चीज़ अपने आप में अनावश्यक थी
    • अगर आप game बनाना चाहते हैं, तो हमेशा existing engine ही इस्तेमाल करना चाहिए—मैं इससे पूरी तरह सहमत नहीं हूँ। ज़्यादातर मामलों में यह अच्छी सलाह है, लेकिन existing engines बहुत ज़्यादा general-purpose होते हैं और game के बारे में बहुत-सी धारणाएँ रखते हैं। हो सकता है आपके game को अलग constraints चाहिए हों
      खासकर 2D में यह और सही है। उदाहरण के लिए, मैं अभी अपने self-made game engine से एक game बना रहा हूँ, जिसमें focus performance, compression, और server या database के बिना architecture पर है
      यह engine उन constraints के भीतर extreme performance और compression हासिल करने के लिए game structure के बारे में बहुत specific structure और assumptions रखता है, जिन्हें मैंने तय किया है। इस पर एक संबंधित Hacker News post मैं जल्द, संभव हो तो अगले हफ्ते डालने वाला हूँ
      पहले भी मैंने browser games को Unity, Godot, React में कई बार बनाने की कोशिश की, लेकिन APIs सीखना बहुत कष्टदायक था, और वे engines मेरे extreme constraints को पूरा नहीं कर पाए। बेशक इसमें मेरी भी कमी हो सकती है कि मैं उन engines को ठीक से इस्तेमाल नहीं कर पाया, लेकिन पीछे मुड़कर देखने पर भी मुझे लगता है कि जो मैंने अंदरूनी तौर पर हासिल किया, वह शुरू से बनाए गए custom engine के बिना संभव नहीं था
      अपना engine और game दोनों खुद बनाते हुए मैंने बहुत कुछ सीखा, और खासकर आजकल LLM की वजह से मुझे लगता है कि experienced developers के लिए अपना tailored game engine बनाकर देखना अचानक ज़्यादातर developers की पहुँच के भीतर एक यथार्थवादी दायरा बन गया है

  • अगर आज की बात हो, तो मैं किसी को भी graphics programming में आने की सलाह नहीं दूँगा
    मैंने 2001 में Nvidia के पहले GeForce 1, जिसे उस समय “Gigatexel shader card” कहा जाता था, के लॉन्च के आसपास शुरुआत की थी, और उसके बाद इस क्षेत्र की प्रगति और innovation की रफ्तार दिमाग घुमा देने वाली रही है। 25 साल पहले की तुलना में आज की तकनीक सचमुच अविश्वसनीय है
    लेकिन इस हैरानी के साथ एक बड़ा “लेकिन” भी है। यह क्षेत्र डराने वाली तेजी से आगे बढ़ रहा है। Nvidia अब scene और asset को प्रभावित करने वाले AI-आधारित effects भी ला चुका है, और उस समय तो यह कल्पना भी नहीं की जा सकती थी कि ऐसी चीजें real-time में संभव होंगी
    अब तो यह भी समझ नहीं आता कि इस क्षेत्र में “ठीक-ठाक expert” बनना भी संभव है या नहीं। दूसरे शब्दों में सवाल यह है: “आज का John Carmack कहाँ है?” वह hardware को आख़िरी सीमा तक निचोड़ने और community में छिपे ideas का इस्तेमाल करने के लिए मशहूर हुआ था, लेकिन आज ऐसे व्यक्ति के लिए कोई competitive moat दिखाई नहीं देता। क्षेत्र इतना व्यापक है और इतनी तेजी से बदलता है कि अगले Carmack बनने का मौका ही नहीं दिखता

    • मुझे यह रवैया सच में पसंद नहीं कि कोई खुद किसी क्षेत्र में आने के बाद दूसरों को मना करे। “मेरी तरह मत बनो, मैंने अपनी ज़िंदगी बर्बाद कर दी” जैसी बात ज़्यादा तर एक थके और passion खो चुके व्यक्ति की बकवास लगती है, और graphics programming से दूर रहने को कहना कल के John Carmack को आकर्षित करने का तरीका नहीं है
      एक दूसरा नज़रिया भी है। अगर आपने अब तक सिर्फ web apps और Kubernetes पर काम किया है, तो उल्टा graphics programming आज़माना अच्छा हो सकता है। इसका feedback loop बहुत रोमांचक है, और इससे महसूस होता है कि एक साधारण computer कितनी बेहिसाब तेजी से काम कर सकता है। आखिर में अगर आप ऐसी optimization भी करने लगें जो बहुत मायने नहीं रखती, तब भी इसका मूल्य है, क्योंकि आपने निचले स्तर पर चीज़ें कितनी तेज़ चलती हैं यह सीखा होगा
      सामग्री भी बहुत है और गणित भी इतना कठिन नहीं है। 3D modeling शायद आपके लिए एक ऐसा creative outlet बन जाए जिसके बारे में आपने सोचा भी न हो। भले ही यह आपके मुख्य काम में बिल्कुल लागू न हो, फिर भी आप computer programming की कला को नए ढंग से सराहने लगेंगे, और शायद Kubernetes को फिर कभी हाथ न लगाने और अपने खाली समय के 5 साल अपने game engine पर लिखने में लगा दें
      ऐसे पागल लोग काफ़ी हैं, और hobby developers की वह community, जो professional game development में घिसकर खत्म नहीं हुई है, सोच से बड़ी है। Graphics Programming Discord भी देखने लायक एक स्वागतपूर्ण जगह है। बस करके देखिए
    • computer graphics अपने आप में दिलचस्प और संतोषजनक है। यह computer science, mathematics, theoretical physics और low-level programming जैसे कई महत्वपूर्ण क्षेत्रों के संगम पर है
      जो लोग वास्तव में क्या कर रहे हैं उससे फर्क नहीं पड़ता और सिर्फ career switch चाहते हैं, उनके लिए इससे बचने की सलाह सही हो सकती है। लेकिन इस तरह जीना अच्छा तरीका नहीं है। बेहतर यह है कि आप उस चीज़ का पीछा करें जो आपको रोचक और मूल्यवान लगती है, लगातार नई चीज़ें सीखें और खुद को चुनौती दें। तब computer graphics सीखना है या नहीं, यह अपेक्षाकृत साफ़ हो जाता है, और सही व्यक्ति के लिए यह शुद्ध लाभ है। भले ही यह पेशा न बने, यह skill कई दूसरे क्षेत्रों में अच्छी तरह transfer हो जाती है
    • graphics programming का एक उपयोगी पहलू आज के समय में exponentially ज़्यादा मूल्यवान है। matrix algebra pipeline और “matrix transformations के रूप में सोचना” machine learning के गणित की नींव बनाने का शानदार और दृश्य रूप से immersive तरीका है
    • Inigo Quilez जैसे व्यक्ति के बारे में क्या? मुझे लगता है कि आज भी वह काफ़ी ध्यान पाने वाला नाम है। और अब पूरे क्षेत्र में लोग पहले से कहीं ज़्यादा हैं, इसलिए हर कोई मशहूर नहीं हो सकता
      किसी क्षेत्र के सबसे चर्चित लोगों में से एक जितना प्रसिद्ध न होना भी ठीक है, और आप सिर्फ आनंद के लिए भी यह कर सकते हैं। graphics और game programming का गणित और कला अपने आप में सुंदर है
    • सही है। Carmack को प्रसिद्ध बनाने वाली ज़्यादातर चतुर techniques software से hardware में चली गई हैं
      graphics programming में न आने की मेरी वजह अलग है। क्या vertices और textures वाला 3D engine कुछ साल बाद भी मौजूद रहेगा? या फिर सब कुछ AI world models द्वारा सीधे render किया जाएगा? games में कितना code होगा, या क्या वे सिर्फ चालाकी से लिखे गए prompts की एक श्रृंखला बनकर रह जाएँगे?

  • अगर आपको linear algebra का एक तेज़ tutorial चाहिए, तो मैंने जो 4 पेज का printable नोट लिखा है, उसे देख सकते हैं: https://minireference.com/static/tutorials/linear_algebra_in...
    SymPy code examples वाला notebook भी यहाँ है: https://github.com/minireference/noBSLAnotebooks

    • अगर आपको लंबा tutorial चाहिए, तो मैं 3b1b की series ज़ोरदार तरीके से recommend करूँगा: https://youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFit...
      visualizations की वजह से वे बातें भी साफ़ महसूस हुईं जो Linear 101 क्लास में समझ नहीं आई थीं
    • सौंदर्य की दृष्टि से भी यह सचमुच सुंदर है। जब भी इतनी सुंदर mathematics को खराब typography और बदसूरत spacing के साथ पेश किया जाता है, तो हमेशा अफसोस होता है

  • यह थोड़ा हैरान करने वाला है कि यहाँ basic design principles या human perception की विशेषताओं को समझने की बात नहीं है
    मेरा भाई 90s~00s के मशहूर computer games में production artist था, और वह बार-बार उन programmers और managers की शिकायत करता था जिनमें visual sense नहीं था और जिन्हें artists की तरफ़ को समझने की कोई जिज्ञासा नहीं थी
    graphics मेरा क्षेत्र नहीं है, लेकिन musician, sound designer और producer के रूप में मैंने जिन सबसे प्रभावी और असरदार audio DSP coders को जाना है, वे music की बुनियाद, sound की physics और acoustics, discrete digital processing, और हम stimuli को कैसे perceive और interpret करते हैं, इन सबके बीच के traps को समझते हैं

    • आपने जिस बात का ज़िक्र किया, उसके ज़्यादा करीब एक अलग भूमिका होती है, जिसे technical artist कहते हैं। मैं वही काम करता हूँ
      अगर graphics programmer में कलात्मक सोच हो तो मदद मिलती है, लेकिन वे आम तौर पर काफ़ी low-level पर काम करते हैं, इसलिए सफलता के लिए यह अनिवार्य नहीं है
    • creative industries के बाहर भी यही बात लागू होती है। B2B/enterprise software में भी मैंने काफ़ी vendors देखे हैं जिन्हें न तो इस बात की समझ होती है कि जिस industry को वे बेच रहे हैं वह कैसे चलती है, और न यह कि users कैसे सोचते हैं
      AI ने इस समीकरण को थोड़ा बदला है, या कम से कम बदलने की क्षमता रखता है, लेकिन मुझे लगता है कि 2000s के मध्य का “coding सीखो” वाला रुझान भी काफी हद तक इसी वजह से था। यह एक ऐसा movement था जिसमें software development को मौजूदा क्षेत्र के experts के लिए “product नहीं बल्कि feature” की तरह देखा गया, ताकि domain को सबसे अच्छी तरह जानने वाले लोग requirements को development team तक translate करने के बजाय खुद software बना सकें
    • 100% सहमत। अच्छे graphics programmers technical artists और artists के साथ काम करते हैं
      सच कहूँ तो graphics programming ज़्यादातर उन लोगों की इच्छाओं को संभव बनाने, या उन्हें वह चीज़ बनाने में मदद करने वाली service role के ज़्यादा करीब है जिसकी वे कल्पना करते हैं
      Inigo Quilez का नाम अक्सर ऐसे उदाहरण के रूप में लिया जाता है जो graphics programmer भी है और artist भी, और वह सच में बेहद शक्तिशाली और unicorn जैसा व्यक्ति है

व्यक्तिगत रूप से मुझे संगीत वादन और audio programming ज़्यादा पसंद है, और यह DSP सीखने के लिए अच्छी बुनियाद बनता है। उदाहरण के लिए, अगर rendering noise को high-frequency तरफ धकेल दिया जाए, तो low-pass filter कभी-कभी noise हटाने में ज़्यादा प्रभावी होता है

  • मेरी बनाई और maintained सूची यहाँ है: https://legends2k.github.io/note/cg_resources/
    अगर जिज्ञासा हो और समय हो, तो इसे सीखना अच्छा रहेगा। यह सच में मज़ेदार है, बहुत कुछ सिखाता है, और computer science के कई दूसरे क्षेत्रों में भी आपको बेहतर engineer बनाता है। आप hardware, systems programming, और programmer के machine model जैसी चीज़ें समझने लगते हैं
    लेकिन अगर आपका अंतिम लक्ष्य पैसा है, तो इसे न सीखना ही बेहतर है। आजकल इसके rewards क्षणभंगुर, अस्थायी और अनिश्चित हैं
    • मैं भी इस material का उपयोग कर रहा हूँ, यह दूसरों के लिए भी उपयोगी हो सकता है: https://owlcat.games/learning
  • शायद इसमें यह भी जोड़ना चाहिए कि “आपकी उम्र 25 से कम हो और आपके पास इसमें लगाने के लिए बहुत समय हो”
    मुझे पहले से graphics programming में रुचि थी, और कुछ साल पहले मैंने Vulkan खुद से सीखना शुरू किया। कुल कितना समय लगाया, यह नहीं पता, लेकिन लगभग 6 महीने की शाम की फुर्सत, शायद उससे थोड़ा कम। मैंने rendering framework जैसा कुछ बना लिया था
    लेकिन यह वैसा काम है जिसमें आगे बढ़ते-बढ़ते एहसास होता है कि आप कितना कुछ नहीं जानते। जैसे ही लगता है कि structure ठीक है, पता चलता है कि यह सही architecture नहीं है
    आख़िर में जो किया जा रहा होता है, वह मूल रूप से applied lighting math है, और बाकी सब plumbing है। जब आप देखते हैं, “यह spotlight cube के आर-पार वैसे ही क्यों जा रही है?”, तब समझ आता है कि shadows calculate करनी होंगी, और फिर उसे render pipeline में डालने का तरीका समझने में हफ़्तों लग जाते हैं। फिर भी, अगर आपको यह सब पसंद है, तो यह काफ़ी “मज़ेदार” है
    • दुर्भाग्य से, Vulkan graphics programming सीखने का सच में पीड़ादायक तरीका है। लगभग हर काम के लिए बहुत ज़्यादा boilerplate code चाहिए
      उदाहरण के लिए, shadows बनाने में भी तकनीक की मूल ज़रूरत से 10 गुना ज़्यादा code लिखना पड़ता है
      graphics programming सीखने के लिए मुझे software renderer लिखना कहीं ज़्यादा आनंददायक लगता है। code कम होता है, और जो code आप लिखते हैं वह boilerplate नहीं बल्कि मूल बात को छूता है। कमी यह है कि hardware acceleration नहीं मिलता, इसलिए यह धीमा हो जाता है
  • यह इस पर निर्भर करता है कि आप क्या करना चाहते हैं
    अगर आप बस game बनाना चाहते हैं, तो Unity, Godot, Unreal जैसे game engine इस्तेमाल कर सकते हैं
    अगर आप engine, simulation, renderer जैसी graphics चीज़ों पर काम करना चाहते हैं, तो आपको low-level language और graphics API सीखनी होगी। भाषा के रूप में मैं C++ की सिफारिश करूँगा; C या Rust भी इस्तेमाल कर सकते हैं, लेकिन C थोड़ा कठिन है, और graphics API अपने-आप में ही कठिन होती है, इसलिए शायद आप language से भी लड़ना नहीं चाहेंगे। Rust भी अच्छा विकल्प हो सकता है, लेकिन व्यक्तिगत रूप से मुझे उसका compile time बहुत धीमा और syntax बदसूरत लगता है
    API के लिए मैं OpenGL की सिफारिश करूँगा। यह cross-platform है, पुराना है, और वही इसकी ताकत भी है और कमी भी; इन्हीं में यह सबसे आसान है
    learnopengl.com OpenGL tutorials में बिना किसी शक के सबसे अच्छा है, इसलिए मैं इसे follow करने की सलाह दूँगा
    OpenGL को कुछ समय इस्तेमाल करने के बाद आप Vulkan या कई API implement करने वाली graphics libraries तक फैल सकते हैं, या अगर ठीक लगे तो OpenGL पर ही बने रह सकते हैं
    यह निश्चित रूप से आसान नहीं है, लेकिन मेरी नज़र में यह computer science के सबसे आकर्षक क्षेत्रों में से एक है
  • मैंने A-Frame(aframe.io) बनाया था और अब भी उसे maintain कर रहा हूँ। पिछले 10 सालों में यह 3D graphics सीखने के लिए एक सहज शुरुआती रास्ता रहा है
    खुद अपनी तारीफ़ करना ठीक नहीं लगता, लेकिन community भी शानदार है। web, सीखते हुए जो आप बनाते हैं उसे share करने, feedback जुटाने और visibility पाने का अच्छा तरीका है। community के भीतर भी ऐसे कई उदाहरण हैं जहाँ लोग professional रूप से 3D graphics में गए हैं
    • मैंने अपना master's thesis A-Frame के साथ लिखा था। उस समय मैं programmer नहीं था और मेरे पास लगभग कोई अनुभव भी नहीं था, लेकिन A-Frame की वजह से मैं अपने ideas को सच में बहुत intuitive तरीके से implement कर पाया
      कभी-कभी repository देखकर शर्म आती है कि उस समय का code कितना बिखरा हुआ था, लेकिन मुझे लगता है कि उस project के बिना मैं आज यहाँ नहीं होता
    • मैं निश्चित रूप से इसकी सिफारिश कर सकता हूँ
      आप simple tags से शुरू कर सकते हैं, फिर animation जोड़ सकते हैं, और अगर वह कम पड़े तो community components जोड़ सकते हैं। अगर वह भी कम पड़े तो ThreeJS में बदल सकते हैं, और shader तक जा सकते हैं। A-Frame शानदार है
      और इसके अलावा आप AR और VR भी कर सकते हैं
  • ख़ासकर जब उस पर अजीब तरह का machine learning वाला नज़रिया भी चढ़ा दिया जाता है, तो लगता है जैसे हम जो भी करते हैं उसे career या नौकरी में बदलने की कोशिश कर रहे हों
    graphics programmer बनना कहने के बजाय, बस graphics programming करना कैसा रहेगा? किसी सरल चीज़ से शुरू कीजिए, फिर धीरे-धीरे समझ आने लगती है, और आख़िर में दिखने लगता है कि यह मूल रूप से GPU को सामान भेजने जैसा काम है; उसके ऊपर आप हर तरह की जटिल concepts की परत चढ़ा सकते हैं
    यह छोटे पहाड़ पर चढ़ते-चढ़ते अचानक सब कुछ ठीक से बैठ जाने और “वाह…” जैसा महसूस होने जैसा है। तब संभावनाएँ और प्रयोग की चीज़ें दिखने लगती हैं
    • मैं नहीं मानता कि वह अभिव्यक्ति ज़रूरी रूप से career या profession को ही दर्शाती है। बल्कि वह identity के ज़्यादा करीब है
      “मैं rock climber हूँ”, “gamer हूँ”, “artist हूँ”, “माँ हूँ”, “पिता हूँ”, “gym rat हूँ”, “graphics programmer हूँ” — ऐसे वाक्य हमेशा profession नहीं बताते, लेकिन वे किसी हल्की-फुल्की, क्षणिक भागीदारी से ज़्यादा गहरे जुड़ाव का संकेत देते हैं
  • मैं उस ray tracing tutorial को खोलकर धीरे-धीरे follow कर रहा हूँ। मुझे इसमें पहले से दिलचस्पी थी, लेकिन इसे कभी आज़माया नहीं था
    आज मैंने PPM image format के बारे में सीखा, और ऐसे कामों के लिए यह काफ़ी सुलभ है। bitmap लिखना कोई बहुत बड़ी rocket science नहीं है, लेकिन PPM उससे भी आसान है