Cần học gì để trở thành lập trình viên đồ họa
(blog.demofox.org)- Năng lực tuyển dụng trong đồ họa thời gian thực đòi hỏi đồng thời API đồ họa tường minh phía CPU và chiếu sáng·shading phía GPU, và rất khó để học sâu cả hai mảng cùng lúc
- Phía CPU xử lý các API hiện đại như DirectX12, Vulkan, Metal, cùng việc tải asset và các công việc hỗ trợ engine; phía GPU xử lý shadow, ambient occlusion, hậu xử lý và các đặc tính hiệu năng GPU
- Trọng tâm học GPU là viết path tracer và hiểu PBR; Ray Tracing in One Weekend, LearnOpenGL PBR, tài liệu Filament và PBRT có thể là điểm khởi đầu
- Portfolio lý tưởng là thể hiện kiến thức bằng một renderer thời gian thực dựa trên C++, một path tracer tạo ảnh giống ảnh chụp, và mã so sánh·kiểm chứng kết quả của hai cách render
- Toán cần thiết chủ yếu là đại số tuyến tính, lượng giác cơ bản và một chút giải tích; ngôn ngữ phía CPU trong phát triển game là C++, còn ngôn ngữ shader phổ biến nhất là HLSL
Đồ họa thời gian thực bao gồm cả hai mảng CPU và GPU
- Rendering hiện đại thực chất gần như là sự kết hợp của hai công việc
- Học phía CPU: các API tường minh hiện đại như DirectX12, Vulkan, Metal, cùng lập trình engine để tải asset và các công việc hỗ trợ khác
- Học phía GPU: toán học chiếu sáng·shading hiện đại, shadow, ambient occlusion, hiệu ứng hậu xử lý, và sự khác biệt giữa các tác vụ nhanh và chậm trên GPU
- Rất khó để học đồng thời cả hai mảng
- Nếu muốn tập trung vào phía GPU, có thể dùng các công cụ có gánh nặng phía CPU thấp như OpenGL, WebGL, DirectX11 hoặc các engine có sẵn
- Nếu muốn tập trung vào phía CPU, hãy bắt đầu bằng việc hiển thị một tam giác lên màn hình, sau đó là hiển thị mesh, và không cần quá bận tâm liệu kết quả có đẹp hay không
Path tracing và PBR
- Việc học phía GPU bao gồm viết path tracer
- Path tracing là phương pháp được dùng trong rendering phim, và là mục tiêu mà các kỹ thuật rendering thời gian thực hiện đại đang cố gắng xấp xỉ
- Tài liệu khởi đầu phù hợp là cuốn sách online miễn phí Ray Tracing in One Weekend, dễ tiếp cận và cho thấy quá trình tạo ra rendering giống ảnh chụp
- Physically Based Rendering(PBR) là cách áp dụng chiếu sáng, đặc biệt là specular
- PBR là phương pháp dựa trên nguyên tắc: nếu tuân thủ các quy tắc thì sẽ đạt kết quả tốt
- Trước PBR, người ta dùng rất nhiều công thức tùy ý, tinh chỉnh và hack cho chiếu sáng, nên asset trông đẹp trong một môi trường ánh sáng có thể trông quá tối hoặc quá sáng bóng trong môi trường khác
- Kết quả là phải tạo các phiên bản asset khác nhau cho từng điều kiện chiếu sáng, tốn nhiều thời gian và công sức
- PBR giúp asset trông nhất quán hơn trong nhiều điều kiện chiếu sáng và giảm thời gian, công sức tạo asset theo từng phiên bản
- Dù vậy, thời gian, chi phí và công sức tạo asset vẫn là một nút thắt lớn trong phát triển game
Tài liệu học đề xuất
- Để nhập môn PBR, phần PBR Theory của LearnOpenGL và các mục con là phù hợp
- Nếu muốn đi sâu hơn, tài liệu Filament có thể là bước tiếp theo
- Càng học sâu PBR, giải tích và thống kê sẽ xuất hiện càng nhiều
- Xa hơn nữa có cuốn sách online miễn phí Physically Based Rendering: From Theory To Implementation
- Machine learning hiện tại có thể không đạt được kết quả như mức độ được thổi phồng, nhưng vẫn đáng học các kỹ thuật fitting và tối ưu hóa trong hộp công cụ khoa học máy tính
- Có thể tham khảo video Machine Learning For Game Developers làm tài liệu liên quan
Mã nên đưa vào portfolio
- Để chứng minh kiến thức với nhà tuyển dụng, lý tưởng nhất là đặt source code có thể chia sẻ ở nơi như GitHub và liên kết trong CV
- Ví dụ portfolio:
- Một renderer kiểu engine có thể tải asset như model và texture rồi render thời gian thực lên màn hình
- Bao gồm một số hiệu ứng như chiếu sáng và shadow, depth of field, area lights, tone mapping, ray traced shadows
- Nếu có thể, hãy dùng chiếu sáng dựa trên PBR, camera người dùng điều khiển được, API như DX12·Vulkan và C++
- Một path tracer tạo ảnh giống ảnh chụp
- Nếu có thể thì C++ là tốt, nhưng cũng có thể là chương trình không có cửa sổ và chỉ xuất PNG
- Không cần phải chạy thời gian thực
- Sẽ tốt hơn nếu path tracer là một chế độ riêng của renderer kiểu engine
- Có thể so sánh kết quả path traced với rendering PBR thời gian thực để kiểm chứng độ chính xác
- Nếu có thể chỉ ra các điểm mà hai kiểu rendering không khớp, giải thích vì sao khác nhau và nghĩ cách làm cho chúng gần nhau hơn trong khi vẫn giữ tính thời gian thực, bạn sẽ được đánh giá cao hơn
- Một renderer kiểu engine có thể tải asset như model và texture rồi render thời gian thực lên màn hình
Toán học, thuật toán và lựa chọn ngôn ngữ
- Nếu tự làm các mục trên, bạn sẽ tự nhiên gặp những phần toán cần thiết
- Về cơ bản, những thứ cần là phép nhân ma trận trong đại số tuyến tính, cross product, dot product, lượng giác cơ bản và một chút giải tích
- Đồ họa và phát triển game có mức toán tối thiểu cần thiết tương đối nhỏ, nhưng phạm vi toán có thể tận dụng thì gần như không giới hạn
- Thuật toán cũng tương tự
- Cần biết các kiểu dữ liệu trừu tượng và thuật toán cơ bản như linked list, hash table, sắp xếp, tìm kiếm
- Thuật toán nhanh nhất thường là thuật toán đơn giản, và array nhanh hơn linked list rất nhiều
- Các khái niệm thuật toán nâng cao hơn sẽ hữu ích khi thực sự cần một thứ mới và tùy biến
- Ngôn ngữ cần học trong phát triển game là C++
- Cũng có người dùng Rust và nó có một phần thị phần, nhưng đó không phải ngôn ngữ tiêu chuẩn mà mọi người kỳ vọng
- WebGPU có nhiều tính năng mà WebGL không có, đang trở thành một nền tảng nghiêm túc hơn, và cho phép làm phần CPU bằng JavaScript
- Tuy nhiên, tôi chưa thấy nhiều việc làm WebGPU hay nội dung WebGPU trên web
- Ngôn ngữ shader phổ biến nhất là HLSL
- Một số người dùng GLSL
- Trong game đa nền tảng, shader thường được chuyển đổi sang các ngôn ngữ shader khác
Phạm vi ứng dụng của LLM và ML
- Công nghệ ML hiện tại được xem là chưa đủ tốt cho hầu hết các trường hợp sử dụng đang được bán ra
- Claude hữu ích khi trao đổi về toán, bài báo và các thuật toán chưa quen thuộc
- Trong những tình huống này, dễ kiểm tra xem nó có đang bịa ra nội dung hay không, và cũng dễ đối chiếu tính hợp lý bằng nguồn khác
- Với lập trình thì không hữu ích lắm
- Ngay cả khi nó đưa ra mã hoạt động đúng như mong muốn, vẫn phải dành thời gian để hiểu đoạn mã đó
- Nếu vậy thì tự viết còn hơn
- Các công dụng nhỏ có thể hữu ích
- Ví dụ, nếu hỏi “trong file này có thấy bug không?”, khi câu trả lời là yes thì có thể điều tra, còn nếu no thì chi phí hỏi gần như bằng không
- Tôi tin rằng một ngày nào đó nhân loại sẽ tạo ra trí tuệ nhân tạo ở cấp độ con người và tiến xa hơn nữa, nhưng không biết thời điểm đó có nằm trong đời mình hay không
- Kỷ nguyên LLM hiện tại gần như là một buổi diễn tập cho lúc “hàng thật” xuất hiện sau này
1 bình luận
Ý kiến trên Hacker News
Trước hết cần phân biệt bạn muốn làm game hay muốn làm lập trình engine 3D
Nếu muốn làm game, tốt hơn nên dùng các engine có sẵn như Unreal Engine, Unity, Godot, Bevy; bạn sẽ học các vấn đề đồ họa ở mức cao hơn thay vì cách tự đẩy từng pixel. Phần thật sự khó là làm cho game thú vị
Nếu muốn làm engine 3D, cần biết rằng đã có quá nhiều game engine tệ hại rồi. Chỉ nhìn phía Rust thôi, các dự án chính đã gồm 3 renderer thất bại, 1 renderer chưa hoàn thiện và renderer trong Bevy; còn các dự án tuyên bố “sẽ làm game engine” thì nhiều hơn rất nhiều. Để đạt tới mức “renderer đầu tay” cũng mất khoảng 2 năm, còn đi tới các cảnh lớn, chi tiết và động thì là việc lớn hơn nhiều
Nếu mục tiêu là kiếm việc, ngành game có lương và giờ làm đều không tốt, dự án kết thúc thì việc cũng kết thúc, và như Hollywood, luôn đầy rẫy người muốn chen chân vào. Thêm nữa, do sự sụp đổ của Metaverse, hiện giờ ngay cả người có kinh nghiệm cũng đang dư thừa
Mobile là bài toán nén vì màn hình, năng lực tính toán, GPU và pin đều thiếu thốn; vì thế phần lớn game indie ngày nay là 2D. Như vậy còn khả thi, và cũng thường được làm bằng HTML/JavaScript
Nhưng việc tạo một renderer cơ bản và game loop không khó đến thế, và nhiều khả năng cũng không chiếm phần lớn mã game. Với một game đơn giản, chỉ cần
drawObject()trong vòng lặpforcũng đủ; các lo ngại như streaming tài nguyên, tối ưu binding, tính song song có thể để sau, khi thật sự cầnTôi tò mò tiêu chí “2 năm tới renderer đầu tay” đang giả định điểm xuất phát và điều kiện thành công nào. Khoảng một năm trước, trong thời gian rảnh một tháng, tức chưa tới 1 tuần nếu làm toàn thời gian, tôi đã làm một deferred renderer có chiếu sáng động, shadow mapping và vài hậu xử lý
Cũng không có lý do gì để xem nhẹ 2D. Rất nhiều công việc nghiêm túc diễn ra trên giao diện 2D, và WebGL cùng 2D canvas cũ ngày nay cũng khá mạnh. Trong các game indie thành công cũng có rất nhiều game 2D
Ngành game không hấp dẫn thì đúng, nhưng ngày nay gần như mọi thứ đều dùng GPU. Viết và gỡ lỗi tác vụ machine learning, trực quan hóa dữ liệu, HUD, cả giao diện người dùng thông thường cũng thường cần hiểu biết về đồ họa
Ngoài game, còn rất nhiều lĩnh vực dùng đồ họa như trực quan hóa, mô phỏng, và lập trình viên đồ họa giỏi thì cực kỳ hiếm, nên đây bất ngờ lại là một sự nghiệp khá ổn. Điều đó khá đối lập với việc có vẻ khó hơn nhiều để lập trình viên game hay nghệ sĩ kiếm được việc tốt. Tuy nhiên cả cung lẫn cầu đều nhỏ, nên chuyển việc có thể không dễ
Nếu chỉ xét độ ổn định nghề nghiệp, tôi muốn khuyên không nên lấy phát triển game làm sự nghiệp, nhưng lập trình đồ họa thì khác
Trong số các game tôi chơi vài năm gần đây, Core Keeper(Unity), WORMHOLE(Unity, đặc biệt là độ trễ ở chế độ vô hạn), Crab Champions(UE4, phải dùng upscaling làm hình ảnh xấu đi để giữ 60fps ở 1920x1200) gặp vấn đề hiệu năng nghiêm trọng
Ngược lại Terraria, Necesse, Barony dùng engine riêng và chạy rất tuyệt, càng lâu đời lại càng trông tốt hơn
Nói công bằng thì Tiny Rogues(Unity) theo tôi nhớ nhìn chung chạy khá ổn, nhưng nhà phát triển đang làm để rời khỏi Unity trong tương lai, nên có vẻ chính họ cũng đã thấy vấn đề
Tôi hiểu sự khác nhau giữa làm game và làm engine, cũng như tầm quan trọng của việc thật sự hoàn thiện và phát hành, nhưng nếu đưa ra đồ rác thì khó để lại di sản tốt. Tôi nghĩ tốt hơn nên đảm bảo một mức chất lượng nhất định, dù phải đi đường vòng xa hơn. Game đôi khi được chơi trong hàng chục năm sau khi phát hành, và nếu có lỗi hay độ trễ thì người chơi sẽ cứ phải chịu mãi
“Trước tiên tôi sẽ làm engine cho game của mình để các game sau dễ làm hơn” là một cái bẫy mạnh đến đáng kinh ngạc. Vì bạn thật sự học được những điều quan trọng và có những chiến thắng nhỏ mỗi ngày. Bạn unroll thêm một chỗ để cảnh trông mượt hơn, thêm một lớp logic vào định dạng cấu hình để tạo cảnh dễ hơn, rồi đọc thêm một bài SIGGRAPH nữa
Luôn có những thứ quan trọng cần cải thiện, nhưng chúng không hợp lại thành một game hoàn chỉnh. Nhìn lại, dùng engine tự viết là cách hoàn hảo để trì hoãn phần khó nhưng cần thiết của trò chơi trong mơ của một người kỹ thuật: “làm cho nó thú vị”. Bạn học được kỹ thuật code một trò chơi điện tử ấn tượng, nhưng không học được cách làm game
Cũng có những cái bẫy cấp dưới. Bạn học cả trăm cách tạo hiệu ứng thị giác đẹp chạy mượt thời gian thực, nhưng không học cách dùng chúng như nghệ thuật
Điều này cũng rất giống cái bẫy “Enterprise Java”. Chỉ là vì nó xử lý các thuật ngữ cụ thể nên tinh vi hơn. Bạn nghĩ mình đã né viên đạn đó vì Scene Graph không có Factory Factory Interface, nhưng thật ra lại bỏ lỡ rằng đối với việc hiển thị bitmap lên màn hình và phản hồi phím bấm, bản thân những thứ đó là không cần thiết
Đặc biệt là với 2D. Ví dụ, tôi đang làm một game bằng game engine tự viết, tập trung vào hiệu năng, nén, và kiến trúc không có server hay database
Engine này có cấu trúc và các giả định rất cụ thể về cấu trúc game để đạt hiệu năng và mức nén cực đoan trong những ràng buộc tôi đặt ra. Tôi dự định sẽ đăng một bài Hacker News liên quan trong thời gian sớm, nếu có thể là tuần sau
Trước đây tôi cũng nhiều lần thử làm game trình duyệt bằng Unity, Godot, React, nhưng việc học API quá cực nhọc, và các engine không đáp ứng được các ràng buộc cực đoan của tôi. Tất nhiên cũng có thể do tôi dùng các engine đó chưa giỏi, nhưng nhìn lại, tôi cho rằng những gì đã đạt được ở bên trong sẽ là bất khả thi nếu không có engine tùy chỉnh được làm từ đầu
Tôi đã học được rất nhiều khi tự làm engine và game, và đặc biệt ngày nay, nhờ LLM, tôi nghĩ việc một lập trình viên có kinh nghiệm tự thử làm game engine tùy chỉnh bỗng trở nên nằm trong phạm vi thực tế đối với phần lớn lập trình viên
Nếu là bây giờ, tôi sẽ không khuyên bất kỳ ai bước vào lập trình đồ họa
Tôi bắt đầu vào năm 2001, khi Nvidia công bố GeForce 1 đầu tiên, cái gọi là “Gigatexel shader card”; từ đó về sau, tốc độ phát triển và đổi mới của lĩnh vực này thật chóng mặt. So với 25 năm trước, công nghệ hiện nay thực sự khủng khiếp
Nhưng sự kinh ngạc này đi kèm một chữ “nhưng” rất lớn. Lĩnh vực này đang tiến hóa nhanh đến đáng sợ. Nvidia còn đưa ra cả các hiệu ứng dựa trên AI tác động đến cảnh và asset, điều mà thời đó không ai tưởng tượng nổi có thể chạy thời gian thực
Giờ tôi cũng không biết liệu có còn khả thi để trở thành một “chuyên gia khá ổn” trong lĩnh vực này hay không. Nói cách khác, câu hỏi là “John Carmack của ngày nay đang ở đâu?” Ông ấy nổi tiếng nhờ vắt kiệt phần cứng đến tận cùng và dùng những ý tưởng ẩn trong cộng đồng, nhưng ngày nay có vẻ một người như vậy không còn hào lũy cạnh tranh nào. Vì lĩnh vực này quá rộng và thay đổi quá nhanh, nên không còn cơ hội để trở thành Carmack tiếp theo
Cũng có góc nhìn khác. Nếu từ trước đến nay bạn chỉ làm web app và Kubernetes, thì ngược lại, bạn nên thử lập trình đồ họa. Vòng lặp phản hồi rất phấn khích, và bạn sẽ cảm nhận được một chiếc máy tính bình thường nhanh đến mức phi lý như thế nào. Dù cuối cùng bạn có tối ưu những thứ không quan trọng, điều đó vẫn có giá trị vì bạn chưa từng học được ở tầng thấp mọi thứ có thể nhanh đến đâu
Tài liệu cũng nhiều, và toán cũng không quá khó. 3D modeling có thể trở thành một lối thoát sáng tạo mà bạn chưa từng biết. Ngay cả khi hoàn toàn không áp dụng được vào công việc chính, bạn sẽ có một cách thưởng thức mới đối với nghệ thuật lập trình máy tính, và biết đâu bạn sẽ quyết định không bao giờ đụng đến Kubernetes nữa mà dành 5 năm thời gian rảnh để viết game engine của riêng mình
Những người điên như vậy rất nhiều, và cộng đồng lập trình viên sở thích chưa bị bào mòn bởi nghề phát triển game chuyên nghiệp lớn hơn bạn nghĩ. Graphics Programming Discord cũng là một không gian thân thiện đáng để ghé qua. Cứ thử là được
Với những người không quan tâm thực sự làm gì mà chỉ muốn chuyển nghề, lời khuyên nên tránh có thể đúng. Nhưng sống như vậy không phải cách hay. Tốt hơn là đi theo những gì mình thấy thú vị và có giá trị, liên tục học điều mới và thử thách bản thân. Khi đó việc có nên học đồ họa máy tính hay không sẽ tương đối rõ ràng, và với người phù hợp thì đó là lợi ích ròng. Dù không trở thành nghề nghiệp, kỹ năng này vẫn chuyển giao tốt sang nhiều lĩnh vực khác
Không cần phải nổi tiếng ngang một trong những người được biết đến nhiều nhất trong một lĩnh vực; chỉ làm vì thấy vui cũng được. Toán học và nghệ thuật của đồ họa và lập trình game tự thân đã rất đẹp
Lý do của tôi khi nói không nên vào lập trình đồ họa thì khác. Liệu vài năm nữa các engine 3D có đỉnh và texture còn tồn tại không? Hay mọi thứ sẽ được world model AI trực tiếp render? Trong game sẽ có bao nhiêu code, hay chúng sẽ tồn tại như một chuỗi các prompt được viết khéo léo?
Nếu cần một hướng dẫn nhanh về đại số tuyến tính, bạn có thể xem bản 4 trang có thể in do tôi viết: https://minireference.com/static/tutorials/linear_algebra_in...
Notebook có ví dụ code SymPy cũng ở đây: https://github.com/minireference/noBSLAnotebooks
Nhờ các hình minh họa, những thứ từng không hiểu trong lớp Linear 101 bỗng trở nên rất dễ nắm bắt
Tôi hơi ngạc nhiên vì không thấy nói đến việc hiểu các nguyên tắc thiết kế cơ bản hay đặc tính nhận thức của con người
Anh trai tôi từng là production artist cho các game máy tính nổi tiếng thập niên 90–00, và anh ấy liên tục phàn nàn về các lập trình viên và quản lý không có cảm quan thị giác, cũng chẳng tò mò muốn hiểu phía artist
Đồ họa không phải chuyên môn của tôi, nhưng với tư cách nhạc sĩ, sound designer và producer, những coder audio DSP hiệu quả và có ảnh hưởng nhất mà tôi biết đều hiểu nền tảng âm nhạc, vật lý và âm học của âm thanh, cũng như những cạm bẫy giữa xử lý số rời rạc và cách chúng ta tri giác, diễn giải kích thích
Nếu graphics programmer có tư duy nghệ thuật thì sẽ hữu ích, nhưng vì thường làm ở tầng khá thấp nên đó không phải điều bắt buộc để thành công
AI đã thay đổi phần nào phép tính, hoặc ít nhất có tiềm năng thay đổi, nhưng tôi nghĩ làn sóng “hãy học coding” hồi giữa thập niên 2000 cũng phần lớn vì lý do này. Đó là xu hướng xem phát triển phần mềm như “một năng lực, không phải một sản phẩm” của chuyên gia trong lĩnh vực hiện hữu, để những người hiểu domain nhất có thể tự làm phần mềm thay vì dịch yêu cầu cho đội phát triển
Thành thật mà nói, lập trình đồ họa phần lớn giống một vai trò dịch vụ: làm cho những điều họ muốn làm trở nên khả thi, hoặc giúp họ tạo ra những gì họ tưởng tượng
Inigo Quilez được nêu như ví dụ về một graphics programmer đồng thời là artist; đó thật sự là kiểu người rất mạnh và hiếm như kỳ lân
Cá nhân tôi thích chơi nhạc và lập trình âm thanh hơn, và đó là nền tảng tốt để học DSP. Ví dụ, nếu đẩy nhiễu khi render lên dải tần cao, đôi khi bộ lọc thông thấp sẽ hiệu quả hơn trong việc loại bỏ nhiễu
Nếu bạn thấy tò mò và có thời gian thì rất đáng học. Nó thật sự thú vị, học được rất nhiều, và còn giúp bạn trở thành kỹ sư giỏi hơn trong nhiều lĩnh vực khác của khoa học máy tính. Bạn sẽ hiểu về phần cứng, lập trình hệ thống, mô hình máy của lập trình viên, v.v.
Nhưng nếu mục tiêu cuối cùng của bạn là tiền, tốt hơn là đừng học. Thời nay phần thưởng cho việc đó rất mong manh, nhất thời và không được đảm bảo
Tôi đã quan tâm đến lập trình đồ họa từ lâu và vài năm trước bắt đầu tự học Vulkan. Không biết tổng cộng đã bỏ ra bao nhiêu, nhưng chắc khoảng 6 tháng thời gian rảnh buổi tối, có thể ít hơn một chút. Tôi đã làm được thứ gần như một rendering framework
Nhưng đây là kiểu việc càng đi xa càng nhận ra mình không biết nhiều đến mức nào. Ngay khi bạn cảm thấy cấu trúc đã ổn, bạn lại phát hiện ra đó không phải kiến trúc đúng
Rốt cuộc, việc bạn làm về cơ bản là toán ánh sáng ứng dụng, phần còn lại là công việc đường ống. Khi tự hỏi “sao spotlight lại xuyên thẳng qua khối lập phương thế này?”, bạn sẽ thấy mình phải tính bóng, rồi sẽ đào sâu vài tuần về cách đưa nó vào render pipeline. Dù vậy, nếu bạn thích những thứ này thì nó khá “vui”
Ví dụ, ngay cả khi tạo bóng, bạn cũng phải viết lượng code nhiều gấp 10 lần so với những gì bản thân kỹ thuật đó vốn dĩ yêu cầu
Nếu muốn học lập trình đồ họa, tôi nghĩ viết một software renderer sẽ thú vị hơn nhiều. Ít code hơn, và code bạn viết chạm vào phần cốt lõi chứ không phải boilerplate. Nhược điểm là mất tăng tốc phần cứng nên sẽ chậm
Nếu chỉ muốn làm game, bạn có thể dùng game engine như Unity, Godot, Unreal
Nếu muốn làm đồ họa kiểu engine, mô phỏng, renderer, bạn cần học ngôn ngữ cấp thấp và graphics API. Về ngôn ngữ, tôi khuyên dùng C++; C hoặc Rust cũng dùng được, nhưng C hơi khó, mà bản thân graphics API đã khó rồi nên chắc bạn không muốn phải vật lộn thêm với ngôn ngữ. Rust cũng có thể là lựa chọn tốt, nhưng cá nhân tôi thấy thời gian biên dịch rất chậm và cú pháp xấu
Về API, tôi khuyên dùng OpenGL. Nó đa nền tảng, lâu đời; đó vừa là ưu điểm vừa là nhược điểm, và là lựa chọn dễ nhất trong số đó
learnopengl.com chắc chắn là tutorial OpenGL tốt nhất, nên tôi khuyên bạn làm theo
Sau khi dùng OpenGL một thời gian, bạn có thể mở rộng sang Vulkan hoặc các thư viện đồ họa triển khai nhiều API, hoặc nếu thấy ổn thì cứ tiếp tục dùng OpenGL
Chắc chắn không dễ, nhưng tôi nghĩ đây là một trong những lĩnh vực hấp dẫn nhất của khoa học máy tính
Tự nói thì hơi ngại, nhưng cộng đồng cũng rất tuyệt. Web là cách tốt để vừa học vừa chia sẻ thứ mình làm, thu thập phản hồi và có được sự chú ý. Ngay trong cộng đồng cũng có nhiều trường hợp trở thành người làm đồ họa 3D chuyên nghiệp
Thỉnh thoảng nhìn lại repository thì thấy code khi đó quá lộn xộn nên hơi xấu hổ, nhưng nếu không có dự án đó thì có lẽ tôi đã không ở vị trí hiện tại
Bạn có thể bắt đầu bằng các tag đơn giản, thêm animation, nếu thiếu thì thêm component từ cộng đồng. Vẫn chưa đủ thì chỉnh bằng ThreeJS, rồi thậm chí đi tới shader. A-Frame rất tuyệt
Hơn nữa còn có thể làm AR và VR
Thay vì “trở thành lập trình viên đồ họa”, sao không chỉ làm lập trình đồ họa? Hãy thử từ những thứ đơn giản, rồi khi bắt đầu nắm được, và cuối cùng thấy rằng thực chất đó là gửi logistics lên GPU, bạn có thể chồng đủ loại khái niệm phức tạp lên trên
Nó giống như đang leo một ngọn núi nhỏ thì bỗng nhiên mọi thứ khớp lại và bạn thốt lên “wow…”. Bạn bắt đầu thấy các khả năng và những thứ để thử nghiệm
Những câu như “tôi là người leo núi đá”, “là game thủ”, “là nghệ sĩ”, “là mẹ”, “là cha”, “là dân nghiện phòng gym”, “là lập trình viên đồ họa” không nhất thiết nói về nghề nghiệp, nhưng hàm ý điều gì đó sâu hơn một sự tham gia hời hợt thoáng qua
Hôm nay tôi học về định dạng ảnh PPM, và nó rất dễ tiếp cận cho mục đích này. Việc ghi bitmap không phải khoa học tên lửa gì, nhưng PPM còn dễ hơn thế nữa