グラフィックスプログラマーになるには何を学ぶべきか
(blog.demofox.org)- リアルタイムグラフィックスの採用で求められる能力は、CPU側の明示的グラフィックスAPI と GPU側のライティング・シェーディング の両方にまたがっており、両分野を同時に深く身につけるのは難しい
- CPU側では DirectX12、Vulkan、Metal のような現代的なAPIと、アセット読み込みやエンジン支援作業を扱い、GPU側ではシャドウ、アンビエントオクルージョン、ポストプロセス、GPUの性能特性を扱う
- GPU学習の中心は path tracer の実装 と PBR の理解 であり、Ray Tracing in One Weekend、LearnOpenGL PBR、Filament のドキュメント、PBRT が出発点になりうる
- ポートフォリオは、C++ ベースのリアルタイムレンダラー、写真のような画像を作る path tracer、両方のレンダリング結果を比較・検証するコードで知識を示す形が理想的
- 必要な数学は線形代数、基本的な三角法、少しの微積分が中心で、ゲーム開発のCPU側言語は C++、シェーダー言語は HLSL が最も一般的
リアルタイムグラフィックスはCPUとGPUの二つの領域を扱う
- 現代のレンダリングは、実質的に二つの仕事を組み合わせたものに近い
- CPU側の学習: DirectX12、Vulkan、Metal のような現代的な明示的APIと、アセット読み込みやその他の支援作業のためのエンジンプログラミング
- GPU側の学習: 現代的なライティング・シェーディングの数学、シャドウ、アンビエントオクルージョン、ポストプロセス効果、GPUで速い処理と遅い処理の違い
- 両方の領域を同時に学ぶのは非常に難しい
- GPU側に集中したいなら、OpenGL、WebGL、DirectX11、既存エンジンのようにCPU側の負担が小さいツールを使える
- CPU側に集中したいなら、まず画面に三角形を表示し、次にメッシュを表示するという形で進めればよく、見た目の美しさをあまり気にする必要はない
path tracing と PBR
- GPU側の学習には path tracer の実装が含まれる
- Path tracing は映画レンダリングで使われる方式であり、現代のリアルタイムレンダリング手法が近似しようとしている対象でもある
- 入門資料として、無料のオンライン書籍 Ray Tracing in One Weekend が適しており、取り組みやすく、写真のようなレンダリングを作る過程を示してくれる
- Physically Based Rendering(PBR) はライティング、とくに specular の適用方法に関わる
- PBR は、ルールを守れば良い結果が得られる原則ベースの手法
- PBR以前はライティングのために任意の数式、調整、ハックを多用していたため、ある照明環境で良く見えたアセットが別の環境では暗すぎたり光りすぎたりして見えることがあった
- その結果、照明条件ごとに異なるアセットのバージョンを作る必要があり、多くの時間と労力がかかっていた
- PBR は複数の照明条件でアセットがより一貫して見えるようにし、バージョン別アセット制作にかかる時間と労力を減らす
- それでもアセット制作に必要な時間、コスト、労力は依然としてゲーム開発の大きなボトルネック
おすすめの学習資料
- PBR入門には LearnOpenGL の PBR Theory セクションとその下位セクションが適している
- さらに深く学ぶなら Filament documentation が次の段階になりうる
- PBRを深く学ぶほど、微積分と統計が多く登場する
- さらに進むと、無料のオンライン書籍 Physically Based Rendering: From Theory To Implementation がある
- 機械学習は、現時点では誇大宣伝ほどの成果は出さないように見えるが、コンピュータサイエンスの道具箱の中で フィッティングと最適化手法 を学ぶ価値はある
- 関連資料として Machine Learning For Game Developers の動画を参考にできる
ポートフォリオとして見せられるコード
- 採用担当者に知識を証明するには、GitHub のような場所に共有可能な ソースコード を置き、履歴書からリンクするのが理想的
- 例となるポートフォリオ:
- モデルやテクスチャのようなアセットを読み込み、画面にリアルタイムでレンダリングするエンジン型レンダラー
- ライティングとシャドウ、depth of field、area lights、tone mapping、ray traced shadows のようないくつかの効果を含む
- 可能なら PBR ベースのライティング、ユーザーが制御できるカメラ、DX12・Vulkan のような API、C++ を使う
- 写真のような画像を生成する path tracer
- 可能なら C++ が望ましいが、ウィンドウなしで PNG だけを出力するプログラムでもよい
- リアルタイムである必要はない
- path tracer がエンジン型レンダラーの別モードになっていればさらによい
- path traced の結果とリアルタイム PBR レンダリングを比較して正確性を検証できる
- 二つのレンダリングが一致しない箇所を指摘し、なぜ違うのかを説明し、リアルタイム性を保ちながらより近づける方法まで考えられれば、さらに高く評価される
- モデルやテクスチャのようなアセットを読み込み、画面にリアルタイムでレンダリングするエンジン型レンダラー
数学、アルゴリズム、言語選択
- 上の項目を実際にやってみると、必要な数学には自然に出会うことになる
- 基本的に必要なのは 線形代数 の行列積、cross product、dot product、基本的な三角法、少しの微積分
- グラフィックスとゲーム開発で必要な数学の最低ラインは比較的小さいが、活用できる数学の範囲に実質的な上限はない
- アルゴリズムも同様
- linked list、hash table、ソート、探索のような基本的な抽象データ型とアルゴリズムは知っておくべき
- 最も速いアルゴリズムは単純なことが多く、配列は linked list よりはるかに速い
- より高度なアルゴリズム概念は、本当に新しくて特注の何かが必要になったときに役立つ
- ゲーム開発で学ぶべき言語は C++
- Rust を使う人もいて一定の存在感はあるが、人々が期待する標準言語ではない
- WebGPU は WebGL になかった多くの機能を備え、より本格的なプラットフォームになりつつあり、CPU側の作業を JavaScript で行えるようにする
- ただし WebGPU の求人や、Web上の WebGPU コンテンツはあまり見かけていない
- シェーダー言語は HLSL が最も一般的
- GLSL を使う人もいる
- マルチプラットフォームのゲームでは、シェーダーが別のシェーダー言語へ変換されることが多い
LLM と ML の活用範囲
- 現在の ML 技術は、販売されている用途の大半に対して十分な水準には達していないと見ている
- Claude と数学、論文、なじみのないアルゴリズムについて話すのには役立つ
- こうした状況では、もっともらしい作り話をしているかどうかを見抜きやすく、別の情報源で妥当性を確認するのも容易
- プログラミングにはそれほど有用ではない
- 望みどおりに動くコードを出してきたとしても、そのコードを理解するには時間をかける必要がある
- それなら自分で書いたほうがよいという考え
- 小さな用途には役立つこともある
- たとえば「このファイルにバグが見えるか？」と尋ねれば、答えが yes なら調査できるし、no でも聞くコストはほとんどない
- いずれ人類は人間レベルの知能を持つAIを作り、それを超えるところまで進むと信じているが、それが自分の生涯のうちかどうかは分からないと見ている
- 現在の LLM 時代は、後になって「本物」が来たときのための予行演習に近い
1件のコメント
Hacker News の意見
まず、ゲームを作りたいのか、3D エンジンのプログラミングをしたいのかを区別すべき
ゲームを作りたいなら Unreal Engine、Unity、Godot、Bevy のような既存エンジンを使うほうがよく、ピクセルを直接押し込む方法よりも、グラフィックスのより高レベルな問題を学ぶことになる。本当に難しいのは面白く作ること
3D エンジンを作りたいなら、ひどいゲームエンジンはすでに多すぎるほどあることを知るべき。Rust 界隈だけ見ても、失敗したレンダラーが 3 つ、未完成のレンダラーが 1 つ、Bevy 内のレンダラーが主要プロジェクトで、「ゲームエンジンを作る」というプロジェクトはさらに多い。「最初のレンダラー」の水準に到達するだけでも 2 年ほどかかり、大規模で細かく動的なシーンにたどり着くのははるかに大きな仕事
就職が目的なら、ゲーム業界は給与も労働時間も良くなく、プロジェクトが終われば仕事も終わり、Hollywood のように入りたがる志望者であふれている。しかも Metaverse の崩壊のせいで、今は経験者も過剰
モバイルは画面、演算性能、GPU、バッテリーのすべてが足りない圧縮作業で、だから最近のインディーゲームの大半は 2D。それならまだ可能で、HTML/JavaScript でもよく作られる
ただし、基本的なレンダラーとゲームループを作ることはそこまで難しくなく、ゲームコードの大部分になるとも限らない。単純なゲームなら
forループでdrawObject()するだけでも十分で、リソースストリーミング、バインディング最適化、並列性といった心配は、後で必要になったときにすればよい「最初のレンダラーまで 2 年」という基準が、どんな出発点と成功条件を想定しているのか気になる。1 年ほど前、空き時間で 1 か月、フルタイム換算なら 1 週間未満の時間で、動的ライティング、シャドウマッピング、いくつかのポストプロセスを備えたディファードレンダラーを作った
2D だからといって見下す理由もない。真面目な作業のかなりの部分は 2D インターフェースで行われており、WebGL や古い 2D canvas も今ではかなり強力。ヒットしたインディーゲームにも 2D は多い
ゲーム業界がいまいちなのはその通りだが、最近はほとんどあらゆるものが GPU を使う。機械学習ワークロードの作成・デバッグ、データ可視化、HUD、一般的なユーザーインターフェースでも、グラフィックスの理解が必要な場合は多い
ゲーム以外にも可視化、シミュレーションなどグラフィックスを使う分野ははるかに多く、優れたグラフィックスプログラマーは極めて少ないので、意外と悪くないキャリア。ゲーム開発者やアーティストが良い仕事を得るのはより難しそうに見えるのとは、かなり対照的。ただし需要も供給も小さいので、転職は簡単ではないかもしれない
職業の安定性だけを見るならゲーム開発をキャリアにするのは勧めたくないが、グラフィックスプログラミングは別
ここ数年で遊んだゲームでは、Core Keeper(Unity)、WORMHOLE(Unity、特に無限モードの遅延)、Crab Champions(UE4、1920x1200 で 60fps を維持するために画面を不細工にするアップスケーリングを使わざるを得ない)の性能問題がひどかった
一方で Terraria、Necesse、Barony は独自エンジンを使っていて見事に動作し、古くなるほどよく見える
公平に言えば Tiny Rogues(Unity) は記憶ではおおむねよく動いていたが、開発者が今後 Unity から離れようと作業中なので、本人も問題を見つけたのだろう
ゲーム作りとエンジン作りの違い、実際に完成させてリリースすることの重要性は分かるが、ゴミを出してしまうと良い遺産を残すのは難しい。遠回りしてでも一定水準の品質を保証するほうがよいと思う。ゲームはリリース後何十年もプレイされることがあり、バグや遅延があれば人々はずっとそれに遭遇し続ける
「次のゲームを簡単に作るために、まず自分のゲーム用エンジンを作る」というのは驚くほど強力な罠。実際に重要なことを学び、毎日小さな勝利が得られるから。シーンが滑らかに見えるようにアンロールをもう 1 つ入れ、シーンを作りやすくするために設定形式へ論理レイヤーをもう 1 つ足し、SIGGRAPH 論文をもう 1 本読むことになる
改善すべき重要なことは常にあるが、それらが完成したゲームにまとまることはない。振り返ると、自作エンジンを使うことは、技術者が夢見たゲームの難しいが必要な部分、つまり「面白く作る」ことを先送りする完璧な方法だった。印象的なビデオゲームをコーディングする技術は身につくが、ゲームの作り方は学べない
下位の罠もある。リアルタイムに滑らかに動く美しい視覚効果を作る方法は百通り学ぶが、それをアートとして使う方法は学べない
これは「Enterprise Java」の罠とも非常によく似ている。ただし具体的な用語を扱うぶん、より巧妙。Scene Graph に Factory Factory Interface がないからその弾は避けたと思ってしまうが、実際には画面にビットマップを表示してキーに反応させる作業には、それ自体が不要だという点を見落としてしまう
特に 2D ではそう。例えば自作のゲームエンジンでゲームを作っているが、性能と圧縮、サーバーやデータベースを持たない構造に焦点を当てている
このエンジンは、自分が定めた制約の中で極端な性能と圧縮を達成するために、ゲーム構造に関する非常に具体的な構造と仮定を持っている。関連する Hacker News 投稿を近いうちに、できれば来週出す予定
以前にもブラウザーゲームを Unity、Godot、React で何度も作ろうとしたが、API を学ぶのが苦痛で、エンジンが自分の極端な制約を満たせなかった。もちろん自分がそれらのエンジンをうまく扱えなかったせいもあるだろうが、振り返っても内部的に達成したことは、ゼロから作ったカスタムエンジンなしには不可能だったと思う
自分でエンジンとゲームを作りながら本当に多くを学んだし、特に今は LLM のおかげで、経験ある開発者が自分でカスタムゲームエンジンを作ってみることが、ほとんどの開発者にとって突然現実的な範囲に入ってきたと思う
今なら、誰にもグラフィックスプログラミングの世界に入ることは勧めない。
2001年に Nvidia の最初の GeForce 1、いわゆる「Gigatexel shader card」が発表された頃に始めたが、それ以降のこの分野の発展速度と革新は目がくらむほどだった。25年前と比べると、今の技術は本当にすさまじい。
ただし、この驚きには大きな「しかし」がある。この分野は恐ろしいほど速く進化している。Nvidia はシーンやアセットに影響を与える AI ベースの効果まで出してきたし、当時はこんなものがリアルタイムで可能になるとは想像もできなかった。
もはやこの分野で「そこそこの専門家」になることが可能なのかも分からない。言い換えれば、「現代の John Carmack はどこにいるのか？」という問いだ。彼はハードウェアを限界まで絞り出し、コミュニティに埋もれていたアイデアを使って有名になったが、今日そういう人に競争上の堀はなさそうに見える。分野があまりに広く、あまりに速く変化していて、次の Carmack になる機会がないからだ。
別の見方もある。これまで Web アプリと Kubernetes しかやってこなかったなら、むしろグラフィックスプログラミングをやってみるといい。フィードバックループは刺激的で、普通のコンピュータがどれほど信じられないほど高速なのかを実感できる。最終的に重要でない最適化をすることになったとしても、低レベルでは物事がどれほど速いのかを学んだことがないなら、それには価値がある。
資料も多く、数学も過度に難しいわけではない。3D モデリングが、知らなかった創作の出口になるかもしれない。本業にまったく応用できなくても、コンピュータプログラミングという芸術を新たに味わえるようになるし、Kubernetes には二度と触れず、余暇の5年を費やして自分のゲームエンジンを書くことにするかもしれない。
そういう狂った人たちは多いし、職業ゲーム開発ですり減っていない趣味開発者のコミュニティは思ったより大きい。Graphics Programming Discord も、覗いてみる価値のある歓迎される場だ。やってみればいい。
実際に何をするかはどうでもよく、キャリアチェンジだけを望んでいる人には、避けろという助言が正しいかもしれない。だが、そういう生き方はよい方法ではない。面白く価値があると感じるものを追い、絶えず新しいことを学び、自分に挑戦するほうがいい。そうすれば、コンピュータグラフィックスを学ぶべきかどうかは比較的はっきりするし、合う人にとっては純利益になる。職業にならなくても、そのスキルは他の多くの領域にうまく転用できる。
ある分野で最もよく知られた人物の一人ほど有名でなくても構わないし、単に楽しいからやってもいい。グラフィックスとゲームプログラミングの数学と芸術は、それ自体で美しい。
私がグラフィックスプログラミングに入るべきではないと思う理由は別にある。頂点とテクスチャを持つ 3D エンジンは、数年後にも存在しているのだろうか？ それとも、すべてを AI の世界モデルが直接レンダリングするようになるのだろうか？ ゲームにはどれほどのコードが入るのか、それとも巧妙に書かれたプロンプトの連なりとして存在するようになるのか？
線形代数の手早いチュートリアルが必要なら、私が書いた印刷可能な4ページ版がある: https://minireference.com/static/tutorials/linear_algebra_in...
SymPy のコード例が入ったノートブックもここにある: https://github.com/minireference/noBSLAnotebooks
可視化のおかげで、Linear 101 の授業では理解できなかったことがすっと腑に落ちた。
基本的なデザイン原則や人間の知覚の特性を理解する話がないのは、少し驚きだ。
私の兄は90〜00年代の有名なコンピュータゲームでプロダクションアーティストをしていたが、視覚的センスもなく、アーティスト側を理解しようとする好奇心もないプログラマーやマネージャーについて、いつも不満を言っていた。
グラフィックスは私の専門ではないが、ミュージシャン、サウンドデザイナー、プロデューサーとして知っている最も効果的で影響力のあるオーディオ DSP コーダーたちは、音楽の基礎、音の物理と音響、離散デジタル処理と、私たちが刺激を知覚し解釈する方法との間にある落とし穴を理解している。
グラフィックスプログラマーが芸術的な考え方を持っていると役に立つが、通常はかなり低レベルで作業するため、成功に必須というわけではない。
AI が計算を少し変えた、少なくとも変える潜在力はあるが、2000年代半ばの「コーディングを学ぼう」という流れも、かなりの部分はこうした理由だったと思う。ソフトウェア開発を既存分野の専門家にとっての「製品ではなく機能」のように扱い、ドメインを最もよく知る人たちが要件を開発チームに翻訳して伝えるのではなく、自分たちでソフトウェアを作れるようにしようという動きだった。
正直なところ、グラフィックスプログラミングは概ね、彼らがやりたいことを可能にしたり、思い描いたものを作るのを助けたりするサービス的な役割に近い。
Inigo Quilez はグラフィックスプログラマーでありアーティストでもある例として挙げられるが、本当に強力で、ユニコーンのような人物だ。
個人的には音楽演奏とオーディオプログラミングのほうが好きで、DSPを学ぶためのよい土台にもなる。たとえばレンダリングノイズを高周波側に押し込むと、ローパスフィルタがノイズ除去により効果的になることがある
好奇心が湧いて時間があるなら、学ぶとよい。本当に面白く、多くを学べるし、コンピュータサイエンスのほかの多くの分野でもよりよいエンジニアになれる。ハードウェア、システムプログラミング、プログラマの機械モデルなどを理解できるようになる
ただし、お金を最終目標にするなら学ばないほうがよい。今の時代、その見返りははかなく一時的で、保証されていない
以前からグラフィックスプログラミングに興味があり、数年前にVulkanを独学し始めた。合計でどれくらい費やしたかは分からないが、6か月ほど夜の自由時間、もしかするとそれより少し少ないくらいを使ったと思う。レンダリングフレームワークに近いものは作った
ただ、先へ進むほど自分がどれだけ分かっていないかを思い知らされる類いのものだ。ようやく構造がよさそうだと感じた瞬間、それが正しいアーキテクチャではないと気づく
結局やっていることは基本的に応用照明数学で、残りは配管作業だ。「なぜスポットライトがキューブをそのまま通り抜けるんだ？」と思って見てみると、影を計算しなければならず、それをレンダーパイプラインに組み込む方法を何週間も掘り下げることになる。それでもこういうものが好きなら、かなり「楽しい」
たとえば影を作るときでさえ、その技術自体が本質的に要求するより10倍は多くのコードを書かなければならない
グラフィックスプログラミングを学ぶなら、ソフトウェアレンダラを書くほうがずっと楽しいと思う。コードが少なく、書くコードもボイラープレートではなく核心に触れている。欠点はハードウェアアクセラレーションを失うため遅くなることだ
ただゲームを作りたいだけなら、Unity、Godot、Unrealのようなゲームエンジンを使えばよい
エンジン、シミュレーション、レンダラのようなグラフィックスをやりたいなら、低水準言語とグラフィックスAPIを学ぶ必要がある。言語としてはC++を勧める。CやRustも使えるが、Cは少し難しく、グラフィックスAPI自体がすでに難しいので、言語とも戦いたくはないだろう。Rustもよい選択肢になり得るが、個人的にはコンパイル時間が非常に遅く、文法が不格好だと感じる
APIはOpenGLを勧める。クロスプラットフォームで歴史が長く、その点は長所でも短所でもあり、その中では最も簡単だ
learnopengl.comはOpenGLチュートリアルの中で断然最高なので、試してみることを勧める
OpenGLをしばらく使った後は、Vulkanや複数のAPIを実装したグラフィックスライブラリへ広げてもよいし、問題なければOpenGLを使い続けてもよい
確かに簡単ではないが、コンピュータサイエンスで最も魅力的な分野の一つだと思う
自分で言うのも何だが、コミュニティも素晴らしい。Webは、学びながら作ったものを共有し、フィードバックを集め、可視性を得るのに適した方法だ。コミュニティ内からも、3Dグラフィックスを専門的に扱うようになった事例が多い
たまにリポジトリを見返すと当時のコードがひどすぎて恥ずかしいが、そのプロジェクトがなければ今の位置にはいなかったと思う
簡単なタグから始めて、アニメーションを加え、足りなければコミュニティコンポーネントを追加すればよい。それでも足りなければThreeJSで修正し、シェーダまで行ける。A-Frameは素晴らしい
さらにARとVRもできる
「グラフィックスプログラマになる」より、ただグラフィックスプログラミングをするのはどうだろう。簡単なものから試してみて感覚がつかめ、結局はGPUに物流を送る仕事なのだと見えてくれば、その上にあらゆる複雑な概念を積み上げられる
小さな山を登っているうちに、突然すべてがぴたりとはまり、「うわ……」となる感じだ。可能性や実験できることが見え始める
「私はロッククライマーだ」「ゲーマーだ」「アーティストだ」「母親だ」「父親だ」「ジム通いの常連だ」「グラフィックスプログラマだ」といった言葉は、必ずしも職業を意味しないが、一時的にかじる程度の軽い関与よりも深い何かを示唆している
今日PPM画像形式を学んだが、こういう用途にはとても取り組みやすい。ビットマップを書き出すのが大層なロケット科学というわけではないが、PPMはそれよりさらに簡単だ