読者です 読者をやめる 読者になる 読者になる

穴日記

どうだ明るくなったろう

Blue-noise Dithered Samplingの実験をしてみた

これはレイトレ合宿4!?アドベントカレンダー記事です。

Blue-noise Dithered Sampling

先日開催されたSIGGRAPH2016には私も参加しましたが、興味深いものの実装が大変そうなものから何の役に立つのかわからない技術まで様々な知見を得ることができました。
その中でも割とさくっと実装できそうで、かつ効果もありそうな発表があり、それがBlue-noise Dithered Samplingです。これは、Roll the Diceというトークの中の発表の一つで、Arnoldという有名なレイトレーシング(パストレーシング)ベースのオフライン商用レンダラを開発しているSolid Angle社による成果ということになっています。
今回は、この発表を元に適当に実装して簡単な実験をしてみました。

実装は以下に置いてあります。

github.com

Blue-noise 

ブルーノイズについてはあまり深くは説明しませんが、以下の図のように各点間の距離がなんとなく等しくなるように平面上に散らばっている点群の性質をブルーノイズと呼んだりします。

f:id:h013:20160822172701p:plain(http://www.geometry.caltech.edu/BlueNoise/より)

二次元平面からのサンプリングはコンピュータグラフィックスにおいて様々な箇所で頻出の問題です。完全にランダムに行えば、それはホワイトノイズになります。周波数領域で周波数に偏りが無い(=ランダム)だからです。ブルーノイズの場合、低周波成分が小さく、高周波成分が大きい、といった特性を持っています。人の網膜細胞もこのパターンらしいです。

さて、ブルーノイズはもともと画像の二値化などのディザリング処理において良くつかわれていました。今回の手法は、このアイディアをサンプリングに応用することでいい感じにディザリングされたレンダリング画像を少ないサンプル数で得る、という手法になります。

実装概要

まず、解きたいレンダリングの問題が何次元の積分なのかについて考えます。例えば、モーションブラーであれば時間方向に積分するため1次元の積分になり、アンビエントオクルージョンであれば半球上で積分するため2次元の積分になります。
このように、解きたい積分がd次元のとき、d次元分の乱数列([0, 1)の範囲)を生成します。2次元の場合、(0.3152, 0.8611)みたいな感じになりますね。普通のレンダリングの場合、このような乱数列を各ピクセルごとに独立に複数回数生成してモンテカルロ積分のサンプルの生成に利用することで画像を得ます。

しかし、今回の場合は全ピクセルで同一の乱数列を使うとします。そして、それぞれの乱数列をピクセルごとに事前に決めておいたd次元の値([0, 1)の範囲)でオフセットします。もし、事前に決めておいた値が以下の図のように完全にランダムなら、結局各ピクセルごとに独立の乱数列を生成するのとほとんど変わりません。

f:id:h013:20160822174126p:plain(128x128、[0, 1)の範囲の乱数列)

しかし、このオフセット値を以下の図のようにブルーノイズを用いればレンダリング結果はディザリングされたものになり、より望ましくなります。

f:id:h013:20160822173929p:plain

これが今回の手法の要旨です。

ブルーノイズオフセットの生成

さて、それではブルーノイズオフセット値はどのようにして得るのでしょうか。これは、論文に詳しく解説されていますが、焼きなまし法による最適化によって得るようです。
まず、与えられたサイズのオフセットマスク画像をd次元、[0, 1)の範囲の乱数列で初期化します。そして、あるオフセット値と別のオフセット値の間で定義されるエネルギー関数の総和を最小化するように、適当に選んだ二つのオフセット値を入れ替える、ということを反復的に行えば良いらしいです。最小化したい式は以下のようになります。

f:id:h013:20160822174528p:plain

https://www.solidangle.com/research/dither_abstract.pdfより)

ここでpi, qiはマスク上の位置で、ps, qsは各サンプル、dはオフセットの次元です。分母のσは定数になります。

で、これを実装するわけですけど今回自分は焼きなまし法は特につかわず(パラメータチューニングとか面倒だし)エネルギー関数を事前に計算しておいて、適当にオフセット値を入れ替え、再計算したエネルギー関数が減少していれば入れ替えを採用、減少してなければ入れ替えは棄却、ということを指定された回数繰り返すようにしました。
さらに、エネルギー計算の再計算も自分以外の全オフセット値に対して実行していると重いため、自分の周囲にのみ着目するような近似計算にして高速化を行ってみました。

わりと適当でしたが、それなりにうまく生成されているように見えたので良しとします。(若干品質が低いような気もする)

実際のレンダリング

レンダリングするときは、既に解説したようにブルーノイズディザリングしたいモンテカルロ積分のサンプル生成にブルーノイズでオフセットした値を投入するだけです。
今回の実験ではモーションブラー(1次元)とアンビエントオクルージョン(2次元)の二つについて試してみました。

結果

それでは結果です。画像は全て512x512でレンダリングしています。オフセットマスクのサイズは128x128です。

以下はモーションブラーの結果です。

f:id:h013:20160822175355p:plain(ランダムオフセット / 1spp(1 sample per pixel))

f:id:h013:20160822175459p:plain(ブルーノイズ / 1spp)

ブルーノイズの方はランダムに比べてノイズが均等に分布していることがわかります。
ただ、サンプル数を1から9sppに上げると両者の差は小さくなりました。f:id:h013:20160822175650p:plain(ランダムオフセット / 9spp)

f:id:h013:20160822175720p:plain(ブルーノイズ / 9spp)

ちなみに、リファレンスとして256サンプリングすると以下のようになります。

f:id:h013:20160822175746p:plain

次に二次元の積分アンビエントオクルージョンの結果です。

f:id:h013:20160822175830p:plain(ランダムオフセット / 1spp)

f:id:h013:20160822175850p:plain(ブルーノイズ / 1spp)

モーションブラーほどではありませんが、ブルーノイズの方が良い結果を得られています。しかし、やはりサンプル数を増やすと以下のように、結果は似たようなものになりました。

f:id:h013:20160822180128p:plain(ランダムオフセット / 9spp)

f:id:h013:20160822180155p:plain(ブルーノイズ / 9spp)

ちなみに以下はリファレンスです。

f:id:h013:20160822180254p:plain

アンビエントオクルージョンも設定によってはブルーノイズの方がかなり良い結果を出すこともあります。例えば以下。

f:id:h013:20160822190029p:plain(ランダムオフセット / 1spp)

f:id:h013:20160822190047p:plain(ブルーノイズ / 1spp)

f:id:h013:20160822190105p:plain(リファレンス)

まとめ

どうも高次元の積分になると効果が薄まっていくようです。この手のサンプリング手法は大体そういう傾向がありますね(Low Descrepancy Sequenceとか)。また、サンプル数を増やすと割とすぐ似たような結果になってしまいました。なんかバグってる可能性もありますが、元の論文のアブストの結果画像も1sppで比較してるのが多く、9sppで比較してるのはボリュームレンダリングだけだったので相性みたいなのがあるのかもしれません。

また、マスク画像のサイズも、今回は適当に128x128と決めましたが結果に影響あるかもしれません。

しかし、1sppで比較した時は間違いなく単純なランダムよりはいい結果になっています。オフラインで長時間レンダリングできるシチュエーションだとちょっと微妙かもしれませんが、むしろリアルタイムレンダリングで、サンプル数を出来る限り減らしたいような状況で活きてくる手法かもしれません。

おわり。

WebGLでリアルタイム流体シミュレーション+レンダリングを実装してみた

はじめに

なんかWebGLが流行ってるらしいのでWebGLすることにしてみました。OpenGLはぼんやりとやったことがあったのですが、ウェッブ技術に対する疎さが深刻化しているのでモダンで先端的なテクノロジーを追及するためにもWebGLの習得は急務といえました。

WebGLJavaScriptと呼ばれるプログラミング言語を用いるようです。僕がJavaScriptを最後に書いたのは四年くらい前にクック●●●のハッカソン?みたいなのに参加した時その場で習得してその場でアプリを作ったとき以来です。それ以来一度も書いていません。

まあJavaScriptとか意識高い大学生でも書けるわけだし適当にAPIを呼び散らかす分には何の問題もないでしょう。というわけでWebGLのサンプルコードを読みながらサンプルドリブンでJavaScriptを習得すんのがいいだろと思いました。

先に結果だけ貼っておきます。いろいろあって流体シミュレーションしつつレンダリングするようなものになりました。
githole/webglSmoke · GitHub

サンプルドリブンプログラミング

とりあえずWebGLのサンプルコードが乗ってるサイトを探しました。WebGLは流行りなだけあって無限にそういうサイトは存在します。こういう時はGoogleで上の方に出てくるサイト=高品質なサイト、というヒューリスティックを実行します。今回参考にしたのは以下の二つのサイトです。

Learning WebGL

wgld.org

前者は英語、後者日本語です。両方のサイトの最初の方のページをブワーって読んでローカルにコピーして実行したりしてみます。適当にコードを書き換えたりするうちに概ねWebGLの初期化の方法を覚えます。

この段階で、WebGLの初期化にさえ至ればあとは慣れ親しんだOpenGLとなんら変わらないという悟りを得ます。こうなればしめたものです。OpenGLAPIを呼ぶのはそう難しいことではありません。GPUにデータを送って、GPUにドローコールを積むだけです。

一つ、面倒なことがあるとすれば行列まわりの演算です。GPUプログラミングなんで、CPUで行列演算してGPUに頂点送ってシェーダーセットしてドローコール呼ぶだけなんですが、その行列演算が驚くべき面倒さです。今回はglMatrixを使いました。なぜか、最新版は4x4行列の逆行列の計算関数が実装されてないっぽく、過去のバージョンから関数を引っ張ってきたりしています。実は実装されてた、みたいな落ちだったら笑えますね。

2D流体シミュレーション

そもそも、「ああ、ブラウザで流体シミュレーションを見たいなあ」と思ったのが今回ウェッブに手を出すきっかけだったので流体シミュレーションを実装します。2Dの流体シミュレーション(WebGL)は無限にあるのですが、3Dは全然ありません。まったく気合いの足りないことです。

というわけで、とりあえず2Dの流体シミュレーションを実装→3Dのシミュレーションに拡張、という手順を踏むことにします。

2Dの流体シミュレーションは、特に頭を使いたくなかったので、Jos Stam先生のStable FluidsをそのままGLSLに移植しました。ググればいくらでも情報が出てくるでしょう。基本的に、ナビエ・ストークス方程式を離散化して解いてるだけですが、移流の解決のためにセミラグランジュ法を使っているのでいい感じに安定になります。

安定なのはいいんですけど、セミラグランジュ法はウンコみたいに数値拡散が起こってしおしおになります。よって、今回はナビエ・ストークス方程式の拡散項は無視してます。数値拡散だけでもやばいのにまともに拡散項なんて解いている場合ではありません。この方法はBridson先生も推奨していたような気がします。まあ移流スキームをもうちょい賢い感じにすればいいんですけど、今回の本旨じゃない気がしたのでこの辺で終わりにします。

さて、WebGLで流体シミュレーションみたいなGPGPUじみたことを行うにはどうすればよいか?という話です。WebCLみたいなのもあるみたいですがとりあえずWebGLだけ使うとすると、レンダーターゲットを二枚用意してピンポンするのが一番です。

このようにすると、二次元の離散化格子はそのままテクスチャの各テクセルに対応するのでシミュレーションも直感的に実装できます。境界条件をちゃんと設定する必要はありますが、どうせWebGLのテクスチャボーダーの処理は二種類くらいしかないので適当に指定します。

テクスチャフォーマットは、RGBAのFLOATテクスチャにしました。これは、本当は拡張機能なのですが、さすがにUnsinged Byteのフツーの8ビットテクスチャだと精度が全然足りないし、パックとかアンパックを組み合わせ始めると泥沼式に面倒さが増していくのであきらめて拡張機能を使いました。

3D流体シミュレーション

というわけで、GLSLへの移植と結果の確認自体はまあすぐできました。やるだけですね。問題はここからです。WebGLは先進的なテクノロジーにも関わらず3Dテクスチャをサポートしてないらしいのです。そしたらどうやって3Dシミュレーションすればいいのでしょう。

まあ実はそんな大したことはありません。3Dテクスチャを2Dテクスチャ上に展開してマッピングしてやればいいのです。シミュレーション空間が64x64x64だとすると、512x512の2Dテクスチャを確保して、その上に64x64のタイルを縦横8枚ずつならべれば64x64x64相当のテクスチャとみなすことができます。

この手の処理は大概テクスチャ境界が面倒になるものですが、FLOATテクスチャは最近傍フィルタしか使えないのでどうにでもなります。

そしたら、あとは2Dシミュレーションを3Dに拡張しつつテクスチャサンプリング部分を自前でアドレッシングするようにするだけです。ヤッター!

レンダリング

シミュレーションが首尾よくできたら最後にレンダリングです。これが結構面倒です。ボリュームレンダリングの手法は無数にあります。

しかし、最初考えてた方法(光源方向からシャドウボリュームテクスチャを生成していい感じにやる)は、WebGLがどうやらマルチレンダーターゲットに対応していないらしいので破綻しました。まあ対応してたところで、イマイチなんですけど。

しかたないので普通にカメラからレイマーチング+光源にも各サンプル点からレイマーチングという方法にしました。この方法だと、サンプリング数がO(N^2)(Nはサンプル数)みたいな感じになりあまり筋がよくないのですが、プライマリのレンダーターゲットの解像度を半分にしてみたりきちんとAABBで枝刈りしたりみたいなことをしていったら結構速度が出るようになったのでそれでよし!としました。

高速化とか

シミュレーションステップの順番を細かく変えたり、圧力項を解くためにガウスザイデルする際、前フレームの結果を使い回りしたり、みたいな涙ぐましい最適化をします。まあまあ速くなります。

おわり

まあなんとかシミュもレンダリングもできました。dat.gui.jsとかStats.jsとか、便利ライブラリを突っ込むとそれっぽくなってかっこよくなります。組み込みも簡単です。

だいたい、一日ちょっとくらいで絵が出て、あとは細かい調整って感じでしたし、どんどんWebGLすればいいんじゃないでしょうか。

シミュレーションを放置しておくと割と爆発したりするんですが、これは色々シミュレーションを雑にやってるせいです。TODOってことで。

githole/webglSmoke · GitHub

一流グラフィックスプログラマへの道~リアルタイム編~

はじめに

こんにちは。holeです。
この記事は第三回レイトレ合宿アドベントカレンダーです。

今回は一流グラフィックスプログラマ(リアルタイム)になる方法を探ってみました。
一流のことは一流の会社を調べるのが一番!ということで海外15社(18種)、国内4社(4種)のグラフィックスプログラマの募集要項を調査しグラフィックスプログラマに求められるスキルを考察してみました。ゲーム会社に偏ってしまいましたが、やはりリアルタイムCGはゲーム屋に一日の長があるためそのようなチョイスになっています。

 対象の会社

対象としたのは以下の会社・職種です。他の会社については、グラフィックス系のプログラマの募集を明示的に行っていなかった(2015/06時点)ため載せていません。

海外

Naughty Dog/Graphics Programmer
Infinity Ward/Sr. Rendering Enginner
Sledgehammer Games/Sr. Rendering Enginner
Sledgehammer Games/Rendering Enginner
Bungie/Graphics Programmer (Sr. or Lead)
Rockstar North/Jr. Graphics Programmer
Rockstar North/Sr. Graphics Programmer
Bethesda Game Studios/Graphics Programmer
DICE L.A./Sr. Rendering Enginner
Crytek/Sr. Rendering Enginner
Crytek/R&D Graphics Enginner
Epic Games/Lead Rendering Programmer
Unity Technologies/Graphics Programmer
Santa Monica Studio/Sr. Engine/Graphics Programmer
Firaxis/Graphics Programmer
Avalance Studios/Sr. Graphics Programmer
Codemasters/Graphics Programmer
Quantic Dreams/Sr. Graphics Programmer

日本
スクウェア・エニックス/第3BD/3Dグラフィックスプログラマー
カプコン/レンダリングエンジニア
シリコンスタジオ/グラフィックス開発エンジニア
Tango Gameworks/グラフィックプログラマー

 それぞれの募集について、要項をまとめました。似たようなスキルは適当にまとめました。精度は何とも言えないところですが、まあ感じをつかむということであんまり統計的データとしての意味はないでしょう。

必須スキル

上位を占めたのはやはりGPU&グラフィックスAPIの知識C/C++の知識でした。あまりにも当然の結論ですね。前者はかなり大ざっぱな分類ですが22ポイント、後者は19ポイントでした。

ゲーム系のリアルタイムグラフィックスプログラマで募集かけてんだからGPUとかDirectXとかシェーダの知識が要求されるのはあまりにも当然ですね。書き忘れてる会社とかはさすがに存在しませんでした。

Crytek/R&D Graphics Enginnerは少し面白く、「特にDirect3Dと明記されていました。CrytekといえばXBoxOne独占タイトルとしてRYSEをリリースしたのは記憶に新しいですが、開発においてMS陣営との結びつきが強いためにD3D知識が重視されてるのかもしれません。

C/C++知識については、現状、AAAタイトルの開発はC++を中心に行われているからでしょう。世の中には無数のプログラミング言語がありますがいわゆるコンソール開発を中心としてプロダクションにおけるゲーム開発はC++が支配的です。ハイレイヤーはまだしも、グラフィックスプログラミングはかなりローレイヤー寄りに分類され、場合によってはエンジン開発と密接にかかわることからC++が選ばれるのも納得です。

重要スキル

続いて、多くの会社が要求スキルとして指定している重要なスキルについてです。上位を占めたのはコンピュータグラフィックス知識全般3D数学ローレベルなデバッグ・最適化の技術です。

グラフィックス知識はかなり漠然とした話ですが、モダンなレンダリング技法(大域照明や影、ポストエフェクトといった全て)のアルゴリズムについての知識といった形になるでしょうか。こういったスキルについて明確に要求していない会社も暗に要求していると考えられるのでほぼ必須スキルになりますね。

次に重要度の高いのが3D数学です。最近のグラフィックスは高度化が進み、それに伴い必要とされる数学力の水準も上昇傾向にあります。多くの会社が明確に「Strong Math Skill」を要求していました。あくまで3D方面のCG数学(線形代数とかその他)という意味合いなのでしょうが、とくに何の指定もなく「数学」と言い切っている会社もあります。

カプコンレンダリングエンジニアは歓迎条件として「光学、数学、物理学の深い知識 」を挙げています。これは、近年の物理ベースレンダリングの流行に伴い光学・物理の知識の重要度が上がっていることの顕れでしょう。しかし、海外の会社は数学を要求することはあっても光学や物理については特に言及のある会社はありませんでした。強いて言えば、Avalance Studios/Sr. Graphics ProgrammerはPhsyically Based Renderingの知識を歓迎条件として挙げていたくらいです。

Infinity Ward/Sr. Rendering Enginner(以下、リンク切れの可能性あり)は

* Strong 3D math, particularly as it relates to modern rendering techniques such as energy. conservation, alternate basis representations, voxelization, and path tracing etc. 

としてあります。パストレーシングくらいは書けないとCall of Dutyは作れないということでしょうか。こういう会社は他にはありませんでした。レイトレをはじめとしたオフラインレンダリングの知識を要求スキルに挙げている会社はほぼありませんでしたが、あると便利な裏スキルに間違いないという確信を持っているので皆さんもレイトレをしましょう。

ローレベルなデバッグ・最適化技術は、やはりグラフィックスプログラマには求められることが多いようで、14ポイントでした。グラフィックスは速度にシビアなケースが多いので当然でしょう。また、各種のグラフィックスプロファイリングツールの習熟を求める会社もかなりの数存在しました。

学歴

今回調査して驚いたのは、コンピュータサイエンスの学士号を要求する会社がとても多い(海外)ということでした。具体的には以下のように記述されます。(Naughty Dog/Graphics Programmerより)

Bachelor’s Degree in Computer Science or equivalent work experience

 要するにコンピュータサイエンスの学士号またはそれに準ずる経験の持ち主であること、を要求してるわけです。日本のゲーム会社は学歴不問としてる場合が多いのでこれはちょっと新鮮でした。別に学士号を持ってなくても相当の能力を示せば良いことになっているので別に門戸が狭いわけではないと思います。

しかし、Quantic Dreams/Sr. Graphics Programmerは明確に

Graduated with a Master Degree in Computer Sciences (Engineering school)

としています。このような、学歴に関する要求は全部で14ポイントでした。ちなみに、Rockstar North/Jr. Graphics Programmerは数学の学士号でもOK!としてます。学歴に関する条件が無い海外のゲーム会社は、Rockstar North/Sr. Graphics Programmer、Epic Games/Lead Rendering Programmer、Unity Technologies/Graphics Programmer、Avalance Studios/Sr. Graphics Programmerでした。エンジン開発系の会社が二社出てきたのは少し面白いですね。

コミュ力とか自主性

コミュ力もかなり重要度は高そうです。何らかの形でGood communication skillを求める会社が多いです。Bethesda Game Studios/Graphics Programmerは対人関係スキルとコミュニケーションスキルをわざわざ別の項目として記述するほどです。ゲーム会社といえやはり社会的能力はあったほうが良いということでしょう。

また、Self motivationという単語を使う会社も多めでした。自主的に行動し、問題に立ち向かい解決する、そういう人間が高く評価されるわけです。

過去の経験

今回調べたのは基本的に中途向けの募集要項なので過去の経験も重要になります。結構具体的に要求している会社も多かったです。

まず、コンソールやPCでのゲーム開発経験を求めるケースが10ポイントに上りました。日本の会社が内3ポイントを占めており、日本においては前職の経験がかなり大事になりそうです。一方、海外ではコンソール経験を明確に求めていないケースも多くありました。海外においてはCG産業はゲーム以外にも幅広く広がっているため、多様な人材を求めているのかもしれません。

経験年数については、普通のプログラマよりもシニアプログラマの方が長め、といった感じです。五年以上のグラフィックスプログラミング経験は8ポイントにも上りました。特に、Crytek/Sr. Rendering Enginnerは少なくも二年間のシニアプログラマ経験を要求しておりなかなかに水準の高いものになっています。

Sledgehammer Games/Sr. Rendering Enginnerは七年以上のグラフィックスプログラミング経験を要求しており今回調べた中では最長でした。

ゲーム開発への情熱

一般に、欧米のゲーム会社は分業が進み自分の専門領域に特化していると言われています。そのためか、一部には海外では個々のプログラマレベルではゲームデザインにコミットしないと考えている人もいるようです。しかし、実際は募集要項に面白い、良いゲームを開発するということについての貢献を求められるケースが見受けられます。実に半分近くの会社で何らかの形でゲームや、ゲーム開発への情熱を要求されています。例えば以下のような形です。Naughty Dog/Graphics Programmerより)

Passion for playing and developing exceptional games 

 また、Bethesda Game Studios/Graphics Programmerは過去のBethesda Game Studiosのゲームのプレイ経験を求めています。

その他の重要そうなスキル

読みやすく、移植しやすく、信頼性の高い最適化されたコードを書ける人間を明示的に求める会社もいくつかありました。特に、Santa Monica Studio/Sr. Engine/Graphics Programmerはドキュメントをちゃんと書きプログラムのテストを書き高い品質のコードを書くことを要求しています。

次世代機(PS4、XBoxOne)への移行が急激に進んでいる今、次世代機の経験も貴重な能力です。五つの会社が次世代機における開発を重要なスキルとしてとらえていました。

ゲームにおけるグラフィックスはシステム全体に広がるため、グラフィックスプログラマはエンジン部分と密接に連携しなければなりません。実際、エンジンプログラマとして募集している会社もあります。そこで、ソフトウェアデザインの知識や大規模なコードの経験を求める会社もあります。明確にリーダーとしての能力について示す必要がある会社もありました。

基本的に欧米の会社を中心に調べたのですが、世界中から人があつまるような会社は英語スキルについても記述がありました。CrytekとUnity Technologiesです。また、スクウェア・エニックスカプコンも同様でした。コンピュータグラフィックスの本場は欧米なので、最新技術を追うために英語は避けられません。特に、日本のエンジニアは英語スキルを求められるでしょう。

グラフィックスプログラマはゲーム内のアセットを作る、いわゆるアーティストとも密接に連携する必要があります。Rockstar North/Sr. Graphics Programmer、Epic Games/Lead Rendering Programmer、Avalance Studios/Sr. Graphics Programmer、Tango Gameworks/グラフィックプログラマーはアーティストとの連携について明確に記述がありました。やはり、リード、シニアクラスになると他チームとのコミュニケーションも重要になりそうです。

小ネタ

Sledgehammer GamesとBungiePS3のプロセッサであるSPUの開発経験を求めていました。これは、彼らの作るゲーム(Call of DutyとDestiny)の主要マーケットとしてPS3がまだまだターゲットに入っているということの証拠ですね。あるいは単に昔の記述を削除し忘れただけなのかもしれませんが。

募集要項の項目の内容と数にも注目です。欧米の会社の要綱は項目数が多く、かつかなり具体的な内容になっています。一例を挙げると、Quantic Dreams/Sr. Graphics Programmerは全部で18項目あり、しかも以下のように具体的な手法にまで踏み込んでいました。

- Excellent knowledge of various rendering techniques such as:
o SSAO
o Deferred Shading technical
o Shadows
o Global Illumination
o Particles
o Etc. .  

他の会社も、項目数が10を超えることは珍しくありません。欧米の会社の項目数の平均は約11.8個でした。一方、日本の会社の項目数の平均は9.25個でした。これも、BethesdaグループのTango Gameworksが押し上げた結果です(16個)。こういうところにも微妙な文化の違いを感じますね。 

まとめ

というわけで各ゲーム会社のグラフィックスプログラマの募集要項を調べてみました。これらを全て満たせば自ずから一流グラフィックスプログラマになれることでしょう。

とりあえずC++・数学・GPU知識・グラフィックスAPI・英語あたりを押さえておくのが重要そうです。