จะเป็นโปรแกรมเมอร์กราฟิกได้อย่างไร
(gpuopen.com)- การเริ่มต้นด้านกราฟิกไม่ได้มีคำตอบเดียว แต่ขึ้นอยู่กับ ความรู้เดิม วิธีการเรียนรู้ และฮาร์ดแวร์ โดยทีม AMD Game Engineering มองว่าสำหรับผู้เริ่มต้นอาจต้องมีจุดเริ่มที่เป็นมิตรมากกว่านี้
- การเขียนโปรแกรมกราฟิกมีโครงสร้างที่ต้องเขียนทั้ง โค้ด C++ ฝั่ง CPU และ โค้ดเชดเดอร์ ฝั่ง GPU แล้วเชื่อมทั้งสองส่วนเข้าด้วยกันผ่านกราฟิก API อย่าง DirectX, Vulkan, OpenGL
- ณ ปี 2023 ตัวเลือกหลักแบ่งออกเป็น API แบบดั้งเดิม อย่าง OpenGL, DirectX 11, WebGL และ API สมัยใหม่แบบ explicit อย่าง Vulkan, DirectX 12, Metal, WebGPU
- API แบบดั้งเดิมเรียนง่ายกว่า แต่ความซับซ้อนของไดรเวอร์และรันไทม์เพิ่มสูงขึ้น ส่วน API สมัยใหม่ต้องใช้โค้ดมากกว่าและต้องเข้าใจ GPU มากขึ้น แลกกับการควบคุมที่มากกว่า
- ในช่วงแรกสามารถเริ่มจากสภาพแวดล้อมที่ง่ายกว่าอย่าง OpenGL, WebGL, เกมเอนจิน หรือ Shadertoy ได้ และหากเข้าใจ C++ กับ GPU pipeline ดีพอ ก็สามารถเริ่มที่ Vulkan หรือ DirectX 12 ได้ทันที
โครงสร้างพื้นฐานของการเขียนโปรแกรมกราฟิก
- คำตอบสั้น ๆ ว่ากราฟิกโปรแกรมเมอร์ใช้ภาษาอะไรเป็นหลักคือ C++
- งานจริงจะเป็นการเขียนทั้งโค้ดโฮสต์ที่รันบน CPU และ โค้ดเชดเดอร์ ที่รันบน GPU ควบคู่กัน
- โค้ดโฮสต์ฝั่ง CPU มักเขียนด้วย C++
- โค้ดฝั่ง GPU มักเขียนด้วยภาษาสำหรับเชดเดอร์ระดับสูง เช่น HLSL หรือ GLSL
- กราฟิก API คือจุดเชื่อมที่ทำให้โค้ดฝั่ง CPU สามารถสั่งงาน GPU โดยใช้เชดเดอร์ รวมถึงข้อมูลและเมทาดาทาที่จำเป็นได้
ควรเริ่มจากกราฟิก API ตัวไหนดี
- ณ ปี 2023 API ที่ใช้กันทั่วไปในเกมพีซีและแอปพลิเคชัน 3D แบ่งได้เป็นสองกลุ่มใหญ่
- API แบบดั้งเดิม: OpenGL, DirectX 11, WebGL
- API สมัยใหม่แบบ explicit: Vulkan, DirectX 12, Metal, WebGPU
- OpenGL, DirectX 11 และ WebGL อิงจากแนวทางเชิงประวัติศาสตร์ของการโปรแกรม GPU ซึ่งในมุมของโปรแกรมเมอร์จะเรียบง่ายกว่าและเรียนรู้ได้ง่ายกว่า
- แต่ความเรียบง่ายนั้นก็มีต้นทุน
- เมื่อเวลาผ่านไป การทำงานภายในของไดรเวอร์และรันไทม์มีความซับซ้อนมากขึ้น
- นำไปสู่คอขวดฝั่งโฮสต์และภาระของไดรเวอร์ที่ซับซ้อนซึ่งผู้ผลิต GPU ต้องเป็นคนพัฒนา
- Mantle ของ AMD ปรากฏบนพีซีในช่วงปี 2013~2016 และมอบการเข้าถึง GPU ในระดับที่ต่ำลงพร้อม abstraction ที่บางกว่า ผ่านความร่วมมือระหว่าง AMD GPU และ EA DICE
- Metal เปิดตัวบนแพลตฟอร์ม Apple ในปี 2014 ส่วน DirectX 12 และ Vulkan เปิดตัวในปี 2016 โดยหันไปใช้แนวทางการโปรแกรม GPU ที่ต่ำระดับกว่าและ explicit มากขึ้น
จุดแลกเปลี่ยนด้านการเรียนรู้ระหว่าง API ที่ง่ายกับ API แบบ explicit
- Vulkan และ DirectX 12 มีภาระช่วงต้นสูงกว่า เพราะโปรแกรมเมอร์ต้องระบุให้ชัดเจนขึ้นว่าอยากให้ GPU ทำงานอะไร
- แต่ในทางกลับกันก็ได้อำนาจควบคุมมากขึ้น และมีโอกาสเพิ่ม ประสิทธิภาพและความคุ้มค่า ของงานบน GPU ได้มากขึ้น
- แค่ดูตัวอย่างการวาดสามเหลี่ยมแรกก็เห็นความต่างของ API ได้แล้ว
- OpenGL หรือ DirectX 11 สามารถวาดสามเหลี่ยมแรกได้ด้วยโค้ดประมาณ 10 บรรทัด
- Vulkan และ DirectX 12 ต้องใช้โค้ดมากกว่านั้นอย่างมาก
- OpenGL และ DirectX 11 ซ่อนรายละเอียดไว้มาก ทำให้เข้าถึงงานกราฟิกเชิงผลิตจริงได้เร็ว แต่ก็อาจทำให้การทำงานของ GPU ดูเหมือน กล่องดำลึกลับ
- Vulkan และ DirectX 12 ต้องการความรู้ระดับล่างและความเข้าใจ GPU ตั้งแต่ต้น แต่ข้อดีคือแต่ละบรรทัดของโค้ดจะสะท้อนชัดเจนขึ้นว่าเกิดอะไรขึ้นบน GPU
ตัวเลือกของเส้นทางเริ่มต้น
- แม้แต่ภายในทีม AMD Game Engineering ก็ยังมีทั้งความเห็นว่าการเริ่มด้วย DX12 หรือ Vulkan สำหรับวัยรุ่นหรือผู้เริ่มต้นนั้นหนักเกินไป และความเห็นว่าถ้าเงื่อนไขพร้อมก็สามารถเริ่มได้
- แม้ OpenGL จะไม่ใหม่และไม่เกี่ยวข้องกับงานสมัยใหม่มากเท่าเดิม แต่ก็ยังถูกมองว่าเพียงพอสำหรับการเรียนพื้นฐาน
- WebGL อาจเป็นจุดเริ่มต้นที่ทำให้เข้าใจกราฟิก pipeline ได้ง่าย
- บนเว็บสามารถทำกราฟิกแบบเรียลไทม์ด้วย JavaScript โดยไม่ต้องใช้ C++
- หากใช้ WebAssembly ก็สามารถรันกราฟิก C++ บนเบราว์เซอร์ได้เช่นกัน
- WebGPU ให้แนวคิดที่ใกล้กับกราฟิก API สมัยใหม่มากขึ้น แต่ก็อาจไม่ต้องการรายละเอียดระดับล่างมากเท่า
- เมื่อเริ่มเขียนโค้ดที่ซับซ้อนขึ้น ก็ยังอาจเจอปัญหาหลายอย่างได้
- แต่ในฐานะ API สำหรับการทำต้นแบบ การเรียนรู้ และการศึกษา ก็ยังมีอนาคตที่น่าสนใจ
- การเริ่มจากเกมเอนจินก่อนก็เป็นอีกวิธีหนึ่ง
- Unreal Engine มีสัดส่วนสำคัญมากในวงการเกมพีซี
- Unity ก็เป็นทางเลือกที่พบได้บ่อย
- ยังมีเอนจินโอเพนซอร์สที่เล็กและเรียบง่ายกว่าอย่าง Godot
- บางสถาบันสอนวิชาเรนเดอร์เบื้องต้นด้วย Unity แต่ก็มีความเสี่ยงที่นักเรียนจะไม่เข้าใจว่าทำไมจึงต้องเรียนความรู้ระดับล่าง
- หากจะเริ่มจาก API แบบ explicit ก็ควรเข้าใจภาพรวมของกราฟิก pipeline สมัยใหม่และฮาร์ดแวร์ GPU ที่นำไปใช้งานได้ดีอยู่แล้ว หรืออย่างน้อยต้องพร้อมเรียนความเข้าใจนั้นไปพร้อมกัน
แหล่งเรียนรู้แนะนำและก้าวถัดไป
- LearnOpenGL: เว็บไซต์สำหรับผู้เริ่มต้นที่เหมาะกับการเรียนกราฟิกโปรแกรมมิงผ่าน API จริงใน C++
- Scratchapixel: เหมาะสำหรับโฟกัสว่าแนวคิดอย่าง ray tracing ทำงานอย่างไรโดยไม่ต้องพึ่งโค้ดมาก
- Udemy: ใช้เป็นแหล่งค้นหาคอร์สสำหรับผู้เริ่มต้นได้
- Rastertek: บทสอน OpenGL และ DirectX 11
- Ray Tracing in One Weekend: หากพอเขียนโค้ดได้แล้ว วิธีเรียนด้วยการลงมือสร้างเองเหมาะมาก
- A trip through the graphics pipeline: แม้จะเป็นบทความปี 2011 ก่อนยุค API แบบ explicit แต่แนวคิดด้านฮาร์ดแวร์และซอฟต์แวร์จากมุมมอง GPU ยังใช้ได้อยู่
- learn wgpu: เว็บไซต์เรียน WebGPU ที่มีสไตล์คล้าย LearnOpenGL และยังอยู่ระหว่างพัฒนา
- Your first WebGPU app: ใช้เป็นสื่อเริ่มต้นสำหรับ WebGPU ได้
- Shadertoy: เป็นจุดเริ่มที่ง่ายกว่า เพราะสามารถเขียนเชดเดอร์ได้โดยไม่ต้องจัดการกราฟิก API โดยตรง
- Vulkan Tutorial: เมื่อต้องเรียน Vulkan หรือ DirectX 12 ก็มีประเด็นสำคัญว่าการไม่กลัว copy-paste ก็เป็นส่วนหนึ่งของการเรียนรู้
- หากยังตัดสินใจไม่ได้ว่าจะเลือกภาษาไหนหรือ ecosystem ของ API ใด ก็ลองหลายแนวทางแล้วใช้วิธีที่เหมาะกับตัวเองต่อไปได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สำหรับมือใหม่ แทนที่จะเริ่มจาก “จะใช้เครื่องมืออะไรดี” ควรถอยออกมาหนึ่งก้าวแล้วถามก่อนว่า “อยากสร้างอะไร”
แม้ตอนเริ่มเรียน ก็อย่าลืม ผลลัพธ์สุดท้าย ทุกวันนี้ในคอมพิวเตอร์กราฟิกส์มีเครื่องมือมากมายที่ช่วย abstraction ขั้นตอนต่าง ๆ ของการวาดพิกเซลลงบนหน้าจอ จนอาจทำให้คุณเสียเวลาลำบากกับโค้ดระดับต่ำตั้งแต่แรก แล้วมารู้ทีหลังว่าสาขาที่ตัวเองอยากไปใช้แค่ Unity, TouchDesigner, threejs, After Effects และแทบไม่ใช้ C++ เลย
แน่นอนว่าการเรียนรู้ว่าข้างล่างทำงานอย่างไรมีคุณค่ามหาศาล แต่ผมมองว่าการเริ่มจากตรงนั้นเป็นแนวทางที่ช้า การเรียนรู้จะเร็วกว่าเมื่อเข้าสู่อุตสาหกรรม แล้วใช้เครื่องมือ abstraction อย่าง game engine หรือ visual programming เพื่อจับแนวคิดการทำงานภายใน
พูดในฐานะคนที่ใช้เวลาหลายปีเรียน C++ และ OpenGL อย่างยากลำบาก และต่อสู้อยู่นานกับ ต้นทุนจม ที่ทำให้ยอมรับแนวทาง no-code ไม่ได้ สุดท้ายถ้ามันไม่ได้ช่วยให้สร้างสิ่งที่อยากสร้าง ก็อย่าเสียเวลากับเส้นทางนี้จะดีกว่า
แม้ไม่ได้เขียนตำราแบบ Mark Kilgard แต่ผมลงลึกกับ API หลายชั้น ตั้งแต่ระดับไดรเวอร์ การทดสอบความสอดคล้องตามมาตรฐาน การจูนประสิทธิภาพ โค้ดเกมและแอปพลิเคชัน ไปจนถึงแพลตฟอร์มเดสก์ท็อปและมือถือหลัก ๆ
แต่สุดท้ายมันพาไปไหน? จริง ๆ แล้วไปได้ไม่ไกลเท่าไร ตอนนี้แทบไม่มีใครสนใจ OpenGL แล้ว และเมื่อผู้ผลิต OS รายใหญ่สองรายทิ้งมันไปในที่สุด ก็แทบเป็นเทคโนโลยีที่ตายแล้ว ลองค้นคำว่า OpenGL ใน “HN Who's Hiring” ก็จะเห็น
จะกลับไปเรียน graphics API อื่นอย่าง Direct3D, Vulkan, Metal ก็ได้ แต่โค้ดกราฟิกส์ระดับต่ำตอนนี้ถูก engine ทำ abstraction ให้แล้ว จึงมีที่ที่ต้องการคนแบบนั้นไม่มาก บริษัทที่ต้องการคนทำไดรเวอร์กราฟิกส์ระดับต่ำทั่วโลกก็น่าจะมีอย่างมาก 5–6 แห่ง กลายเป็น ช่องเฉพาะที่จำกัดเส้นทางอาชีพ
ยิ่งคุณโฟกัสกับส่วนที่เล็กลงของเครื่องมากเท่าไร ถ้าจะยึดสิ่งนั้นเป็นทั้งอาชีพ คุณก็ยิ่งต้องเป็นผู้เชี่ยวชาญระดับโลก ถ้าไม่ได้วางแผนจะเป็น John Carmack คนต่อไป ผมแนะนำให้ไปให้กว้างมากกว่าขุดให้ลึก
บน YouTube เต็มไปด้วยวิดีโอสอนเขียนโปรแกรมสำหรับมือใหม่ที่ให้เรียน tech stack เป็นชุด ๆ มากกว่าจะโฟกัสกับการสร้างสิ่งที่น่าสนใจ ผลคือเพื่อเติมเรซูเม่ ก็สร้างเครื่องจักร Rube Goldberg ซับซ้อนแบบบูชาสินค้าขึ้นมาเพียงเพื่อ render ข้อความไม่กี่บรรทัดบนเว็บเพจ
ตอนเรียนมหาวิทยาลัยผมเคยทำ graphics programming นิดหน่อยหนึ่งเทอม ซึ่งมันซับซ้อนพอที่คำตอบสมเหตุสมผลต่อ “อยากสร้างอะไร” จะเป็นประมาณ “render สามเหลี่ยมสีเขียวบนพื้นหลังสีดำ” จากตรงนั้นการไปสู่สี่เหลี่ยม ลูกบาศก์ ทรงกลม ทรงกลมที่ animate ได้ และลูกบอลเด้ง เป็นพัฒนาการที่เป็นธรรมชาติและช่วยให้โฟกัสกับเป้าหมาย ดังนั้นต้องหลีกเลี่ยงความผิดพลาดในการตอบคำถามข้างต้นว่า “เกมยิงมุมมองบุคคลที่หนึ่งที่มีแสงแบบ ray tracing และ subsurface scattering”
โค้ดเวอร์ชันแรกของลูกบอลเด้งคงแย่มาก ๆ แต่ไม่เป็นไร เมื่อเวลาผ่านไปคุณจะรู้วิธี optimize และปรับปรุงมันเอง และไม่มีอะไรน่าตื่นเต้นเท่ากับการ ค้นพบ design pattern ด้วยตัวเอง พออ่านหนังสือเรื่องใหม่แล้วรู้สึกว่า “อ้าว อันนี้ฉันก็ทำอยู่แล้วนี่!”
แน่นอนว่าอาจเข้าด้วยบทบาทอื่นอย่าง gameplay programmer แล้วค่อย ๆ ย้ายไปสายกราฟิกส์ก็ได้ และอาจง่ายกว่าด้วย แต่สุดท้ายบทบาท graphics programmer ก็ต้องใช้ C++
สิ่งที่พูดก่อนหน้านี้น่าจะเหมาะกับคนที่อยากทำงานเกี่ยวกับกราฟิกให้ productive ได้เร็วมากกว่า ไม่ใช่ graphics programming โดยตรง
เครื่องมือเปลี่ยนไปตามเวลา และจากประสบการณ์ วิศวกรเก่ง ๆ มักใช้ เครื่องมือหลายอย่างในระดับความชำนาญที่หลากหลาย ได้ มากกว่าจะขุดลึกแค่อย่างเดียว
แม้ในงานจริงจะไม่ได้ทำสิ่งนั้น ก็ยังได้ความรู้เชิงทฤษฎีมากมายและได้ฝึกอัลกอริทึมที่ซับซ้อน
กราฟิกส์ยังให้ประสบการณ์คณิตศาสตร์ประยุกต์มากด้วย มีหลายสาขาจริง ๆ ที่ต้องการคนทำคณิตศาสตร์ได้อย่างมาก ที่ทำงานเก่าของผมซึ่งทำซอฟต์แวร์เครื่อง CNC ก็ต้องการคนเขียนโปรแกรมคณิตศาสตร์สำหรับควบคุมสว่านให้เจาะบล็อกโลหะออกมาเป็นรูปทรงเฉพาะ แต่หายากมากจริง ๆ ในทางกลับกัน วิศวกร cloud DevOps ถึงจะแพงแต่หาได้ค่อนข้างง่าย
ถ้าเป็น graphics programmer ผมคิดว่าควรมีความเข้าใจที่สมดุลในภาพรวมว่ากราฟิกส์ทำงานอย่างไร นอกเหนือจากการเขียนโปรแกรมพื้นฐานและความรู้ API แล้ว graphics programmer ที่ดีควรรู้เรื่อง เมทริกซ์การหมุน วิว และโปรเจกชัน, คณิตศาสตร์เวกเตอร์ทั่วไป, shader programming, procedural primitives อย่าง Voronoi, SDF, Perlin, การประกอบภาพ, forward rendering และ deferred rendering, เทคนิคการ sampling แบบต่าง ๆ, เทคนิคเงาและแสง
นอกจากนี้ยังต้องเข้าใจว่า art pipeline ทำงานอย่างไรและดึงข้อมูลออกจากแอป 3D อย่างไร ใช้ profiler และ debugger ได้คล่อง อ่าน paper ของ SIGGRAPH ได้ เทคนิค space partitioning และ volume hierarchy, การ implement ray tracer ง่าย ๆ, ความเข้าใจ primitive อย่าง sprite, triangle, n-gon รวมถึงประสบการณ์กับ particle และ simulation
ผมรู้ flow พื้นฐานมาก ๆ ของการสร้างโมเดล เช่น modeling → skin/rigging → animation → texturing และแนวทางคร่าว ๆ ในการเขียนสิ่งเหล่านี้ลงไฟล์ แต่ส่วนนี้เป็นจุดที่ยากเป็นพิเศษที่จะได้ ประสบการณ์ภาคปฏิบัติจริง ถ้าไม่ได้ทำงานร่วมกับ artist
ผมทำ graphics programming เป็นงานอดิเรกและเรียนรู้หลายอย่างที่พูดถึงที่นี่แล้ว แต่เพราะไม่มี ประสบการณ์ทำงานในตำแหน่งนี้ เลยแทบไม่ได้โอกาสสัมภาษณ์
ขอแนะนำคอร์ส Graphics From Scratch ของ Pikuma สิ่งแรกที่ทำคือเขียนฟังก์ชัน
set_pixelด้วย SDL และหลังจากนั้นทั้งคอร์สก็ให้ลงมือเขียนโค้ดเองทั้งหมดตั้งแต่ การคำนวณเมทริกซ์ ทุกอย่าง การแปลงจุดยอดทั้งหมด ไปจนถึงการ rasterize สามเหลี่ยมทั้งหมด ล้วนเขียนเองเพื่อคำนวณว่าแต่ละพิกเซลควรเป็นสีอะไร
https://pikuma.com/courses/learn-3d-computer-graphics-progra...
https://www.gabrielgambetta.com/computer-graphics-from-scrat...
หลังจากนั้นผมเรียน WebGPU ได้ภายในไม่กี่วัน ซึ่งคิดว่าคงเป็นไปไม่ได้ถ้าไม่ได้ความเข้าใจจากคอร์สนี้
ถ้าต้องการแรงจูงใจ ผมทำเดโมโดยคอมไพล์เรนเดอเรอร์ที่สร้างตอนท้ายคอร์สเป็น Wasm ไว้ด้วย: https://rmshin.github.io/3d-renderer-wasm
ควรเริ่มด้วยโค้ด SDL แบบ
putpixelเหมือนยุค 90 หรือเริ่มจาก Shadertoy ดี? คณิตศาสตร์เมทริกซ์พื้นฐานยังสำคัญเสมอแน่นอน แต่จะสอนการ rasterize สามเหลี่ยมอย่างไร? ข้าม scanline แล้วไปสู่พิกัดเชิงเอกพันธุ์กับ quadtree เลยได้ไหม?จำเป็นต้องสอน Phong shading จริงหรือ หรือจะข้ามไป BRDF เลยได้ไหม? บางส่วนอาจกลายเป็นการสอน “ทริกเก่าๆ” มากกว่าจะเป็นเทคนิคที่มีประโยชน์
ทุกวันนี้สถิติและการสุ่มตัวอย่างสำคัญกว่ามาก ผมเชื่อว่ากราฟิกยิ่งผ่านไปแต่ละปีก็ยิ่งเป็นคณิตศาสตร์มากขึ้น ดังนั้นต้องเรียนคณิตศาสตร์ และต้องสอนคณิตศาสตร์
ในบรรดานั้น ขอแนะนำ GitHub repository นี้อย่างแรง: https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting...
ถ้าคุณเป็นสายเรียนรู้ด้วยภาพ ช่องนี้ก็เป็น ขุมทรัพย์ เช่นกัน: https://www.youtube.com/watch?v=ih20l3pJoeU
คุณสามารถเรียนกราฟิกผ่าน การเขียน shader บน Shadertoy ได้ โปรแกรมเมอร์กราฟิกจำนวนมากก็เริ่มจากที่นั่น
ขอโปรโมตตัวเองเล็กน้อย ผมทำ tutorial ไว้มากกว่า 10 ตอน ครอบคลุมการเขียน shader ใน VS Code, SDF, ray marching, noise functions, fractal Brownian motion และอื่นๆ
https://github.com/suboptimaleng/shader-tutorials
แน่นอนว่าเป็นการยืนอยู่บนไหล่ยักษ์อย่าง Inigo Quilez, The Art of Code, SimonDev, Acerola
มีเส้นทางมากมายจริงๆ ในการเป็นโปรแกรมเมอร์กราฟิกโดยไม่ต้องเริ่มจาก DX/VK/OGL และก็ไม่จำเป็นต้องใช้ C++ ด้วย แค่ดูงานกราฟิก 3D น่าทึ่งที่ 3Blue1Brown ทำด้วย Python ก็พอ
ถ้าอยากใช้เกมเอนจิน ก็เรียน DirectX หรือ Vulkan ถ้าอยากทำแอปพลิเคชันบนเบราว์เซอร์ ก็เรียน WebGL
แต่ API พวกนั้นหนัก และตัวมันเองก็ไม่ได้สอนเรื่องกราฟิกให้มากนัก ถ้าอยากเรียนแนวคิดกราฟิก แนะนำให้ลองสร้างทั้ง rasterizer และ ray tracer ด้วยตัวเองในภาษาที่ต้องการ
ยังมีไลบรารีกราฟิกและสภาพแวดล้อมการเขียนโค้ดอีกมากที่สนุกกว่าการขุด Vulkan หรือ DirectX อย่างยากลำบาก Processing นั้นยอดเยี่ยม และ Python-based PlotDevice.io รวมถึงรุ่นก่อนหน้าอย่าง NodeBox และ DrawBot ก็น่าดู ShaderToy ก็เป็นอีกที่ที่เรียนเรื่องการเขียน shader หรือ rendering ได้มาก และเริ่มต้นง่าย ใน JavaScript ก็มีตัวเลือกและไลบรารีมากมาย สิ่งเหล่านี้เข้าถึงง่ายกว่าและสร้างแรงจูงใจให้มือใหม่ได้มากกว่า แต่ก็ยังมีพลังและความยืดหยุ่นพอให้ผู้เรียนที่อยากรู้อยากเห็นลงลึกได้เท่าที่ต้องการ
ในเมื่อบทความนี้ขึ้นหน้าแรกแล้ว ผมขอแชร์แหล่งข้อมูลที่ใช้จริงในวงการเขียนโปรแกรมกราฟิก อนึ่ง ผมเป็นหนึ่งในผู้เขียน: https://raytracing.github.io/
ในบทความข้างบนก็มีอยู่ในส่วน “Useful Websites” ด้วย
กราฟิกตอนนี้กว้างมากจน ไม่มีวิธีเรียนเดียวที่เหมาะกับทุกคน อีกต่อไปแล้ว ถ้าอยากเรียนกราฟิก ผมแนะนำให้หา mentor
ผมเป็นนักพัฒนาเกม แต่ไม่ใช่โปรแกรมเมอร์กราฟิกมืออาชีพ ในงานผมใช้ API กราฟิกสมัยใหม่กับ GLSL shader แต่ไม่นานมานี้ลูกวัย 13 ปีของผมเริ่มอยากขยับจาก Scratch หรือ Python ไปเรียน C++ ผมจึงตัดสินใจว่าวิธีที่ดีที่สุดคือหยิบ OpenGL 1.2 DLL เก่าๆ ที่ยังอยู่ในคอมพิวเตอร์มาตั้งแต่ปี 1999 ออกมา แล้วให้เริ่มเขียนโค้ด immediate mode แบบ
glutและglbegin/glvertex/glendสนุกกว่าการต้องทนกับการตั้งค่าจิปาถะที่ API สมัยใหม่ต้องการมาก ลูกผมสนใจด้านเรขาคณิตเชิงคำนวณอย่าง Voronoi diagram มากกว่า ดังนั้น API กราฟิกเป็นแค่เครื่องมือเพื่อไปถึงเป้าหมายเท่านั้น และตอนนี้ shader หรือ lighting สวยๆ ยังไม่ใช่เรื่องสำคัญ ประสิทธิภาพของ C++ กับ OpenGL เก่าๆ เร็วกว่า Scratch ราวพันเท่า จึงดูเหมือนเจอจุดที่ดีสำหรับขั้นการเรียนรู้ตอนนี้
แม้จะใช้ OpenGL 1.2 API แบบง่ายแล้ว การพยายามเข้าใจ C++ กับ OpenGL ไปพร้อมกันก็ยังเป็นปริมาณการเรียนที่ค่อนข้างทะเยอทะยาน ความเรียบง่ายจึงช่วยให้รับมือทางใจได้ ตอนนี้ไปได้ดี ลูกผมทำเดโม marching squares ที่ใช้ได้ และผมช่วยใส่เมนู IMgui ให้ปรับพารามิเตอร์ตอนรันไทม์ได้ สนุกทีเดียว
ผมไม่ค่อยแน่ใจว่าเว็บไซต์นี้กำลังถามอะไรกันแน่ อยากทำ rigging เหรอ? texturing? modeling? เขียน driver? ทำ GUI? แอนิเมชันเว็บไซต์? เครื่องมือกราฟิก? shader? เอนจินภาพถ่าย 2D? เกม 2D? เกม 3D? สคริปต์เชิงกระบวนวิธี? การปรับแต่งโค้ดกราฟิกให้เร็วขึ้น?
ภายใต้คำว่า “คอมพิวเตอร์กราฟิก” มีสาขาย่อยอยู่เป็นร้อย ๆ แต่เว็บไซต์นี้โฟกัสไปที่มุมเล็ก ๆ มุมหนึ่งในนั้น คือ การเขียนโปรแกรม Graphics SDK
โดยทั่วไปคาดหวังว่า graphics programmer จะต้องทำงานได้ครอบคลุมทั้งเกม, 3D, 2D, เครื่องมือ, shader และการปรับแต่งประสิทธิภาพ
ผมเองก็อยู่บนเส้นทางนั้นเหมือนกัน เมื่อ 2 ปีก่อนผมทำเอนจิน 3D ตัวแรก โดยทำตาม tutorial หลายชุดและวิดีโอ YouTube
มันเรียบง่ายมาก แต่ผมชอบอะไรที่เรียบง่าย ตอนนี้กำลังใช้เอนจินนี้ทำ เกมสร้างเมือง อยู่ การได้เรียนรู้วิธีจัดการองค์ประกอบต่าง ๆ ด้วยเมทริกซ์และ cross product สนุกมากจริง ๆ
https://www.youtube.com/watch?v=cvyrfPUpyp0