(cache) Radium Software Development

これで Window Maker (GNUStep) が起動するところまで漕ぎ着けることができる。これ以上の凝ったカスタマイズは，またの機会にとっておくことにしよう……。

GNU screen は， UNIX ではごく標準的なツールだけれど， cygwin パッケージの中には含まれていない。別途にインストールする必要がある。

これは完全なポートではないけれど，軽く使う分にはこれで十分そうだ。

飯を食うついでに寄った本屋で，こんな本を買ってみた。翔泳社の「組み込み UML」。

組み込みシステム開発者に向けられた UML の解説書だ。実践的なプラクティスをベースとして解説を進めているところが，非常に具体性を伴っており，面白く感じられた。また，組み込みシステム開発とゲーム開発の置かれている立場に共通性みたいなものを感じた部分もあり，そのことが興味を引いたようにも思われる。

> 第一章組み込みシステム開発の現状とオブジェクト指向開発
> 1.2 今までの開発スタイルの何が問題なのか
>  1.2.1 コード偏重開発
>  1.2.2 保守や拡張を考慮しない開発スタイル
>  1.2.3 制御とタスク中心の開発スタイル
>  1.2.4 経験と勘を偏重する開発
>  1.2.5 開発偏重

ずいぶんとまめに更新されている tvmet だけれど，いつまでたっても 1.0.0 がリリースされる気配は感じられない。更新の大部分は，内部的な構造の変更や，細かなオプティマイズに費やされているようだ。ユーザが直に触れる部分で変化したところと言えば， normalize 関数が新たに加えられたことぐらいかと思う。

v_norm = tvmet::normzlize(v);

こんな感じでベクトルの正規化を行うことができる。以前も，

v_norm = v / tvmet::norm(v);

で同じようなことができたけれど， tvmet::normalize の方は expression template を使用するぶん，最適化のかかるチャンスが広がるかもしれない。どの程度の効果があるかは，定かではないけれど……。

そう言えば， path tracer を書き直している最中に，大いにハマった落とし穴があった。例えば次のようなソースを書いたとする。

typedef tvmet::Vector<double, 2> vector;
typedef tvmet::Matrix<double, 2, 2> matrix;

matrix m;

m = 1.0, 2.0,
3.0, 4.0;

vector v(-1.0, 1.0);

v = m * v;

実は，この記述には大きな間違いが存在する。コンパイルはエラーも警告もなく通ってしまうけれど，致命的な副作用を含んだコードが出来上がってしまう。ここで試しに v を出力してみると，

この現象は， "v = m * v" が expression template によってどのように展開されるのか考えてみるとよく分かる。

v[0] = m[0] * v[0] + m[1] * v[1];
v[1] = m[2] * v[0] + m[3] * v[1];

このように， v[1] の演算の時点で v[0] が変更されてしまっているため，誤った結果が導きだされてしまうわけだ。これを回避するには，

v = m * vector(v);
v = vector(m * v);

のようにテンポラリ・オブジェクトを一旦噛ますようにすればいい。

よくよく考えてみれば，すごく初歩的なミスなんだけれど，ドキュメントに別段の注意書きがあるわけでも無いので，うっかりハマってしまった。これは大いに気をつけねばならない。

しかし，このような気付き難いミスが潜在してしまう仕様ってのも，どうしたものかと思う。慣れの問題なのかもしれないけれど……ううむ。

"Bidirectional Estimators..." の方は， Eric Veach が初めて Bidirectional Path Tracing を導入した論文だ。まだこの頃は，有限要素法（ラジオシティ）が有力だと考えられていた時期に当たるようで，モンテカルロ法の各種の特徴 −− 追加のデータ構造が必要無いことや，結果に偏りが生じないこと −− を強調するような内容になっている。 BPT を導入するに当たっても，これらの原則が崩れないことを前提として挙げている。

通常の path tracing において点光源が使用された場合，分散を抑えるチャンスは直接照明処理に限られてしまう。上記のページに貼られている画像のように，光源が遮蔽物によって覆われている場合などは，直接照明処理がほとんど効かなくなるために，どんなに反復数を増やしたところで分散を抑えることは不可能となってしまう。このようなシチュエーションにおいて， BPT は，いくぶん良い結果をもたらす可能性があるようだ。光源側からの光の伝達をある程度追跡することによって，分散を抑えるチャンスを広げることができるわけだ。

また，光源からの２次反射以降にスペキュラ成分の高い BRDF を持った反射面が存在する場合にも，同様のことが言える。このことについては Eric Veach の次の論文でさらに詳しく触れられているようだ。

ただし，僕の目標は，とりあえず拡散面だけでもまともに扱えるようになる，というところにあるので，とりあえずこれはスキップしておきたいと思う。

例えば，窓のまったく存在しない，真っ暗闇の部屋を想像する。そして，その部屋の天井に，ほんの小さな穴をあけてみる。すると，そこから太陽光（平行光源）が射し込んできて，床の僅かな範囲が照らし出される。しばらくすると目が次第に慣れてきて，僅かな反射光によって部屋の中がうっすらと見えてくるようになるだろう。

このようなシーンに対して， path tracing は非常に分が悪い。運良く光線を辿るパスを引き当てる率は非常に低く，どんなに反復数を増やしたところで，砂を撒いたような白い点が現れてくるだけで，基本的には真っ暗な画像しか得ることはできないだろう。

たとえフォトンマップを用いたとしても，良い結果を得ることは難しいかもしれない。太陽光を伝達するフォトンのほとんどは穴の手前で跳ね返ってしまい，ほんのわずかな数のフォトンしか部屋の中に入ってくることはできないだろう。過剰に大量のフォトンを用いれば，それなりに意味のある情報を得ることが可能となるものの，その大部分は無駄に費やされてしまっているという事実には変わりがない。

これらの手法とは対照的に， MLT ならば，比較的安定した結果を得ることができそうだ。 start-up bias を消去するプロセスにおいて，天井の穴を通過するパスを探し当てることができていれば，その後の反復において効果的な条件が得られるようになる。メトロポリス法は，このように密疎の分布がある程度明確な条件下において，値の収束を速める性質を備えているようだ。

フォトンマップを用いるにしても，単純に太陽からの平行光源を適用するのではなく，替わりに，天井の穴の範囲を覆うエリア並行光源（広がりを持たないスポットライトと同等）を扱うようにすれば，非常に効果的なレンダリングを行うことができる。しかしこれは，ユーザに対してレンダリング・アーキテクチャの性質を正しく把握する必要を求めることになる。

今回挙げた例のように単純なものなら，そのような機転も簡単に利かすことができるかもしれない。しかし例えば，狭く開いたドアから平行光源が差し込んでいて，そのドアが徐々に開き，カメラがそこから外に出る……というような一連のシーケンスを作成するとしたら，どうだろうか。前述のような応用を利かすには，ちょっとしたテクニックが必要となりそうだ。

あるいは，何も考えず，あるがままにセットアップを行い，大量の計算機時間にものを言わすことになるか，だ。

なかでも，ハイポリモデル同士の衝突判定を扱ったデモ "MeshMesh" は，なかなか印象的な内容だ。例えば，輪っかの中に牛の足を突っ込んで，そのまま両者を引きずり回してみたりとか，牛の股で輪っかを挟み込んで，それを上に持ち上げてみたりとか……そんな感じで，オブジェクト同士が複雑に絡み合う様子を確認することができる。本当に見た目通りのメッシュで判定を行っているようだ。

少なからず衝突判定で苦労した経験のある身としては，こんなハイポリのメッシュをベタで扱うことのできる時代になったものかと，ある種の感動さえ覚えることができる。 Stephane Redon の "continuous collision detection" 以来の驚きだ。

Pierre 氏と言えば，衝突判定ライブラリ "OPCODE" が有名かもしれない。

OPCODE は，メッシュの階層化に AABB tree を用いている。同ページには， OBB tree ベースのライブラリの代表格 "RAPID" との比較を行った結果が提示されている。両者のアルゴリズムにおける特性を把握する上で，非常に参考になる資料なのではないかと思う。

……ええと，以前にもこんなことを書いていたような気がするな。と言うのも，諸事情あって，そろそろまた，僕の中で衝突判定が再燃の兆しを見せているのだ。

ただ今回は，前回の流行時（？）に蓄積した情報が備わっているので，悩み迷う要素がだいぶ削られているのではないかと思う。例えば，メッシュの階層化には AABB tree を，空間分割（オブジェクトレベルでの階層化）には loose octree を，交差判定には LSS (line swept sphere) 対三角形を用いる……という構成には，もはや揺るぎ無さそうだ。

Maya 自体が version 4.5 に移行しつつあるということで，それに追随する形でのリリースとなったらしい。新バージョンにおける最大の変更点と言えば，編集画面にかぶせられていたウォーターマーク（「これは試用版です」という透かしの表示）が取り払われたことかもしれない。試用版だからしょうがないと思いつつ無視する努力をしていたものの，あれはあれで結構うざかったんだ……。

同サイトにある価格情報のページによれば， Maya 4.5 Complete の販売価格は $1,999 ，国内では約２６万円になるとのことだ。ホームユースには相応しくない値段だけれども，プロ用途としては安い方の部類に入る価格だ。他の競合製品と比較した際の価格パフォーマンスは，十分に良い状態へと引き込めているのではないかと思う。最大のライバルである 3ds max の価格が既に $3,000 を越えてしまっていることを考えると，かなり果敢な価格設定だとも言える。

Maya の機能拡張を担う強力なスクリプト言語 "MEL" (Maya Embedded Language) の存在は，ゲーム開発者にとっての Maya の存在価値を大きく引き上げているように見える。それに対し 3ds max は，欧米デベロッパ間における普及率の高さから，既存のリソースやノウハウの蓄積という点で大きく抜きん出ているように思える。

どちらにも選択する動機は十分に存在する。この辺りのせめぎ合いは，まだ当分の間続くことになりそうだ。

……と，そんなブルジョアな世界の話は置いておいて，我々のようなプロレタリアートには Blender という心強い（？）味方がいる。権利買い上げのための募金活動を予定の半分の期間で達成するという輝かしいスタートを切ったオープン開発の流れは，まだだいぶ緩慢なきらいが見られるものの，一歩一歩着実に進行しつつあるようだ。

同サイトには，去年の１０月に開催された "Blender Conference 2002" のレポートが掲載されている。

このイベントは，プロジェクトの立ち上げの成功と Blender のオープンソース化を祝って開催されたものだ。イベントの開催と同時に cvs サーバへのアクセスが解禁される，なんていうドラマチックな演出も用意されていたようだ。

Blender は，今やオランダを代表するオープンソース・プロジェクトとなりつつある。このカンファレンスも， Waag Society というオランダ国内に存在するメディア促進協会の協賛によって開催されたそうだ。やはり現地での人気は高いようで，コントリビュータも主としてオランダ人によって構成されている。

日本で言うところの Ruby みたいな存在になるのかな，と思う。

"Blender Conference 2002" のページにアップロードされている "A GUI for designing interactivity in game creation" を読んでみた。

これは，オランダはデルフト工科大学の Jonathan van Wunnik 氏が，卒業研究のレポートとして作成したものらしい。研究の要旨は，題名が表しているように，インタラクティブなゲーム制作環境の可能性について調査するというものだ。昨今のゲーム制作方式についての分析を交えつつ， Blender のゲームエンジンに対する評価や改善案などを提示している。

余談だけど，このレポートはデザインが非常によく練られている。このまま gdm の記事にでも使えそうな雰囲気だ。また，ゲーム制作環境の現状について細やかに調べられており，参考になる点も存在する。卒研としては，かなり力の入ったものと言えるのではないかと思う。

Blender のゲームエンジンは "Ketsji" と名付けられたフレームワークによって支えられている。

チュートリアルなどを介して実際の利用方法について調べてみると，どうも，ゲームエンジンと言うよりは，物理エンジンに近い使い方がなされているような雰囲気だ。

Game Blender の第一歩は，オブジェクトを "Actor" として登録するところから始まる。例えば，大きな板と，その上に球を配置し，球を "Actor" として設定する。ここでメニューバーから "Start Game" を実行すると，球が重力で落下し，床で跳ね返る，といった動きが再生される。

オブジェクト同士のインタラクションについては "Logic Brick" という機構によってカバーされている。

"Sensor", "Controller", "Actuator" という３種類の「部品」を使って，オブジェクトの振る舞いやユーザの入力などを処理するための「回路」を構築していく。この辺りは，いわゆる電子ブロックに近いノリだ。もしかしたら，「パネキット」に似ているかもしれない。

Blender には Python を利用したスクリプティング機能が存在するものの，オブジェクト同士のインタラクションについては，ほとんどこの "Game Brick" によって定義することが可能であるようだ。ゲームエンジンのデモなどを見てみると，初期化処理やエフェクトの一部などに Python スクリプトが使用されている他は，ほとんどすべて Game Brick で構成されていることが確認できる。

また， Game Brick には， "Python Controller" のように，スクリプトと連携を行うための部品も用意されているので，いざとなれば，複雑な処理だけを Python スクリプトに負担させるような作り方も可能なのだろうと思う。

溺愛掲示板への kawachi さんの書き込みから，こんな本の情報を得た。

"Collision Detection in Interactive 3D Environments" ……高速衝突判定ライブラリ "SOLID" で有名な Gino van den Bergen 氏の著書だ。

SOLID は，オブジェクトの階層化に AABB tree を，オブジェクト同士の最短距離算出に GJK アルゴリズムを利用している。

件の本の内容も，公開されている目次から想像する限りでは，その線に沿って書かれているように見える。

これは買うしかあるまい……他人に薦められるかどうかは別として，自分は買わなくてはいけないような気がする。

ちなみに，これは初めて知ったことなんだけれど， Gino 氏はオランダ人で，実は Blender の開発とも深く関わっているそうだ。

主に物理エンジンの開発へ関与しており，一時期は SOLID を衝突判定ルーチンとして使用していたこともあるらしい（ただし，ライセンス等の問題もあって，今は別のものに置き換えられているようだ）。

Blender の提供するゲームエンジン機能は，物理エンジンがゲームシステムのフレームワークの一部として汎用的に利用できる可能性についてアピールする内容のように感じられる。そして，固定的な動きを定義する「アニメーション」，動的なふるまいを与える「物理エンジン」，インタラクションを定義する「ロジック」の３つ柱によって，インタラクティブな 3D コンテンツの構築がある程度まで可能になることを提示している。

しかし， Blender のゲームエンジンは，本当にこの方式を実現できるほど完成されたレベルには到達していないようだ。例えば，上に貼った画像は，サンプルゲームにおける Game Brick の一部分を抜き出したものなんだけれど，慣れないとこれだけでも十分に複雑なもののように見える。もちろん，本格的なコンテンツを作成しようものならば，これよりも数倍から数十倍複雑なロジックを構築しなくてはならないはずだ。そういった場合に，個々の問題をうまく極小化したり，分離したり，階層化したりする機構が用意されていなければ，たちまち人の手には管理できないものになってしまうだろうと思う。

現に，本格的なゲームを Game Blender によって構築した例がまったく存在しないという事実は，システムの根本的な不備をある程度裏付けてしまっているように思える。

ああ，「マイノリティー・リポート」ってディックの原作だったんだ……。僕は，最も好きな小説作家としてフィリップ・ディックを挙げるほどのファンなのに，この作品のことは全然知らなかった。どうやら，「マイノリティー・リポート」がスピルバーグによって映画化されるということで，表題作と短編数本を寄せ集めて新刊として出したものらしい。比較的最近（９９年）の刊行なので，未チェックだったのかもしれない。僕がよくＳＦを読んでいたのは，それよりも前の話だ。

映画の方の評判は……まあ，微妙な所なんだけれど，原作の方は，えーとなんていうか，いわゆるいつものディック調のお話だ。予知能力者を利用し，犯罪者が犯罪を行う前に拘束する機関−「犯罪予防局」を軸とした，サスペンス物の短編小説。こういう奇怪なアイデアがいきなり飛び出してくる辺りが，いかにもディックっぽいなと思う。

なんの断りもなくプレコグ（予知能力者）などが前提条件として登場してくるのも，もはやお馴染みの所業だ。このように，あまりＳＦ的な理屈付けにはこだわらず，奇抜で病的だけれどどこか説得力のある……そんな設定がポンポン出てくるのが，ディック作品の面白みの一つであると思う。さらに，そこで扱われるのが，他のＳＦ作家には珍しい形而上的なテーマであることが多く，そこがまたディック独特の魅力を形作っている。

この原作が最初に発表されたのが５６年のことだと言うから……ずいぶんと昔の話だ。近代世界が舞台のＳＦという，ともあればすぐに色あせてしまうようなテーマばかりを扱っているわりには，未だにその輝きが失われていないことに驚きを感じる。生前は一介のペーパーブック作家として終えてしまったとのことだけれど，半世紀を経た今となって，このように続々と映像化が進められているのは，彼の持っていたイマジネーションが今もなお人々に鮮烈な影響を与えつづけているという証拠だろうと思う。

オープンソースでは ODE - "Open Dynamics Engine" が最も有名だと思う。

最近見たものでは， Si Brown 氏の "Buggy Demo" が印象的だった。

これは，氏が ODE の習作として制作したものだそうだ。やや調整が極端なきらいはあるものの，挙動が非常に面白く，触っていて飽きのこないデモだ。ソースも公開されている。このソースがかなりシンプルなもので，この量でこれだけのことが出来るんだから，もしかしたら相当に便利な道具なのではないかと考えたわけだ。ふむ……。

また，件のデモは，ステンシルシャドウのデモにもなっている。どうやら Cass Everitt のテクニックを実践したものらしい。

処々の問題をうまく解決しているようで，影について不自然さは特に感じられない。スムースシェード時に発生するポッピングについては，ちょっとした調整によって回避しているようだ。まあ，オブジェクトが凸型のみに限定されるなら，いくらでも解決方法はあるかな……。

やぐらの下に潜るとフレームレートが下がるのは，ステンシルの描画に膨大なフィルを費やしてしまっているためだと思われる。これは，解像度を低くするとスローダウンがまったく発生しなくなることからも裏付けられる。ううむ，こんな調子だと，屋内シーンの描画とかは相当辛くなりそうだ。

Ensemble Studios のプログラマ Matt Pritchard 氏の記事だ。……ところで，ニックネームが "The Optimizer" って，あんた，かっこええなあ。

この記事は，実はちょっと古い（初出が gdm の 2002 年 6 月号）ものなんだけれど，氏が "Age of Empires" や "Age of Kings" 等の著名タイトルを通して得た貴重な体験について綴られており，ハッキング対策の基礎知識として現在でも十分に通用するものであると思う。

国内のゲーム業界は，コンシューマゲーム機というクローズな環境を長年相手にしてきたためか，ハッキング行為に対して比較的無頓着であるようにも思える。例えば "Metal Gear Solid II" などが，正式な発売日を前にしてクラッキング版が流れてしまった事件などを考えると，比較的大手の主力製品でさえ，ほとんどまともな対策が施されていないことが分かる（あるいは，よほどハッカーの技術が優れていたのか……）。

欧米のユーザは比較的ラジカルな行為を好む傾向にあるらしく，大手各社はハッキング対策に苦心しているようだ。この辺りの傾向と対策については Gavin Dodd 氏の記事 "Keeping the Pirates at Bay: Implementing Crack Protection for Spyro: Year of the Dragon" に詳しい。

ゲームショーなどで開発中タイトルの試遊台を注意深く覗いてみると，たまにドングルのようなものが挿さっていることに気付くかもしれない。特に PS2 における USB 端子の存在は，既存のセキュリティ保護ハードウェアを利用可能にするという点で，大きなメリットをもたらしているようだ。

外部に提出する ROM を管理するという作業は，非常に面倒くさい作業ではあるんだけれど，そこを押してまで対策を行っているのは，過去に痛い目を見ているからこそであろうと思う。開発中のバージョンは，デバッグ情報などが含まれていることもあって，ハッキングに対する耐性が特に弱くなる傾向がある。外部への提出には細心の注意を払わねばならない（もっとも，そこまで慎重な会社だったら，デバッグ情報付きのバージョンを決して外部に出したりしないだろうけど）。

こういったハッキング行為の影響は，今までは個人の範囲内に限られていた。極端に言えば，一部に不正を働くユーザがいたとしても，多くのカジュアル・ユーザにはその影響が及ばないものと考えることができる。しかし，ネットワークゲームにおけるハッキング行為はそうではない。不正行為はゲーム全体の価値をスポイルする可能性を秘めた危険因子だ。件の記事では，そういったネットワークゲームが持つ独特の危険性について詳しく分析し，いくつかの「法則」としてまとめている。

この手の情報というのは，パブリックな場では隠される方向に向かうため，積極的に調べなければ知ることのできない情報が多い。例えば，件の記事に載っている "Aiming Proxy" （Quake のチートの一種で，狙撃補助プログラムを裏で走らせることによって精密な射撃を可能にする）などのチートが存在することは，今までまったく知らなかった。

最も印象的なのは，メモリ解析によって Age of Empires の内部ステータスを取得する VB プログラムが作成されてしまった，という事例だ。ファミコン時代ならともかく，今のようにほとんどのメモリが動的に取得されるような状況で，特定の変数の位置を断定するというのは，非常に困難な行為であるように思える。しかし，スタティックなポインタを介したナイーブなアクセス方法を使用している場合，これを解析するのは，実際にはそれほど難しくないことだという。

例えば，次のようなコードで変数へのアクセスを行っている場合，バイナリ差分ツールとデバッガを駆使すれば，その位置を断定することは不可能でない。慣れれば簡単でさえある。

GAME_MASTER->GAME_WORLD->PLAYER[n].ResourceAmount[Wood_Index] = value;

余談だけれど， Pritchard 氏はこういった情報を直接ハッカーから聞き出して調べたそうだ。すげえ仕事だなあ……。

件の記事では，こういった解析を防ぐには OOP が役に立つかもしれない，というような指摘がなされている。例えば，ゲーム的に露出しがちなパラメータへのアクセスには必ずアクセスメソッドを介すようにし，メモリ格納時には XOR をかける（！）などだ。グローバルなデータへのアクセスも， singleton クラスを用いるようにすれば，その中でいろいろと意地悪を利かすことが可能になるかもしれない。

ディックの思考を読み取る上で，非常に参考となる文献なのではないかと思う。特に，印象に深く残った部分があるので，（翻訳者の方に感謝しつつ）それを引用してみようと思う。

……初めて書いた話には犬が登場しますが、そいつはゴミ回収業者のこと
を、家のひとが金属の容器に蓄めてはきちんと出してくれる貴重な食料を、
毎週金曜の朝に盗みにくる奴だと思いこんでいます。
（中略）
話の最後でその犬は、いつの日かそのゴミ回収業者が、自分たちの食料を
盗むように、その家族まで食べてしまうだろうと考えだすのです。もちろ
ん、犬の想像は間違ってます。ゴミ回収業者がヒトを食べたりしないこと
は、みんなわかっています。しかしこの犬の外挿法は、ある意味では……
つまりその犬に随意に与えられた現実という観点からいえば、理にか
なっています。
（中略）
おそらく各々の人間もまた、他人と異なった生き方や経験に基づく世界に
いるわけだから、誰もが独自の私的な世界のうちに住んでいるのだ、と。
さらには、もし現実というものが人それぞれで異なっていたとしたら、私
たちは現実というものを単一なものとして話してよいのだろうか。

僕には，形而上学的な考え方や，哲学的な言葉を理解することはできないけれど，この一節は，ディックがその生涯をかけて表現しようとしていたものを，誰にでも理解できるかたちで，端的に表しているような気がする。

しかしこのエッセー，中盤から後半にかけての神がかりっぷりが凄い。何も知らない人が見たら明らかに電波が入ってると感じるだろうし，僕もそう思う。末期の３部作は，ネタではなく，半ば本気で書いていたのだなあと，今さらながら驚いた。まさに私小説だったわけだ……。

この "xyzzy" という単語は，元はいわゆる jargon の一種で， "foo", "bar" などと同じく「適当な呪文」として用いられるもののようだ。日本語で言えば "hogehoge" とか，その類に属するものかと思う。

こういうギークっぽいネタを調べるには everything2.com が便利だ。

ううむ……諸説挙げられているものの，はっきりとした起源は判明していないように思える。

xyzzy /X-Y-Z-Z-Y/, /X-Y-ziz'ee/, /ziz'ee/, or /ik-ziz'ee/ adj.

やはり「エクスワイジージーワイ」というように，まんまのっぺらと読むのが無難なようだ。「ジィジー」，「イクジジー」辺りは，言っても通じない可能性が高いと思われる……。

これとはあまり関係無いんだけれど……学生の頃に "Z80" を「ジーエイティーと読め」と叩き込まれて，ああ，今までこれを「ぜっとはちじゅう」って読んでいたのは，周囲に同じ文化の言葉を話す人間がいないが故だったのだな，とショックを受けた経験がある。しかし，ひとたび社会に出てみれば，そんなのはどこでも「ゼッパチ」なのであって，単にその教員がカブれていただけ，っていうオチだった。

"Z-Buffer" を「ジーバッファー」と読む日本人は，今のところ僕は約一名しか知らない。やっぱ外資系の企業なんかだと，容赦なく「ジーエイティー」で「ジーバッファー」だったりするのかなあ，とか，かっぺっぽい妄想に想いを馳せるこの頃だ。

"xyzzy" の起源について諸説挙げられている中でも，「外積の計算順序の暗記法」という説は，特に異彩を放っていて面白い。

でもまあ，元からこういう唱え文句がなんとなく存在していて，それを暗記に使ってみた，ってところなんだろうなあ，と思う。

"xyzzy" の起源がはっきりしないのとは対照的に， "foobar" の起源は非常に明確だ。 RFC にもそのことが明文化されているぐらいだ。

第二次世界大戦においてアメリカ軍兵士の間で使用されていた，とか，ドイツ語の "furchtbar" から派生したものである，とか，やけに詳しく特定できているものだと思う。そういえば，映画「プライベート・ライアン」でも，兵士達がしきりに "FUBAR" を連発していて，ああこれのことなのかと，ひとり納得していた記憶がある。

例えば，対象となるプロダクトがゲームである場合，製品の配布規模には関わらず，タイトル当たり $2,500 でのライセンシングとなるらしい。１ドル１２０円で換算すると約３０万円になるから，思ったよりも安い価格かもしれない。

実際に製品で mp3 を使用するには，デコーダーの開発（あるいは既製品の導入）が必要となるため，最終的には割高に転じる可能性もあるんだけれど……それにしたって，一旦独自開発して使いまわすようにすれば，元を取るのは簡単なことだろうし，とにかく色々と考えてみる余地のでる価格帯ではないかと感じた。

有名な所では "Grand Theft Auto 3" の PC 版が Thomson 社からのライセンス供与を受けているようだ。たしか，「カーラジオ」ディレクトリの中に適当な mp3 を突っ込んでおくと，ゲーム中にそれらの mp3 を BGM として再生してくれる，なんていうフィーチャーがあったから，恐らくそれの絡みだろうと思う。あれだけ売れたタイトルなら $2,500 なんてほんの僅かな出費だろう……。

ここでちょっと面白いのは， 5,000 コピー以下のプロダクトにはライセンス料の支払いが課せられないという特記事項が存在することだ。

同人ソフトみたいなのだったら支払わなくて済むということかな……。もっとも，そんな理由で選ぶぐらいだったら， Ogg Vorbis に手を出した方がよほど賢明だろうと思う。

昔は，デコーダに関して，無料で配布される製品に使用される場合のみロイヤリティーの支払いが免除される，なんていう項目があったような気がするんだけれど，このような例外は今は存在しないようだ。

文面通りに解釈するならば，パッケージあたり $0.75 のライセンス料を支払うか，あるいは $50,000 を一括で支払うか，どちらかを選択しなければならない。ううむ……。

"Silent Hill 3" は，昨年のゲームショーで動いているところを確認したことがある。そのゲームショーで最も印象に残ったタイトルの一つでもある。ゲームのバックグラウンドとなる陰鬱な雰囲気を表現するかのような，濃く深みを帯びたエフェクトの数々がとても印象的なゲームだった。

ign にはムービーも置いてある。ううむ，公式ページでさえ情報は限られているのに……。海外メディアからの露出が，だいぶ先行しているようだ。

"Silent Hill 2" では，カットシーンデモをプリレンダムービーとして海外に発注していたようだけれど，どうやら今回は全編リアルタイムを実現しているようだ。上の低画質ムービーでは確信を得られないものの，細部にリアルタイムの徴証が見受けられる。

見たところ，影処理にはステンシルボリューム法が用いられているようようだ。エッジの上手くボケた感じから連想されるのはシャドウマップ法だけれど，最初に挙げたスクリーンショットのように，オブジェクト同士が複雑に影を落とし合うようなシーンをシャドウマップ法で対応するのは難しい。これを解決するには，ステンシルボリューム法かシャドウデプスバッファ法あたりが妥当な選択肢だ。しかし PS2 のレンダリング精度の低さを考慮すると，シャドウデプスバッファの実装には無理がある。このように消去法で考えてみると，ステンシルボリューム法を用いているという結論が導き出せるのではないかと思う。

ステンシルシャドウ特有のシャープなエッジをぼかすには，シャドウ生成後にブラー処理を入れ込むという方法が考えられる。オブジェクトの後ろに回りこんだ影が，オブジェクトのエッジに沿って欠けてしまっている（最初のスクリーンショットが確認しやすい）のは，恐らくそのブラー処理の影響だ。シャドウ範囲が減退する方向に何らかの補正をかけているのだろうと思う。さもなくば，物体の手前にシャドウが漏れ出してしまうかもしれない。

上のシャドウの件や，複雑な光源処理，アーティスティックなエフェクト群など，数々の挑戦的な取り組みが印象に残る内容だ。まるで，画面から畑田氏の気迫が伝わってくるようでもある。

PS2 という，いまとなっては旧式に分類されるようなハードウェアにおいて，常に果敢な態度を保持していることには，非常に関心させられる。ともあれば，旧世代マシンで頑張ってもしょうがない，とか，どうせ PS3 までの辛抱だから，とか，そんな理由を付けて逃げてしまったり，守りに入ってしまったりする所を，敢えて正面から立ち向かうには，何らかの固い信念と，それに見合った実力が必要なのだろうと思う。

映画自体については……なんて言うか，原作やファンタジーに対して特に思い入れの無い人にとっては，やはり辛いものがある内容だったと思う。しかし，純粋に映像と音響を楽しむ映画だと割り切ってしまえば，それなりに楽しむことができるかもしれない。それくらい，気合の入った内容であることは間違い無い。

「ロード・オブ・ザ・リング」において使用された各種 VFX 技術については， CG World の記事などでも比較的詳しく解説されていた。遠近法を逆手にとった撮影テクニックや，身長の異なる代役を使った演技，精巧なミニチュア背景など，古典的なローテクが活かされる一方で，完全に CG のみで制作したカットや， VR カメラの導入（HMD を装備し VR 空間で撮影を行うという本格的なものだ），群集シミュレータ "Massive" など，最先端の VFX 技術が惜しみなく活用されている。

特に，過剰なまでのポストプロダクト加工を行っていたことは興味深い。画像全体としての色調補正などはもちろんのこと，特定の個所を際立たせるために局所的な効果を適用すること（例えば，特定の人物の輝度を上げて目立ちやすくする，など）も少なくなかったようだ。編集を馴染ませるための補正作業ならともかく，撮影した映像の見た目そのものを変化させてしまうほどの加工を施しているとは，思いもよらなかった。

ちなみに，これらのポストプロダクションには Discreet の "inferno" を使用しているようだ。ツールを使いこなし，軽快にコンポジット作業をこなしていく姿は，なかなか印象的だった。

個人的に最も興味があるのは "Massive" なんだけれど，これについては解説がほとんど無かった。公式ページの解説の方が詳しいかもしれない。

ああ，「ぼくらのうた」が欲しいと思った次の瞬間には，在庫が全て無くなっていた。

あと少し……あと少しばかり早く反応できていればと思うと，なんだかもの凄く悔しい。

なんにしろ， RTR の解説は丁寧で分かりやすいので，まずそちらを読んでみることが肝心だ。

簡単に言えば，「線分対三角形」，「LSS 対線分」，「LSS 対球」の３つの判定を組み合わせて実現する，というものだ。早期に除外が断定できる条件を見極めることがキモとなりそうなんだけれど，意外と手を抜ける個所が見つからなくて苦労している。最終的な高速化パターンに辿り着くまでには，まだだいぶ時間がかかりそうだ。

当たり判定に関して常に問題となるのは，いわゆる「壁抜け」現象への対処だ。アクションゲームをやり込んだことのある人なら，壁や床をスカっと抜けてしまう，あるいは，埋まって動けなくなってしまう，なんていう現象を経験したことがあるかもしれない。壁の隙間に向かってグリグリとキャラを押し付けたり，特定の個所へ勢い良くぶつかったりすると，発生することが多い。

こういった現象は，演算精度の問題や，衝突反応処理のマズさなど，複合的な要因が考えられる。あるいは，演算精度を補正する処理が仇となってバグを生み出してしまうこともある。とにかく共通して言えることは，滅多に成立しない条件が引き金となってしまうことだ。こういったバグが，プログラマとして最も嫌われるパターンかもしれない。

この問題に関して，ちょっとしたインスピレーションを得る機会があった。 gdalgorithms に立ち上がっていた次のスレッドがヒントだ。

元の質問はこんな感じだ……「演算を単精度浮動小数点 (float) で行う限り，無視できない量の誤差が生じてしまうのは必然だ。このため，交差位置を正確に求めたつもりでも，どうしても軽く『埋まって』しまうことがある。これを安全に補正するにはどうしたらいいのだろうか？」

これに対する Thatcher Ulrich と Charles Bloom （Oddworld コンビね……）の回答は，「補正しない」というものだ。

これにはまず，「交差判定が一方通行である」，「交差面を正確に把握する手段が存在する」という前提が必要となる。

「交差判定が一方通行」ということは，少しでも面に埋まると，以降，その面に対しては判定が行われないことを意味する。その代わりに，「交差面を正確に把握」し，その面に対して更に埋まるような方向への動きは打ち消す，という処理を入れ込んでおく。こうすることで，埋まった状態を保持したまま安全に移動を行うことが可能となる。

この手法において重要なのは，当たり側（いわゆる "collider"）が，ある程度の厚みを持っているということだ。これが無いと，ひとたび「埋まった」瞬間から，一連の面に対する判定が正しく行われなくなってしまう危険性がある。もし，当たり側に厚みがあれば，特定の面に多少埋まってしまったところで，他の面に対しては正しく判定が行われる見込みがある。ただしこれには，判定の際に生じる誤差よりも厚みの方が十分に大きい，ということが前提となるかもしれない……。

誤差をカバーするために余計な補正を加えるのではなく，誤差を含んだ状態で出来るだけ正しく動作する方法を適用する，という方法論は，個人的には盲点だった。うまくいけば，比較的シンプルな処理で，通常状態における「抜け」や「埋まり」を解消することが可能となるかもしれない。

あ，ていうか，参考にならないや……。某氏の的確な突っ込みで話題が終了していた。はあ。

ボロノイ領域の判定から closest-feature を特定し，最短距離を算出する（これが半径以下なら交差）という手法のアプローチも考えてみたことがあるものの，まともに検証してみるとこれが意外と複雑で，途中で投げ出してしまった経験がある。 LSS 対三角形程度の判定ならば，プリミティブの組み合わせで地道に対応した方が，最終的には良い結果が出せるのではないかと思う。

このツールがちょっと面白くて， TeX に似たフォーマットに従って数式を打ち込んでいくと，画面上のプレビューがインタラクティブに更新される，という仕組みになっている。こういったインタフェースは性に合っているみたいで，すぐに気に入ってしまった。 GUI と CUI は両立できるものだよね……とか，十年も前に議論されていたことを思い出したりした。

それで，肝心のレンダリングの品質はというと，残念なところ，あまり良いとは言えない。 TeX には到底及び付かないレベルだ。上に貼り付けた画像の例で言えば，インテグラルが微妙にしまらない感じだし，アポストロフィは間が抜けてるし……等々。まあ，どうせドキュメント自体大したものじゃないんだし，軽く数式を入れる程度であれば，これで十分だろうと考えている。

ところで， OpenOfice Math は， MathML 形式での出力に対応しているようだ。

将来的に優れた MathML レンダラが登場したならば，そちらでレンダリングを行うようにすれば良いのかもしれない。今のところ，そこまでするほどの良質のレンダラは存在しないようだ。

こんな感じで，文章の中に気軽に MathML が入れられるようになったら，意外と便利かもしれない。

一般的に知られている SAT (Separating Axis Theorem) ベースの OBB vs. OBB 交差判定において，不安定なシチュエーションが存在するという話だ。とは言っても，これはちょっと過剰にセンセーショナルな表現で，タネは意外と単純なものだ。つまり，２つの OBB が極めて平行に近い状態にあると， edge-edge 判定において算出される外積ベクトルが小さすぎて誤差含みになってしまい，判定に悪影響を及ぼしてしまう，という仕組みだ。ううむ，すぐにでも気付きそうなトラップなんだけれど，意外と盲点になってしまっているようだ。あの Magic Software の Dave Eberly 氏でさえハマっていたと言うんだから侮れない。

Eberly 氏は，いずれかの軸が平行になった状態を検出するコードを追加し，平行が検出された場合には，平行によって重複した６つの軸判定をスキップすることによって問題を解決したそうだ。これは至極まともな回避方法だと思う。それに大して，理論派でお馴染み（？）の Christer Ericson 氏は，判定式に軽くイプシロンを噛ませるだけで対処可能だと指摘している。

ううむ，言っていることは正しいように聞こえるんだけれど……なんか不思議だな。もっとも， OBB vs. OBB を書く機会はしばらくの間無さそうだから，検証はまたの機会に回しておこうと思う。

演算精度と言えば，こんなスレッドが立ち上がったこともあった。この ML にしては珍しく長いスレッドだ。

float よりも高い精度を得るにはどうするのが良いだろうか，という質問が発端だったんだけれど，次第に宗教戦争っぽい色を帯びてきて，やれ任意精度算術を使えだの，有理数算術を使えだの，いやイプシロンで十分だの，よく分からない流れになってしまった。あややや……。

ええっと，課長の甥のことは置いといて……。相対誤差と絶対誤差の違いを常に把握していなければならない，という Ericson 氏の指摘には，ちょっと悟らされるものがあった。

先にあった OBB vs. OBB におけるイプシロンの噛ませ方もそうなんだけれど……値の相対的な大小関係によって，誤差の有様は変化する。演算順序によって変化する誤差だってあるわけで，過剰なハックは誤差を増長させる危険性を秘めている。だから，本当の「安定性」を得るには，値の意味合いや演算内容を正しく把握し，常に適切な対処を心掛けることが重要であって，単純なスレッショルドだけで全てに対応できるものではない，というわけ……。

他にも Bermei 氏関連の CD を同時にいくつかお貸ししていただいた。驚くような力作揃いで嬉しい限り。普段とは違った音楽シーンを覗き見た感じがする。

Bermei 氏の楽曲群は，その全体的な完成度の高さに加え，曲の構成に対する気遣いを感じられる所が，得に優れていると思う。例えば，「ぼくらのうた」の，間奏曲から「翼をください」，そして「まっくら森の唄」へと繋がる辺りの展開などは，非常に美しく感動的なものだ。情景の表現に富んだ楽曲の数々が，心に染み入るような効果を与えている。

幼い頃に見たものや聴いたもの……例えば映画とかお話とか，それから唄とか，そういったものが，自分に対して今でも同じような感情を与え続けているとは限らない。むしろ違っていて当然だ。

そのような考えを，このアルバムは幾多にも感じさせてくれる。

例えば，遠い昔に「翼をください」を聴いたとき，それは幼心にも良いものには感じられなかったと思う。「富や名誉は要らないから」，ただ翼が欲しいなんて，牧歌的にもほどがあると思う。脂ぎったイノセンスに，図らずも毒気が湧いてくるような感触を覚えていた。

しかし今は，むしろ，その純朴な願いを理解できるような気がする。生き続けることに付きまとう様々な苦しみとか，まだ見ぬ未来に潜む得体の知れない暗闇とか，そういったものが確かに存在することを，今の僕は知っている。だからこそ，自分自身に絡みつく全てのしがらみから開放され，真に自由になることができたならば，どんなに良いことだろうかと思う気持ちを，心のどこか奥底に携えている（それが普段表面化することは無いのだけれど）。

そういった願いの全ても，結局は空しいものでしかない。その願望自体が，生きることに対しての否定に他ならないからだ。生きることへの執着が，全てを泥沼の中へと誘い込んでいる。そういった自己矛盾を死ぬまで抱え続けることが，人の一生なのだろうと思う。

しかし，純粋に，苦しみから逃れ自由に至りたいという願いを抱くことは，決して否定されるものではないはずだ。どの時代のどこの場所でも，人々はそういった望みを持ち続け，それを唄に歌ったり，あるいは祈りとして捧げたりしてきたのだろうと思う。

十年前の「翼をください」は，あまりにも直截的で，もはや，そこから何も感じることはできなかった。しかし，今改めて，別の情景へと昇華したこの唄を聞いて思うことは，そんなことだったかもしれない。

原曲は Sting の代表的ナンバーで，ジャズ色の濃い，渋味の効いた曲だ。

bertama のカバーは，これとはうって変わって，とても聞きやすいポップなクラブサウンドへと変貌を遂げている。

ところで，この歌詞の内容をよく調べてみると，なかなか面白い。

もっとも，これはイギリス人であるところの Sting が歌ってこそ意味のあるものなんだけれど……。

いまどき，山高帽に背広でステッキを持ち歩いて……なんていうイギリス人がいるかどうかは分からないけれど，自身のポリシーを頑なに守ろうとする，古き良きイギリス人の気骨をよく表していると思う。こんな人がどこかに居たら（付き合う対象としてどうかは別として）素敵だろうと思う。

イギリスと言われて最初に思い出すのは，最近身近に体験した，時差の問題にまつわる話だ。

日本の標準時は GMT+9 ……つまり，イギリスとは９時間の時差がある。分かりやすく表現すれば，こちらが夕飯でも食おうかという時分の夜１９時が，向こうではちょうど始業したばかりの朝１０時に相当する。すると，それからしばらくして，こちらが帰り支度を始めている辺りに，向こうからガンガンと業務メールが送られてくることになる。終業間際に担当者の机を覗いてみれば，いつものようにげんなりした顔を拝むことができるかもしれない。

アメリカの場合は，この関係が逆転する。東海岸などは１０時間の時差があるから，ちょうど昼夜を逆転させたような関係だ。それがサマータイム時期には１１時間の時差になるわけで，もうまったく正反対の世界となるわけだ。

そんなわけだから，真夜中にかかってくる電話は海外からのコールであることが多い。要注意だ……。

メールをはじめとした通信インフラの発達によって，情報の伝達効率は飛躍的に向上したものの，時差の問題が存在する限り，どうしても「地域の壁」のようなものを感じざるを得ない。通常なら簡単な対話によって解決できるような用件も，回答を得るまでに１日かけて往復しているような状況では，どうにも効率が悪くなってしまうのだ。最後の手段として，昼夜シフトを入れ換えるという手もあるのだけれど……向こうの都合に合わせてこちらが不便な生活を強いられるというのも変な話かもしれない。

これが，国内での開発が終了してからの話であればまだ救われている方で，全世界同時発売なんかを目指した日には，どんな具合になってしまうのだろうかと思う。昼は国内からの対応に，夜は国外からの対応に追われて，忙殺されるディレクターと，疲弊するプログラマーたち……。あまり想像したくない図だ。

そうそう，必要だったのはこれなんだ。「余弦定理」ね……こんなのもすっかり忘れてしまっている。よく，「高校生程度の数学知識があれば」というような表現があるけれど，本当に高校数学をマスターしていれば，大抵の問題は難なく対処できるのではないかという気がしてくる。

いちいち数学の教科書を引っ張り出すのが面倒な場合には， "Eric Weisstein's World of Mathematics" が便利だ。

広範囲に渡って詳細な項目をカバーした数学データベースだ。これは教科書ではないので，復習に使うには解説が簡潔過ぎるんだけども，失念してしまった公式を参照する程度であれば十分な情報量を持っている。

ただし，公式の名前まで忘れてしまった場合や，英語での綴りが分からない場合には，検索に多少手間取ることになるかもしれない。例えば「ピタゴラスの定理」だったら "Pythagorean Theorem" ってな感じで， "Pythagoras" の綴りが分からないとどうにもならないわけだ。

先ほどの「余弦定理」も名前を忘れてしまっていたので，三角形関連の項目をしらみ潰しに調べるハメになってしまった。うう……。

逆に，英語ではよく聞くけれど，いざ日本語では何と言うか分からない，という用語もあると思う。最近知ったのは，三角形の交差などによく登場する "Barycentric Coordinates" という用語には，「重心座標」という語が対応するということだ。

人名が付けられている場合には訳も簡単だろうけど……こんな話もあったりするんで，識者の方々と言えども，迂闊に間違うわけにはいかないだろうと思う。

ざっとプレイしてみた感触は……初代 ZOE に MGS2 レベルのカットシーンを乗っけた感じ，ってのが近いと思う。アクションゲームとしてもそれなりに進化しているようで，少し安心した。数十匹も群がる敵機に向かって，数十本のレーザーを一気に叩きつける感覚は，今までに体験したことの無いものかもしれない。

エフェクトが濃くてよくわからないんだけど……かなり大胆に LOD をかましているようだ。

上のスクリーンショットを見てみると，遠くの機体も一応ポリゴンで描画されているように見える。たしかに，下手にビルボードを使うよりも，テクスチャ無しの極少ポリモデルを使った方が，システム的には簡潔にまとまりそうな気もする（ただし，アーティストにかかる負担は別途に要検討だ）。

やはり，グローエフェクトは，何か縮小バッファのようなものを利用して描画しているように見える。それから，今回 Anubis のエフェクト群を観察していて感じたことなんだけれど……グローを専用のバッファで処理する利点として，エフェクトの描画にテクスチャを使用する必要が無くなる，という点が挙げられるのではないかと思った。

ボス戦などで，とにかくすごい量（数千のオーダーだろうなあ……）のパーティクルが登場するシーンがあるんだけれど，ここまでくると，エフェクトの描画に UV 座標の指定が無くなるだけで，かなりのトラフィック軽減になるのではないかと思う。通常ならテクスチャ付きビルボードで描画するものを，単なるピクセル描画のみで代替できたとしたら……どうだろう。

あと，これは MGS2 から続く疑問なんだけれど，天候エフェクト（雨や雪）の構造が未だによくわからない。じっと画面を凝視しても，まったくパターンが読み取れないことから，少なくとも単純なテクスチャアニメーションでは無さそうだ。ううむ，ちょっとした職人技の類であるような気がするんだけどなあ……。

小技として面白かったのが，フレームの「抜き」を，意図的にエフェクトとして利用していることだ。処理落ちもしていないのに，わざとフレームを落とす，なんてのは，ゲーム屋さん的には矛盾しているように思えるかもしれない。しかしこれは，単なるスローモーションとは違って，時間の進み方が変化したような，奇妙な非現実感を与える効果がある。

映画などでも，これと同じような特殊効果が用いられることがあるようだ。

ここで例に挙げられているのは「プライベート・ライアン」の冒頭シーン（主人公が茫然自失状態に陥るところ）だ。映画の場合は，高速シャッターを使って撮影することで，フレーム間の断続感を出すことができる。一方，リアルタイムＣＧの場合は， 60Hz の滑らかな動きから急激にレートを落とすことによって，同じような効果を得ることができる，という仕組みだろうと思う。

後半の盛り上がりっぷりが尋常でない。参考文献リストだけ見たら，これが単なる書籍の紹介文であるなんて，誰も絶対に考えないだろう。これらの参考文献を辿るだけで数ヶ月は要しそうな感じだ。嬉しいやら何やら，もう……。

> 単純な適応的サンプリングによるアンチエイリアシング手法が
> 必ずしも正しい画像をレンダリングするものではない事実を
> 統計的な観点から指摘 [Kirk91]

肝心の文献は ACM Portal からダウンロードすることができる。

ただし，ダウンロードには所定のアクセス権が必要だ。 SIGGRAPH 会員であれば問題無い。こういうときのために，会員になっておいたんだよね……。単なる見栄が半分で入手した会員権だけれど，こんなときには役に立ってくれる。ここぞとばかりにダウンロードしてみた。

ええと，内容は……「一定量のサンプルにおいてある程度の変動が認められた場合，サンプル量を増加させる」という，単純な適応的サンプリング法には，実は統計的な偏りが含まれている，という事実を指摘するものだ。また，この論文では，サンプル量の変化と期待値の間に相関性が生じないように配慮した「偏りの無い (unbiased)」適応的サンプリング法を提示している。

モンテカルロ法において特に気を留めなくてはならないのが，この「偏り」の概念についてだ。リアルタイムＣＧを扱う場合にはほとんど縁の無かった統計的な問題が絡んでくるため，アルゴリズム上のちょっとした「捻り (tweak)」が「偏り」に結び付き，おかしな結果を導き出してしまうことがある。統計の知識がまったく無いに等しい僕にとっては，先生方のおっしゃる「偏りの生じないアルゴリズム」を丸呑みにして信じるしかないわけで……とても心細い状況だ。

それなりに正しいと信じていたものが，実は誤りを含んだものだった，という話で言えば，次の論文も興味深いものだ。

これは Jensen 本でも軽く触れられていたことなんだけれど，一般的に普及している Phong のシェーディングモデルが，物理的にはかなり問題の含まれたものだという事実が指摘されている。簡潔にまとめると，入射した放射照度以上のエネルギーが放出されているケースが存在することと，相互性 (reciprocity) が成立しないという２点が問題として挙げられている。特に後者は，いわゆるヘルムホルツの相互性（BRDF は入射と放出が等しい関係にあるという法則）が成り立たないことを意味しており，物理モデルへ適用するには大いに問題が含まれていることを明らかにしている。

同論文では， Phong モデルの対比として Torrance-Sparrow モデルについても触れられている。ただしその結論は，

They may still be useful, however, as ad hoc basis function.

ということだ。どうやら，ジオメトリ項によって遮断されたエネルギーが，すべて吸収されるものと前提していることがお気に召さないらしい。まあ，元が Phong モデルの拡張なだけに，なあ……。

結局，この論文では，「まっとうな」シェーディングモデルとして Neumann-Neumann モデルか，あるいは Minnaert モデルが好ましいと結論付けている。たしか Jensen 本では Shlick モデルを薦めていたっけな……。いずれも扱ったことのないモデルなので，詳細についてはよく知らない。まあ，いずれ，お世話になることだろうと思う。

おかげさまで，毎日のように興味深い情報を得ることができる。有り難いことです……。今日の更新で特に面白かったのは， SIGGRAPH 2002 Online にある "When Will Ray-Tracing Replace Rasterization?" の資料について，だ。

これは， SIGGRAPH 2002 において行われた同名のパネルセッションからプレゼンテーション資料を転載したものらしい。リアルタイムＣＧ界の重鎮たちがリアルタイム・レイトレーシングの可能性について語ると言う，とても興味深い内容のものだ。

で，その内容はと言うと……ええと，まあ，いろいろあるんだけれど，簡潔にまとめるならば， Kurt Akeley 氏のプレゼンにある次の引用文が，件の問題の状況を，非常に的確に（あるいはシニカルに）表していると言えるかもしれない。

"In ten years, all rendering will be volume rendering."
-- Jim Kajiya, 1991

うーん。大先生ったら，そんな発言してたのか……。下手なことは言えないものだと思う。

CPU の処理能力やメモリ容量，それにグラフィクスハードウェアの諸機能は，ムーアの法則にのっとり，まさに指数関数的な成長を遂げている。しかしながら，ボリュームレンダリングが古典的なサーフェスモデルに取って代わるようなシフトは，ついぞ起こりえなかった。それどころか，いまだにハイエンドの世界においてもラスタベースのレンダリング方式が堂々と用いられているような状況だ。プロダクションの世界においては，レンダリング・アーキテクチャの根本的な改変にリソースを割り当てるような強い動機は，いまだ見出されていないようだ。こうしている間にも，潜在的に生まれつつある新しいリソースたちは，より複雑な形状や，より自然なライティング，それに，より広大なシーンを表現する方向へと，次々と費やされようとしている。

そんなわけで，セッション参加者各人のリアルタイム・レイトレに対する視点は，どれも十分に慎重なものとなっている。可能性として（もしくは，飽くなき興味の対象として）リアルタイム・レイトレの方向性は今後も存続しうるものの，それによって古典的なラスタベース方式がかき消されるようなことは，まず無いだろう，ということらしい。

上のプレゼンでもちょっと触れられていたんだけれど，この世の中にはボリュームレンダリング・アクセラレータなるものも存在するらしい。しかも PC に挿さるやつだ。

512x512x512 のボクセルデータを 30Hz で高速表示。ボリュームモデルとポリゴンモデルを半透明合成可能。内蔵メモリは 2GB までの拡張に対応……とか，なにやら剛毅なオーラを放っているハードウェアだ。どうやら，こういった製品は，医療機器分野などにおいて固定的な需要を得られているらしい。あの sgi も医療分野で収益を挙げていると言うし，ＣＧ屋さんにとっては意外と侮れない分野なのかもしれない。

以前から興味のあった "Zope" に，少しずつ手を出してみている。

Zope - "Z Object Publishing Environment" は，一言で表すならば，ウェブアプリケーション・フレームワークの一種だ。 Python を基幹としたシステムに，コンテントマネージャやオブジェクトデータベース (ZODB) ，それに専用のウェブサーバまでを含めており，「これさえあれば何でも」的な，包括的なフレームワークを構成している。また，米 Zope Corporation を中心としたオープン開発が進められており，多数のプロダクト（アプリケーション）がコミュニティから提供されていることが，売りの一つとなっているようだ。

まずは，入門書としてフリーで公開されている "The Zope Book" に軽く目を通し，基本的な操作方法について調べてみている。

ざっと触ってみた感じの印象としては，かなり雑然とした感触を持ったフレームワークのように思われる。この辺りの雑然ぶりは， Python そのものに近い感覚があるかもしれない。それぞれ単体としては便利なはずの道具が，ぎりぎりの秩序でうずたかく積み上げられてしまっており，そのことが全貌を掴み難くしてしまっているような感覚だ。 Python の場合は， Python そのものが持つグルー（糊）としての性質の良さが救いになっているんだけれど，果たしてそれが Zope にも当てはまるものかどうかは……まだ僕にはよく分からない。

例えば，ドキュメントの記述手段として DTML と ZPT (Zope Page Template) の２系統が許されてしまっている所などは，まさに Zope の「育ちの悪さ」を表面化してしまっている所なのだろうと思う。解説を読む限りでは， DTML は下位互換のために残されているものと解釈できるんだけれど，実際には，現在でも多くのプロダクトが DTML によって構築されているようだ。ううむ……。

Zope は， Zope というフレームワークが強力に外堀を固めているため，これだけで何でも出来てしまうような印象を与える一方で， Zope 本来の設計を超えた範囲での応用がままならないというきらいがあるようだ。雑誌やウェブ等の解説記事では，どうしてもポジティブな面ばかりが強調されているように思えるのだけれど，ちょっと google なんかにかけてみれば，すぐに Zope への不満の言葉を見つけることができる。

ううむ……後者のやや感情的な批判はともかくとして，前者の "Why We Don't Use Zope" は， Zope の実用面から見た弱点を理論的に指摘し，もっともな警告を行っているように思える。

ただ，僕が使おうとしている用途は，例えば仕様書のブラウジングとか，イメージボードのカタログ化とか……そういった類の，多くても数十人程度しか利用しないであろう，実に単純なアプリケーションばかりだ。要求される複雑度やアクセス耐性など，たかが知れている。つまり， Zope でも十分に適していると言えるのではないかと思う。

何はともあれ，プロダクトを自作する程度のところまで漕ぎ着けないことには，良し悪しも判断できるものではないようだ。次の機会には，その辺りまで迫ってみたいと思っている。

ちなみに "Quixote" ってのは，いわゆる「ドン・キホーテ」のことで，英語読みだと「クィクソート」になるらしい。ええと，元はフランス語だっけな。でも，フランス語では「キショット」と読むらしいし……もう，何がなんだか。

Quixote は，内から外までゴテゴテに塗り固められた Zope とは違って，かなりライトウェイトな設計となっている。 Overview にある例を見ればわかるように，まま Python スクリプトを書くような感覚でドキュメントを構築することが可能だ。

これが Zope だと， DTML や ZPT のように非常に特殊なテンプレート言語の使用を強制されることになる。 Python スクリプトの呼び出しなどは，実際には非常に限定的なものだ。この辺りのアプローチの違いが， Zope と Quixote において最も対照的な部分と言えるのではないかと思う。

Quixote の概要については， Linux Journal の次の記事に詳しい。

このように， Quixote とは，あくまでもウェブアプリケーションのフレームワークを提供する一介のモジュールに過ぎず，その他の機能の実現については Python に元から備わっているものを利用すれば良い，というようなポリシーが根底にあるようだ。例えば，画像を扱うには PIL (Python Imaging Library) を使えばいいし，データベースにアクセスするには，各種 DB モジュールからお好みのやつを持ち出してくればいい。これは， Python を既にマスターしている人にとっては実に自然な感覚だ。

実のところ，まだ僕は Zope をほんの少ししか触っていないのだけれど，そんな状態にあっても， Zope の売り文句の一つである「Python との強力な統合」という言葉には，少し疑問を覚える所がある。元来プログラマでない人（ウェブデザイナなど）にとっては，このくらいの囲い込みっぷりが良い方向に働くこともあるのかもしれないけれど，既に Python を CGI 等の用途に使い込んでいる人にとっては，これはむしろ障壁に感じられることが多いのではないかと思う。

しかし，当の Kuchling 氏も，オブジェクト永続化機構としての ZODB (Z Object Database) はかなり評価しているようで， Zope から独立したかたちで ZODB を利用する方法を勧めていたりする。

これはまた， Zope や Quixote とは別件として調べてみるのも面白いかな……。超高級言語におけるオブジェクト永続化機構は，一旦使い出すとなかなかクセになるものがある。特に Python におけるそれは，型付けの緩さが良い影響をもたらしているのか，非常に使い勝手の良いものになっていると思う。

そんなわけで……気持ちは少し Quixote に傾きつつある。結局のところ，管理を行う人物が自分だけであれば Quixote でも問題無いかもしれない。しかし，少なからず他人に委任する部分が出てくることは必然であり，そういった場合に Zope のマネジメントの堅さは，かなり魅力に感じるものがある。それに，既存のアプリケーションの量で言えば， Quixote などは Zope の足元にも及び付かないものだ。 "ZWiki" や "SquishDot" ，それに "Zch" のような優秀なアプリケーションが多数存在することを考えに入れると，これは決して無視することのできない要素に思われる。

GNU Common C++ は，ソケット通信やシリアル I/O 関連の機能をまとめたクラスライブラリだ。スレッドを利用したセッション処理などにも対応しており，サーバ・クライアントの両面をカバーすることができるようになっている。他にも XML パーサやオブジェクト永続化機構など，なんだかとりとめのないものを色々と集めているようだ。ちょっと節操の無い感じかもしれない。

使ってみた感触は……悪くないと思う。一旦 tcpstream を生成してしまえば，あとは iostream と同じような感覚で扱うことができる。

ost::tcpstream echo("mypc.hoge.co.jp:7");

// send
echo << "hello" << std::endl;

// recv
std::string buf;
echo >> buf;
std::cout << "echo: " << buf;

適当にパケットクラスを設計し，次にそれ用の iostream 入出力関数を用意してやる。そうすれば，あとは "<<", ">>" の組み合わせで好き勝手に通信を行うことができる。それで，ええと，エラー処理はどうすればいいのかな……まあ，その辺りは後で調べてみよう。

入出力の部分はともかくとしても，あの面倒な接続処理が全て省けてしまうのは嬉しい。環境に依存する部分を隠す手段としても有効かもしれない。

そんな感じで，なかなか良さげなライブラリではあるんだけれど，ドキュメントが不親切だったり， cygwin への対応がおろそかにされていたり（最新バージョンでは make も通らない）と，多少不安を感じさせる要素も存在する。しかし，プロジェクト自体はそこそこ活発に動いているようであり，少なくとも，いきなり消滅してしまうようなことは無さそうだ。

GNU Common C++ は，元は OST (Open Source Telecom) 社のインハウスツールとして制作されていたものらしい。

現在も同社のメンバーを中心として開発が続けられている。恐らく彼らは業務でこれを利用しているはずだから，ある程度の実績は見込んでもいいのかもな，と考えている。

しかし，なんて言うか……いまだに finger プロトコルなんかをまともに使っているのは，この界隈ぐらいのものだな，と思う。

詳しい経緯は分からないのだけれど， FPS 系のゲームを作っている会社ばかりが finger を開いていることから，やはりこれは id が始めた慣習なのではないかと考えている。

件の plan の内容は，主に GeForce FX と ATI R300 の性能比較，それに， DOOM エンジンにおける新機能への対応状況についての報告で占められている。各ハードウェアの性能に関する話題については，ええと，ひとまず置いておくとして……それよりも興味を誘われたのは， Carmack 自身の OpenGL に対する姿勢について，いくつかの表記が見られたことだ。

僕は，純粋に OpenGL が好きだから，という理由だけで OpenGL を使っている。他にもつまらない理由がいくつかあるのだけれど，煮詰めれば単に好みの問題でしかないのだろうと自己分析している。だから， Windows 向けのゲームを作る限りにおいては DirectX を使うのが正解だろうし，本気でマルチプラットフォームを目指すならば，ハードウェアに依存する部分は完全に囲っておいて， DirectX だろうが OpenGL だろうが対応できるようにしておくのがスジだろうと思う。そんなわけだから， Carmack がここまで OpenGL にこだわりを持つ理由というか……その心境というものが，あまり理解できないでいる。

件の plan には，頂点シェーダの機能について，ベンダ依存の実装から ARB 拡張（委員会によって策定された共通拡張仕様）への移行を決定した，とのことが書かれている。一見，共通仕様の存在はとても都合の良いものに感じられるかもしれないけれど，実際には様々な問題が潜伏している。

まず，機能上は同じものでも，ハードウェアによって処理速度は異なるため，そのことを考慮せずに単純に利用することはできないという問題がある。また， OpenGL ARB は仕様の制定に対してとても慎重な態度をとっているため，新しい機能が共通仕様として使用できるようになるまでには，かなりの期間が要されるという問題もある。

それに，仕様が制定されてから各ベンダが対応を行うまでには，また更なるディレイが存在するわけで，実際には相当の期間を待たないことには共通仕様として利用することができない，というのが実情だ。今回の ARB_vertex_program の件も，「ようやく実用レベルになった」というのが本音のようだし，ましてや ARB_fragment_program への対応などには，まだかなりの時間が要されそうな雰囲気だ。

もう一つ興味深かったのは， Carmack も GeForce FX の騒音問題について触れていることだ。

> The current NV30 cards do have some other disadvantages: They take up two
> slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually
> one to care about fan noise, but the NV30 does annoy me.

大陸の人たちは PC の大きさや騒音なんて気にしないものかと思っていたのだけれど，さすがに限度というものが存在するようだ。最近のビデオカードはアクセラレーションの状態によって放熱ファンの回転速度を変化させるような機能が実装されているようで， 3D を使う度に PC が唸り出すものだから，余計に気になってしまうのかもしれない。僕のマシンでも，更新同期を切って描画しまくる（1000Hz オーバーぐらい簡単に出る）と，筐体から蚊の飛ぶような音が聞こえてくることが確認できる。

一度，ファンレス PC の静音性というものが，どんなものなのか，体験してみたいと思っている。

少し前までは，結局は HDD の回転音が本体の静音性をスポイルしてしまっている，というのが実情だったんだけれど，最近は驚くほど静かな HDD が存在することから，ひょっとしたら本当の意味での「無音 PC」を実現できるのではないかと考えている。

年賀

cygwin

tvmet 0.7.0

天井の穴

Flexine

Maya PLE 4.5

Ketsji

Collision Detection

The Minority Report

ODE

How to Hurt the Hackers

Gnosticism

xyzzy

mp3licensing.com

Silent Hill 3

The Lord of the Rings

Robust Collision Response

OpenOffice Math

Higher Accuracy

ぼくらのうた

Englishman In New York

World of Mathematics

Anubis

Avoiding Biases

Stop Rasterizing

Zope

Quixote

Common C++

Carmack's Plan