このウェブサイトはかなり進化したね。サンタに寄付をお願いするいいきっかけだよ。コンピュータグラフィックスにはもっとオープンな教育が必要だと思う。伝統的な技術は古い本に閉じ込められていて、わざわざ探しに行かないといけないし、セルゲイ・サヴチェンコの「3D Graphics Programming Games and Beyond」は良い本だよ。新しい技術は、特許で守られた門の向こうにあって、浅い論文やスライドでほんの少ししか情報が得られないことが多い。グラフィックスAPI、特に現代のものは、余計に混乱させることが多いしね。ソフトウェアラスタライザーやレイトレーサーを書くのはいいスタートだと思うよ。GPUの存在は忘れちゃおう。それと、ちょっと脱線するけど、ここにはDiscord以外の連絡方法がないみたいで、それがちょっと残念。前に確認したときは電話番号が必要だったし。寄付ページには、ホームページから直接リンクがあった方がいいと思う。

まだ覚えてるよ、同級生が3Dコンピュータゲームの作り方を知りたがってて、教授が困ってたときに、私が「図書館からFoley & Van Damを借りてみて」と言ったんだ。ちょうど返却したばかりだったから、借りられるはずだよ。新しい版がいくつか出てるね。https://www.goodreads.com/book/show/5257044-computer-graphic...

グラフィックスは、キャリアのほとんどの間、私にとって盲点だったな。今の職業に上手く滑り込んだ感じで（結局、データや分散系の仕事が多い）。今やってることは楽しんでるし、そこそこ得意だと思うから、悪いことではないけど、（ここにいる多くの人と同じように）ゲームを作りたくてプログラミングを始めたんだ。ティーンエイジャーの頃にOpenGLで惑星を太陽の周りに回す遊びをしたり、Flashで鳥がうんちをしてくる悪いスペースインベーダーのクローンを作ったり、Racketでひどいブレイクアウトのクローンを作ったり、VulkanやMetalでたまに実験したりしたけど、ジョン・カーマックやティム・スウィーニーのようになる夢は叶ってないな。Vulkanを学ぼうとするたびに、どれだけコードを書かなきゃいけないかに混乱して、イライラして諦めちゃう。基本がちゃんと理解できてないからだと思うし、Vulkanに飛び込むと、比喩的に「消防ホースから水を飲む」ような感じになっちゃう。こんなことが起きないことを願ってるけど、もしまた失業したら、やっと真剣に取り組んで学ぶいい理由になるかもね。

WebGLか、もっといいのはWebGPUを試してみて。すごく簡単だし、学んだ概念は他のAPIにも応用できるよ。https://webgpufundamentals.org や https://webgl2fundamentals.org なら、WebGL2よりWebGPUの方が、MetalやDirectX12、Vulkanのような現代のグラフィックスAPIに近いと思う。

私も同じ気持ちだよ。シェーダーを使って「アート」を作ろうとしてたんだけど、ZbrushやMayaにインスパイアされたんだ。でも、これらの巨大なソフトウェアの小さなクローンを作るために必要なことを学ぶのは、日常的に取り組まないと無理だと思う。Zbrushのパフォーマンスは本当にすごい…魅了されるよ。大学に通いながらこれに深く取り組むのは難しいと思う。

> Vulkを学ぼうとするたびに、どれだけコードを書かなきゃいけないかに混乱して、イライラして諦めちゃう。 Vulkanは初心者向けじゃないよ。基本を知ってても、かなり冗長だし。モダンなOpenGLで十分だと思う。もしVulkanを使う必要があるなら、その上に構築されたライブラリの一つを使ってみるといいよ（例えばSDL3を使ってる）。シェーダーで自由にやりたいことができて、リソース管理はそのライブラリに任せられるから。

VulkanはグラフィックスAPIじゃなくて、低レベルのGPU APIなんだ。グラフィックスはGPUが扱える機能の一つに過ぎない。それがVulkanがそうなっている理由を理解するのに役立つよ。

僕の意見があるんだけど、現代のコンピュータグラフィックスはすごく複雑で、Vulkanみたいな深いところに飛び込むよりも、基本をしっかり学ぶ方がいいと思う。Vulkanはエンジンのプロ向けで、フレームタイムをほんの数マイクロ秒でも短縮したい人向けなんだ。VulkanやD3D12は素晴らしいけど、経験豊富なエンジンプログラマーにとっては最大限に活用できる細かいホストデバイスの同期メカニズムを提供してる。一方で、初心者はその冗長さに圧倒されがちで、初期設定のボイラープレートがどれだけ面倒かは言うまでもない。GPUは全く異なるプログラミングメモリモデルを持っていて、コンピュータグラフィックスとGPUプログラミングを混同するのが問題だと思う。二つは明らかに関連してるけど、時にはかなり異なることもある。最近はGPGPUの推進で、GPUがシェーダーコアだけでなく、いくつかの異なるコプロセッサを組み合わせていて、十数種類のAPIでプログラムできるようになってる。だから、代わりに以下を提案するよ：1) CPUラスタライザーを実装する。二つのステージだけで、プリミティブアセンブラとラスタライザー。2) CPUレイトレーサーを実装する。チュートリアルのウェブリンクはそれぞれこちら： https://haqr.eu/tinyrenderer/ https://raytracing.github.io/books/RayTracingInOneWeekend.html これらはパフォーマンスや機能を最大化するために多くの方法で拡張できるよ。基本的な正確さを達成するためにはかなりの複雑さが必要になるし、プリミティブアセンブラはもちろん、フラスタムとバックフェイスのカリングが必要だし（これにはいくつかのプリミティブを再三角形化することも含まれる）。ラスタライザーにはZバッファリングが必要だし、レイトレーサーには異なるプリミティブのためのライティング、シャドウ、カメラ交差アルゴリズムが必要で、浮動小数点のダイバージェンスも考慮しなきゃいけない。球体、平面、三角形はそれぞれ最適化できる。ラスタライザーにさまざまなアンチエイリアシングアルゴリズムを追加してみて。シェーディングも追加して、最初はフラットから始めて、次に頂点ごと、フラグメントごとに拡張してみて。カメラの距離で詳細レベルを制御するテッセレーターを追加してみて。通常のZバッファリングの代わりに早期破棄を追加してみて。基本的なウィッテッドCPUレイトレーサーにBRDFを追加して、マイクロファセット理論、サブサーフェススキャッタリング、カオスティクス、フォトンマッピング/ライトトランスポートを追加して、一般的なグローバルイルミネーションの実装を目指してみて。デノイジングアルゴリズムも追加して。もちろん、より早い交差検索のための加速データ構造を実装して使ってみて。これらに取り組むことで、GPUがどのように機能するか、なぜ特定の方法で開発されたのかをより詳細に理解できると思う。Vulkanのようなものでプログラミングするのではなく、構造体を埋める時間を費やすよりもね。この後は、OpenGL 4.6やD3D11のようなもう少し「基本的な」グラフィックスAPIを自由に探求してみて。shadertoy.comやshaderacademy.comはフラグメントシェーダーを理解するのに役立つ素晴らしいリソースだよ。いくつかの広く使われているシェーダー言語があるけど、業界のほとんどはHLSLを使ってる。GLSLは簡単かもしれないけど、HLSLの方が確実に柔軟性がある。ここまで来たら、より複雑なシナリオを探求してみて。デファードレンダリング、環境光遮蔽、ミラー、時間的アンチエイリアシング、ライティングやシャドウのためのレンダー・トゥ・テクスチャなど。これはゲームに焦点を当ててるけど、2D UI、テキストレンダリング、合成など、別の方向に進むこともできる。なぜCPUから始めて、再びGPUに戻ることを勧めるのか、誰が「今、グラフィックスにCPUを使うの？」って聞くかもしれないけど、答えはこうだ：WARP[1]やLLVMpipe[2]はどちらも生産品質のソフトウェアラスタライザーで、リモートデスクトップセッション中によく読み込まれるんだ。実際、「ラスタライザー」というのは控えめな表現で、D3D10/11やOpenGL/Vulkanデバイスの完全なソフトウェア実装を提供してる。もちろん、ほとんどの映画レンダラーはCPUで動作してる。浮動小数点の精度が向上してるからね。映画はビデオゲームのような一時的なぼやけでは済まないから。最近はCPUコアもかなり安くなってるから、100万以上のコアを持つレンダーファームが複雑なピクサーやドリームワークスのフレームを処理してるのも珍しくないよ。

このウェブサイトのコンテンツが本当に好きで、その作成にかけた努力に感謝してる。去年のHNのフィードバックに対して行動を起こしてくれた著者にも感謝！ [0] [0] https://news.ycombinator.com/item?id=40622209

まだ、意味不明な誤字だらけのダサい画像が真ん中にあるよ。教育リソースとしてはあまり良くない印象だね。

今年の目標の一つは、基本からソフトウェアの3Dレンダラーを作ることなんだ。ゲームエンジンもGPUも使わない。楽しみだよ！

build-your-own-x*は、「お気に入りの技術をゼロから再現するための、よく書かれたステップバイステップのガイドの集まり」として人気があります。 * https://github.com/codecrafters-io/build-your-own-x

これだよ: https://haqr.eu/tinyrenderer/

OPのリンクはいいけど、別の視点が欲しいなら（へへ）、こちらもおすすめだよ。 https://gabrielgambetta.com/computer-graphics-from-scratch/i... これもゼロからで、無料だよ。名前が被ってるのは残念だけど、誰が先に使い始めたのかはよくわからないな :(

https://www.youtube.com/watch?v=qjWkNZ0SXfo 3Dグラフィックスを解明する1つの公式

いいショーだね。これが僕が推奨しているやり方で、何年も教えてきたんだ。残念なことに、ほとんどの人が3Dグラフィックスは必ずラスタライズと他人のAPIを使うものだと思ってる。僕は、直接メモリアクセス（モード13h）で簡単に画像を表示できた時代に独学で学べたことが本当にラッキーだったし、ラスタライズじゃなくてレイトレーシングに集中できたのが良かったと思ってる。

NVidiaがグラフィックスAPIの独占をやめるかもしれないし、Googleがウェブの独占をやめるかもしれない。AMDは代替品だけど、あまり良くないし、メンテもされてないしね。

今、ウェブサイトのリンクをLLMに投稿して、インタラクティブなリソースに変えられるようになったよ。今日は1000ページのPDFを使って、ゲームエンジンについてもっと学ぶためにやってみた。忘れられたPDFやブックマークになりたくないなら、これが一番いい方法だね。

どのLLMが1000ページのPDFを収められるくらいのコンテキストウィンドウを持ってるの？

みんなが役立つかもしれない無料のグラフィックスプログラミングリソースのリストを（あまり更新してないけど）持ってるよ。 https://gist.github.com/notnotrobby/ceef71527b4f15869133ba7b...

これは貴重な情報だね。ここでの僕のユーザー名は、（今は古いけど）ゲームエンジンのReactor 3Dから取ったんだ。Quake 3が高校を支配してた頃に独学でこのことを学んだ。Doomが僕をコンピュータに引き込んだけど、Quake 3が3Dに引き込んでくれた。買った本の数学はあまり理解できなかったけど、コードはそのままコピーした。キャリアが進むにつれて、ウェブとグラフィックスのいいブレンドになったよ。今やWebGL/WebGPUが広く使われるようになったから、PhDの人たちに頂点パックやアライン、GPUに構造体を送る方法を教えたんだ。研究を続けてPhDを取得しなかったのは後悔してるけど、Xbox 360のXNA用にReactor 3Dをパートタイムで書いて、その5年後に純粋なOpenGLに書き直した。高度な概念にはまだ苦労してるけど、幸運にも他にもいろんな人がいる。面白い事実として、MonoGameの基盤として使われるXNA Silverlightを書いた人と一緒に働いてたから、僕はMonoGameの大おじさんみたいなものだね。ただ、今はやり方が変わったから、違った種類のエンジンが求められてる。だから、Vulkan/Dx12/Metalのやり方が新しい流行なんだ。