!!!独り言日記 !!金八先生（2004/06/30） もう、３年ぶりくらいにゲーム買ってきました。というか、東京来てから 初めてゲーム再開です。 秋葉に行くのもこれまた半年振りくらい。 買ったのはチュンソフトの「3年B組 金八先生」（PS2）です。 某所で以外と評判よかったので・・・（正直、クソゲーかと 思ってたもんで・・すみません(^_^;;）。 もう、３Ｄは一切なしでオムニバスドラマ形式のものなのですが、 これが結構いい話が多いっす。 「金八」の名はありますが、なんか学園ファンタジーっぽくて ほのぼのしてますねぇ。ドラマとは別物と考えたほうが良しです。 個人的には、良アドベンチャーかも。 絵が「猫の恩返し」の方ですので、あまりアニメアニメしたのが 苦手な人でも安心かもしれません。 !!Pentium4（2004/06/28） 時間がかなり空いてしまいました。 今までAthlonマシンを使っていたのですが、仕事用にPentium4マシンにて プログラム(レンダラ)を検証しています。 で、Pentium4というとSSE2とハイパースレッドですね。 演算処理を4並列するわけですが、それにもまして浮動小数点演算での 精度がAthlonマシンよりも正確な気がします。 （Athlonの場合は、オーバーフロー・アンダーフロー対策しないと とんでもない値をはじき出したりしていました） 後、レンダラのソースを再度見直していますが 一度交差判定部をすべて作り直したところ、微妙に速度アップ。 速いCPUだと、下手にコザイクして（条件判定で）計算を省くよりも 「がっ」と計算ししてしまったほうが速いのかもしれません。 （もしかしたらキャッシュに乗るかどうか、といった低レベルな 最適化が効いているのかもしれないですし） !!ポリゴンの管理（2004/06/19） 今、レンダラで32ビット値でポリゴンを連番管理しているのですが これだと上限は約4億ポリゴンになります。 が、実際は億を超えるのもあるので、ただいま64ビットで扱うように いじってます。 Windows(VC++)では、「__int64」にて64ビット整数を扱います。 ただし、メモリのアドレス自身は32ビットですので、頂点座標やら法線やらを すべてメモリに格納する、といったことは難しいです。 （100万程度ならば大丈夫ですけども） この場合は、メモリではなくハードディスクに情報を蓄える、としないといけません。 これも実装するためソースをがしがしいじってます。 で、全面的にソースを見直し（リファクタリング）してますが、 「あのころは若かった」って記述も多くこっばずかしいかぎりです(^_^;; （とは言っても１年も経ってないけど） 関係ないですが、過去のソース・というよりも一番はじめに書いたであろう プログラムソースを未だに残していたりします。 当時は20年くらい前だっけなぁ、FM-8でBASICでアドベンチャーゲーム作って 遊んでました。それがまだ残ってたりします。当時は紙にプログラムを書いて、 それを打っていたんすね。テープやFM-8そのものはもうないのですが、 ソースだけは紙で残っているわけです。 ファミコン全盛期なんでその影響受けまくりだったころなんですが、 グーニーズのマイキー（だっけな、主人公のキャラクタです）を 紙にドット絵で写し、3プレーン（8色分）で 色を考慮して16進に書き出していた（手作業で）ことを思い出します(^_^;; 当時のファミコンの説明書には、キャラクタの紹介でドット絵が描いてたんすよ。 たしか、スパルタンXやロードランナー・スーマリもそうだったはず。 なんで、それを模写して16進変換してディスプレイ（FM-8上）で色つき再現して 遊んでたと。 まぁ、そんなこんなで懐かしい気持ちで「ドット絵職人」(MdN)なる本を購入。 今、ドット絵がアツい！！ !!GPUの進む道（2004/06/15） ついにここまできたかという感じですが、リアルタイムレイトレーシング が実験では成功したようですね。 http://spin.s2c.ne.jp/news0406.html#saarcor リアルタイムというと、nVIDIA/ATIなどのGPU（Ｚバッファベース）が 主流ですが、仮にこのレイトレ自身がハードウェア実装されるとなると その流れも変わるかもしれません。 今まで、手間をかけていた「反射」「屈折」などを１レイをたどるだけで 実装できてしまうわけですからね。 （いわゆるネイティブのレイトレに近づいた、ということで） これが進むと、「オフラインレンダラ」「リアルタイムレンダラ」の境が なくなり、ゲーム画面などがムービーそのものになりそうですねぇ。 楽しみな反面、末恐ろしい技術進歩だなぁと。 Zバッファレンダラが消えてしまうとびっくりではありますが(^_^;;、 たぶんそうなるんだろうなぁ。 !!ボトルネック（2004/06/13） レンダラにて、ボトルネック解決策をいろいろ調査中です。 一般にレイトレ式のレンダラは、ポリゴンとの交差判定が速度に影響しますが、 GIを考えると「間接照明」を求めること自体がネックになってしまいます（交差判定以前に）。 なので、イラディアンスキャッシュなどの「補間」が必要になるのですが、 これってフォンシェーディングをグローシェーディングにしたようなもんで（ちょっと強引かな(^_^;;）、誤差のしきい値をキツくしないといろいろ問題が出てきます。調整もトライ＆エラーが 発生して面倒ですし。 ただ「間接照明」は緩やかに変化しますので、補間と相性がいいといえばいいかもしれません。 ですので、イメージとして間接照明を貼り付ける（IBL：Image Based Lighting）、 シャドウマップと併用する、というのも高速化する方法論の１つかもしれません。 後は、レイトレスタイルにこだわらずスキャンラインで処理をしてしまうとか （RenderManのごとく）。これだとGPUでアクセラレートすることもできるかも。 現状、十数秒で１フレーム(1000x800pixelほど)をレンダリングしてしまうGIレンダラもあるとのことで（実際に製品化されてます）、なんだか技術の進歩というか取り残されているのを感じてます(^_^;; レンダラは掘れば掘るほどアツいっすねぇ。さて、論文をあさるか・・・ !!実家からの連絡にて（2004/06/12） 実家からの連絡にて、架空請求のはがきがひっきりなしに届いているとのこと。 「無視しといて」という風に親に伝えておいたのですが、不特定多数に 出してるんでしょうかね、ネットで調べてもいろいろヒットしてました。 これが、私が東京に出る前（しかも実家の住所が変わる前）の住所宛で来ていた、 ということからしても、学生時代の卒業名簿が妖しいっす＜漏れどころ 後、最近はメールでのウイルスNetSkyの多いこと・・・毎日が メールでの（ノートンの）「感染してます」ダイアログを閉じる作業を行うという 面倒くささ・・・ と、いろんな手段で来ますねぇ。あ、それとワンギリも最近流行ってるのかな、 去年まではナリを潜めていたのですが、最近ちょこっと来たりします。 私は、ネットで調べるとすぐに情報が手に入るのでいいのですが、 実家の親とかはパソコンを使えないので心配ではあります・・・・ヘタに頑固なんで 大丈夫だとは思うのですが・・・ !!外部ファイル化（2004/06/08） レンダラにて、ようやく情報をファイルに移行（今までは、プログラムにパラメータを記述してコンパイル、などといった手間をかけてました）。 これで、いろいろチェックできます。フォトンマップの方を詰めてますが、フォトンを 集めるとき（ファイナルギャザー時）の半径が小さいと、やはりモヤモヤが出ます。 ので半径を大きくすると飽和されてモヤが目立たなくなります。 しかし、時間とのトレードオフです。 他のレンダラもいじって比較してみましたが、これは同じですね。 やはり、「品質を取るか」「時間をとるか」のバランスが難しいです（フォトンマップでも）。 でも素朴な疑問で、フォトン時のスカイライトってどうするんだろう？ 半球から適度にフォトンを飛ばすんだろうか・・・ 後、先日実験していたシェーダー言語ですが、仮想コードを吐き出す部分までは どうにかいけたのですが、よく考えりゃ定義されていない変数も持っておく必要がありますねぇ。 BMRTで言うと、 surface clay ( float Ka = 1, Kd = 0.7, roughness = 0.1;) { normal Nf = faceforward (normalize(N), I); Ci = MaterialClay (Nf, Cs, Ka, Kd, roughness); Oi = Os; Ci *= Oi; } のCi/Oiです。後、#includeによるヘッダ内包もあり、 中身を見るとほぼC言語では・・・結構強敵ですね(^_^;;＜構文解析 この構文解析＆コンパイラ部分で、軽く１ヶ月は費やしそうですので 後回しにしよう・・・ 関係ないですが、Wikiのイメージ表示はWebブラウザのキャッシュに 蓄えられないようですので（表示時間がかかりますので）refでリンク形式にしました。 !!シェーダー言語（2004/06/06） RenderMan形式（RIB）ではマテリアル情報は、「シェーダー」という形で言語として 定義することができます。私はBMRTしか知りませんが、拡張子slのファイルを中間コードに コンパイルしてslcになります。 例えばプロシージャルテクスチャマップ（計算で模様をつける方式）を行いたい場合、noise関数とか 加減剰余算したりで、Shadeで言う「雲」「木目」「ストライプ」などを表現できます。 ほんと、関数＋数式で事細かに「プログラム」できるため、いろんな表現が可能になり、 かつ拡張性があるわけです。 で、これをいざ独自レンダラに加えるとなると「構文解析」の壁が立ちはだかります。 ちと、このあたりの言語解析部分もやらないとダメだなぁ・・・ !!情報追加中・・・（2004/06/05） 細々とした情報をいろいろ追加していってます。 とりあえず、私のメモ帳をWeb化・共有化しちゃおうということでやってますが、 FlashとかPS2とかMSXとか、まぁどこからでも情報を引き出せるように、ということで 息抜きとして牛歩前進で進めていくことにしています。 某方から3Dのアルゴリズム（初歩）を、というのがありましたので これも公開していきますね（長々とリンクが切れてますが(^_^;;）。 で、なぜこんなことをする（わざわざ一般公開する）のかというと、私も 仕事をする上で、いろんなWeb検索・情報にて助けてもらったことが多々あるから というのも理由としてあります。 いわば、ギブ＆テイクです。 ぶっちゃけ、仕事として当たり前のこととか、MSXとか「使わねーだろ」とか言いたげな 趣味情報を共有できれば、輪が広がれば、ということでして(^_^;; !!現場の声を聞いてみました（2004/06/03） 本日、某所に行って某ムービーを作成したクリエイターの方に「実際、レンダリングしてどれくらい時間がかかったんですか？」という質問をしてみました。 キャラクタ（人）のアニメーションをして、640x480pixelで1フレーム1分ちょっとだそうな。 これが、クロスの計算と髪の毛の計算を入れてですから、世界の壁を感じました(^_^;; MAX恐るべし。 たぶん、普通の（一般的に言う）レイトレをせずに スキャンラインベースとシャドウマップだと思うのですが（でもGI対応）、 「まじめにパストレでレンダリングしました」というよりも、フェイク的な技法のほうが むしろ現場の声としては大きいかもしれないですね（特にアニメーションベースだと）。 これは、「速度」と「品質」のバランスが重要なのかも。 一般的に、２時間のアニメーションを1秒24フレームでレンダリングする場合、 １フレームを3分としたら、なんと1年まるまるレンダリングで待たされる、ということになります。そう考えると、速ければ速いほどいいというのは現実味を帯びますね。 ちなみに、以下のイラディアンスキャッシュですが半球の半径を大きくしすぎると 誤差を飲み込んでしまい、結果的にウソが出やすいために、「円を塗り重ねた」的な 表現になってしまっている、というのが原因のようでした。 ただ、許容範囲の半径を小さくすると、今度は水玉のような低周波ノイズが出るんですよね・・・ ちなみに、6/1のドラゴンの画像はキャッシュ用半球の半径17.0/許容誤差1.0でイラディアンスキャッシュ計算を 行っていました。シーンによってパラメータを変えないと思った絵が出ない・・・ これもなんとかしたいですねぇ。 天球光だけのシーンならいいのですが、面光源が入ると、やはりフォトンを取り入れないと 速度的にも品質的にも辛いようです。 ということで、そろそろフォトンに突入しようかと。 !!イラディアンスキャッシュ実験（2004/06/02） 引き続きイラディアンスキャッシュを掘ってます。イラディアンスキャッシュを実装するに あたって、「放射照度を表す半球の有効半径」と「誤差を緩和する重み付け係数」が あります。 この指定により、計算時間が大きく変わるわけですが・・・ 以下は、テスト的に半径を大きく取ってみたときの 放射照度のキャッシングされた位置を表したものです。 色変化が激しい部分に密に分布するのが分かるかと思います。 {{ref icache_20040601.png}} {{ref icache_20040601_2.png}} ２つを比べてみて、半径が大きくても密なところにキャッシュが貯まっていくようですね。 できれば、この２つのパラメータは自動化したいですので何とか特徴をつかみたいところです。 重み付け係数は、小さいとより「密なところ」にキャッシュが潜り込むようになります（正しい値に近づきます）。ただし、あまり小さすぎると処理時間がかかってしまいます。 1.0とかにすると、実際の照度の密なところがあるにもかかわらず、ほとんど均等になってしまいます。 この２つめの「半径400」「重み付け係数0.2」を実際に間接照明だけレンダリングしてみました。 {{ref icache_20040601_3.png}} これは、天井に面光源を１つ配置してます。 ・・・いかにも「円を塗り重ねてます」ってのが見えてしまっている・・・(^_^;; 境界部分を飽和させる方法はあると思うのですが・・ちと数式をいろいろ推敲してみようかと思います。 !!イラディアンスキャッシュ実験（2004/06/01） Wikiにてデータ管理をするようにしましたので、記念に、ということでいろいろアップ中です。このページは「日記」となります。WikiはFreeStyleWikiを使わせていただいております。 便利なツールに感謝です。が、Wikiの性質上、誰でも書き込みできますので個人サイト作成には（セキュリティ上）厳しいかもしれませんね(^_^;;。日記は凍結しちゃうかな。 さて、パストレをベースにしたイラディアンスキャッシュの実験です。 すべて、640*480pixelにて（スペースが多いですが）108590ポリゴンの オブジェクトを配置してレンダリングしました。 Athlon 1100Mhz/Mem512MBのWin2000です。 !50path/pixel（間接照明のみ）→427秒（約7分） {{ref srender_20040601_50path.png}} 上記は普通のパストレースです。 !約1200path/pixel（間接照明のみ）→3082秒（約51分） {{ref srender_20040601.png}} パストレースをちょっと変形させて、かつ精度を上げて約1200path/pixelくらいで レンダリングしてみました。 まだ、微妙にノイズが残ってますね。 !約1400path/pixel相当（間接照明のみ）→84秒（約1.4分） {{ref srender_20040601_icache.png}} イラディアンスキャッシュを自己流にアレンジして実装してみました。 一応、1400pathほど（「約1400path」となっているのは、厳密にはすべての ピクセルにて1400pathの計算をしているわけではないからです）の精度です。フォトンマップは使っていません。 が、イラディアンスキャッシュの補間の影響で、目の部分・影（陰）の部分が甘くなってしまっています。また、床に低周波ノイズが見られますねぇ。 しかし、このサンプルは「間接照明」のみですので直接照明が入ると、それも緩和されることになります。 誤差は無視して進めちゃいましょう。 !1400path/pixel相当（間接照明＋直接照明（平行光源））→101秒（約1.7分） {{ref srender_20040601_d.png}} これくらいでしたら、どうにか実用に耐えることができるでしょうか。 ただ、もっとスピードアップしたいところではあります。 イラディアンスキャッシュ（実際は方法論だけ採用させていただいて、アルゴリズムはおそらくオリジナルです・・・と思いたいです(^_^;;）を使うと、本来時間のかかる処理を大幅に節約できることが分かりました。 放射照度勾配（irradiance gradients）も実験してみたのですが、画質の向上も少なくて速度も遅かったために却下しました。 また、3Dの技術に関してもページを作って紹介することにしますね（本職に差し障りのない程度に）。