ถ้าอยากเป็น Graphics Programmer ควรเรียนรู้อะไรบ้าง

 (blog.demofox.org)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทักษะที่งานด้านกราฟิกส์แบบเรียลไทม์ต้องการคือทั้ง explicit graphics API ฝั่ง CPU และ การจัดแสง·เชดดิ้งฝั่ง GPU แต่การเรียนทั้งสองด้านให้ลึกพร้อมกันทำได้ยาก
  • ฝั่ง CPU เกี่ยวข้องกับ API สมัยใหม่อย่าง DirectX12, Vulkan, Metal รวมถึงการโหลด asset และงานสนับสนุนเอนจิน ส่วนฝั่ง GPU เกี่ยวข้องกับเงา, ambient occlusion, post-processing และลักษณะด้านประสิทธิภาพของ GPU
  • แกนกลางของการเรียนฝั่ง GPU คือ การเขียน path tracer และ การเข้าใจ PBR โดย Ray Tracing in One Weekend, LearnOpenGL PBR, เอกสาร Filament และ PBRT สามารถเป็นจุดเริ่มต้นได้
  • พอร์ตโฟลิโอที่เหมาะคือการแสดงความรู้ผ่าน real-time renderer ที่ใช้ C++, path tracer ที่สร้างภาพเหมือนภาพถ่าย และโค้ดที่เปรียบเทียบ·ตรวจสอบผลลัพธ์จากการเรนเดอร์ทั้งสองแบบ
  • คณิตศาสตร์ที่จำเป็นมีแกนหลักคือ linear algebra, ตรีโกณมิติพื้นฐาน และแคลคูลัสเล็กน้อย ภาษาฝั่ง CPU สำหรับพัฒนาเกมคือ C++ ส่วนภาษา shader ที่พบบ่อยที่สุดคือ HLSL

กราฟิกส์เรียลไทม์ครอบคลุมทั้งฝั่ง CPU และ GPU

  • การเรนเดอร์สมัยใหม่แทบจะเป็นการรวมงานสองอย่างเข้าด้วยกัน
    • การเรียนฝั่ง CPU: API แบบ explicit สมัยใหม่อย่าง DirectX12, Vulkan, Metal และการเขียนโปรแกรมเอนจินสำหรับการโหลด asset รวมถึงงานสนับสนุนอื่น ๆ
    • การเรียนฝั่ง GPU: คณิตศาสตร์ของการจัดแสง·เชดดิ้งสมัยใหม่, เงา, ambient occlusion, เอฟเฟกต์ post-processing และความแตกต่างระหว่างงานที่เร็วกับงานที่ช้าบน GPU
  • การเรียนทั้งสองด้านพร้อมกันทำได้ยากมาก
    • หากต้องการโฟกัสฝั่ง GPU สามารถใช้เครื่องมือที่ภาระฝั่ง CPU ต่ำกว่า เช่น OpenGL, WebGL, DirectX11 หรือเอนจินเดิม ๆ
    • หากต้องการโฟกัสฝั่ง CPU ให้เริ่มจากการแสดงสามเหลี่ยมบนหน้าจอก่อน จากนั้นค่อยแสดง mesh โดยไม่จำเป็นต้องกังวลมากว่าผลลัพธ์จะสวยหรือไม่

path tracing และ PBR

  • การเรียนฝั่ง GPU รวมถึง การเขียน path tracer
    • Path tracing เป็นวิธีที่ใช้ในการเรนเดอร์ภาพยนตร์ และเป็นเป้าหมายที่เทคนิคการเรนเดอร์เรียลไทม์สมัยใหม่พยายามประมาณค่าให้ใกล้เคียง
    • หนังสือออนไลน์ฟรี Ray Tracing in One Weekend เหมาะเป็นแหล่งเริ่มต้น เข้าถึงง่าย และแสดงกระบวนการสร้างงานเรนเดอร์ที่ดูเหมือนภาพถ่าย
  • Physically Based Rendering(PBR) คือแนวทางการจัดแสง โดยเฉพาะวิธีใช้ specular
    • PBR เป็นแนวทางตามหลักการที่ให้ผลลัพธ์ดีเมื่อทำตามกฎ
    • ก่อนยุค PBR มีการใช้สูตร การปรับแต่ง และการแฮ็กแบบกำหนดเองจำนวนมากเพื่อทำแสง ทำให้ asset ที่ดูดีในสภาพแสงหนึ่งอาจดูมืดเกินไปหรือดูเหมือนเรืองแสงในอีกสภาพแวดล้อมหนึ่ง
    • ผลคือจำเป็นต้องทำ asset หลายเวอร์ชันตามเงื่อนไขแสง ซึ่งใช้เวลาและความพยายามมาก
  • PBR ทำให้ asset ดูสม่ำเสมอกว่าเดิมในหลายสภาพแสง และลดเวลา·ความพยายามที่ต้องใช้ในการสร้าง asset แยกตามเวอร์ชัน
    • ถึงอย่างนั้น เวลา ต้นทุน และแรงงานในการสร้าง asset ก็ยังเป็นคอขวดใหญ่ของการพัฒนาเกมอยู่ดี

แหล่งเรียนรู้แนะนำ

  • สำหรับการเริ่มต้น PBR ส่วน PBR Theory ของ LearnOpenGL และหมวดย่อยต่าง ๆ เหมาะสม
  • หากต้องการลงลึกขึ้น เอกสาร Filament สามารถเป็นขั้นถัดไปได้
    • ยิ่งเรียน PBR ลึกเท่าไร แคลคูลัสและสถิติก็จะปรากฏมากขึ้นเท่านั้น
  • ถัดไปอีกมีหนังสือออนไลน์ฟรี Physically Based Rendering: From Theory To Implementation
  • มองว่า machine learning ในปัจจุบันยังไม่น่าจะให้ผลลัพธ์ได้เท่ากับกระแสโฆษณาเกินจริง แต่ก็ยังคุ้มค่าที่จะเรียนรู้ เทคนิค fitting และ optimization ในฐานะเครื่องมือหนึ่งในกล่องเครื่องมือของวิทยาการคอมพิวเตอร์

โค้ดที่เหมาะสำหรับแสดงในพอร์ตโฟลิโอ

  • หากต้องการพิสูจน์ความรู้ให้ผู้รับสมัครเห็น วิธีที่เหมาะคือวาง ซอร์สโค้ด ที่แชร์ได้ไว้บนที่อย่าง GitHub แล้วลิงก์จากเรซูเม่
  • ตัวอย่างพอร์ตโฟลิโอ:
    • renderer แบบเอนจินที่โหลด asset เช่นโมเดลและ texture แล้วเรนเดอร์แบบเรียลไทม์บนหน้าจอ
      • รวมเอฟเฟกต์บางอย่าง เช่น การจัดแสงและเงา, depth of field, area lights, tone mapping, ray traced shadows
      • ถ้าเป็นไปได้ให้ใช้การจัดแสงแบบ PBR, กล้องที่ผู้ใช้ควบคุมได้, API อย่าง DX12·Vulkan และ C++
    • path tracer ที่สร้างภาพเหมือนภาพถ่าย
      • ถ้าเป็นไปได้ C++ จะดี แต่จะเป็นโปรแกรมที่ไม่มีหน้าต่างและส่งออกเฉพาะ PNG ก็ได้
      • ไม่จำเป็นต้องเป็นเรียลไทม์
    • ถ้า path tracer เป็นโหมดแยกใน renderer แบบเอนจินจะยิ่งดี
      • สามารถเปรียบเทียบผลแบบ path traced กับการเรนเดอร์ PBR เรียลไทม์เพื่อตรวจสอบความถูกต้องได้
      • หากสามารถชี้จุดที่ผลเรนเดอร์ทั้งสองไม่ตรงกัน อธิบายได้ว่าทำไมจึงต่างกัน และคิดวิธีทำให้ใกล้เคียงขึ้นโดยยังคงความเรียลไทม์ไว้ได้ ก็จะได้รับการประเมินสูงขึ้น

คณิตศาสตร์, อัลกอริทึม และการเลือกภาษา

  • หากลองทำสิ่งข้างต้นด้วยตัวเอง จะเจอคณิตศาสตร์ที่จำเป็นไปตามธรรมชาติ
    • สิ่งที่จำเป็นพื้นฐานคือการคูณเมทริกซ์ใน linear algebra, cross product, dot product, ตรีโกณมิติพื้นฐาน และแคลคูลัสเล็กน้อย
    • กราฟิกส์และการพัฒนาเกมมีคณิตศาสตร์ขั้นต่ำที่ต้องใช้ค่อนข้างน้อย แต่ขอบเขตของคณิตศาสตร์ที่นำมาใช้ได้แทบไม่มีขีดจำกัด
  • อัลกอริทึมก็คล้ายกัน
    • ควรรู้จัก abstract data type และอัลกอริทึมพื้นฐาน เช่น linked list, hash table, การเรียงลำดับ และการค้นหา
    • อัลกอริทึมที่เร็วที่สุดมักเป็นแบบเรียบง่าย และ array เร็วกว่า linked list มาก
    • แนวคิดอัลกอริทึมขั้นสูงจะช่วยได้เมื่อจำเป็นต้องสร้างสิ่งใหม่และเฉพาะทางจริง ๆ
  • ภาษาที่ควรเรียนสำหรับการพัฒนาเกมคือ C++
    • มีคนใช้ Rust และมีส่วนแบ่งอยู่บ้าง แต่ไม่ใช่ภาษามาตรฐานที่ผู้คนคาดหวัง
    • WebGPU มีฟีเจอร์จำนวนมากที่ WebGL ไม่มี และกำลังกลายเป็นแพลตฟอร์มที่จริงจังมากขึ้น พร้อมทำให้งานฝั่ง CPU เขียนด้วย JavaScript ได้
    • อย่างไรก็ตาม ยังไม่ค่อยเห็นตำแหน่งงาน WebGPU หรือคอนเทนต์ WebGPU บนเว็บมากนัก
  • ภาษา shader ที่พบบ่อยที่สุดคือ HLSL
    • บางส่วนใช้ GLSL
    • ในเกมหลายแพลตฟอร์ม shader มักถูกแปลงไปเป็นภาษา shader อื่น

ขอบเขตการใช้งาน LLM และ ML

  • มองว่าเทคโนโลยี ML ปัจจุบันยังไม่ดีพอสำหรับการใช้งานส่วนใหญ่ที่ถูกนำไปขาย
  • Claude มีประโยชน์สำหรับพูดคุยเรื่องคณิตศาสตร์, งานวิจัย และอัลกอริทึมที่ไม่คุ้นเคย
    • ในสถานการณ์เหล่านี้ตรวจสอบได้ง่ายว่ามันแต่งเรื่องขึ้นมาหรือไม่ และตรวจความสมเหตุสมผลกับแหล่งอื่นได้ง่ายด้วย
  • สำหรับการเขียนโปรแกรมยังไม่ค่อยมีประโยชน์นัก
    • แม้มันจะให้โค้ดที่ทำงานได้ตามต้องการ แต่ก็ยังต้องใช้เวลาเพื่อทำความเข้าใจโค้ดนั้น
    • ถ้าเป็นอย่างนั้น มองว่าเขียนเองจะดีกว่า
  • การใช้งานเล็ก ๆ อาจมีประโยชน์
    • เช่น ถ้าถามว่า “เห็นบั๊กในไฟล์นี้ไหม?” เมื่อคำตอบคือ yes ก็ไปตรวจสอบต่อได้ และแม้คำตอบจะเป็น no ต้นทุนในการถามก็แทบไม่มี
  • เชื่อว่าวันหนึ่งมนุษยชาติจะสร้างปัญญาประดิษฐ์ระดับมนุษย์และก้าวข้ามไปไกลกว่านั้นได้ แต่ไม่รู้ว่าจุดนั้นจะเกิดขึ้นในช่วงชีวิตของตนเองหรือไม่
    • ยุค LLM ปัจจุบันคล้ายกับการซ้อมใหญ่เพื่อวันที่ “ของจริง” มาถึงในภายหลัง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • ก่อนอื่นต้องแยกให้ออกก่อนว่าอยากทำเกม หรืออยากทำ การเขียนโปรแกรมเอนจิน 3D
    ถ้าอยากทำเกม ควรใช้เอนจินที่มีอยู่แล้วอย่าง Unreal Engine, Unity, Godot, Bevy จะดีกว่า และจะได้เรียนรู้ปัญหากราฟิกในระดับสูง แทนที่จะเรียนวิธีดันพิกเซลเข้าไปเอง สิ่งที่ยากจริง ๆ คือการทำให้เกมสนุก
    ถ้าอยากสร้างเอนจิน 3D ต้องรู้ไว้ก่อนว่าเอนจินเกมแย่ ๆ มีอยู่มากเกินพอแล้ว แค่ฝั่ง Rust ก็มีโปรเจกต์หลัก ๆ เป็นเรนเดอเรอร์ที่ล้มเหลว 3 ตัว เรนเดอเรอร์ที่ยังไม่เสร็จ 1 ตัว และเรนเดอเรอร์ใน Bevy ส่วนโปรเจกต์ที่บอกว่า “จะทำเอนจินเกม” นั้นมีเยอะกว่านั้นมาก แม้แต่การไปให้ถึงระดับ “เรนเดอเรอร์ตัวแรก” ก็ใช้เวลาประมาณ 2 ปีแล้ว และการไปถึงฉากขนาดใหญ่ ละเอียด และไดนามิกนั้นเป็นงานที่ใหญ่กว่านั้นมาก
    ถ้าเป้าหมายคือการหางาน อุตสาหกรรมเกมมีทั้งค่าจ้างและชั่วโมงทำงานที่ไม่ดี พอโปรเจกต์จบ งานก็จบตาม และมีผู้สมัครที่อยากเข้ามาล้นเหมือน Hollywood ยิ่งไปกว่านั้น เพราะการล่มสลายของ Metaverse ตอนนี้แม้แต่คนมีประสบการณ์ก็ล้นตลาด
    มือถือเป็นงานบีบอัดที่ขาดแคลนทั้งหน้าจอ พลังประมวลผล GPU และแบตเตอรี่ ดังนั้นเกมอินดี้ส่วนใหญ่ในช่วงนี้จึงเป็น 2D อย่างน้อยก็ยังพอทำได้ และมักทำด้วย HTML/JavaScript ได้ด้วย

    • ดูเหมือนคุณจะสมมติว่าคนส่วนใหญ่พยายามจะ แข่งด้านภาพ กับ Unreal ซึ่งแน่นอนว่าแทบเป็นไปไม่ได้
      แต่การทำเรนเดอเรอร์พื้นฐานกับ game loop ไม่ได้ยากขนาดนั้น และมีโอกาสสูงที่จะไม่ได้เป็นโค้ดส่วนใหญ่ของเกมด้วยซ้ำ ถ้าเป็นเกมเรียบง่าย แค่ drawObject() ในลูป for ก็อาจเพียงพอแล้ว ส่วนเรื่องอย่าง resource streaming, การปรับ binding ให้เหมาะสม, parallelism ค่อยไปกังวลทีหลังเมื่อจำเป็นก็ได้
      อยากรู้ว่าเกณฑ์ “2 ปีกว่าจะถึงเรนเดอเรอร์ตัวแรก” นั้นตั้งต้นจากจุดไหนและถือว่าสำเร็จเมื่อไหร่ ประมาณปีก่อน ผมใช้เวลาว่างหนึ่งเดือน หรือเทียบเป็นงานเต็มเวลาไม่ถึง 1 สัปดาห์ ทำ deferred renderer ที่มี dynamic lighting, shadow mapping และ post-processing บางอย่างได้
      2D ก็ไม่มีเหตุผลให้ดูถูก งานจริงจังจำนวนมากเกิดขึ้นบนอินเทอร์เฟซ 2D และ WebGL กับ 2D canvas รุ่นเก่าก็ทรงพลังพอสมควรในปัจจุบัน เกมอินดี้ที่ฮิตจำนวนมากก็เป็น 2D
      เรื่องที่อุตสาหกรรมเกมไม่ค่อยดีนั้นถูกต้อง แต่ทุกวันนี้แทบทุกอย่างใช้ GPU การเขียนและดีบักงาน machine learning, data visualization, HUD, รวมถึง user interface ทั่วไป ก็มักต้องอาศัยความเข้าใจด้านกราฟิก
    • ค่าเฉลี่ยของอุตสาหกรรมเกมอาจไม่ดีนัก แต่ผมคิดว่านิชอย่าง graphics programming ไม่ได้เป็นแบบนั้น
      นอกจากเกมแล้ว ยังมีสาขาที่ใช้กราฟิกอีกมาก เช่น visualization, simulation และ graphics programmer ที่เก่งนั้นหายากมาก จึงเป็นสายอาชีพที่ดีอย่างน่าประหลาดใจ ค่อนข้างตรงข้ามกับที่ดูเหมือนว่านักพัฒนาเกมหรือศิลปินจะหางานดี ๆ ได้ยากกว่า อย่างไรก็ตาม ทั้งอุปสงค์และอุปทานต่างก็มีขนาดเล็ก การย้ายงานจึงอาจไม่ง่ายนัก
      ถ้าดูเฉพาะความมั่นคงในอาชีพ ผมอยากห้ามไม่ให้ยึด game development เป็นอาชีพ แต่ graphics programming นั้นต่างออกไป
    • น่าเสียดายที่เกมซึ่งเดิมทีดีอยู่แล้วกลับเจอ ปัญหาประสิทธิภาพ เพราะ Unity หรือ Unreal Engine บ่อยเกินไป ผมไม่อยากให้แนะนำสิ่งเหล่านี้ และยังไม่รู้ว่า Godot กับ Bevy ดีกว่าหรือไม่
      ในบรรดาเกมที่เล่นในช่วงไม่กี่ปีที่ผ่านมา Core Keeper(Unity), WORMHOLE(Unity โดยเฉพาะอาการหน่วงในโหมด infinite), Crab Champions(UE4, ต้องใช้ upscaling ที่ทำให้ภาพดูน่าเกลียดเพื่อรักษา 60fps ที่ 1920x1200) มีปัญหาประสิทธิภาพหนักมาก
      ในทางกลับกัน Terraria, Necesse, Barony ใช้เอนจินของตัวเองและรันได้ยอดเยี่ยม ยิ่งเกมเก่าก็ยิ่งดูดีขึ้น
      ถ้าพูดอย่างเป็นธรรม Tiny Rogues(Unity) เท่าที่จำได้โดยรวมรันได้ดี แต่ผู้พัฒนากำลังทำงานเพื่อย้ายออกจาก Unity ในอนาคต จึงดูเหมือนเขาเองก็พบปัญหาเช่นกัน
      ผมเข้าใจความต่างระหว่างการทำเกมกับการทำเอนจิน และความสำคัญของการทำให้เสร็จและออกวางจำหน่ายจริง แต่ถ้าปล่อยขยะออกมา ก็ยากที่จะทิ้งมรดกที่ดีไว้ได้ ต่อให้อ้อมไกล ผมคิดว่าการรับประกันคุณภาพระดับหนึ่งจะดีกว่า เกมบางเกมถูกเล่นต่อไปอีกหลายสิบปีหลังวางจำหน่าย และถ้ามีบั๊กหรืออาการหน่วง ผู้คนก็จะต้องเจอมันต่อไปเรื่อย ๆ
    • ถ้าเริ่มทำเอนจิน โดยเฉพาะทำไปเรียนไป ก็มีโอกาสสูงว่าจะทำเกมไม่สำเร็จ ในทางเทคนิคมันเป็นไปได้ที่จะสำเร็จทั้งสองอย่าง แต่จากที่ผมเคยเจอเองและเห็นคนหลายสิบคนในชุมชนนักพัฒนาเกมงานอดิเรกของโปแลนด์ โอกาสสำเร็จน่าจะใกล้เคียง ต่ำกว่า 5%
      “ฉันจะทำเอนจินสำหรับเกมของตัวเองก่อน เพื่อให้ทำเกมถัดไปได้ง่ายขึ้น” เป็นกับดักที่ทรงพลังอย่างน่าประหลาดใจ เพราะในทางปฏิบัติคุณได้เรียนรู้สิ่งสำคัญและได้ชัยชนะเล็ก ๆ ทุกวัน คุณจะคลายลูปเพิ่มอีกนิดเพื่อให้ฉากดูลื่นขึ้น เพิ่มชั้นตรรกะอีกชั้นในรูปแบบ config เพื่อให้สร้างฉากง่ายขึ้น และอ่านเปเปอร์ SIGGRAPH เพิ่มอีกฉบับ
      มีสิ่งสำคัญให้ปรับปรุงอยู่เสมอ แต่สิ่งเหล่านั้นไม่ได้รวมกันเป็นเกมที่เสร็จสมบูรณ์ เมื่อมองย้อนกลับไป การใช้เอนจินที่ทำเองคือวิธีที่สมบูรณ์แบบในการเลื่อนส่วนที่ยากแต่จำเป็นของเกมในฝันของวิศวกร นั่นคือ “ทำให้มันสนุก” ออกไป คุณจะได้ทักษะการโค้ดวิดีโอเกมที่น่าประทับใจ แต่ไม่ได้เรียนรู้วิธีสร้างเกม
      ยังมีกับดักย่อยด้วย คุณเรียนรู้วิธีสร้าง visual effect สวย ๆ ที่รันลื่นแบบเรียลไทม์ได้เป็นร้อยวิธี แต่ไม่ได้เรียนรู้ว่าจะใช้มันเป็นศิลปะอย่างไร
      เรื่องนี้คล้ายกับกับดักของ “Enterprise Java” มาก เพียงแต่แยบยลกว่าเพราะมันเกี่ยวข้องกับศัพท์เฉพาะ คุณอาจคิดว่าหลบกระสุนนั้นได้แล้วเพราะใน Scene Graph ไม่มี Factory Factory Interface แต่จริง ๆ แล้วคุณพลาดประเด็นที่ว่าสำหรับงานแสดงบิตแมปบนหน้าจอและให้มันตอบสนองต่อปุ่ม สิ่งนั้นไม่จำเป็นตั้งแต่แรก
    • ผมไม่จำเป็นต้องเห็นด้วยเสมอไปกับคำแนะนำว่าถ้าอยากทำเกมให้ใช้เอนจินที่มีอยู่แล้วเสมอ ในกรณีส่วนใหญ่เป็นคำแนะนำที่ดี แต่เอนจินที่มีอยู่แล้วนั้น เอนกประสงค์ เกินไป และมีสมมติฐานเกี่ยวกับเกมมากมาย เกมของคุณอาจต้องการข้อจำกัดที่ต่างออกไป
      โดยเฉพาะใน 2D เป็นแบบนั้น ตัวอย่างเช่น ผมกำลังทำเกมด้วยเอนจินเกมที่ทำเอง โดยโฟกัสที่ประสิทธิภาพ การบีบอัด และโครงสร้างที่ไม่มีเซิร์ฟเวอร์หรือฐานข้อมูล
      เอนจินนี้มีโครงสร้างและสมมติฐานเกี่ยวกับโครงสร้างเกมที่เฉพาะเจาะจงมาก เพื่อให้ได้ประสิทธิภาพและการบีบอัดในระดับสุดขั้วภายใต้ข้อจำกัดที่ผมกำหนดไว้ ผมตั้งใจจะโพสต์บทความที่เกี่ยวข้องบน Hacker News เร็ว ๆ นี้ ถ้าเป็นไปได้ก็สัปดาห์หน้า
      ก่อนหน้านี้ผมเคยพยายามทำเกมเบราว์เซอร์หลายครั้งด้วย Unity, Godot, React แต่การเรียน API เป็นเรื่องทรมาน และเอนจินเหล่านั้นตอบโจทย์ข้อจำกัดสุดขั้วของผมไม่ได้ แน่นอนว่าอาจเป็นเพราะผมใช้เอนจินเหล่านั้นไม่เก่งด้วย แต่เมื่อมองย้อนกลับไป ผมคิดว่าสิ่งที่ทำได้ภายในนั้นคงเป็นไปไม่ได้หากไม่มี custom engine ที่สร้างตั้งแต่ศูนย์
      ผมได้เรียนรู้อย่างมากจากการทำทั้งเอนจินและเกมเอง และโดยเฉพาะในยุคนี้ ด้วย LLM ผมคิดว่าสำหรับนักพัฒนาที่มีประสบการณ์ การลองทำเอนจินเกมแบบปรับแต่งเองได้เข้ามาอยู่ในขอบเขตที่เป็นจริงสำหรับนักพัฒนาส่วนใหญ่อย่างฉับพลัน

  • ถ้าเป็นตอนนี้ ผมคงไม่แนะนำให้ใครเข้ามาทำกราฟิกส์โปรแกรมมิงเลย
    ผมเริ่มตอนปี 2001 เมื่อ Nvidia เปิดตัว GeForce 1 รุ่นแรก หรือที่เรียกว่า “Gigatexel shader card” และตั้งแต่นั้นมา ความเร็วของการพัฒนาและนวัตกรรมในสายนี้ก็ทำให้เวียนหัวได้เลย เมื่อเทียบกับ 25 ปีก่อน เทคโนโลยีตอนนี้สุดยอดจริง ๆ
    แต่ความน่าทึ่งนี้มีคำว่า “แต่” ตัวใหญ่ ๆ อยู่ สายนี้พัฒนาเร็วอย่างน่ากลัว Nvidia ถึงขั้นปล่อยเอฟเฟกต์ที่ขับเคลื่อนด้วย AI ซึ่งมีผลต่อฉากและแอสเซ็ตออกมาแล้ว ในตอนนั้นเราไม่เคยนึกเลยว่าสิ่งแบบนี้จะทำได้แบบเรียลไทม์
    ตอนนี้ผมยังไม่แน่ใจด้วยซ้ำว่ายังเป็นไปได้ไหมที่จะเป็น “ผู้เชี่ยวชาญที่ใช้ได้” ในสายนี้ พูดอีกอย่างคือคำถามว่า “John Carmack ในยุคนี้อยู่ที่ไหน?” เขาโด่งดังจากการรีดประสิทธิภาพฮาร์ดแวร์จนสุด และใช้ไอเดียที่ซ่อนอยู่ในคอมมูนิตี้ แต่ทุกวันนี้ดูเหมือนคนแบบนั้นจะไม่มีคูเมืองในการแข่งขันแล้ว เพราะสายนี้กว้างเกินไปและเปลี่ยนเร็วเกินไป จนไม่มีโอกาสให้ใครเป็น Carmack คนต่อไป

    • ผมเกลียดท่าทีแบบเข้ามาในสายงานหนึ่งแล้วหันไปห้ามคนอื่นจริง ๆ “อย่าเป็นเหมือนฉันเลย ฉันเสียชีวิตไปเปล่า ๆ” นั่นแทบจะเป็นคำเพ้อของคนที่หมดไฟและเหนื่อยล้า และการบอกให้คนเลี่ยงกราฟิกส์โปรแกรมมิงก็ไม่ใช่วิธีดึง John Carmack ในวันพรุ่งนี้เข้ามา
      ยังมีอีกมุมหนึ่งด้วย ถ้าจนถึงตอนนี้คุณทำมาแต่เว็บแอปกับ Kubernetes การลองทำกราฟิกส์โปรแกรมมิงกลับเป็นเรื่องดี วงจรฟีดแบ็กมันเร้าใจ และจะทำให้คุณสัมผัสได้ว่าคอมพิวเตอร์ธรรมดา ๆ นั้นเร็วแบบเหลือเชื่อแค่ไหน ต่อให้สุดท้ายคุณไปทำ optimization ที่ไม่สำคัญนัก มันก็ยังมีคุณค่า เพราะคุณไม่เคยได้เรียนรู้ว่าสิ่งต่าง ๆ ในระดับล่างนั้นเร็วแค่ไหน
      แหล่งเรียนรู้ก็มีเยอะ และคณิตก็ไม่ได้ยากเกินไป การทำ 3D modeling อาจกลายเป็นช่องทางสร้างสรรค์ที่คุณไม่เคยรู้ว่ามีก็ได้ แม้จะนำไปใช้กับงานหลักไม่ได้เลย มันก็จะทำให้คุณชื่นชมศิลปะของ computer programming ในมุมใหม่ และคุณอาจตัดสินใจไม่แตะ Kubernetes อีก แล้วใช้เวลาว่าง 5 ปีเขียนเกมเอนจินของตัวเองก็ได้
      คนบ้า ๆ แบบนั้นมีเยอะ และคอมมูนิตี้นักพัฒนาสายงานอดิเรกที่ยังไม่ถูกการพัฒนาเกมเป็นอาชีพกัดกร่อนนั้นใหญ่กว่าที่คิด Graphics Programming Discord ก็เป็นพื้นที่ที่เป็นมิตรและน่าเข้าไปดู ลองทำดูเถอะ
    • คอมพิวเตอร์กราฟิกส์นั้นน่าสนใจและให้ความรู้สึกคุ้มค่าโดยเนื้อแท้ มันอยู่ตรงจุดตัดของสาขาสำคัญหลายอย่าง เช่น วิทยาการคอมพิวเตอร์ คณิตศาสตร์ ฟิสิกส์เชิงทฤษฎี และการเขียนโปรแกรมระดับล่าง
      สำหรับคนที่ไม่ได้สนใจจริง ๆ ว่าจะทำอะไร แค่อยากเปลี่ยนอาชีพ คำแนะนำให้เลี่ยงอาจถูกต้อง แต่การใช้ชีวิตแบบนั้นไม่ใช่วิธีที่ดีนัก ควรตามสิ่งที่คุณรู้สึกว่าน่าสนใจและมีคุณค่า เรียนรู้สิ่งใหม่ ๆ อยู่เสมอ และท้าทายตัวเองมากกว่า แบบนั้นคำตอบว่าควรเรียนคอมพิวเตอร์กราฟิกส์หรือไม่ก็จะค่อนข้างชัดเจน และสำหรับคนที่เหมาะ มันจะเป็นกำไรสุทธิ ต่อให้ไม่ได้กลายเป็นอาชีพ ทักษะก็ยังถ่ายโอนไปใช้กับหลายด้านอื่นได้ดี
    • กราฟิกส์โปรแกรมมิงมีแง่มุมที่มีประโยชน์อย่างหนึ่ง ซึ่งทุกวันนี้มีคุณค่าเพิ่มขึ้นแบบทวีคูณ พายป์ไลน์พีชคณิตเมทริกซ์ และการ “คิดในรูปของการแปลงด้วยเมทริกซ์” เป็นวิธีที่ยอดเยี่ยมและมีความดื่มด่ำทางภาพในการปูพื้นฐานคณิตศาสตร์ของแมชชีนเลิร์นนิง
    • แล้วคนอย่าง Inigo Quilez ล่ะ? ผมมองว่าแม้ในปัจจุบันเขาก็ยังเป็นบุคคลที่ได้รับความสนใจมากพอ และตอนนี้ทั้งวงการมีคนมากขึ้นมาก จึงเป็นไปไม่ได้ที่ทุกคนจะดัง
      ไม่จำเป็นต้องโด่งดังเท่าหนึ่งในคนที่เป็นที่รู้จักที่สุดของสาขาก็ได้ แค่ทำเพราะสนุกก็พอ คณิตศาสตร์และศิลปะของกราฟิกส์กับเกมโปรแกรมมิงนั้นงดงามในตัวเอง
    • ใช่เลย เทคนิคฉลาด ๆ ส่วนใหญ่ที่ทำให้ Carmack โด่งดังได้ย้ายจากซอฟต์แวร์ไปอยู่ใน ฮาร์ดแวร์ แล้ว
      เหตุผลของผมที่ไม่อยากให้เข้ามาทำกราฟิกส์โปรแกรมมิงนั้นต่างออกไป อีกไม่กี่ปีข้างหน้า 3D engine ที่มีเวอร์เท็กซ์และเท็กซ์เจอร์จะยังมีอยู่ไหม? หรือทุกอย่างจะถูกเรนเดอร์โดย world model ของ AI โดยตรง? ในเกมจะมีโค้ดอยู่มากแค่ไหน หรือมันจะดำรงอยู่เป็นลำดับของพรอมป์ต์ที่เขียนอย่างชาญฉลาด?

  • ถ้าต้องการบทเรียนเร่งรัดเรื่องพีชคณิตเชิงเส้น ลองดูฉบับพิมพ์ได้ 4 หน้าที่ผมเขียนไว้: https://minireference.com/static/tutorials/linear_algebra_in...
    ยังมีโน้ตบุ๊กที่มีตัวอย่างโค้ด SymPy อยู่ที่นี่ด้วย: https://github.com/minireference/noBSLAnotebooks

    • ถ้าต้องการบทเรียนที่ยาวกว่านี้ ขอแนะนำซีรีส์ของ 3b1b อย่างยิ่ง: https://youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFit...
      เพราะการทำ visualization ทำให้สิ่งที่ไม่เข้าใจในคลาส Linear 101 คลิกขึ้นมาทันที
    • ในเชิงสุนทรียะก็สวยงามจริง ๆ ผมมักเสียดายทุกครั้งที่คณิตศาสตร์อันสวยงามถูกนำเสนอด้วย ไทโปกราฟี แย่ ๆ และระยะห่างที่ดูไม่ดี

  • แปลกใจเล็กน้อยที่ไม่มีการพูดถึงหลักการออกแบบพื้นฐานหรือคุณลักษณะของการรับรู้ของมนุษย์
    พี่ชายผมเคยเป็นโปรดักชันอาร์ติสต์ของเกมคอมพิวเตอร์ชื่อดังในยุค 90 ถึง 00 และเขาบ่นอยู่ตลอดเกี่ยวกับโปรแกรมเมอร์กับผู้จัดการที่ไม่มีเซนส์ด้านภาพและไม่มีความอยากรู้อยากเห็นที่จะเข้าใจฝั่งศิลปิน
    กราฟิกไม่ใช่ความเชี่ยวชาญของผม แต่ในฐานะนักดนตรี ซาวด์ดีไซเนอร์ และโปรดิวเซอร์ คนเขียน audio DSP ที่มีประสิทธิภาพและมีอิทธิพลที่สุดเท่าที่ผมรู้จัก เข้าใจพื้นฐานของดนตรี ฟิสิกส์และอะคูสติกของเสียง รวมถึงกับดักระหว่างการประมวลผลดิจิทัลแบบไม่ต่อเนื่องกับวิธีที่เรารับรู้และตีความสิ่งเร้า

    • มีบทบาทแยกต่างหากที่ใกล้กับสิ่งที่พูดมากกว่า เรียกว่า เทคนิคัลอาร์ติสต์ ซึ่งก็เป็นงานที่ผมทำอยู่ด้วย
      การที่กราฟิกส์โปรแกรมเมอร์มีวิธีคิดแบบศิลปินย่อมช่วยได้ แต่โดยปกติพวกเขาทำงานในระดับค่อนข้างต่ำ จึงไม่ใช่สิ่งจำเป็นต่อความสำเร็จ
    • นอกอุตสาหกรรมสร้างสรรค์ก็ใช้ได้เหมือนกัน ในซอฟต์แวร์ B2B/องค์กร ผมเห็นผู้ขายค่อนข้างมากที่ไม่รู้เลยว่าอุตสาหกรรมที่ตัวเองขายให้ทำงานอย่างไร หรือผู้ใช้คิดอย่างไร
      AI อาจเปลี่ยนสมการไปบ้าง หรืออย่างน้อยก็มีศักยภาพจะเปลี่ยน แต่ผมมองว่ากระแส “มาเรียนโค้ดกัน” ช่วงกลางทศวรรษ 2000 ก็เกิดจากเหตุผลแบบนี้อยู่มาก คือการมองการพัฒนาซอฟต์แวร์เหมือน “ฟังก์ชัน ไม่ใช่ผลิตภัณฑ์” ของผู้เชี่ยวชาญในสาขาเดิม เพื่อให้คนที่รู้โดเมนดีที่สุดสร้างซอฟต์แวร์เอง แทนที่จะต้องแปล requirements ไปให้ทีมพัฒนา
    • เห็นด้วย 100% กราฟิกส์โปรแกรมเมอร์ที่ดีทำงานร่วมกับเทคอาร์ติสต์และอาร์ติสต์
      พูดตรง ๆ กราฟิกส์โปรแกรมมิงโดยมากใกล้เคียงกับ บทบาทบริการ ที่ทำให้สิ่งที่คนเหล่านั้นอยากทำเป็นไปได้ หรือช่วยให้พวกเขาสร้างสิ่งที่จินตนาการไว้
      Inigo Quilez มักถูกยกเป็นตัวอย่างของคนที่เป็นทั้งกราฟิกส์โปรแกรมเมอร์และศิลปิน ซึ่งเป็นคนที่ทรงพลังมากและเหมือนยูนิคอร์นจริง ๆ

โดยส่วนตัวแล้วผมชอบการเล่นดนตรีและการเขียนโปรแกรมเสียงมากกว่า และมันก็เป็นพื้นฐานที่ดีสำหรับการเรียน DSP เช่น ถ้าดัน noise ของการเรนเดอร์ไปไว้ย่านความถี่สูง บางครั้ง low-pass filter ก็จะกำจัด noise ได้มีประสิทธิภาพกว่า

  • รายการที่ผมทำและดูแลอยู่ที่นี่: https://legends2k.github.io/note/cg_resources/
    ถ้าเกิดความสนใจและมีเวลา ก็น่าเรียนรู้ไว้ มันสนุกจริง ๆ ได้เรียนรู้อะไรเยอะ และยังทำให้คุณเป็นวิศวกรที่ดีขึ้นในอีกหลายสาขาของวิทยาการคอมพิวเตอร์ด้วย คุณจะเข้าใจฮาร์ดแวร์, system programming, machine model ของโปรแกรมเมอร์ ฯลฯ
    แต่ถ้าเอาเงินเป็นเป้าหมายสุดท้าย ก็อาจไม่ควรเรียน ในยุคนี้ผลตอบแทนของมันเลือนลาง ชั่วคราว และไม่รับประกัน
    • ผมเองก็ใช้แหล่งข้อมูลนี้อยู่ และอาจมีประโยชน์กับคนอื่นด้วย: https://owlcat.games/learning
  • น่าจะต้องรวมเงื่อนไขว่า “อายุต่ำกว่า 25 และมีเวลาให้ทุ่มกับเรื่องนี้มาก” ด้วย
    ผมสนใจ graphics programming มานานแล้ว และเมื่อไม่กี่ปีก่อนเริ่มเรียน Vulkan ด้วยตัวเอง ไม่รู้ว่าใช้เวลาไปรวมทั้งหมดเท่าไร แต่คิดว่าน่าจะใช้เวลาว่างตอนเย็นอยู่ราว 6 เดือน หรืออาจน้อยกว่านั้นนิดหน่อย ผมทำสิ่งที่ใกล้เคียงกับ rendering framework ได้
    แต่ยิ่งไปต่อก็ยิ่งเป็นงานประเภทที่ทำให้รู้ว่าตัวเองไม่รู้อะไรอีกมากแค่ไหน พอเริ่มรู้สึกว่าโครงสร้างดูเข้าท่าแล้ว ก็พบว่ามันไม่ใช่สถาปัตยกรรมที่ถูกต้อง
    สุดท้ายสิ่งที่ทำอยู่โดยพื้นฐานคือ คณิตศาสตร์แสงประยุกต์ ส่วนที่เหลือคือ plumbing “ทำไม spotlight ถึงทะลุ cube ไปเฉย ๆ?” พอดูก็พบว่าต้องคำนวณ shadow แล้วก็ต้องขุดลึกเป็นสัปดาห์ว่าจะเอามันใส่เข้าไปใน render pipeline ยังไง แต่ถ้าคุณชอบอะไรแบบนี้ มันก็ “สนุก” พอสมควร
    • น่าเสียดายที่ Vulkan เป็นวิธีเรียน graphics programming ที่ทรมานมาก แทบทุกอย่างต้องใช้ boilerplate code มหาศาล
      เช่น แม้แต่ตอนทำ shadow ก็ต้องเขียนโค้ดมากกว่าที่ตัวเทคนิคเองจำเป็นต้องใช้จริง ๆ ถึง 10 เท่า
      ถ้าจะเรียน graphics programming ผมคิดว่าการเขียน software renderer สนุกกว่ามาก โค้ดน้อยกว่า และโค้ดที่เขียนก็แตะถึงแก่น ไม่ใช่ boilerplate ข้อเสียคือเสีย hardware acceleration ไป จึงช้าลง
  • ขึ้นอยู่กับว่าคุณอยากทำอะไร
    ถ้าแค่อยากทำเกม ก็ใช้ game engine อย่าง Unity, Godot, Unreal ได้เลย
    ถ้าอยากทำ graphics อย่าง engine, simulation, renderer ก็ต้องเรียนภาษา low-level และ graphics API สำหรับภาษา ผมแนะนำ C++ ส่วน C หรือ Rust ก็ใช้ได้ แต่ C ค่อนข้างยาก และ graphics API เองก็ยากอยู่แล้ว คุณคงไม่อยากต้องสู้กับภาษาด้วย Rust ก็อาจเป็นตัวเลือกที่ดี แต่โดยส่วนตัวรู้สึกว่า compile time ช้ามาก และ syntax ดูไม่สวย
    ส่วน API ผมแนะนำ OpenGL มัน cross-platform เก่าแก่ ซึ่งเป็นทั้งข้อดีและข้อเสีย และเป็นตัวที่ง่ายที่สุดในบรรดานั้น
    learnopengl.com เป็นบทเรียน OpenGL ที่ดีที่สุดอย่างชัดเจน แนะนำให้ลองทำตาม
    หลังจากใช้ OpenGL ไปสักพักแล้ว จะขยายไป Vulkan หรือ graphics library ที่ implement หลาย API ก็ได้ หรือถ้าพอใจก็ใช้ OpenGL ต่อไปได้
    แน่นอนว่ามันไม่ง่าย แต่ผมคิดว่าเป็นหนึ่งในสาขาที่น่าหลงใหลที่สุดของวิทยาการคอมพิวเตอร์
  • ผมสร้าง A-Frame (aframe.io) และยังดูแลอยู่ มันทำหน้าที่เป็นทางเข้าสู่การเรียนรู้ 3D graphics แบบนุ่มนวลมาตลอด 10 ปีที่ผ่านมา
    พูดเองก็เขิน แต่ community ก็น่าทึ่ง เว็บเป็นวิธีที่ดีในการแชร์สิ่งที่สร้างระหว่างเรียน รวบรวม feedback และเพิ่ม visibility ใน community เองก็มีหลายกรณีที่กลายไปทำ 3D graphics อย่างมืออาชีพ
    • ผมเขียนวิทยานิพนธ์ปริญญาโทด้วย A-Frame ตอนนั้นยังไม่ใช่โปรแกรมเมอร์และแทบไม่มีประสบการณ์ แต่ A-Frame ช่วยให้ผม implement ไอเดียของตัวเองได้อย่าง intuitive มาก
      บางครั้งย้อนกลับไปดู repository แล้วก็อายที่โค้ดตอนนั้นเละมาก แต่ถ้าไม่มีโปรเจกต์นั้น ผมคงไม่ได้มาอยู่จุดนี้
    • แนะนำได้แน่นอน
      เริ่มจาก tag ง่าย ๆ แล้วเพิ่ม animation ถ้ายังไม่พอก็เพิ่ม community component ถ้ายังไม่พออีกก็แก้ด้วย ThreeJS และไปได้ถึง shader เลย A-Frame ยอดเยี่ยมมาก
      แถมยังทำ AR และ VR ได้ด้วย
  • รู้สึกเหมือนเราพยายามเปลี่ยนทุกอย่างที่ทำให้กลายเป็น career หรืออาชีพ โดยเฉพาะยังพ่วงมุมมอง machine learning แปลก ๆ เข้าไปด้วย
    แทนที่จะ “เป็น graphics programmer” ลองแค่ ทำ graphics programming ดูดีไหม? เริ่มจากอะไรง่าย ๆ ไปก่อนจนจับทางได้ และเมื่อเห็นว่าสุดท้ายมันคือการส่ง logistics ไปยัง GPU ก็สามารถต่อยอดแนวคิดซับซ้อนสารพัดไว้ข้างบนได้
    มันเหมือนปีนภูเขาลูกเล็ก ๆ แล้วจู่ ๆ ทุกอย่างก็ลงล็อกพอดีจน “ว้าว…” คุณจะเริ่มเห็นความเป็นไปได้และสิ่งต่าง ๆ ให้ทดลอง
    • ผมไม่คิดว่าสำนวนนี้จำเป็นต้องหมายถึง career หรืออาชีพเสมอไป มันใกล้เคียงกับการบอกตัวตนมากกว่า
      คำอย่าง “ฉันเป็นนักปีนผา”, “เป็น gamer”, “เป็น artist”, “เป็นแม่”, “เป็นพ่อ”, “เป็นคนติด gym”, “เป็น graphics programmer” ไม่ได้จำเป็นต้องหมายถึงอาชีพ แต่บอกนัยถึงบางอย่างที่ลึกกว่าการมีส่วนร่วมแบบผิวเผินที่ผ่านเข้ามาชั่วคราว
  • ผมเปิด บทเรียน ray tracing นั้นแล้วกำลังค่อย ๆ ทำตามอยู่ สนใจมานานแล้วแต่ไม่เคยได้ลอง
    วันนี้ได้เรียนรู้รูปแบบภาพ PPM ซึ่งเข้าถึงง่ายมากสำหรับงานแบบนี้ การเขียน bitmap ก็ไม่ใช่วิทยาศาสตร์จรวดอะไรอยู่แล้ว แต่ PPM ง่ายกว่านั้นอีก