2002-09-01
昨日の無念のフォトンマッププログラムを色々といじくり回してみているものの，納得の行く解答はなかなか得られずにいる。うーむ，恐らくどこかでとんでもない勘違いをかましていると思うんだけれど……どこだ。
ともかく，処理の重たい状態のままで試行錯誤を進めるのも苦痛なので，ここは一旦 kd tree の実装に移行しようかと思う。そうすれば，フォトン数を増加させて実験することも可能となるだろう。フォトン数が少ない状態では，統計的データの分散や，光束密度判定における誤差成分の混入など，正しく処理を行っていても含まれる誤差が多く存在する。だから，出力結果に怪しい部分が存在しても，それがバグによるものなのか，もしくは本来含まれる誤差なのか，判定するのが難しい。ゆえに，フォトン数を増加させることが重要なのだ……。
上の絵でも，例えば球の後ろに影がほとんど無かったりするんだけれど，これは単なるバグである可能性もあるし，光束密度判定に使用するフォトン数が多すぎるために精度が落ちてしまったとも考えられる。
しかし進みが遅いなあ……こんぐらいとっとと通過したいってのが本音なんだけれど。
なんとなく気晴らしにスタンフォード大のウェブを訪問してみた。何かしらヒントが得られるかもしれないしね……とか思いながら。
Pat Hanrahan の講義 CS 348b "Image Synthesis Techniques" では，毎年 "Rendering Competition" なるものが催されているようだ。恐らく，講義の間に習得した技術を実践するための機会を設けたものなんだろうと思う。
http://graphics.stanford.edu/courses/cs348b-competition/cs34...
過去のコンペを見てみると分かるんだけど， Jensen のフォトンマップ本が出て以来は，生徒の間でもフォトンマップを題材にする人が増えているみたいだ。 2002 年のコンペの中では G. Petschnigg and I. Malik の "Vase" や， K. Ong の "Martinis" などが，その良い例だ。
http://graphics.stanford.edu/courses/cs348b-competition/cs34...
http://graphics.stanford.edu/courses/cs348b-competition/cs34...
特に一等賞の "Vase" は，なかなかレベルの高い作品のようだ。題材の選択がいいし，対象物の観察や測定手法も丁寧で良い。結果の見せ方やレポートの作り方が洗練されているのも好印象だ。
なんつうか，自分も学生のうちにフォトンマップとか通過しておきたかったなあ，と思うことしきり。自分にとってのその頃と言えば， Pentium のペアリング規則がどうのこうのー，とか言ってた頃かな，と思う。あれはあれで面白かったけれど，そういう暇があったら，もうちょっと数学の勉強とか真面目にやっとけ，って感じだ……。
K. Ong が "Martinis" の題材として使用したという Mark Meyer のページが，少し面白かった。
http://www.photo-mark.com/feature/stilllife/
普段の生活の中にごくありふれたオブジェクト達が，写真家の目を通すことで芸術的なものに変身するという，一つの例。写真家ってのは芸術家なんだよなあ，って思った。いや，当たり前のことなんだけれど。
http://www.photo-mark.com/cgi-bin/portfolio.cgi?port=6&page=...
2002-09-02
微妙に仕事が入ってきた。まあ，大した量じゃないんだけれど。
やはり，アセットの管理方法や，データのフローがしっかり組み立てられていないと，色々と苦労することになるなあ，と痛感することしきり。単に面倒なだけならば我慢する手もあるけれど，あまりにも複雑な作業工程に惑わされ，誤って大切なデータを消してしまうような事も考えられるから，何も手を打たないわけには行かないだろうと思う。
NXN 社のアセット管理ソフトウェア "alienbrain" が，サーバとクライアント＊２０で，えーと…… $30,000 ぐらい。それに対して， Ensemble Studios が "The Age of Kings" のインハウス製アセットマネジメントシステムの開発に費やしたリソースが，まあ，３人月＋アルファぐらいだと言う。ただし，後者は柔軟なアプリケーションを設計する能力を持った優秀なプログラマが必要で，しかもその人材は期間中フルタイムで拘束されることになる。
http://www.gamasutra.com/features/20010221/marselas_01.htm
なんにしろ，どうにも alienbrain は高すぎるよなあ，ってのが本音。主に，裕福な映画業界なんかをメインターゲットとしているのかもしれない。こういうシステマチックな管理ツールは，いかにも米国のホワイトなマネージャの類が好みそうな代物だと思う。
ゲーム制作において，デバッグほど過酷な作業は他に存在しないと思う……なんてのはプログラマのエゴかもしれないけれど，連日送られてくるバグレポートの山にプログラマとしての自尊心を打ち砕かれつつ，期日の都合から再設計を試みることも許されずに，クズの山の上に更にクズを積みあげるような行為を続け，それでもなお完成の日を夢見て薄暗い塹壕の中をひたすら這い回る様は，まるで醒めない悪夢を永遠に見つづけるような感覚だ。
そんなとき，冗談混じりに，昔ならこんなの裏技扱いだったのにねえ，なんてことを言ってみることがある。確かに，昔はある種のバグが「技」として歓迎される風潮があった。有名なマリオの「−１」面なんてのは，単なるバグってるだけの，本来何の取得も無いはずの現象なのに，みんな嬉々として楽しんでいた記憶がある。
おそらくドラゴンクエストなんてのは，過去最もユーザにデバッグされたゲームの一つだろうと思う。
http://www.ipe.tsukuba.ac.jp/~s990427/dq/
昔は単なる不思議な現象として受け取っていたものも，今プログラマとしての視点で見直してみると，非常に含蓄を持った，ある種の教訓のようにも見えてくる。簡単なロジックミスから，カウンタオーバーフロー，ステートの初期化忘れ，あるいは重要な設計面での手抜きなど，プログラマなら誰もが共感できるようなミスの集合体だ。
例えば， DQIII の有名なランシールバグなどは，非常に簡単な仕様面でのミスが原因。ドラクエほど有名なゲームならば，一人パーティーで冒険するユーザがいることぐらい考え得ただろうに，それをチェックしていないのは，かえって不思議なほどでもある。テスト項目の不備が原因とも言えるかもしれない。
http://www.ipe.tsukuba.ac.jp/~s990427/dq/urawaza3.html
DQIV で「にげる」を８回選択すると全ての攻撃が改心の一撃になる……という現象は，逃げカウンタと各種フラグを混ぜてしまったことから発生した，一種のカウンタオーバーフロー系のバグだ。このバグは，その現象があまりにも鮮やかなものだから，てっきり制作者の意図として入れてあるのかと思ったほどなんだけれど，その実は，誰もが一度は経験するような初歩的なミスが原因だったようだ。
http://www.ipe.tsukuba.ac.jp/~s990427/dq/dq4-3.html
これは最近まで知らなかったんだけれど， DQII には「不正な復活の呪文」を利用するという技が存在したそうだ。不正な復活の呪文を入力するとサムチェックで拒絶されるんだけれど，実はこの時点で各キャラのデコーディングは完了していて，しかも再入力の際にそのメモリがクリアされないがために，不正なステートの再現が可能になってしまう，というもの。
http://www.ipe.tsukuba.ac.jp/~s990427/dq/dq2-3.html
まるでクラッキング手法のような技だ。こりゃあ，今だったらセキュリティホール扱いだよなあ，とか思った。
とまあ，懐古趣味としてはこんな感じ。他にも，スト２やバーチャロンのように，仕様外の現象が後に仕様として取り込まれるケースなんかもあったりするわけで，ゲームのバグってのはわけわからんなあ，と思った。
ハングアップとハマりだけは，なんとしても直さねばならない。それが原則。あとはまあ，見つけたらなんとかする。それ以前にバグを作らないことが重要でもあるけれど，これは制作者が人間である以上どうにもならない領域があることは否定できない。あるいは，祈りや魔除けを導入するとか。
2002-09-03
CG World の付録に付いていた Houdini の Apprentice Edition を家のマシンに入れてみたんだけれど，どうにもうまく動いてくれない。 RADEON じゃだめなんだろうか……うーむ。
UI とか絶妙に UNIX 風味だし（Motif っぽい雰囲気だ），まだどちらかと言えば UNIX 寄りなソフトなのかもしれない。付録 CD の中には Linux 用のバイナリも入っているようだから，そちらを試してみるのもいいかもしれない。
げーはなさん情報で "DOSBox" の存在を知る。
"DOSBox" は，簡単に言うと PC-AT + DOS エミュレータだ。 80286 ベースの PC-AT マシン相当のエミュレータに， DOS 互換の OS を内蔵している。 OS まで込みでエミュレーションしているのが面白いところで，ホスト OS 上のファイルにも簡単にアクセスできるようになっている。 Dr. DOS 等の互換 OS を調達してくる必要も無いから，お手軽感は非常に高い。
現段階でサポートしているハードウェアは， VGA, Adlib など。 Sound Blaster の実装はまだ未完成のようで，あまりいいエミュレーションは期待できないようだ。ただし，これは近い将来に解決されるかもしれない。動作原理は簡単なはずだからだ。
DOSBox が従来の PC エミュレータと大きく異なるのは， CPU のエミュレーションを素で実装しているという点だ。例えば VMWare なんかは 386 CPU の上で複数のカーネルを走らせることによって「仮想マシン」を実現するという仕組みになっている。これに対して DOSBox は完全にソフトウェアによるエミュレーションだ。動作速度では前者の方が圧倒的に有利だけれど，特定の環境を忠実にエミュレートするには後者の方が向いているかもしれない。
そんなわけで，とりあえずいくつか古めのデモを scene.org から落として試してみた。 286 以下限定となると動作するデモは意外と少なく，まともに見れるのは Triton の "Crystal Dream" ぐらいかもしれない。
"Crystal Dream" のような古いデモは， scene.org の Hornet ミラーから入手することができる。
http://www.scene.org/file.php?file=/mirrors/hornet/demos/199...
他にもいくつか見ることのできるデモを探してみた。
Preview by Dust
http://www.scene.org/file.php?file=/mirrors/hornet/demos/199...
Even Better Than The Real Thing by Phoney Coders
http://www.scene.org/file.php?file=/mirrors/hornet/demos/199...
Takeover by Epical
http://www.scene.org/file.php?file=/mirrors/hornet/demos/199...
Ecargxus by The Phoney Coders
http://www.scene.org/file.php?file=/mirrors/hornet/demos/199...
Shoot by The Phoney Coders
http://www.scene.org/file.php?file=/mirrors/hornet/demos/199...
あとは Turbo Pascal を動かしてみるなんてのも面白いかもしれない。あれは確か基本的に 8086 ベースで，拡張として 286 サポートとか，そんな感じだったはずだ。
2002-09-04
サーバが不調で仕事がなかなか思うように進まない。中央集権型のシステムで基幹をやられてしまうと，本当に何もできなくなってしまう。高い金を出してリースしているようなサーバがこんな調子だと，気分的にかなり萎える。どうにかならんものだろうか……。
強化現実関連を漁っていたときに面白いものを見つけたのを思い出した。 Joohi Lee の "AR Modeling" だ。
http://www.cs.unc.edu/~lee/publications/ismr2001/
とりあえずムービーを見ると分かりやすい。
http://www.cs.unc.edu/~lee/publications/ismr2001/ARModeling....
強化現実空間を利用して，実世界に存在するオブジェクトをポリゴンモデリングするためのインタフェースを提供している。どちらかと言えば実験色の強かった "Surface Drawing" とは違って，かなり実用性を感じさせる内容だ。
このツールで使用されている透視型 HMD は，市販の小型カメラ２個とグラストロンの組み合わせによって構成されている。カメラから取り込んだ視差付き画像をワークステーション (SGI Onyx2) 上でＣＧと合成し，グラストロンで立体表示することによって強化現実空間を構成している。
カメラやプローブの座標を得るのには，赤外線 LED と光学センサの組み合わせが使用されている。センサユニットは Image Guided Technologies 社の "3D Optical Localizer" と呼ばれる製品を使用しているらしい。どうやら医療機器用として販売されている製品のようだ。ウェブで調べてみたんだけれど， IGT 社のウェブサーバが落ちてしまっているようで，これ以上調べることはできなかった。
仮想空間と現実空間で深度による描画優先順位を持たせることができないのが，ちょっと気になる。相当に凝ったことをすれば深度の取り込みも可能なんだろうけれど（例えば視差からイメージベースで深度を求めるとか），それを低レイテンシで行うのは非常に困難だ。ただでさえレイテンシは問題となるわけだから，下手に負荷を必要とするような処理は使えないというのが実情だろうと思う。
何はともあれ，最近，強化現実関連が非常に面白いなと感じる。仮想現実よりも応用用途が広そうなのが魅力なのかなと思う。
突然思い出したんだけれど，仮想現実と言えば……ルーディ・ラッカーのＳＦ小説「ハッカーと蟻」に「ブードゥー」と呼ばれるトラップが登場する。
「ハッカーと蟻」の世界では， HMD とセンサーグローブによる仮想現実インタフェースが一般的な操作デバイスとして普及している。小説の中で主人公は，自分に罪を着せたハッカーを追って仮想現実の中へと没入する。しかし，その中で主人公は，ハッカーの作り出した「蟻」による攻撃を受けてしまう。危険を感じた主人公は HMD を外して現実世界へ復帰するんだけれど，実はその「HMD を外す」という一連の行動も「蟻」の見せた仮想現実の一部で，現実世界へ戻ったと思い込んで安心している主人公を再び仮想世界の幻術の中へと引き摺り込んでしまう。
こうして完全に虚を突かれた主人公は，たちまちにして仮想世界と現実世界に対する認識を喪失し，「蟻」の見せる幻術（ブードゥー）の中へと捕らえられてしまう。 HMD から洪水のように流れ込んで来るビジュアルはビデオドラッグ効果を引き起こし，主人公をトランス状態へと移行させる。こうなると HMD を自力で外すこともできなくなり，ただひたすら流れ込む情報に脳を打ち震わせるしかなくなってしまう。
たとえどんなに没入感の高い仮想現実が提供されたとしても，現実世界との間を移行するフェーズを把握している限りは，両者を混同する確率はかなり低いだろうと思う。しかし，この「ブードゥー」のような手法によってそのタイミングを失ってしまったとしたら，正常な認識を維持することは，もしかしたらとても難しくなるかもしれない。
ひとたびトランス状態に突入してしまったら，緊急停止ボタンを押すことだってままならない。現実にこれが成立したら，かなり危険度の高いトラップになるのかもしれないなあ，と思った。するってえと，ユーザの脳波とか測定して緊急停止する安全装置とか必要になるんだろうか。うーむ。
2002-09-05
訳あって Python のバージョンアップ作業などを行っていたら，既存のスクリプトが DB 関連でつまづくようになってしまった。問題のスクリプトでは shelve モジュールを使ってオブジェクトを Berkeley DB に格納しているんだけれど，この BSD-DB がバージョンによって微妙に互換性が失われているらしいのだ……。うーむ。
http://www.python.org/doc/current/lib/module-shelve.html
やはり，バイナリ形式のデータベースは融通が効かないな，と痛感した。データが壊れてしまった場合の復帰に弱いし，今回のような不測のトラブルに対する対処も取りづらい。それほど大きくないデータを扱うのならば， shelve を使うまでもなく mapping と pickle を使って線形化するのがいいだろう。 pickle のデータフォーマットも，あれはあれでかなり謎だけれど，基本的にテキスト形式だから手で修正できないこともないと思う。
最近，流体関連にちょっと食指を伸ばしてみている。とは言っても，流体物理と言えばそれだけで一つの分野を構成してしまうぐらい奥が深いわけで，僕みたいな素人がおいそれと手を出せる分野ではないような気もする。ただ， CG に使う流体シミュレーションはあくまでも見た目重視で，わりとインチキをかましてるんよ……みたいな話を聞いたので，ちょっぴりやる気を出してみようかと思ったわけ。ほんのちょっぴりだけれど。
この分野で最先端と言えば，なんと言っても Ron Fedkiw 軍団だろう。
http://graphics.stanford.edu/~fedkiw/
SIGGRAPH 2002 の "Animation and Rendering of Complex Water Surfaces" などは，フォトンマッピングを使用した超フォトリアルレンダリングとも相まって，非常に美しい結果を導き出している。
http://graphics.stanford.edu/~fedkiw/papers/stanford2002-03....
この論文は基本的に， SIGGRAPH 2001 で発表された "Practical Animation of Liquids" の手法を改良したものとなっている。だいたいの仕組みは変わらないんだけれど，細かい部分で物理挙動の正確さを向上させる工夫がなされている，とのことだ。
http://graphics.stanford.edu/~fedkiw/papers/stanford2001-02....
この論文で使用している手法は，流体の基礎である Navier-Stokes 式をセミ・ラグランジュ法で解き，得られた結果から陰関数曲面を構成してレンダリングする，と，まあ，そんな感じの流れ。とは言っても，「セミ・ラグランジュ法」なんていきなり言われたって僕には何のことかさっぱり分からない。しょうがないので参考文献を頼りにすることにした。
どうやら Jos Stam の "Stable Fluids" が，セミ・ラグランジュ法による流体解析の基礎となっているらしい。
http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/...
この論文は，流体の前知識が無い人でも読み始めることができるように，かなり気遣われているんだけれど，僕はそれさえも理解できないレベルだから，更に参考文献を追ってみることにする。
次に辿り着いたのが， Nick Foster の "Realistic Animation of Liquids" だ。
http://www.cis.upenn.edu/~fostern/liquid.html
ふぅ……ってわけで，ここまで来てやっと理解できる内容になってきた。ここからまた元の文献まで戻ってこれるかどうか分からないけれど，まあ，この論文だけにしたって役に立つ部分はありそうだ。
Nick Foster 氏は他にも気体（煙）のシミュレーションや炎の表現など，主に自然現象の CG 表現手法について色々と興味深い研究を行っている。本職は PDI/DreamWorks に勤めるＣＧ映画屋さんだそうだから，リアリティの追及と同時にプロダクションへの応用のしやすさなどを重視しているような雰囲気がある。
http://www.cis.upenn.edu/~fostern/
http://www.cs.brown.edu/people/tor/sig2002/StructuralFlames0...
まあ，とにかく，色々読んでみよう。読める部分だけでも。
2002-09-06
ちょっと忙しくなってきたので，久しぶりに会社に泊まってみた。来週の前半辺りが小さな峠になるかもしれない。
もう夜はだいぶ涼しくなってきたようで，空調を入れなくともそれほど暑くならない。ようやく過ごしやすい季節になってきた。今回は寝袋もあるので万全だ。前回のようにエアパッチに包まれながら枕（読み古しのサンデー）を涙で濡らすこともあるまい……。
件の Nick Foster の論文を元に流体の基礎をかじってみている。
件の論文の方法では，まず空間をグリッド状に等分し，その各セルについて圧力と速度の情報を与えるようにしている。媒体は圧縮不可能なものと前提しているため，質量についてはわりといい加減に扱うことができるようだ。まあ，そんな感じで圧力と速度のベクトル・フィールドを展開し，離散化された Navier-Stokes の式を適用することでフィールドの変化を追っかけていく。
流体のシミュレーション部分についてはだいたいこんな感じで，水面の形状を求めるにはまた別の方法が導入される。前述のセル毎に質量変化を追うようにすれば水面の形状を求めることもできそうだけれど，そうすると形状の精度がセルの分割度に依存してしまうので，あまりよろしくないようだ。それで件の論文では，形状を表現するのにマーカ・パーティクルを用いる方法と，サーフェス・パーティクルを用いる方法，それとハイト・フィールドを用いる方法が紹介されている。中でも最も単純で表現の幅が広そうなのがマーカ・パーティクルを用いる方法だ。
マーカ・パーティクルは質量を持たない仮想的な粒子の表現で，純粋に流体の形状をトレースするために使用される。速度フィールド内に放たれたマーカ・パーティクル群は，単純に速度フィールドから得られるベクトルに従って移動する（質量が無いのでそういう扱いになる）。また，これらのパーティクルは，流体の物理演算自体には何らフィードバックを引き起こさない。
実装面については MIT の Neel Master 氏のレポートが参考になりそうだ。
http://graphics.lcs.mit.edu/~neel/fluid/start.html
ちょっと地味な内容だけれど，まあ基礎だし，こんなもんかなと思う。いきなり Ronald Fedkiw みたいなこともできないし……。それに，それにこの方法だって陰関数曲面を張るところまでやって，レンダリングにももうちょっと色気を加えれば，それなりに見応えのあるものを作り出せるのではないかと思う。
こんな感じで，なんとなく調べてはみているものの，自分で実装する予定は当面無い。それ以前にやるべきことがたくさんあるし，まあ，通勤中の暇潰しってことで，ひとつ。
2002-09-07
昨日から継続勤務。誰もいない職場で，のんびり仕事。
前回の仕事もそうだったんだけれど，他人の仕事との間に依存関係が発生した際のスケジューリングが，あまり上手く処理できていないような気がする。ていうか，かなり下手だ。基本的にそこらへん，人づての情報とか口約束をベースに進めているからなあ……。それぞれのタスクの依存関係も含めて管理できるようなスケジューリングの手段を，早急に確保する必要があるのかもしれない。
巷で噂の "Tenebrae" を試してみた。
http://users.pandora.be/hollemeersch/blackrose/tenebrae/inde...
Tenebrae は，初代 Quake にステンシル・シャドウや per-pixel 系のエフェクトを付加した改造ソフト (mod) だ。こういったレンダリング・エンジンの置換まで含めたヘビーな改造が可能なのは，完全なソースが公開されている Quake ならではのことだ。 Quake にノンフォト・レンダラを積んだ "NPRQuake" なんかもそうなんだけれど， Quake は今となっては十分に低スペックなために，こういった実験的なプロジェクトのプラットフォームとして使用されるケースが増えてきているようだ。
Tenebrae の実行には製品版の Quake のパッケージが必要となる。データは製品版のものを使用するからだ。もしかしたらシェアウェア版の Quake のデータでも動くかもしれない。そこら辺は試してみないとわからないな……。
Tenebrae の一番の特徴は，なんと言ってもステンシル・シャドウの追加だろう。 Quake 元来のライトマップはアンビエント成分として扱い，その上に Tenebrae 独自の光源処理を重ねるような仕組みになっているらしい。そのため Tenebrae 独自の光源情報をマップデータに追加する必要があり，そういった加工の施されてないマップは全体的に暗めの光源になってしまう，とのことだ。これは今後のバージョンで，自動的に光源を配置するような拡張を施して対処する予定，との情報もある。
どうやら GeForce をメインターゲットとして調整されているようで，自宅の RADEON 8500 だと所々に変なゴミが見えてしまったり，壁が透けてしまったりすることがある。水面の処理など根本的にバグっているようだし，全体的にちょっと残念な実行結果になってしまった。それでもかなり面白い絵が出ていると思うし，極端に処理が落ちるようなことも無くて，そこそこ快適に動いているのは，わりと恐ろしいことだと思う。
Willi Hammes 氏が Tenebrae に特化したマップの作成を行っている。
http://www.3dluvr.com/willi/main/gamestuff/maps/screenshots/...
http://www.3dluvr.com/willi/main/gamestuff/maps/screenshots/...
http://www.3dluvr.com/willi/main/gamestuff/maps/screenshots/...
もう既に Quake がどうのこうのってのとは違う次元に突入しているような気がする。ううむ……。
2002-09-08
昔から何かにつけて，困った場合に他人のソースを参考にしているのは，自分が優柔不断な性分なせいなのかもしれない。まあ，そんな感じで今までプログラミングの勉強をしてきたわけなんだけれど，こういった他力本願な技も C++ ではなかなか通用しないようだ。というのも，参考になるような説得力を持つソースがなかなか存在しないのだ。
ゲーム関連や UNIX 界隈なんかでは特にそうなんだけれど，まだ C の方が優勢な地方も多い。それとか， C++ を導入するにはしているんだけれど，そのデザイン手法が古いがゆえに，僕的に納得ができないというケースもある。デザイン手法が古いと言うこと自体は決して否定されるべきことではないと思うんだけれど，少なくとも僕が求めているものとは違う，ということだ。
そんなわけで，なんとなく参考になりそうな C++ ベースのプロジェクトを求めて SourceForge をさまよっていると，こんなプロジェクトに出くわした。
http://openmsx.sourceforge.net/
この "openMSX" は，まあ，わりとありがちな MSX エミュレータの一つ。主に UNIX 向けに制作されていて，デバイス系のインタフェースには SDL が使用されている。 SourceForge のプロジェクトなんで当然のごとくオープンソースだ。早速ソースを見てみると，わりと参考になりそうな雰囲気が感じられる。ちゃんと系統立てたクラス階層が確立されている（ように見える）し， doxygen でソースコードのドキュメンテーションを管理するなど，制作手法にも余念が無い。設定ファイルに XML を使用している所など，なんだかやけにかぶれているような感じさえある。
他にも参考になりそうなプロジェクトはいくつかあったんだけれど，やはり最も面白そうだったのが，この "openMSX" だった。 MSX エミュレータということで興味が湧くし，モチベーションを維持するにはこういう遊びの感覚が大切だと思う。何はともあれ，まずはソースを読んでみることだ。
SourceForge から CVS リポジトリを閲覧していて気が付いたんだけれど， SourceForge のリポジトリ・ビューワには Python ベースの "ViewCVS" が使用されているようだ。昔は perl ベースの "cvsweb" だったような気がするんだけれど……。どうだっけ。
http://viewcvs.sourceforge.net/
なんだかんだ言って，ウェブアプリ言語のシェアは，最終的に PHP と perl に収束しそうな気がしているんだけれど，まだ Python もそこそこ頑張っているようだ。 Zope の勉強でもしてみっかな……。
2002-09-09
ちょっと忙しくて泊まり。スケジュールの都合で多少仕事が立て込んでいるけれど，もうしばらくすれば楽になりそうな感じだ。ゲームショーには問題無く行けるだろうと思う。
何気なく思うことありて， blog ツールとして有名な "Movable Type" を試してみた。
"Movable Type" は blog − つまりウェブ日記を発行するためのツールだ。 blog ツールとしての出来はなかなか良いようで，機能はそこそこ充実している。それに，なんといってもインタフェースがかっこいい。使う気にさせてくれるツールだと思う。
http://www.movabletype.org/screenshots/screen-mainmenu.html
僕が突然このツールに興味を持ったのは， "Cognition" というライブラリが Movable Type をドキュメンテーションに使用しているのを見たのがきっかけだった。
http://love.psy.utexas.edu/cog/
Cognition は C++ で認知モデルを扱うためのフレームワークライブラリらしい。まあ，そこは比較的どうでもいい話。それよりも，このすっきりとしていて見やすい感じのウェブ構成が Movable Type によるものであるというところに興味を惹かれた。
僕は今，さまざまな場面で Wiki をドキュメンテーションの道具として利用している。 Wiki は，例えばこのサイトの Wiki のように個人で扱う分にはなかなか便利なツールだと思うんだけれど，複数人でのディスカッションにはあまり向いていないというのが僕の意見だ。この事は以前から何かとつけて繰り返し主張してきている。
文書の構成方法に関してほとんど制限が無く，どの書き手がいくらでも自由に編集できるというのは，ある場面では便利そうに見える一方で，他人の手による変更箇所が把握しずらく，議論の流れが追い難いという弱点がある。いかにも XP (eXtreme Programming) らしいコンセプトを持ったツールだし，つまりは使い方や書き手を選ぶ性質があるということなんだと思う。
http://www.todo.org/cgi-bin/jp/tiki.cgi?c=v&p=Tiki%2F%A5%AF%...
そんなわけで，現在， Wiki に代わる，もしくはそれを補助するためのツールを探していて，そういった意図から Movable Type に注目してみたというわけだ。
えーと，それで……結論から言えば， Movable Type をドキュメンテーションの道具として使うという案は，あまりよろしくなさそうだ。ちょっと使えば分かるんだけれど， Movable Type 自体かなり blog に特化されたツールであり，むしろドキュメンテーションの道具として使っている Cognition の例はかなり特異であると言わざるを得ない。
テンプレートをがしがし整備した上に， Brad Choate の "MTMacro" プラグインなんかを入れて定型的な機能を強めれば，それなりに使えるツールに化ける可能性もあると思うんだけれど，そこまでする余力があるのならば，そのリソースを使って他にもっと良い手段を用意できそうな気もする。
http://www.bradchoate.com/past/cat_movable_type.php
あとは Berkeley DB を使用しているのも，個人的にはちょっと鬼門だった。個人あるいは小規模の集団が生成するテキストの量なんてたかが知れているんだから，テキストファイルベースでも十分に管理できると思う。データの汎用性や扱いやすさを考えるならば，テキストファイルベースにするメリットはいくらでもあるはずだ。
ただ，何気なく DB を使いたくなる気持ちは分からないでもない。なんだかんだ言って便利だし……。
余談だけど，"Movable Type" とは「活字」を意味する語句らしい。
2002-09-10
最近，強化現実関連を漁っていた影響で， HMD (Head Mount Display) に少し興味が湧いてきた。僕が具体的に知っている HMD 製品と言えば，オリンパスの "Eye-Trek" と，ソニーの "Glasstron" ぐらい。どちらもコンシューマ向け AV 機器と売り出されている製品で， VR/AR 用の HMD としては少し心もとない感じもするんだけれど， VR/AR 関連の研究室でもグラストロンを HMD として利用しているというし，この付近のランクの製品でもそれほど問題無いのかもしれない。
それで，これらの製品のスペックがどの程度のものか調べるためにウェブをさらってみたところ，実はどの製品も既に生産終了となっていることが判明した。
http://www.olympus.co.jp/LineUp/HMD/Info/n020603a.html
数年前，この手の製品が立て続けに発表された時期があったような気がするんだけれど（もちろん，あの「バーチャル・ボーイ」もその内の一つだ），結局どれも流行らずに廃れてしまったわけか……。まあ，無理もないかもしれんけど。
そんな感じで絶望感に見舞われていると，どこからともなくこんな製品の情報が流れてきた。
http://www.sony.co.jp/SonyInfo/News/Press/200209/02-042/
なんてタイムリーな話題なんだろう。しかもただの HMD ではなくモーショントラック機能付きと来ている。むむむ，これはこれは。
「現在，各ソフト会社に提案中」なんてコメントが書いてあるけれど，よくもまあこんな特殊なデバイスを，一つも対応アプリの無い状態で売り出そうと考えるものだと思う。 ps.com でのみの販売としてあるから，元々それほど大掛かりに売り出そうとは考えていないのかもしれない。ううむ。
モーショントラック機能が PS2 のみに対応というのも，ちょっと謎。でもまあ，特に仕様に変な所が無い限りは，ソフト側の対応に苦労することもなさそうだし，一人称視点のゲームならばおまけ機能として対応してみるのも面白いかもしれない。どっかのレースゲーム作ってる人たちとか，確実に飛びつくだろうな……。
定価６万円かあ。侠気の見せ所だろうか。ひぃ。
今日も今日とて DOSBox 。僕はやはり PC-AT に思い入れがあるんだと思う。 DOS の経験はそれほど長くないはずなんだけれど（僕が PC-AT を入手した頃には既に Win95 が出ていた），何故だかノスタルジーを感じることができる。
DOSBox は Adlib のエミュレーションがほぼ完成しているので， Adlib 関連のアプリなら問題無く動かすことができる。例えば Vibrants のミュージックディスクとか，いい感じだ。
http://www.scene.org/file.php?file=/music/groups/vibrants/ad...
タイマの再現度がまだ完璧でないのか，もしくは僕のマシンが遅いのが原因なのか，とにかく演奏がモタつくことがあるようだ。ウィンドウを後ろに回したりすると直ることもあるから，やはりタイマの再現度が原因なのかもしれない。
2002-09-11
最近，時間的にはかなり余裕があるはずなんだけれど，いまいち調子が乗ってこなくて，ひどく時間を無駄にしているような気がしてならない。今日も C++ で詰まることが多くあり，一日を無駄に潰してしまった感じが後に残った。
例えば，こんなコード。
このコードが何故通らないのか理解できずに悩んでいる。なんとなく "std::min
もう一つショッキングだったのが，基底ファンクタクラス（unary_function, binary_function 等）の使用方法についてだ。僕は今まで，例えば「const Foo& を引数に持ち bool を返すファンクタクラス」を定義する場合に，
こんな感じにしていたんだけれど，これは
とするのが正しい作法らしい（テンプレートへの引数が "const Foo&" ではなくて "Foo" となっている所に注目）。この話題については Effective STL の第４０章でも軽く触れられている。ただし，詳細についてはあえて解説せずに「その理由を知っても面白い事は何も無い」といった感じで流されてしまっている。まあ，この人が軽く流してしまうぐらいなんだから，相当につまらない事情なんだろうと思う。
とかく C++ は謎ばかりだ。僕は「C++ 使い」になる意志は全く無くて，表層的な知識や道具の使い方さえマスターできればそれでいいと考えていた。しかし，本当にこの道具を使いこなそうと考えるのならば，表層的な知識だけではとうてい対処し切れないであろうことが明らかになってきた。特に，アルゴリズムやら関数アダプタやらの付近は鬼門だ。正しい使用法を把握するには，まずその存在意義を完全に理解する必要があるだろうと思う。あるいは，イディオムを全て丸暗記するぐらいの所業を選ぶか，だ。
結局のところ STL は感覚的に扱えるようなものではなく，その作法と流儀を身に染み込ませなければならない。しかも都合の悪いことに，遠まわしで役立たずなエラーメッセージがその習得を著しく阻害している。そんなわけだから，短い期間での見返りを期待するのではなく，気長かつ冷静に付き合っていく必要があるのかなと思う。
もしプロジェクトに対して本格的に C++/STL を導入するとなれば，メンバー全員で相当な勉強をする必要があるだろうと思う。しかし，ベタの C でもそれほど苦労することなく制作が可能であることを知ってしまっている以上，わざわざ苦労してまで別の路線を歩もうとは思わないかもしれない。何か全体を引っ張ることのできるようなモチベーションが必要だ。
僕の場合のそれは，世の中が C++ に向かって移行しつつあることに対しての漠然とした不安感とか，そんな感じ。負の思考が行動の原動力になるなんて，いかにもらしいっちゃ，らしいと思う。
2002-09-12
今日は "The Document of Metal Gear Solid 2" の発売日。通勤途中に新宿で降りて，西口のヨドバシで購入した。ついでに DC の「斑鳩」も購入。この前来たときは売り切れてたんだ。
しかし，こんなに余裕あるんだったら CEDEC に行っとくんだったかな……。結局，今年も行きそびれてしまった。
"The Document of Metal Gear Solid 2" は， "MGS2" の「インタラクティブ・メイキングディスク」なる商品だ。「メイキング」とは銘打たれているものの，実際には，作品中に使用された素材のデータベース・ブラウザみたいな感じの内容になっており，メイキングディスクというよりかはむしろ資料集に近いと言える。
http://www.konamijpn.com/products/mgs2_doc/japanese/index.ht...
なんと言っても凄いのが，その豪快なまでの見せっぷりだ。例えばモデルビューワでは，ゲーム中に使用されたキャラクタ／背景のモデルデータはおろか，実験用データや未使用モデル等まで含めて，とにかく全てを見せんがばかりの勢いでデータが放り込まれている（実際のところ，ほぼ全てのモデルが収録されていると思う）。
モデルビューワに続いて必見なのがカットシーンデモのプレイヤだ。ここでは作品中に使用された全てのカットシーンデモが再生可能（ただし音声は未収録）で，再生中に任意のタイミングで静止することができるようになっている。また，静止させた状態ではカメラが自由に動かせるようになっており，自分の興味のある箇所を好きなアングルで心ゆくまで観察することなども可能だ。
ビューワ系の資料集だけではなく，スクリプトやコンテ画集など，本来のメイキングっぽい内容も多く盛り込まれている。ここでも見せまくりの勢いはとどまることを知らず，ほぼ全てのイベントに関してスクリプトやストーリーボードが閲覧可能となっていたり，企画草案のスキャンが全収録されていたりと，恐らく制作者当人達でさえも把握し切れないであろう情報量が，ここに詰め込まれている。もはやここまで来ると一般的な「メイキング」の範疇はとうに越えており，制作者の側から見たシナリオの構成とか，個々の場面における演出の意図とか，はては商品の企画意図とか戦略構成とかまで明らかにされてしまっている。
いわゆるメイキングってのは，要するに裏方の上っ面だけを客に見せて喜ばせるような商売のことだと思うんだけれど，この場合は言わば内面的な意味での裏方までもさらけ出してしまっているわけで……なんとも恐ろしい企画だと思う。
プログラムシステムに関しても，ごく表層的なものに限られているものの，解説するセクションが設けられている。 CPU のメモリマップとか， VRAM の配分表とか，ちょっとマニアックな情報もいくつか載せられていた。ふうむ，常駐データが８ＭＢ近くあるってのは，ちょっと予想外だったかもしれない。
こんな感じで，とにかく見せまくりの凄い内容なんだけれど，これを見て喜ぶユーザはごく一部に限られるかな，といった感じではある。ゲーム制作一般に関して参考になるという要素はむしろ限られており，やはりというか，主に PS2 でのアーチスティックな表現方法に関して参考になる部分が大きい。限られたスペックの中でいかに印象的な画を見せるかという点においては，現段階でも最高の水準にある作品だと思うからだ。
あと，これは実際に見てみるまで知らなかったことなんだけれど， The Document of MGS2 には「ＶＲミッションモード」が５つほど収録されている。要するに "MGS2 Substance" の体験版付き，というわけだ。
http://www.konamijpn.com/products/mgs2_sub/
これはこれで，なかなか面白かった。僕はむしろ， MGS2 に対してこういうゲームであることを望んでいたんだ（だから MGS2 をクリアした時，少なからずとも MG が嫌いになった）。出たら買おうと思う。
2002-09-13
仕事が少し詰まってきた。どうも量を見誤っていたらしい。ゲームショーがどうのこうのとか言ってる場合じゃなくなってきたみたいだ。うーむ。
本来の仕事が忙しいからっていって基盤整備が停止してしまうのも悔しいので，また少しずつ泊まり作業を増やしていこうかと思っている。だから，とりあえず今日は泊まり。来週はもっと忙しくなりそうだ。
Python スクリプトを書いていて，何気なく末端再帰を使いたくなった。 Python に末端呼び出しの最適化は実装されているんだろうか。確認せねば……。
http://www.python.org/doc/pythonVSscheme.html
どうやら無い模様。そういうもんらしい。
ところで，上の記事は Python と Scheme の特徴を比較するという内容のものだ。 Scheme は Lisp の標準化仕様の一種で，典型的な関数型言語とされている。 Scheme ではループ処理として末端再帰を多用するために，末端呼び出しの最適化が言語仕様として定義されている，というような話を聞いたことがある。
末端呼び出し (tail call もしくは sibling call) とは，その名の通り，関数の末端にて次の関数の呼び出しを行うことを指す。例えばこんな感じだ。
この例では，呼び出した関数の返値をそのまま自らの返値として使っている。こうなるとわざわざこの関数に戻ってくる必要はなくて， afunc から直接に呼び出し元へと返ってくれれば，実質的に同じことになる。そこで， afunc を呼び出し (call) するのではなく， afunc の先頭へとジャンプ (goto) するようにしてしまえば，いくぶんか処理を稼ぐことができる。
コールがジャンプになるだけでは，それほどありがた味が無いかもしれない。それよりも重要なのは，呼び出し時にスタックフレームの内容をすべて廃棄することができるという点だ。これを再帰呼び出しとして使うと，再帰がいくら深くなってもスタックを消費しないという，「安全な」性質を持つ再帰関数を実現することができる。
末端再帰は，自分の先頭に対してのジャンプとなるため，実質的にはループ処理と同じことだ。実際の場面でもループの代用として使うことが多いかと思う。
例えば，こんな感じの深いループがあったとする。
最下層から１段目のループまで抜けるのに goto を使用している。僕は goto を使うことにそれほどためらいを持っていないつもりだけれど，こんなのソースばかり書いているとダイクストラに呪われてしまうので，あまり良くないかもしれない。そこで，末端再帰を使ってみることにする。
こんな感じだ。
他にも，２段目のループを別の関数にまとめるって方法もある。その方が書きやすいと思ったならば，そうするに越したことは無いだろう。もちろん，末端再帰の方がコンパクトにまとまって読みやすくなる場合もある。 Java にはラベル付き break 文なんてのもあったっけ……。なんにしろ，フラグとかを使ってまどろっこしい処理を書くのは，あまり良い解決法では無いと思う。
部外者にとってにみれば，実質的に同じであるものを選ぶのに何を迷っているのかと思われるかもしれない。同業者の中にだってそう考える人は存在するようだ（しかもそう少なくない数が，だ！）。しかし，実際にはそうではない。少なくとも僕にとっては，そんな軽々しく解決されるべき問題では無いと思う。修辞句を持たない文章がただの記号であるように，理論的なエレガンスを求めないコードなど，ただのバイト列でしかないからだ。
2002-09-14
寝袋から抜け出して朝食を買いに外に出ると，外はうっすらと寒さを覚えるような気候だった。泊まってる間に季節が切り替わってしまったようだ。なんか，いつもこんな調子だなあ。もうＴシャツと短パンでは外は寒い。
端末として利用している Linux マシンに実は GeForce が挿さっていることを思い出して，試しに NVIDIA の Linux 用 GLX ドライバを入れてみることにした。
http://www.nvidia.com/view.asp?IO=linux_display_1.0-3123
ちょっと前までは， Linux にハードウェアアクセラレータを効かせるとなると，やたらに苦労することになるぞ，と脅されたような記憶があるんだけれど，今はそれほど案ずることも無くなったようだ。カーネルドライバと GLX ドライバの rpm をインストールしてから，ドキュメントの手順に従って XF86Config をちょちょっと書き換えるだけで完了した。
試しに Game Blender のデモを動かしてみると，まったく快適に動くことが確認できた。 Mesa 上で動かしてみたときは，キー入力も受け付けないぐらいに重くなっていたもんだから，それと比べたらずいぶんな変化だ。 XScreensaver の GL 系セーバなんかもかなり快適に動いてくれる。うむ，ばっちりだ。
NVIDIA 系の OpenGL 拡張が使えるかどうかは試していない。まあ，そこまでヘビーに使うことは考えてないかな……。なんだかんだいって，もはやこの分野は Windows が基準で動いているのは事実だと思うから， Linux に対してそれほど過剰な期待はしていない。まあ， ARB 拡張がそこそこ動けばそれでいいかな，って感じ。
最近知ったんだけれど， C や C++ の記述スタイルで，オペレータやカンマの前で改行するというスタイルを持つ人もいるようだ。例えばこんな感じ。
これらの人が，どのような考えからこのスタイルを使っているのかは定かではないんだけれど，それなりに理由付けすることはできるかなと思う。例えば次のような文があったとする。
ここで，１行目は "+" 演算子で終わっているため，続く２行目が存在することを推測することができる。しかし，２行目はそれ単体として文が成立しており，この行だけ見ても１行目の存在をうかがい知ることはできない。これを件のスタイルに直すと，
このようになる。１行目はセミコロンが無いために文が続くことを推測できるし，２行目もそれ単体では成立しないため，どこからか続く文脈の一部であることを知ることができる。
とはいっても，これはちょっとこじつけっぽい理由付けかな，と思う。カンマを前の単語に付随させるのは自然言語の文法からの類推で理解できることだし，演算子を行末に残すことも同じく自然な扱いだと思う。そこを曲げてまでしてカンマを行頭に持ってくるってんだから，相当にストイックな所業だと思う。
そこまでする何か面白い理由があるのかもしれない。機会があったらその理由を聞いてみることにしよう。
2002-09-15
今日は普通に休み。髪を刈りに行こうと思っていたのに，思わず夕方まで寝過ごしてしまった。夏の間は，昼間があまりにも暑苦しいもんだから，目覚ましなんかかけなくても昼過ぎには起きることができたんだけれど，涼しくなってくるとそうも行かないみたいだ。
急に涼しくなってきたんで，ちょっと風邪気味。くしゃみが止まらない。
久しぶりにフォトンマップのプログラムをいじくってみた。今は kd tree の最初の実装がなんとか完了したところで，簡単なテストプログラムなら正しく動くのを確認している。そこで試しに 10,000 個のフォトンを食わせてみたら，今度は segmentation fault で止まってしまった。ううむ。まだどっかでバグってるなあ……。ノード数が多くなると止まってしまうようだ。
とりあえず現時点で見つかっているバグを直したとして，その次には kd tree からポインタ参照を無くす作業が控えている。フォトンマップはバランス二分木構造なので，ポインタ参照を無くして配列として保持することができるのだ。この改良を施すだけでもだいぶメモリ効率が良くなるはずだ。
Virt のページがいつの間にかリニューアルしている。 fx2.0 以降の新曲もいくつかあるようだ。その中でも特に良かったのが "Until Tomorrow" 。
http://virt.vgmix.com/music/virt_-_until_tomorrow.mp3
ソウル風味のディスコミュージック。こういうの好きだなあ……。
なにげに Virt は歌が上手いなあ，と思う。上の "Until Tomorrow" や， "We feel" でも，裏声を上手く使って一人でよくハモっている。彼の得意技の一つであるアカペラによるリミックス技なんて，彼の歌唱力が変態的に発揮された好例だろう。比較的最近発表された "TMNT3 - stage1" なんて，なんだかもう凄いことになっている。
http://virt.vgmix.com/music/v-tmnt3-stage1.mp3
その前には「マニアック・マンション」のラップアレンジなんてのもあった。こちらは，もう原曲が想像できないぐらいのアレンジっぷりだ。ワウ・ギターの声帯模写が秀逸だと思う。
http://virt.vgmix.com/music/v-michael.mp3
2002-09-16
相変わらず流体関連の資料を漁っているんだけれど，どいつもこいつも難解な内容のものばかりで，いつまでたっても読み終わらない。通勤中の読書ネタは当分これだけで保ちそうな感じだ。嬉しいやら悲しいやら……。
まず最初に苦労したのが馴染みの無い関連用語たちだ。 "viscosity" は「粘性」で， "convection" は「対流・伝達」， "advection" は「移流」。さすがに電車の中まで辞書を持ち込むわけにはいかないので，分からない単語があると適当にすっ飛ばして読んでるんだけど，こんなにも重要な語彙が欠落しているとひどく苦労することになる。ていうか，苦労するとかそういうレベルじゃなくて，まったく分からないよな……。
最初に手を付けた Foster & Metaxas の論文では，これから読むすべての論文において基礎となる部分について詳しく解説している。ゆえに，解法としては最も簡単なものを採用している。
http://www.cis.upenn.edu/~fostern/pdfs/gmip96.pdf
そしてこの次に来るのが Jos Stam の "Stable Fluids" だ。
http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/...
前述の Foster & Metaxas の論文では Navier-Stokes 式の移流項を差分法によって解いている（CFD の世界ではこれを「オイラー法」として分類するようだ）のだけれど，これはタイムステップ (delta t) が十分に小さくないと発散を始めてしまうという宿命的な弱点がある。 Stam はこれを克服するために特性曲線法 (Method of Characteristics) を導入した。この解法はタイムステップがいくら大きくなっても発散が起きないという，実に都合の良い特徴を持っている。後の論文でセミ・ラグランジュ法 (semi-Lagrangian method) と呼んでいるのは，この解法のことを指しているようだ。なぜ「ラグランジュ法」なのかは，僕にはよく分からないんだけれど……。
Stam の "Stable Fluids" にはもう一つ面白い手法が取り込まれている。 Stam が定義した Navier-Stokes 式の４つの解法プロセスのうち，拡散項（粘性による効果を与える項）と投影処理（質量保存を成立させるための調整処理）を周波数ドメイン (Fourier domain) 上で行うことにより，より簡単な演算に変換できるというものだ。ふむむ，流体で FFT を使うってのは，このことだったんだな……。他にも投影処理に疎行列ソルバを導入するとか，前述の特性曲線法もそうなんだけれど，色々と数値解析関連のバックグランドを必要とされる方法であるようだ。まあ，どっかからライブラリを拾ってくりゃいいんだろうけどさ。
とまあ，基礎部分についてはこんな感じ。その後の論文についても， Navier-Stokes 式の解析についてはこれらの手法が応用される形になっている。 Foster & Fedkiw の "Pratical Animation of Liquids" なんかは，解法はほとんど "Stable Fluids" と同じもので，あとは陰関数曲面の構成方法にちょこっと工夫が加えられているとか，そんな感じのようだ。
http://graphics.stanford.edu/~fedkiw/papers/stanford2001-02....
そして最新の論文である Enright & Fedkiw の "Animation and Rendering of Complex Water Surfaces" なんだけれど，この手法では，陰関数曲面を展開するのに流体のパーティクルだけを使用するのでなく，流体とその外側（気体側）の両面においてパーティクルをトレースすることによって，面の形状をより正確に再現しようというのがその概要であるらしい。他にも物理処理において細かな補正法などが導入されており，結果としてより正確でリアルな流体シムを構成することに成功しているようだ。
http://graphics.stanford.edu/~fedkiw/papers/stanford2002-03....
後半はだいぶすっ飛ばし気味で（ていうかほとんど読んでない）通してみたんだけれど，ノリとしては，基礎中の基礎が Foster & Metaxas で，そこから処理速度と安定性について改良を施したのが Stam の Stable Fluids ，あとは基本的に派生形って感じだ。つまり最初の２つを押さえることが大きな要となるらしい。
Foster & Metaxas はわりと簡単な内容だから，最大の難関は Stable Fluids が越えれるかどうかかな，と思う。
2002-09-17
基礎学力が絶対的に足りていないことは明らかなんだから，それなら基礎から改めて勉強し直せばいいんだろうけれど，そういった落ち着きだけはどうしても持つことができないようだ，自分は。
やはり，いまさら開始地点まで戻るのは面倒くさいんだろうと思う。面倒くさいか／面倒くさくないか，でビットの立ってしまう人間だから，そういった選択肢を取り得ることは今までも無かったわけだし，これからも無いんだろうと思うと，ちょっと絶望する。
Gamasutra に "Online Games Resource Guide" なる記事が掲載されている。なんだか知らないけどネットワーク特集みたいだ。
http://www.gamasutra.com/resource_guide/20020916/index.shtml
ネットワークゲーム関連の技術と言うと，ちょっと前までは，伝送路がどうとか TCP/IP がこうとか，アプリケーション層よりも下での話題が多かったような気がする。それが今では，大規模多人数 (MMP) をいかに扱うか，と言ったような，より上の方のレイヤでの問題を解決する方法についての話題へとシフトしてきているようだ。この特集でも，すべての記事がアプリケーションに関する話題だし，「大規模多人数ゲームでいかにストーリーを作り出すか」などというような，ネットワークならではのゲームデザインに関する深い考察が現れているのも，ネットワークゲームの本質的な成長が始まっていることを表しているのだと思う。
個人的には，ハイパフォーマンス・データベースの構築とか，裏方のハードウェア構成とか，そういった話題に興味があるので， "Of Internet Servers and SQL Databases: Designing the Backend for Power and Performance" なんて記事が良さそうだ。
http://www.gamasutra.com/resource_guide/20020916/hallenberg_...
ところで， Gamasutra の記事には必ず "Printer Friendly Version" が付いている。レイアウト指定を極力排除することによって，ウェブ上での閲覧よりも印刷時の利便を図ったバージョンのことだ。しかしこれを IE で印刷しても，あまり良い結果は得られない。どうも間抜けなレイアウトになってしまうのだ……。そこで，試しに "html2ps" を導入してみることにした。
http://www.tdb.uu.se/~jan/html2ps.html
"html2ps" は，まあ，その名の通り html を Postscript 形式に変換する perl スクリプトだ。上図のように，かなりそれっぽい仕上がりになってくれる。こりゃあなかなかいいなあ。
ただ，行の端の揃え具合（専門用語でなんて言うんだろ……）がちょっと甘くなってしまった。ハイフン振り (hyphenation) の定義ファイルを用意していないのが原因になっているのかもしれない。ハイフンネーション定義ファイルは TeX に添付されているものを使うらしいんだけれど，よく考えてみたらこのマシンには TeX が入ってないんだった。ううむ，昔は TeX のために Linux を入れていたぐらいなんだけれどなあ。
2002-09-18
案外，作業がスムースに進んでいるようだ。これならゲームショー行けるかな……。無理してまで行きたいわけでも無いんだけれど，チケットをわざわざ確保してもらったのにそれを無駄にするのは勿体無い気がする。
多少不安が残るので今日は泊まり。半ば惰性気味ながらも。
最近， GDAlgorithms list の流れに追いつけられないでいる。
http://www.geocrawler.com/lists/3/SourceForge/4856/0/
とは言っても，ポスト量が急に増加したとか，そういうわけでもなくて，単に読むのをサボっているだけだ。遅れを取り戻すために，通勤移動中にログを追いかける方式を導入してみようと思う。さっそくログを印刷するためのフィルタを適当にこしらえてみた。
僕にとって，この手の作業はまさに Python の仕事だ。 "RFC2822" モジュールと "mimetools" モジュール，それに "multifile" モジュールを組み合わせて，メールファイルから必要な情報だけを切り出していく。技術系 ML と言えども Outlook 的な HTML メールがポストされることもあるし，プログラムファイルが添付されたメールがポストされることもまれにあるから，そういうのを自動的にカットしなければならない。ゴミっぽい履歴引用とか SourceForge のバナーとかも排除対象だ。
http://www.python.org/doc/current/lib/module-rfc822.html
http://www.python.org/doc/current/lib/module-mimetools.html
http://www.python.org/doc/current/lib/module-multifile.html
こうして出力されたテキストデータを a2ps に通して Postscript へとコンバートする。段付けとか装飾の類は a2ps が勝手に処理してくれる。なかなか便利なツールだ。
こんな感じで，とにかく何でもいいからグルー言語を１つは押さえておくと，小回りが効くようになって便利だと思う。僕のおすすめは Python だけれど，もちろん perl でも問題無いし，最近何かと人気の Ruby も結構だろうと思う。
ただ， CPAN (Comprehensive Perl Archive Network) なんかを見てみると，やはりこの分野では perl が圧倒的に有利だな，と感じる。このモジュールの充実ぶりは，グルー言語としてかなり魅力的な要素だ。
http://www.cpan.org/modules/00modlist.long.html#ID2_PerlCore...
Python も "Vaults of Parnassus" などを漁れば，かなりの数のモジュールを見つけることができる。
しかしこの中には，開発途中で不安定なモジュールや，完成しないまま放置状態のモジュールなどが存在する。しかもその数は決して少なくない。そんなわけだから，これを CPAN とタメ張らせようってのは，ちょっとまだ無理な話だな，と思う。
2002-09-19
kd tree の細かなバグを修正して，少々のチューニングなどを施すと，フォトントレーサがそこそこ軽快に動くようになった。やはり単純なサーチ処理とは比べ物にならないほどの速さだ。これでようやく試行錯誤が可能になるというものよ……。
それからしばらく試行錯誤を繰り返した結果，なんとか正解っぽい絵が出るようになった。まだ細部については怪しいものだけれど，以前の失敗作（右図）と比較すると，だいぶ大域照明っぽい絵に近づいたと思う。
以前のプログラムでは何を間違えていたのかと言うと，拡散面におけるフォトンの散乱方向の分布だ。これについて僕は Jensen 本にある
という記述をそのまま鵜呑みにして，法線との余弦に比例した確率で分布させるようにしていたんだけれど，これが間違いだった。実際は半球上に一様に分布させるのが正解のようだ。
ただし，拡散反射において放射束の分布が法線との余弦に比例するというのは間違いではない。ではなぜフォトンの散乱方向は一様に分布するのか。それは，この場合は散乱方向から見た投影面積を基準として考えるため，余弦が相殺されるのだ。それではなぜ，ここで「散乱方向から見た投影面積」を用いるのか。それは，えーと……。
Jensen 本を読み直すときにいつも思うことなんだけれど，この本には，フォトンマッピングに使用する「フォトン」というモデルについて，明確な定義が抜けてしまっているような気がする。そしてこの記述の欠如が，肝心な部分の理解の妨げになっているのではないかと思う。特に，「フォトン」を光の粒子モデルとしてのそれと混同してしまう，なんてのはとんでもない勘違いのパターンだ。
結局のところ最も大切なのは，フォトンマップ − つまり，ある地点に入射する放射束の分布を表すデータ構造，を構築することにある。「フォトン」とは，その過程に登場するひとつの道具であり，そのネーミングは，放射束の伝播を分かり易く解説するために持ち出されたメタファでしかない。だから，空間中を光子がびゅんびゅん飛びまわっている様子を連想してしまうのは，かなり危険な兆候だと思う。
結論としては，フォトンマップに記録するのは「ある地点に入射する放射束の強さ」なのだから，そこから見た投影単位面積を基準として考えるのが自然でしょう……ってことで収めておきたいと思う。
自分の手に余る概念を扱う場合は，必要以上に深く考えるのをやめて，ひとまず文献に書いてあることを鵜呑みにすることで無理矢理にでも前進しようすることがある。しかし Jensen 本の場合，それはそれでまた泣きを見たりするわけで，内容を正確に理解せずに実装を進めるのは，かなり危うい行為であるようだ。
2002-09-20
今日は東京ゲームショーへ直行……のはずだったんだけれど，入場パスを職場に置いてきてしまったので，しぶしぶ職場を経由してから幕張へと移動した。乗り換えが多くて面倒だ。自宅から海浜幕張まで５回も乗り換えている。
空は信じられないほどの快晴。それと，千葉のだだっ広さと，京葉工業地帯のサイバーっぽさに，少し心が癒された。千葉っていいよね，いろんな意味で。
今年のゲームショーは目玉的要素に欠いていて，いまいち淋しげな雰囲気だったような気がする。今回から年一回の開催になったんで，その分ちょっとは盛り上がるのかなあと思っていたんだけれど，そんなこともない様子だ。もうゲームショウがどうこうって時代じゃないのかもしれない。
そんな全体的に冷え気味のムードの中で，一際活気に溢れていたのがセガとコナミだった。
個人的にセガの注目作は "Shinobi" だったんだけれど，唯一の隠し玉であった「バーチャロン・マーズ」もそれなりに注目を集めていたみたいだ。他にもレースゲームが数個とか， "House of the Dead" とか「スーパーモンキーボール」とか……とにかく手札の多さでは随一だったように思える。
なにげに GBA 版のセガラリーが出展されていたのでチェックしてみた。かなり頑張っている感じなんだけれど，レースゲームに仕立て上げるには厳しいフレームレートだったようだ。しかしその意気や良し。次は "Power Drift" 的擬似３Ｄで是非……。
コナミの方は "ZOE2" (ANUBIS) がいい感じだった。前作と比較して様々な部分に洗練が見られる。多彩な要素を有していながらも不完全な形に終わってしまった前作の雪辱を晴らそうという気合が感じられる。或いは小島組の開発力の成せる技か。 MGS2 チームのリソースがかなり回されているのではないかと思う。
ビジュアル面では，エフェクト類に著しい進化が見られる。煙の表現とか特にいい感じだ。パーティクル／プリミティブの量が PS2 とは思えないぐらい出ているように感じられる。 MGS2 でも感じたことなんだけれど，描画リソースの割り振り方が大胆だと思う。あと，ちょい NPR 気味のレンダリングもいい感じだ。ムービー（セルアニメ）との雰囲気の整合が上手くいっている。
タイトーのブースで例の HMD (PUD-J5A) を体験してみた。追従性はかなりいい感じ。残念なのは，どう頑張っても画面が小さく見えること。よく HMD の売り文句として「２ｍ先の２５インチに相当」とか，そういうのが謳われているけれど，やはり小さいものは小さいものにしか見えない。視野が狭いことにはどうにもならないのだ。開放的なデザインもあって（ゴーグルと顔面の隙間が遮蔽されていない），かなり没入感は低いものになっている。
それでも，ネット予約販売分は既に売り切れているそうで，それなりに需要は存在するようだ。
2002-09-21
色々と状況に変化があり，意外にも，まったく何ともない普通の連休になってしまった。間違いなく忙しくなると思ってたんだけどな……。
amazon.co.jp から荷が届いた。「オブジェクト指向における再利用のためのデザインパターン」と "Best of Moog" だ。
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126
http://www.amazon.co.jp/exec/obidos/ASIN/B00001R3NJ
「〜デザインパターン」の方は，某エリート系プログラマから「GoF を読め」との指令を受け賜ったので買ってみた。しかしぶ厚い本だなあ……。斜め読みするだけでも骨が折れそうだ。おとなしく結城浩氏の本を選んでおいた方が良かっただろうか。
http://www.amazon.co.jp/exec/obidos/ASIN/4797316462
もう一方の "Best of Moog" は，突如として "Popcorn" を聞きたくなったので買ってみた。内容は，いわゆるモンド趣味なコンピレーション・アルバム。有名な Hot Butter の "Popcorn" をイントロに迎えて，これでもかってぐらい Moog づくしな内容になっている。
しかし，これだけシンセを前面に押し出した内容にも関わらず，逆に人間臭さを感じさせる要素があると思う。 Moog が醸し出すアナログの匂いってのもあるんだけれど，なんていうか，使いづらいインタフェースを前にして四苦八苦する人間の足掻きみたいのが，その裏に感じ取れるのだ。鍵盤ちょっと押しただけでドカーンと音が出てしまうっすよ，みたいな。
まあそんなことはどうでもよくて……やはり Perrey-Kingsley はいいな，と思った。基本的に牧歌的な曲調のはずなんだけれど，それに超絶的かつ暴力的な Moog の音が乗っかることによって，特殊な異次元感覚が作り出されている。それが，未来でも過去でも現在でも無い，不思議な時代の感覚を生み出すのだ。「僕の生まれるちょっと前」って感覚が，まさにこれ。例えば，大阪万博の辺りの，それ。
2002-09-22
普通の休日の二日目。普通に松屋で飯を食ったり，普通に連射パッドを買ってみたりした。
http://www2.elecom.co.jp/peripheral/gamepad/jc-u808t/index.a...
実売価格２千円の安物パッドだ。いかにもダメそうなデザインなんだけれど，相応な価格でもあるので，あまり期待せずに買ってみることにした。実際に使ってみると，意外にも手にフィットするんで驚きだ。なんだかなあ。
ZOE2 の TGS 用ムービーがコナミのウェブサイトにアップされていたので，落としてみた。
http://www.konamijpn.com/tgs2002/main.html#st1
http://www.konamijpn.com/tgs2002/main_e.html#st1
ていうか，もう英語版も用意してあるのか……。最近，コナミやカプコンはワールドワイドな展開を意識しているよなあ，と実感する。どちらも世界市場で通用する強力なコンテンツを多数保有している会社だ。それとはまったく対照的な存在が SCE だと思う。国内と海外に中規模のデベロッパを有しているにも関わらず，非常に地域性の高いタイトルばかりを作り出しているような印象がある（ＧＴは唯一の例外かもしれない）。国内の売り上げに伸び悩んでいる今，積極的に国外の需要を開拓せねば，行き着く所に行き着いてしまうと思うのだけれど……。
で，件のムービーの内容は非常に印象的なものに仕上がっている。またいつもの「小島マジック」（仕込みを派手に盛り上げておいて，本編でユーザを裏切る）のような気もしないこともないんだけれど，いや今回こそは……と期待する気持ちを隠せない。 ign の記者が「僕はまた恋に落ちてしまった」というような表現を使っていたのだけれど，まさにそんな感じだ。もう二度と信じまいと思っていたのに，ってやつ。
2002-09-23
相変わらずフォトンマッピングのプログラムをちくちくといじってみている。サーチ処理をある程度高速化したり，円錐フィルタを組み込んでみたりした。円錐フィルタを使うとノイズっぽいムラが多少緩和されるようだ。詳しい原理はよく理解せずに使っているんだけれど……。
左の画像は，試しにできるだけ高画質な設定でレンダリングを行ってみたものだ。２０万個のフォトンを光源から放出し，放射輝度の推定には３千個のフォトンを使用している。最終的にフォトンマップに収容されるフォトンの数は８０万個以上に達する。これは，壁面の反射係数を高くしているのが大きな影響を与えているようで，もう少し暗めの配色にすればフォトンの総数はそれほど増加しないものと思われる。
今のところ，マテリアルはすべて純粋なランバート面（拡散反射面）のみのはずなんだけれど，ちょっとランバート面とは違う見た目になってしまっているような気がする。なんかグロスっぽいんだよな……。壁面が暗く淀んでいるのも気になるところだ。まだバグが残っているんだろうか。根本的に勘違いしている部分があるのかもしれない。
近接フォトンの検索に単純な距離判定を用いているため，壁際での誤差がかなり大きくなっているのが分かる。これは Jensen 本で紹介されているような方法（例えば距離判定に楕円を用いる方法など）を適用すれば改善されるのかもしれない。しかし，その辺りの解説はあまり詳しく書かれていない。ふーむ……。
右の画像は，左の１／１０のスペックでレンダリングを試みたものだ。つまり，２万個のフォトンを放出して，放射輝度推定には３００個のフォトンを使用している。この程度の画質だとレンダリングはかなり高速になる。この 320x180 の画像でちょうど１分程度だ。ちなみに左の画像は 640x360 で１２０分以上費やされている。
現時点で処理速度に最も大きな影響を与えているのは，近接フォトンの検索処理であることは明らかだ。実際，２０万個のフォトンを使っても，フォトントレーシングと kd tree の構築にはさほど時間がかからない（数十秒で完了する）。これに対して，放射輝度推定に使用するフォトンの数を増やすと，指数関数的に処理量が増加する。
検索処理において近接候補を保持する方法が，いまいちよろしくないような気がする。 kd tree から近接候補になりそうなフォトンを見つけてくると，これを近接候補リストに追加するんだけれど，この処理がネックになっていると思うのだ。挿入処理だからって線形リスト構造を使うと挿入位置の検索が遅くなるし，だからって配列を使うと挿入処理が遅くなってしまう。やはりここにもツリー構造を導入すべきかもしれない。ちょっと構造は複雑になるけれど，そうするだけの価値はあるに違いない。
2002-09-24
昨日のレンダリングでは反射係数を高くしすぎた感じがあったので，少し値を落としてレンダリングしなおしてみた。これでもいちおう物理ベースのレンダリング・システムなんだから，やたらに試行錯誤をするんじゃなくて，実測値から定数を引っ張ってくるようにすればいいんだろうけども，調べるのが面倒なのでやっていない。フォトン・トレーサについても同じで，一般的な照明器具の照度（ルクス）から放射照度へと換算し，そこから１フォトンあたりの放射束の強さと放出するフォトン数を割り出すのが真っ当な方法だと思う。しかしその手順も不明な点が多いので手を出していない。写真屋さんとかだったらそういうのに詳しいのかもしれない。
そうしてレンダリングした画像が上の左の図。やはり昨日のは反射しすぎだったようだ。これでだいぶ落ち着いた感じがするけども，それでもなおツヤっぽいのが抜け切れていないように見える。ううむ。実世界にありふれた拡散反射面のマテリアルって，反射係数はどの位の値なんだろう。とりあえず拡散面で反射係数 1.0 ってマテリアルはなさそうだ。拡散反射のメカニズムを理解していないのでなんとも言えないけれど，理論的な限界値がどこかにあるんだろうな，と思う。限りなく白に近い白とはどんなマテリアルだろう？ なんか禅問答みたいだ（風の色は……）。
「物理ベース・レンダリング」ってワードで "Cornell Box" の事を思い出した。確かコーネル大のページに元祖 "Cornell Box" の詳細なデータが記載されていたはずだ。さっそく探してみると，すぐに見つけることができた。
http://www.graphics.cornell.edu/online/box/data.html
スペクトル毎の反射係数として記載されているので，どう読んだものやら戸惑うんだけれど……まあだいたい 0.7 ぐらいの反射係数を持っているってことのようだ。ふむ，意外と高い値なんだな。僕の左上の画像で，白い壁面部分が反射係数 0.65 に設定されている。
せっかくなので Cornell Box のデータを元にパラメータを再設定してレンダリングを行ってみた（形状については変更が手間なのでそのまま）。その結果が右の図だ。うわ……きつ。なんかすごくネバい配色だ。元は拡散面同士の相互干渉について検証するために作られたモデルだから，こんなにきつい配色がなされているのかもしれない。ちなみにリファレンス画像はこれ。
http://www.graphics.cornell.edu/online/box/box.jpg
いずれは形状についても同じ環境を用意してみよう。その前にエリアライトの実装だな……。これはそれほど難しいものでもないので，次のステップとして実装してみたいと思っている。
2002-09-25
なんとなく Gamasutra の特集記事 "Online Games Resource Guide" に手を出してみた。
http://www.gamasutra.com/resource_guide/20020916/index.shtml
まず読んでみたのが "Of Internet Servers and SQL Databases" という記事。
http://www.gamasutra.com/resource_guide/20020916/hallenberg_...
この記事の著者の Pete Hallenberg 氏は，米 Incredible Technology 社に勤務するプログラマで，同社のゲーム用ネットワーク・システム "ITNet" の開発を担当した人物だ。 ITNet は同社の製品である "Golden Tee Fore!" というアーケードゲームのために開発されたシステムで，全世界で延べ７０万人ほどのユーザを抱える大規模なネットワークシステムであるらしい。
http://www.itsgames.com/products/GT2003/gt2003.htm
記事の主な内容は，ネットワークゲームのインフラストラクチャに関する話題で占められている。 Hallenberg 氏が ITNet プロジェクトを通して得たノウハウについて網羅的に触れられており，特にデータベースの扱いについては詳細に記述されている。氏自身もデータベースに深く触れるのはこの仕事が初めてだったそうで，ゲームプログラマがデータベースの世界に初めて触れた際に出くわすであろう意識のギャップについて，非常にリアリティのある体験談が語られている。同じような境遇に置かれた人にとっては，参考になる知識が多く含まれているのではないかと思う。
個人的に印象に残ったのが，「データベースは決して『便利なブラックボックス』としては動いてくれない」という氏の意見だ。例えば僕などは，業務用のデータベースに対して漠然と「パワフルで使いやすいに違いない」というような先入観を持ってしまっているんだけれど，実際にはそううまく事は進まないということだ。データベースと一口に言っても様々な製品が存在するわけで，その製品毎に特徴があり，弱点や長所なども存在する。これを有効に扱うには専門的な知識な不可欠なわけで，それが無ければどんなに強力なシステムも凡庸なスペックに成り下がってしまうだろう。ただし，正しい使用法さえ習得すれば，非常に強力で堅牢なサービスを提供してくれるに違いない。
結局， ITNet プロジェクトでは専門のＤＢプログラマを１人雇うことにしたそうだ。記事の中では更に，データベースの世界では自分達の常識が通用しない場合が度々あることを認めており，専門家の存在意義を確認するような内容になっている。うーむ，「オラクルマスター」なんていう制度が存在する理由をようやく理解できた気がする。こういうの，やっぱり箔が付くんだろうなあ。
http://www.oracle.co.jp/education/master/
もう１つ "Distributing Object State for Networked Games Using Object Views" という記事にも手を出してみたものの，読んでいていまいち盛り上がらないんで，途中で読むのを諦めてしまった。書いてあることはそう難しくもないと思うんだけれど，僕自身がネットワークゲームをまったくプレイしていないこともあって，内容に実感が伴わないのだ。
http://www.gamasutra.com/resource_guide/20020916/lambright_0...
ネットワークゲームを避けるようにしているのは，ネットワークゲームが中毒性を持っていることを良く知っているからだ（身をもって知ったと言い換えても良い……）。特に大規模マルチプレイヤ系のゲームは時間が無限に潰せてしまうことが容易に予想できるので，今まで故意に手を出さないようにしてきた。しかし，さすがにそろそろ１つぐらい何かやってみてもいいかな，と思う。ＦＦのＰＣ版が出たらプレイしてみるのも面白いかもしれない。
http://www.playonline.com/ff11win/index.html
あ，でもこれ，要求スペックが……。
2002-09-26
小さなタスクが蓄積されたので，今日は泊まり。とは言っても単純な作業ばかりだ。それほど辛くはない。
Microsoft Excel の吐く xls ファイルを解析する手段について少し調べてみた。まず最初に見つけたのは "xls2xml" というソフトだ。
http://www.iamnota.com/xls2xml/
名前が示す通り xls ファイルを XML に変換するソフトらしい。 XML パーサだったらいくらでも巷に存在するから，一旦変換してしまえばあとはどうにでもなる。さっそくビルドして適当な xls ファイルを食わせてみたんだけれど，変換エラーになってしまった。ううむ，サンプルデータは普通に変換できるのに，自分で作成したデータはほとんど変換できない。
どうやら xls2xml は既に開発の中止されたプロジェクトのようで，今後この問題が改善されることも無さそうだ。もとより，最近の Excel は XML 出力をサポートしているはずだから，こういったソフトを使う意味は無いのかもしれない。ううむ， Office 2000 を買えってことかな……。
xls2xml はだめそうなので他の手段を探そう。そういえば perl には xls のパーサがあったはずだ。
http://www-6.ibm.com/jp/developerworks/linux/011130/j_l-pexc...
"ParseExcel" というモジュールを使えばいいらしい。なるほど……。とりあえず CPAN でサーチしてみると，該当するモジュールを見つけることができた。
http://search.cpan.org/author/KWITKNR/Spreadsheet-ParseExcel...
ParseExcel を使用するには "OLE-Storage_Lite" と "IO-stringy" の各モジュールが必要だ。
http://search.cpan.org/author/KWITKNR/OLE-Storage_Lite-0.10/
http://search.cpan.org/author/ERYQ/IO-stringy-2.108/
日本語を扱う場合には Jcode モジュールも入れておいた方がいい。
http://search.cpan.org/author/DANKOGAI/Jcode-0.82/
この Jcode モジュールを使用するには MIME-Base64 モジュールが必要なようだ。
http://search.cpan.org/author/GAAS/MIME-Base64-2.12/
あとはがしがしと Makefile.PL をかませばインストール終了だ。例を参考に簡単なスクリプトを組んでみると，すぐに何の問題もなく xls ファイルが読めるようになった。ちょっと解析速度が遅いような気もするけども，どうにもならないほどではない。
近頃はスクリプト言語というと Python や Ruby ばかりで， perl を使う機会はほとんど無くなってしまった。学生の頃はもっぱら perl を使用していたものの，あの頃の perl といったら perl4 のことで，今の perl (perl5) とはちょっと雰囲気の異なるものだった。例えば "my" でローカル変数の定義，なんてのは perl5 からの構文で， perl4 の頃はもっとグロい仕組みだったと思う。これがもうしばらくすると perl6 が主流になって，また馴染みの無い文法とかが出てきたりするのかもしれない。
久しぶりの perl はそれほど違和感のあるものでもなかった。一時期は相当の perl 嫌いだったんだけれど，既にその頃の記憶も薄れてしまったようだ。相変わらず変な言語ではあるものの（正規表現の辺りとか特に……），そこが perl の面白さなんだと思う。倒置的制御文（"DoFunc() if (a = b);" みたいなやつ）とかも，他の言語にはなかなか存在しない構文で，独特の趣きを感じる。書き手の自由度が非常に高いから，トリッキーな文を構築するという行為それ自体が楽しみに繋がる。趣味的には面白い言語だ。
とか言ってたら，「文字列の比較は "==" ではなく "eq"」を思い出せなくて１時間ぐらい詰まってしまった。あぁ……。
2002-09-27
今日中に終了すると思われていた作業が微妙に終わらず，結局日付を跨いでしまうことになった。予期せぬ２泊だ。
今は平均的な仕事量で言えば楽な時期のはずなんだけれど，突発的に忙しくなる瞬間があるから，そのタイミングを計り違えるとこういう事態に陥ってしまう。
ふと， Xbox の新しいロットで modchip の使用が不可能になったらしい，という話を思い出した。どういう対策が施されたのか少し気になったので， Xbox-Linux 関連を調べ回ってみることにした。
http://xbox-linux.sourceforge.net/
ううむ。ここではまだそれほど話題にはなっていないようだ。メーリングリストに関連する投稿が多少存在するものの，明確な情報を得ることはできなかった。
http://sourceforge.net/mailarchive/forum.php?forum_id=9486
どうやら，彼らにとっても情報が不足しているらしい。
話の発端になったのはオーストラリアの少年の情報だ。北米や日本ではそのロットは出回っていないかもしれないし，その少年の情報がガセである可能性も無くはないと思う。
ともかく，もう少し様子を見るほかないようだ。
ついでに Xbox-Linux の現状を少し調べてみた。
http://xbox-linux.sourceforge.net/articles.php
Xbox に Linux をインストールするには「クロス・インストール」の手法を利用する。つまり， Xbox の内蔵 HDD を PC に繋ぎ替えて，その PC 上から Linux のインストールを行い，作業が終了したらまた Xbox に繋ぎ直す，という手順を踏むわけだ。
http://xbox-linux.sourceforge.net/articles.php?aid=200224706...
ただし Xbox の HDD にはパスワードによるアクセス保護機能が付けられているため，単純に PC に繋ぎ直しただけではアクセスすることができない。そこで， Xbox を起動してダッシュボード画面に切り替わった直後に電源を付けたまま HDD を外し（！），そのまま電源の付いた PC に繋ぎ直すという手段を使うそうだ。すげえ。 IDE でホットプラグができるなんて知らなんだ……。
こうしてクロス・インストレーションを行った後に， Xbox 用 Linux カーネルの入った起動用 CD を作成すればインストール完了だ。ここで，自分で焼いた CD-R を起動に使うために modchip が必要となる。
http://www.extreme-mods.com/products/evoxchips.htm
ハードウェアの改造が必要とされるのは単にこの理由だけだから，起動手段さえなんとか確立されれば，ハードウェア改造無しに Linux を導入することも可能となるのかもしれない。
2002-09-28
一昨日から継続勤務。久しぶりに始発で朝帰りをした。朝日を浴びながら家路を歩くのがあまり好きじゃないもんで，普段はあまり朝帰りしないんだけれど，今日は２泊目だったのでやむを得ない。家に着いてから８時頃に寝て，それからずっと夕方まで寝てた。
ZOE2 の高解像度画像が ruliweb にポストされている。どうやら ign inside からのパクりのようだ。
http://www.ruliweb.com/data/rulinews/read.php?num=9296
ちょっと面白いので観察してみた。
全体の解像度が異様に高いのはスクリーンキャプチャ用の分割レンダリングを使用しているためと思われる。このエッジの滑らかさからすると通常の１６倍以上の解像度でレンダリングしているのではないかと思う。まあ，この辺りは既に常套手段なので無視するとしよう……。
やはり見た目で面白いのはエフェクト類だと思う。自機の周囲に出るハローは前作からの伝統かな……。たまに変に見えることがあるけれど，一枚板で良く表現できていると思う。他に面白いと感じたのが，レーザーの軌跡エフェクトの解像度が周囲のそれと比べて異様に低いことだ。
http://www.ruliweb.com/data/news3/08m/31/ps2/zoe209.jpg
理由はいくつか考えられると思う。これらのエフェクトをパーティクルで描画しているか，もしくはオフスクリーンで描画しているか……。 PS2 のハードウェア仕様を考慮すると，後者の方法を選択するには多少の努力が必要かもしれない。ダブルバッファとデプスバッファだけで既に 3MB 使ってしまっているはずだから，オフスクリーン処理は残りの 1MB をやりくりしなければならない（しかもテクスチャは全て廃棄）。とりあえず描画できたとしても，グロー処理を入れる時点でいっぱいいっぱいだ。デプスバッファを捨てれば少し余裕ができるものの，ポストエフェクト（被写界深度など）との兼ね合いを考えるとそれも難しいかもしれない。そもそも，恒常的にそんなフルスクリーン・エフェクトを入れてフィルが足りるものかどうか……。
もう１つの方法は，パーティクル群でグロー付き軌跡を表現する方法だ。軌跡を多項式曲線あるいは直線群で保持し（マイクロプログラム化を意識するならサブディビは使わないと思う……），描画エンジン側で適応的な分割を行う。そうしないと視点からの距離によってパーティクルの密度に偏りが出てしまうからだ。描画側の処理でスクリーン座標上におけるパーティクル間隔が一定になるレベルを求めるようにすれば，見た目のクオリティに対して最適なレベルを保つことができる。頑張ればマイクロプログラムで実装することも可能かもしれない。僕だったらちょっと遠慮したい内容だけれど，本当のプロならためらわないだろうと思う。
あと気になるのは，上の画像でかなりの数の敵キャラが表示されていること。これだけの数を出して処理速度を保つとなると，全部ビルボードにしなきゃなんないかもしれない。どうだろう……。製品版を手にいれたら，あの敵の群のなかに突っ込んでみよう。
2002-09-29
今日も寝まくり。どうせ来週は寝れなさそうなので，今のうちに存分に寝ておこうと思ったわけで……。
今回，フォトンマッピング・レンダラの実装において，初めて本格的に C++ と STL の導入を試みている。これは半ば実験的な試みなわけだけれど，結果としてかなり良い経験が得られたと思っている。
STL については，アルゴリズムの導入によってその本当の威力を思い知ることができたと思う。 lower_bound （バイナリサーチ）や sort （クイックソート）のようなアルゴリズムは，あらゆるプログラミングにおいて常用する価値のあるものだ。普段は実装の手間やバグ混入の危険性から省略してしまうような高速化も，これらのアルゴリズム・テンプレートが存在すれば状況は変わってくるかもしれない。特に，これらのアルゴリズムが基本的にバグフリーであることは重要なポイントだ。ある処理を導入する際に必要とされるコストのうち，平均的に最も高い割合を占めるのがバグ混入の危険性だと思うからだ。
実際のところ， STL を使いこなすにはその構造や作法について知識を深める必要があり，導入にはある程度のコストが求められる。 STL は決して「抽象化されたスーパーツール」ではないと言うことだ。これは少し失望したことでもあったけれど，それでもなお導入する価値のあるものだと確信するに至った。
C++ のテンプレートという機構そのものについては， STL や boost, tvmet などを使用することで間接的にその恩恵を被ったわけで，直接的に僕がどうこうする部分はあまり無かったし，今後もそういう付き合いが主になると思う。ただ，型の指定や定数の定義や，部分的な実装の挿入（strategy の指定）とか，そういった情報の決定を先延ばしにしておいて，とりあえず処理の内容だけを記述することができるのは便利かなと思った。そうすることで，各モジュールの実装と，それを使用する側の実装を完全に分離することが可能になるからだ。
C だとこれらの情報はマクロを使って先行して与えることになるので，どうしても「使用する側の都合」が「使用される側」に染み出てしまい，末端の処理をモジュールとして切り離すことが難しくなっていた。実質上分離されたものとして扱うことは可能かもしれないけれど，再利用性やユニット・テストの都合を考えると，完全に分離することこそが重要だと言えると思う。
得られたのはメリットばかりではない。デメリットも存在する。最も大きなデメリットは，やはり，コンパイル速度の遅さだ。率直に言って非常に重い。重過ぎだ。レンダリングよりもビルドの方に時間がかかることもあったぐらいだ。
これは本当に深刻な問題だと思う。特に，開発が進むにつれて効率が悪くなるというのが嫌な感じだ。テストケースを用意して具体的に検証してみることが必要だと思う。ううむ……。
2002-09-30
土日に十分寝たおかげか，妙に目覚めが良い。毎日こうだったらいいのに，と思うぐらいに。
なんだか知らないけれど，台風が来ているらしい。もう１０月だと言うのに……。洗濯物が外に干せずに，家の中で腐っていく。嫌な話だ。
フォトンマップ・レンダラの実装をこのまま続けたとして，現段階の次の次の辺りのステップに存在するのが，重点サンプリング法を使った分散レイトレーシングの最適化だと思う。これは，フォトンマップから得られる放射束の入射情報をヒントに重点的サンプリングを行うことで，分散レイトレーシングの宿命であるノイズ（分散）の発生を極力抑えようという方法だ。恐らくこれこそがフォトンマップ・レンダラの中でも最も重要な要素であり，従来の手法では効率良く解決することの出来なかった問題を解決へと導いたことで，フォトンマッピングの存在をＣＧ界にとって必要不可欠なものへと決定付けた要因なのではないかと思う。
で， Jensen 本からその実装方法を得るつもりでいたんだけれど，少し当てが外れてしまった。実は，この「フォトンマップベースの重点サンプリング法」は， Jensen 本の中ではかなり軽い扱いがなされているのだ。１ページ半ぐらいでさらっと流されてしまっている。残念ながらこの解説では実装方法が分からない（分かる人には分かるのかもしれないけれど……）。しょうがないので参考文献を当たってみることにした。
http://graphics.stanford.edu/~henrik/papers/ewr6.html
ていうか，これ，著者 (Jensen) の論文なんだよなあ……。なんだかなあ。
この論文 "Importance Driven Path Tracing using the Photon Map" では，フォトンマップから得られる放射束の入射情報を用いて path tracing のノイズを軽減する方法と，その効果について述べられている。実装方法についても比較的詳しい解説がなされている。
実装方法は簡単で，極座標 (phi, theta) をグリッドにマッピングして，そのグリッド毎に入射放射束の強さを求めて，それを基に重み付けを行って，云々……。ただし，このグリッドをどの程度に分割すべきかという問題についてはまったく触れられていない。実装例の解説には「４ｘ１６ぐらいで十分だ」と，なんだかあまり当てにならないコメントが載せられている。一体，何がどう十分っていうんだろう？
なんとなく考えていたことなんだけれど， Jensen 本は，フォトンマップの利点について，コースティクスの高速なシミュレーションが可能であることを，必要以上に前面に押し出しているような風がある。そんなにコースティクスって重要な要素だったんだろうか。僕はＣＧの歴史にはあまり詳しくないので，この事実が持つ重要性みたいなものを理解することはできないのかもしれない，と思う。