CGじいさんシリーズvol.1「CG検定に出る古典的レンダラー」時代を錯誤したCGじいさんが古典的レンダラーを今の若い人にわかるよう語ってくれます

ただいまご紹介にあずかりました、CGじいさんでございます。

CG検定の検定日が近づいてまいりました。自分は大東亜戦争以前から3DCGを仕事として作り続けて来たのでありますが、この検定を受ける若きCGクリエイターやその卵である皆様におかれましては、CGクリエイター検定に見事合格、そして立派な日本人としてご活躍していただく為に、古典的なレンダラーについての理解を深めていただく必要があるとの思いに至り、このブログに残そうと思った次第であります。

さて、古典的なレンダラーとはいったい何でありましょうか。

ナウなヤングはUE4だEeveeだというご時世ではございますが、実は若い皆さんが今後、古典的なレンダラーに出会う可能性がまだあるのです。Maxならスキャンライン レンダラー、MayaならMaya Softwareというレンダラーが残っています。これこそが古典的レンダラーです。標準でプロ用の統合3DCGソフトに付属していて、実制作では誰も使わない、時代遅れのレンダラーであります。

そのくせツールに必ずついている最も一般的なレンダラーなのでありますから、他のツールから変換されたシェーダーがこれ用のシェーダーだったりする事があります。ユーザーはなにやら良くワカランが、折りにつけ何かと付き合わねばならぬ、、という事態に直面するのであります。

戦前のレンダラーは、反射・屈折がせいいっぱいで、間接光の表現(GI、グローバルイルミネーション)は夢のまた夢でした。間接光を計算するには、昔のコンピュータではレンダリングが終わらないくらいに爆発的にCPUパワーが求められてしまうのです。

その後のCPUパワーの増大により、過去の一時期隆盛を極めたこれらのレンダラーに対し、間接光まで含めた「物体の明るさを決めるすべての照明を考慮する」という新しい設計のレンダラーが出現し始めました。この「すべての照明」という意味がグローバルイルミネーションの「グローバル」の意味そのものであります。それに対する形で古典的なレンダラーのやっている、直接光のみの局所的な照明計算はいつしか「ローカルイルミネーション」と呼ばれるようになったのです。

古典的レンダラーでも反射、屈折はできます。それこそがGIではない、「ただの」レイトレーシングです。カメラから光線を逆に追跡し、反射屈折方向にも追跡しながら物体やライトの情報と位置関係からピクセルの色を決める。これだけでも場合によってはかなりの計算量が必要でした。乱暴に説明いたしますと、GIはこのレイトレの原理をさらに間接光にも応用したものなのであります。

間接光の表現ができると、物体の色が他の物体の照明に影響を与える「カラーブリーディング」という現象がリアルに再現できます。これを見た自分はその表現力に驚愕し、CGの未来に希望を抱いたものであります。

さらに話が少し脱線いたしますが古典的レンダラーにはこの「ただの」レイトレーシング法と、スキャンライン法というレンダリングアルゴリズムがありました。レイトレーシングがピクセルごとに光線を追跡するのに対し、スキャンラインは文字通りスキャンラインごとにバッファ(Zバッファなどと呼ばれる)をメモリに持ち、隠面処理(どの面がカメラに見え隠れするかの判定)などの計算を行います。反射屈折計算は疑似的にしか行わないので計算はレイトレより速いのですが、当然表現力は低くなります。しかしこれらの言葉はもはや若い皆さんには覚えるにも値しない言葉です。にもかかわらずこのような日露戦争以前の言葉が、いまだにCG検定の問題に出てくるようで、これには困ったものだナアと感じています。

ちなみにMaya標準レンダラー「Maya Software」にはray tracingのon/offができるスイッチがあり、このスイッチを入れない限りはスキャンラインレンダラーとして働く、いいとこ取りのハイブリッドレンダラーだと記憶しておりますが、最早どうでもよい昔話でございます。

さて話を戻しますが、「間接光の計算をいかに効率よく行うか」という問いへの答えには決定打がなく、過去様々なアルゴリズムがこれまで考案され、様々なレンダラーに実装されてまいりました。ラジオシティ法は一時脚光を浴びましたが最近は流行りません。フォトンマップ法はコースティクス(集光)の表現をする時やサブサーフェス・スキャッタリングで使われます。最近は便利な世の中でして、ご存じでない方はそれらの言葉をググって頂ければどんな事をするのかがすぐ画像で分かりますので、ご覧頂ければ幸いでございます。

それと同時に、昔のレンダラーはシェーダーの扱いが物理ベースではないので、物理的に正しい計算をまったくいたしておりません。それっぽいアルゴリズムで計算をしているだけです。32bitのHDRIも扱えなければ、太陽のシミュレーションなど不可能なのです。扱う数値は0.0~1.0がほとんどで、それ以上の値を入れても良いことはあまりないのですが、現代の厳密な物理ベースのシェーダーとは違い、どんな値でも入れることそのものは許してしまうところがご愛敬です。

ご愛敬と言えば、Maya Softwareでのambientパラメータで行うことはそのシェーダの当たっているオブジェクト全体に、指定された色を一様に足すだけです。「環境光」と称しておきながらこんな事しかできないのであります。GIレンダラーのいわゆるアンビエントオクルージョン(AO)とは全く考えが違うのです。色を足すだけなら同じ事がコンポジットでできてしまうので、当時の自分はこれは「百害あって一利なし」と考えておりました。もしCG検定で「アンビエント成分」の類の言葉が出てきたとき、それはこの古典的な意味でのアンビエントである可能性があるので、覚えておいた方がよろしいかと思います。

古典的レンダラーでのspecularも、reflectionやglossinessとはまったく違い、物体の光源に向かっている面の一部がハイライトとして明るくなるように見せているだけの代物であります。現実世界のスペキュラーハイライトは物体の表面での微細な反射により現れるもので、結局は反射の見え方のひとつなのですが、古典的レンダラーのシェーダーではスペキュラーは反射とは別物として扱われます。また古典的レンダラーでは反射屈折はボケません。ガキっとピントの合った反射屈折の表現でも「リアルだ」と言われていたのが当時の世相でありました。

さて当時のレンダラーで間接光まで表現したい場合、例えば室内の表現などが仕事として来た場合、当時のCG制作者はどうしていたのでしょうか。

自分は過去のCG仕事において室内の表現をする場合には、すべての壁面に面ライトを置き、微妙な間接光の見え方を真似たり、テクスチャに直接オクルージョン的なマップをそれらしくペイントで書き込むなどの、細かな努力をしておりました。いまやVrayやArnold、さらにはリアルタイムのゲームエンジンであるUE4もしっかりした計算をやってくれるそうですし、いざとなればそのような計算でテクスチャをベイクしてしまえば描画は劇的に速くなりますので、現代においてはまったく行う必要のない努力でありましょう。

おわかりいただけましたでしょうか。「今日も決戦明日も決戦」「足らぬ足らぬは工夫が足らぬ」の精神で戦っていた自分でありますが、21世紀の日本CG業界の未来のため日夜努力邁進されている若い皆さんに、私のような老いぼれの知識が役に立てれば望外の幸いであります。

長くなりましたがご清聴、ありがとうございました。

Z-FLAG

東京の神保町のCGプロダクションです。日本一を目指して活動中

最近の投稿

Follow Us