2002-12-01
思うところあって，音声圧縮について少し考えてみることにした。
ともあれば Ogg Vorbis によってすべてが解決されてしまいそうな問題ではあるんだけれど，そうも行かないケースもあるだろうと思う。パテントフリーをうたう Ogg Vorbis であろうとも，特許訴訟の恐怖に脅かされ続けていることには変わりないからだ。
http://news.com.com/2100-1023-249710.html?legacy=cnet
http://www.xiph.org/archives/vorbis/200005/0022.html
個人的には，少しでも多くの人がこのプロジェクトに賛同を示すことによって，世論に影響を与えることができるのではないかと考えているものの，やはり仕事が絡んでくると必要以上に慎重にならざるを得ないのが実情だ。特許問題は組織の外部に向かって開かれた問題だから，個人の思想とか主義とかでは決して動くことのできない領域なのだ。
メディア通信関連の技術は，最近特に槍玉に上げられることが多く，より一層の慎重さが求められる領域でもある。もし Ogg Vorbis を使うのであれば，それが安全であるという根拠を何か持たなくてはならない。
特許関連の情報を収集していて，こんなページを見つけた。
ドイツの FFII （公共情報促進協会）内のソフトウェア特許調査班が主催する，ソフトウェア特許の情報ページだ。「情報科学分野における技術発展を，特許の悪用による侵害から保護する」というスタンスにのっとって，ソフトウェア特許に関する各種情報を無償で公開している。
例えば，音声データ圧縮に関する情報をたどってみると……こんな感じだ。
http://swpat.ffii.org/patents/effects/mpeg/index.en.html
Fraunhofer 社の特許がずらっと並べられている。どれも，題名を見るだけでぞっとするようなものばかりだ。
フリー MP3 エンコーダで有名な LAME Project のサイト内に，音声関連の特許についてまとめたページを見つけた。
http://www.mp3dev.org/mp3/free.html
これを見れば，恐ろしく基礎的な技術にまで，余すことなく特許が主張されていることがわかると思う。もちろん，これらの特許がすべて額面通りの効力を持っているとは限らなくて，内容を緻密に調査すれば，抜け道を見つけることも可能だろうと思う。しかしそれには，法律・技術の両面における専門的な知識と膨大な時間が必要とされる。元を取ろうと思えば決して行うことのできない所業だ。
現在， MPEG layer-3 関連の特許を保持すると主張し，実際にその特許料の徴収を行っているのは，仏 Thomson 社と，独 Fraunhofer 研究所の２組織であるようだ。
http://www.mp3licensing.com/about/index.html
今のところ， 彼らは MP3 の特許料のみで満足しているように見える。しかし，その影響範囲を拡張することに対して，やぶさかではないようだ。
http://www.mp3licensing.com/other/index.html
なんとなく予想できたことだけれど， ATRAC もちゃっかり攻撃範囲内に入っている。 JPEG 特許問題では要求額をさっさと呑むことで逃げを打ったソニーも，対象が ATRAC ともなれば簡単に譲るわけにはいかないだろう。適用範囲があまりにも広過ぎるためだ。一方の Thomson & Fraunhofer だって，決して安くは売り渡すことはないだろうと思う。
どちらも，いつまでも睨み合いを効かせていないで，さっさとドンパチやってほしいものだと思う。そして願わくば，何の益の無い不毛な結果に陥ってほしいと思う。そういった不毛な争いこそが，世論を動かす一つの原動力になり得ると考えるからだ。
2002-12-02
今さらながら， make の扱いづらさに嫌気が差してきた。なんとかしなきゃ……。
ビルドツールと言って，まず最初に挙げられるのは，やはり，昔ながらの make (1) ではないかと思う。
http://www.slakhack.org/cgi-bin/man.cgi?section=1&topic=make
小規模のプロジェクトでは非常にうまく働くこのツールも，プロジェクトの規模が大きくなるにつれ，様々な問題が発生してくる。このツールは基本的にルールベースで動作するため，条件判定で動作を切り替えたり，動的にルールを変更させたりするのが難しい。それに加えて，単純に構文がマズいということもある。あまりにもマズいものだから， GNU make では大幅な構文の追加が行われたりしたほどだ。
http://www.gnu.org/manual/make/html_node/make_107.html
これに加えて， GNU make では様々な機能の拡張が行われている。しかし，オリジナルの make の上位互換品である限り，コンセプトの部分ではさほど変化がないはずだ。
そんな状態にありながらも，いまだにこのツールが幅を利かせているのは，第一に GNU make がそれなりにまともなツールであるということと，次に autoconf と automake の存在があるからこそではないかと思う。これらのツールは UNIX の各実装間における互換性を高める目的に大きく貢献している。今でこそ，ほとんどのツールのビルドが "configure && make" で完了してしまうような世の中だけれども，ほんのちょっと前（５年ぐらい前）までは，ユーザがいちいち define を切り貼りしたりとか，苦し紛れで Imakefile を使ってみたりとか，そんな状態だったと記憶している。
まずは簡単に make の代替品を探してみることにした。とりあえず候補に挙がったのは， "Ant" (Apache Ant) と "Jam" (Boost.Jam) ，それに SCons の３つだ。
http://jakarta.apache.org/ant/
http://www.boost.org/tools/build/build_system.htm
おそらく，知名度で言えば Ant がぬきんでているのではないかと思う。 Jam は，ちょっとマイナーかな……。
ただ，この中では，なんとなく SCons が面白そうだ。ひとまずのところは，これを調べてみることにしようと思う。
2002-12-03
SCons ("a Software Construction tool") は， Python 上で動作するビルドツールだ。 Python スクリプトを書いていく要領で，ビルドのルールを記述することができる。例えば， foo.c と bar.c から fubar を生成するためのルールの記述は，次のようになる。
SCons の設定ファイルは，実際には Python スクリプトそのものなので， Python の構文をそのまま利用することができる。これにより，ビルド条件による動作の変更などが，より柔軟に記述できるようになっている。
もちろん， make のようなルールベースのツールでも，記述次第では同様の動作が可能だ。しかし，ある程度の気合と覚悟が必要になるのは事実だと思う。大したことのない動作でも，やたらに記述量が増えてしまったり，ルール同士が複雑に関係しあうために，全体の管理が難しくなってしまったり……誰でもそんな経験が一度はあると思う。
この辺りの処理を，すでに慣れ親しんでいるスクリプト言語によって，思うがままにコントロールできるというのは，予想以上に心地が良い。これはちょっと癖になるかもしれない。
SCons は，ファイル間の依存関係を自動で検出するようになっている。 C/C++ の場合は，プリプロセサ (cpp) を利用して，依存するヘッダファイルの列挙を行っているようだ。どうやらこの処理は実行時に行われるようなので，総ファイル容量が増えるにつれ，予想以上に動作が重くなる危険性があるかもしれない。まだ小規模なケースでしか試していないので，その辺りの事情は掴みかねている。
また， SCons は，ファイル内容の変更の検出を，タイムスタンプベースではなく， MD5 を使ったメッセージダイジェストの比較によって実現しているようだ。これはちょっと面白いかもしれない。メッセージダイジェストは，本来は同一性の検証のために利用されるものなんだけれど，これを同一性の否定のために利用するってのは正しい適用なのかどうか，ちょっと僕には分からない。 恐ろしく低い確率だけれど，メッセージダイジェストが衝突する可能性は０ではないはずだ。これを看過するのは工学的に正しい判断なんだろうか。ううむ。
まあ，実害ないからいいとは思うけど……。連続稼動４９日と１７時間でハングアップするソフトウェアが欠陥品かどうか，みたいな話だろうと思う。
http://eclient.eizo.co.jp/support/faqs/trouble/16.html
2002-12-04
今週末に忘年会があることをすっかり忘れていた。あー，そう言えば，そんな話もあったっけな。
金曜日が忘年会ってことは……ちょっと予定がずれてしまったような気がする。今日は泊りで作業していこう。
UML のシーケンス図やら何やらを書くのに，ミキタさんの推薦（？）に従って，手書きを導入してみることにした。印刷に失敗したムダ紙（どこのオフィスにも， Postscript コードのダンプがびっしりと印刷された紙束のひとつやふたつが置いてあるものだ）の裏に図をごりごりと書きなぐって，適当に見当をつけていく。最後に，ちょっと丁寧に清書してから，スキャナで取り込んだ画像を Wiki に貼り付ければ，立派な設計メモの完成だ。
図表の類を手書きで素早く済ます，ってのは，意外といい方法だと思う。再編集や再利用が発生する段になると，どうしてもドローソフトの方に分があるのは認めるとしても，ちょっとしたメモ程度だったら手書きでも問題ないはずだ。正式な文書として運用する段階になってから初めてドローで清書する，みたいな感じで十分だと思う。
デジタルな文書として残す以上，図表もデジタルに作成した方がいいだろう，みたいな固定概念があったんだけれど，その辺りはバランス良く住み分けを行うことが大切だと思う。
http://www.blender.org/modules/documentation/intranet/docs/d...
まあ，見た目が汚くなってしまうのは，どうしようもないことなんだけどね……。その辺りは書き手の心掛け次第ということにしておきたい。
SCons の導入をゆるゆると進めてみてはいるものの，まだ安定性の部分に関して確信が持てないでいるため，例外的な形で導入するにとどめている。日常作業では SCons を利用しながらも，平行して Makefile も用意しておく，というのが原則だ。
ところで， SCons の発祥のルーツをたどると， perl の "CONS" というツールにたどり着く。
ぜんぜん聞いたことがなかったんだけれど，そこそこ有名なツールのようだ。 SCons よりもこちらの方が歴史が古く，知名度も高い。そのため，安定性については，こちらの方が多少信頼できるものがあるのかもしれない。 SCons へ依存することに不安を感じるのならば，こちらを試してみるのもいいだろうと思う。僕もちょっと傾きかけている感じだ。
Python に拒絶反応があるという人にも薦められるかもしれない。ただしその前に，その人が Perl をも嫌っていないか確認した方がいいだろう。さもなくば，３度目には何も聞いてもらえなくなってしまうかもしれない。
2002-12-05
ちょっとした興味から， HTTP について調べてみている。
http://www.faqs.org/rfcs/rfc2616.html
http://www.atmarkit.co.jp/fnetwork/rensai/netpro01/netpro01....
前から考えていることなんだけれど，こういった枯れたインフラを，もっと積極的に取り入れていくことはできないだろうかと思う。例えば，ステートレスなデータ交換のほとんどは HTTP でカバーすることができるし，対話的コミュニケーションについては FTP や TELNET が役に立つかもしれない。 IM （インスタント・メッセンジャー）を利用してプッシュ配信を実現するのも面白いし，場合によっては実用的だろうと思う。
このように，技術基盤を既存のインフラの上に乗せていくことによって，アプリケーションの開発コストを極力抑えることが可能となる。外部に蓄積されたノウハウを利用できることも，大きなメリットとなりうるのではないかと思う。
昨今の HTTP/HTML の隆盛ぶりには目を見張るものがある。元はドキュメントへのアクセス手段を提供するだけだった HTTP がここまで成長したのは，動的生成されたドキュメントの配信が，ネットワーク透過な汎用インタフェースとして利用されるようになったためだと思う。このことが， HTTP と HTML の用途を限り無く広くしているように思える。
そんなに HTTP がいいんだったら，いっそのこと， HTTP をもっと強力で汎用的なものに強化してしまおう，というような動きが一部にはあるようだ。 WebDAV (Web-based Distributed Authoring and Versioning) と呼ばれる HTTP の拡張仕様は，その顕著な例だ。
WebDAV は，既存の HTTP の機能に加え，リソース管理関連の機能が強化されたプロトコルだ。まず，既存の GET/PUT オペレーションに対して， COPY, MOVE, MKCOL （mkdir に相当する）といったメソッドが加えられた。さらに，リソースに対して「プロパティ」の概念が与えられ，簡単なロック機構も利用可能となった。この時点で，既に FTP は不要になりそうな感じだし，場合によっては既存のネットワーク・ファイルシステムよりも強力なサービスとなるかもしれない。
http://www.ietf.org/rfc/rfc2518.txt
また， WebDAV の拡張仕様となる RFC 3253 には，バージョン管理に関する機能も盛り込まれている。ここまで来ると，単なるファイルシステムのイミテーションを越えて，「コンテンツのオーサリング」という用途を本格的に意識した仕様になってくる。
http://www.ietf.org/rfc/rfc3253.txt
ansi.org に置かれている Mark Ryland 氏のプレゼンテーションを通して，そのコンセプトのいくばくかを理解することができると思う。
http://web.ansi.org/public/iisp/mtg/nov1998/ryland.pdf
マイクロソフト社員である Ryland 氏が SMB と WebDAV の比較をぬけぬけとやってのけているのは，なかなか面白い図だと思う。「IPX/SPX, NetBEUI は死んだ」，と置いた上で，その対極である IP, TCP, HTTP を軸とするデファクト標準の流れへと転向していく様は，一種のショック反応のように思えなくもない。
2002-12-06
今日は忘年会。１２月も始まったばかりだと言うのに，もう忘年会なんてのは，少し滑稽な気もする。
わりと普通に飲み食いして終了。料理がなかなか美味かった。良きことかな。
HTTP のテストプログラムをいくつか作成しながら， HTTP/HTML をアプリケーションのインタフェースとして積極的に用いてみるのはどうだろうか，なんてことを考えてみた。
ゲーム／非ゲームを問わず，現場において簡単なインハウスツールを用意する必要に駆られることは，当然のごとく存在すると思う。例えば，簡単なバッチ処理とか，雑多なフィルタとか，小規模データベースとか，そんなやつだ。こういったツールを作成するのに，多くの場合， VB や C++ Builder といった RAD 向けのフレームワークを用いることになると思う。人によっては MFC を使うかもしれない。どちらも， Windows に限って言えば，適切な選択だと思う。
僕の場合は，マルチプラットフォーム重視とアンチ・プロプリエタリーの立場（？）から， FLTK や Tk を利用することにしていたんだけれど，決してその結論に満足しているわけではなかった。どうにも中途半端な感触が拭いきれないのだ。
そこで， HTTP/HTML という選択肢が登場する。これらがオープンで非プラットフォーム依存なインフラであることには疑いの挟みようがないし，場合によってはプログラミング言語の壁さえも突破する可能性を秘めている。 HTTP サーバの実装はアプリケーションの実装と完全に分離させることが可能だから，極端な話，テキストさえ吐ければどんなものでも利用することができるのだ。
HTTP/HTML をインタフェースとして利用することには，他にもいくつかのメリットが考えられると思う。一つに，デザインが楽であること。一つに，ネットワーク透過型であること。一つに，既存の成熟したインフラであること。などなど……。
もちろんデメリットも存在する。最も大きいのは， HTTP が基本的にステートレスなデザインであるために，アプリケーションのステート管理が難しくなることだ。また，クライアント主導で動作する "Pull" 系のシステムであるために，サーバ側の望むタイミングでイベントを発生させることが難しいというのもある。これらの弱点を補うには，やはり専用のフレームワークを用意することが必須だろうと思う。
そういうの，既に存在しないのかな……。 MS の ".NET" 構想が，コンセプト的には似たものを感じるんだけど，実態はどうなんだろう。まったく調べていないので分からない。
http://www.microsoft.com/japan/net/
どうしたものだか……。
インタフェースと言えば，最近読んだこんな記事が，印象に深く残っている。
http://k-tai.impress.co.jp/cda/article/toys/0,,11504,00.html
プリンタとスキャナの複合機だからこそ実現できたインタフェースだ。機械に弱い方へ云々……というのをさっぴいても，優れたインタフェースなのではないかと思う。ちっこい液晶画面と貧弱なボタンでオペレーションするのに比べれば，ずっとまともな手段だ。 OCR を搭載すれば完璧かもしれない。
動的にドキュメントを生成し，それ自体がインタフェースになっているという点では， HTTP/HTML に近いものを感じる。逆に， HTTP/HTML を紙インタフェース化することも可能だと思う。そうすることのメリットを見つけるのは難しいと思うけど……。
2002-12-07
紙メディア経由で HTTP/HTML ，なんて話をしていて，ふと，こんなのを思い出した。
http://www.jwz.org/gruntle/tty.html
カリスマハッカーとしてお馴染みの Jamie Zawinski 氏のアイデアで，アンティークなタイプライタをキーボードに仕立て上げたら，なんかハックっぽくっていいんじゃないの，とのことだ。確かにこれは面白いかもしれない。オフィスで使ったら騒音公害になりそうだけど……。
ちなみに， UNIX において端末デバイスを意味する "tty" とは "Teletype" の略語で，通信機能を持ったタイプライターのことを指している。 UNIX が生まれた当時は，端末と言えばテレタイプのこと意味していたのだ。
http://www.tonh.net/teletype.html
http://www.tonh.net/decwriter.html
ベル研究所でオリジナルの UNIX が完成したのが 1969 年のこと。当時は，ビデオ出力を持った「仮想端末」はまだ高価な存在で，一般的に用いられるようなデバイスではなかったようだ。かの有名な仮想端末 "VT100" が登場したのが 1978 年で，その辺りでやっと仮想端末が一般的な存在として扱われるようになってくる。つまり， UNIX とテレタイプの付き合いは，相当長い間続いていたと考えていいようだ。
http://www.tonh.net/digitalvt100.html
それで，久しぶりに件のページを覗いてみたら， "ElectriClerk" というマシンについての記述が加えられていた。
http://www.ahleman.com/ElectriClerk.html
おお，本当に作ってしまう人が居たとは……。
どうやらこれは，ハリウッド在住のアーティスト Andrew Leman 氏による作品で， "Cthulhu Lives!" というライブ・アクション・ゲームのために用意されたセットの一部であるらしい。
"Cthulhu Lives!" というのは， H.P.Lovecraft の「クトゥルー」系ホラーをベースとした，ライブ形式のロール・プレイング・ゲームだ。主催者側の用意したセットとシナリオに従って，「ライブで」ゲームをプレイしてしまうという，とんでもないアトラクション企画だ。
http://www.cthulhulives.org/Game16/photos16.html
http://www.cthulhulives.org/Game64%20mose/photos64.html
Leman 氏はこの "Cthulhu Lives!" に小道具担当として参加しており， "ElectricClerk" もそのセットの一部として作成した，というわけらしい。
単発のアトラクションにここまで凝った小道具を用意するってのも凄いんだけど，このマシンだけをとって見てみても，異常なまでの情熱とセンスが感じられる。「未来世紀ブラジル」を意識してデザインしたとのことで，雰囲気は十分。中に入っている Mac ともちゃんと連動しているようだし，フレネルレンズで画面拡大するギミックまで実装済み。この手のマニアが見たら，喜んで飛びつきそうな作品だ。
2002-12-08
雨が疎ましく感じる休日。明日から本格的な冷え込みが始まると伝える天気予報の声をすっかり無視して，また頭を丸めてみた。あんまり関係無いと思うんだよね，髪の毛の量と体感温度ってのは。
坂口尚の「１２色物語」の文庫版が出ているのを見つけて，思わず手にとってしまった。
http://www.bookclub.kodansha.co.jp/Scripts/bookclub/intro/in...
僕は，連載ものの長編漫画・小説といったものが，あまり好きでないと思う。どうしても惰性で動いてしまう部分が存在するからだ。その点，短編ものはいい。一編一編が，それぞれ精一杯のクォリティで表現されようとする。例えばこの「１２色物語」などは，おそらく短編集という形式でしか表現できないであろう境地に達していると思う。あまりにも内容が詩的なのだ（そうでないのも混ざってるけど）。
最も気に入ったのは「蜃気楼」。忘却と戦い，幻の中に生き続けた男の話。
美しいオルガンの音色や，星空のようにきらめく夜景。そういった輝かしい瞬間の数々も，時が過ぎればすべて幻のように消え去ってしまう。人生そのものさえも，同じようなものだ。そういった理不尽な運命を，誰もが否応無しに受け入れることを運命付けられている。
男は，愛する人の死に運命の残酷さを知り，そしてその運命に抗うことを決意する。無常を否定し永遠を信ずるその姿は，一見して尊い生き様のように見えて，実は虚しい行為であるように感じられてならない。
もしかしたら，この物語の解釈は，人によって二通りに分かれるのかもしれない。果たして男の生き方は正しかったのか，間違っていたのか。
少なくとも，今の僕には，間違った生き方のように感じられる。あるいは，１０年前の自分であれば，正しいと感じたかもしれない。多分，そういう心理的変化こそが，大人になるってことなんだと思う。
そして，２０年後にこの物語を読んだときに，どう感じるのか。それは実際に時を経てみないことには分からないことだと思う。
2002-12-09
あまりにも寒いんで何事かと思えば，雪が降っていた。
ここ数年，なんだかんだ言って，結局，毎年雪が降っているような気がする。今年も予報では暖冬のはずだったんだけれど。
極太眉毛の謎生物が銃火器を撃ちまくるアクションゲームこと "Ratchet & Crank" を，借り物でちょろっとプレイしてみた。
http://www.ratchetandclankgadgets.com/
ゲーム内容についてはさておき……このゲームで使用されている LOD 手法が面白い。画面をじっと観察してみると分かるんだけど，視点からの距離に応じてオブジェクトが連続的に変形している。 "Continuous Level of Detail" - CLOD だ。
http://www.google.com/search?q=%22level+of+detail%22+CLOD
基本的には， edge collapse とか vertex collapse とか呼ばれている手法の派生に見える。これらの技術に関する詳しい内容については， Stan Melax のページや， idga Tokyo セミナーのプレゼンテーションなどが参考になると思う。
http://www.melax.com/polychop/index.html
http://www.igda.jp/Endeavors/Event/tgs2002_Downlord.htm
R&C における CLOD 手法は，基本的には， Huebner 氏が概要を説明している "Vertex Collapse CLOD" に近いものだと思う。しかし， R&C の CLOD で特長的なのは，頂点崩壊のプロセスを連続的に行っているところだ。つまり，頂点を崩壊先へといきなり詰めるのではなくて，距離値をパラメータとして内挿補間を行っているのではないか，ということだ。
これにより， R&C ではポッピング（非連続的な変形の瞬間に発生する見た目の違和感）を，完全に除去することに成功している。じっと凝視すれば，オブジェクトがぐにょぐにょと変形している様子を確認することができるんだけれど，ゲームを真面目にプレイしている限りでは，まず気付くことは無いだろうと思う。
実のところ，ランドスケープ以外に CLOD を使用している例を見るのは，初めてのことのような気がする。例えば，フライトシミュレータ系のゲームとか， 3D ストラテジー系のゲームなどでは，比較的冗長な形状のランドスケープを広域に渡って扱うため，当然のように CLOD が使用されている。特にランドスケープに対する CLOD については， VIPM (View Independent Progressive Mesh) とか ROAM (Realtime Optimally-Adapting Meshs) と呼ばれることが多いようだ。
http://www.cognigraph.com/ROAM_homepage/
http://www.gamasutra.com/features/20000403/turner_01.htm
http://www.muckyfoot.com/downloads/tom.html
http://www.cbloom.com/3d/techdocs/vipm.txt
しかし，建物や上モノのように複雑な形状を持つオブジェクトに対して CLOD を適用している例は，かなり限られているように思える。少なくとも，僕は知る範囲では実用例を見たことがないと思う。
そんな状態なので，まともな CLOD を見るだけでも物珍しいものがあるんだけれど，その上に，本当の意味での「連続的な」 CLOD を実現していることには，軽い驚きを感じずにいられなかった。
2002-12-10
"Ratchet & Crank" の背景デザインは，細かなパーツがぎっしりと積み上げられた感じのビジュアルが印象的だ。
http://gamespot.com/gamespot/filters/products/screenindex/0,...
http://gamespot.com/gamespot/filters/products/screens/0,1110...
これは，単にデザインコンセプトとして意図されたものなのかもしれないけれど，例の LOD システムと関連している部分も，少なからず存在するように思える。 LOD システムの特性に合わせたデザインを模索した結果，こういった方向性が導き出されたのではないか，ということだ。
背景を構成するパーツのそれぞれをよく観察してみると，例の CLOD に限らず，多種多様な LOD 手法が適用されていることがわかる。例えば，遠景ではビルボードに変幻する樹木や，半透明でフェードアウトする草花。木の幹と葉には CLOD を利用しつつ，枝だけはビルボードに切り替わる，なんていう努力賞もののモデルも存在した。
ちなみに，ポリゴンモデルからビルボードへの移行も，アルファブレンディングによって連続的に行われるようになっている。こんな所にも，ポッピングを最低限に抑えるための工夫が仕込まれているわけだ。非常に細やかな仕事だと思う。
MIP マッピングの調整も，かなりギリギリのレベルを攻めているように見える。テクスチャ解像度の適応化という本来の目的などは，もはや無視だ。少しでもテクスチャ転送量を減らすべく，見た目に悪影響を及ぼさない範囲で，最低限の解像度を保つような設定がなされている。さらに，床面にはトライリニア補間を利用し，オブジェクトや壁面の類にはバイリニア補間を利用する，というような使い分けも行っているようだ。
このように LOD の設定を詳細に行うには，一体成形で巨大なモデルを作成するよりも，細かなパーツ類を敷き詰めることによってモデリングを行った方が，有利な点が多いように思える。シーンを細かなパーツ群に分割して，それらのパーツごとに独立して LOD を解決していくことで，パーツごとに最も有効な設定を適用することができるというわけだ。
R&C では，こういった倹約努力を突き詰めた結果，描画効率をかなり向上させることに成功しているようだ。背景の密集感もさることながら，空中を飛び回る中立キャラ（破壊可能な非敵性キャラ）の数々が，静止しがちな背景に動きを与える存在となって雰囲気を盛り立ててくれている。これは恐らく，背景とキャラを表示した後に残った分の処理を中立キャラに割り当てるような配分になっているのではないかと思う。
こういった「動く背景」の類は，場面の賑やかし役として，積極的に使っていくべきだと思っている。しかもそれが破壊可能ってのは，いかにも向こうのゲームらしくて，ちょっと面白いなと思った。
R&C のような LOD システムを構築する上で，大きな問題となる点がいくつか存在すると思う。ひとつに，アーティストの負担が極端に増えてしまうこと。ひとつに，理想的な CLOD を実現するのが難しいこと。等々……。アーティストの負担に関する問題はひとまず置いておくとして，プログラマ的には， CLOD システムの解決が非常に悩ましい問題ではないかと思う。
Huebner 氏の解説するようなリアルタイム頂点崩壊プロセスには，いくつかの難関が控えている。まず，崩壊によって引き起こされる変形が，できるだけ目立たないようにすること。それと，崩壊によって破綻の起きないトライアングル・ストリップを生成すること。これと同時に，実行時効率の優れたストリップ構造になっていることも望まれる。しかし，これらの要素を同時に達成することは，極めて難しい問題のように思えてならない。
2002-12-11
頂点処理を軽減したいがために LOD を適用するのに，余計なプロセスを噛ませてまで LOD を強化する行為には，多少矛盾を感じないでもない。 LOD を強化すること自体が，逆に処理を重くしてしまう危険性を秘めているからだ。
リアルタイム頂点崩壊の手法では，結局のところバスを通過する頂点データ量は変化しない。そのため，軽量化の恩恵を受ける部分と言えば，透視変換回数とか，プリミティブ発行回数とか，そういったパイプラインの末端に位置する部分に限られてしまうはずだ。頂点ユニットの影響範囲が広い PS2 だからこそ，ある程度の効果が期待できるものの，昨今の一般的なハードウェアでは余計に効果が薄くなる方向にあるのではないかと思う。
しかしながら， LOD は決して軽視できない要素だ。特に， R&C のように開放空間が主体となったシーンを扱う場合には，可視判定／遮蔽判定によるカリングがほとんど期待できないため，否が応でも LOD に頼らざるを得ない。視野錐体内に含まれるオブジェクトのうち，そのほとんどは遠景に属しているわけだから，ひとつひとつのオブジェクトについては微量の効果でも，全体ではかなりの影響力を持つ可能性があると思う。
"Ratchet & Crank" の制作を行った Insomniac Games 社は， "Spyro the Dragon" シリーズの制作で知られるデベロッパだ。
http://www.insomniacgames.com/
ちなみに， "Spyro the Dragon" のキャラクターは， "Crash Bandicoot" と同じく米 Universal 社のコピーライト物であるため，現在では Universal 社と提携関係にあるコナミが制作と販売を行っている。もう Insomniac が Spyro を作ることは無いわけだ……。そこで， Spyro の代わりとして新たに創り上げたキャラクターが "Ratchet & Crank" ってことになるんだろうと思う。
それはさておき， Insomniac Games はかなりの技術者集団として知られる会社だ。特に LOD に対するこだわりは，もはや執念に近いものを感じる。 Spyro シリーズでも，初代 Playstation という制限された環境にも関わらず，かなり凝った LOD 手法を展開していたそうだ。
今回の R&C における LOD 手法も，そういったこだわりの一環として実行されたものなんだろうと思う。しかし，この場合の本当に素晴らしいところは，技術がプログラマの単なるエゴに終わらず，アーティストがそのコンセプトを正確に（恐らく，正確に）理解することができており，しかもそれを適切に応用することができる，という一連の流れがきちんと成立していることだと思う。
ともあればおろそかにされがちな「プログラマ／アーティスト」間のコンセンサスが，非常に高いレベルで実現されているという好例ではないかと思う。そして，それこそが Insomniac の底力なのであろうと考えている。
2002-12-12
また借り物なんだけど……セガの "Shinobi" を軽くプレイしてみた。
http://www.sega.co.jp/ps2/shinobi/
ダイレクトな操作系，成長要素の皆無な主人公，奈落死即終了の辛い難易度……そういった要素のひとつひとつが，このゲームが正統なアクションゲームの後継者であり，あの「忍」の正統な続編であることを思い知らせてくれる。今時分，ここまでアクション色の強いゲームは珍しい存在のように思える。下手に RPG っぽく染めてしまうのではなく，純粋にアクションゲームとして攻めてきたことには，何か固い意志のようなものを感じる。その辺りの決断には，個人的に賞賛を送りたいと思う。
数十分程度のプレイで，２面のラストまで行くことができた。このボスはやたら強い……恐らくここが最初の難関なんだろう。この，ちょっと高めの難易度を承知しているか否かで，ユーザの評価が大きく変化するのではないかと思う。
とりあえず買ってみようかなあ。
半年ぐらい前から， gdalgorithms-list を購読している。それだから，いつの間にか， gdalgorithms のアーカイブが Geocrawler から SourceForge へ移行してしまっているのに気付かなかった。
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
Geocrawler も，決して使いやすいものではなかったけれど，これはもっと使い難いような気がする。素直に MHonArc でも使ってもらった方が見やすいと思うんだけど……。
http://sources.redhat.com/ml/cygwin-developers/2002-11/threa...
そんなわけだから，それなりにチェックしたいのならば，ちゃんと subscribe した方がいいだろうと思う。
それで， gdalgorithms のログをチェックしていると，こんな話題を見つけた。
http://sourceforge.net/mailarchive/message.php?msg_id=245051...
ハイポリモデルから自動生成した法線マップを利用する場合に，影の側（環境光のみの範囲）において立体感が失われてしまうのが嫌だねえ，って話だ。いやあ，そりゃあ，ハイポリモデルを使っていても同じことだと思うんだけど……。
法線マップ云々はさておき，影響する光源が環境光のみになってしまうと，モデルの立体感が大幅に失われてしまう，という問題が存在するのは確かなことだ。これに対して Microsoft の Dan Baker 氏は，単純な一定環境光を使用するのでなく，代わりに半球マッピングなどを用いてみるのはどうだろうか，というような提案をしている。
http://sourceforge.net/mailarchive/message.php?msg_id=245051...
これは至極もっともな意見だ。内積演算が一つ増えてしまうけれど，昨今のハードウェアなら問題無いレベルだろう。もちろん， PS2 のような比較的貧弱な環境においても，ひとまず検討してみるぐらいの価値はあるだろうと思う。半球マッピングを導入することで，光源数を減らすことのできる可能性が考えられるからだ。
テクスチャユニットに余裕があるのなら，放射輝度マッピング（拡散環境マッピング）を使ってみるのもいいかもしれない。
http://www.microsoft.com/corpevents/gdc2001/slides2002/Distr...
そう言えば， "Real-Time Rendering" に， "Dead or Alive" の Xbox 版が放射輝度マッピングを利用している，なんて記述があったような気がする。これはやはり，一定環境光の代わりに放射輝度マッピングを利用した，ということなんだろうと思う。
放射輝度マッピングは，環境光以外のライティングにも利用することができるものの，現行のハードウェアで放射輝度マップのリアルタイム生成を行うことは，コスト的に考えて見合わない部分があるため，固定的に利用することのできる範囲 − 例えば環境光とか − においてのみ利用するのが妥当と考えられるからだ。
将来的には，これをリアルタイムに生成することも考えられるだろうと思う。
http://www.t-pot.com/program/67_diffusemap/index.html
それにはまず，圧倒的なパフォーマンスが実現されることと， HDR 機能が一般的な存在になることが重要かと思われる。意外と軽視されがちな HDR なんだけれど，シェーダの持つ可能性を広げる意味では，非常に重要なポジションを占めているのではないかと思う。
2002-12-13
また借り物で，ゼルダを触らせてもらった。
http://www.nintendo.co.jp/ngc/gzlj/index.html
序盤を軽く通してみた限りでは，なかなかいい感じ。これまでのシリーズと比較すると，カットシーンデモの類がだいぶ増えているようだ。さすがにムービーは使っていない模様。この調子でムービーを入れ込んでいったら，すぐにディスクが足りなくなってしまうだろうと思う。
現時点で最大の問題点は，個人所有の GC 本体を職場に設置してしまっていることだ。いい加減，家に持って帰らないと……。
今は， GC と CRT を， XRGB （スキャンコンバータ）を経由したコンポジット出力で接続している。これだと，色のにじみが顕著に表れてしまう。大型家庭用 TV に接続した方が，かえって綺麗に見えるぐらいだ。恐らく，いまどきの TV に搭載されている種々の画像補正機能が良い方向に働いているんだと思う。コンポーネント出力を使えば，さらに上の画質を得ることができるんだろうけど，投資が余計にかかってしまうのが，ちょっと……。
http://www.micomsoft.co.jp/displtv.html
http://www.micomsoft.co.jp/xrgb2plus.html
今日は，先週とは違ったメンバーでミニ忘年会。この時期に急いで席を確保したこともあって，結局，和民で普通に飲む会合になってしまった。
でも，まあ，なんていうか……なかなか愉快な会合だった。料理はダメだったけど。
2002-12-14
普通の休日。久しぶりに１２時間近く寝た。不毛だ……。
また借り物で，「逆転裁判２」をプレイしてみた。
http://www.capcom.co.jp/saiban2/
ううむ，評判は常々聞いていたんだけれど，これは確かに面白い。最近，ノベル系のゲームをめっきりプレイしなくなっていたものだから，こういったゲームをプレイしていると，なんだか懐かしい気分になってくる。なんだか懐かしいんだけど，それと同時に，今までに経験したことの無いような面白さを感じるのが不思議だ。
ともあれば，プレイヤーに選択肢を消化させるだけのゲームになってしまう危険性のあるこの分野において，「ユーザ自身に思考させる機会をいかに与えるか」という問題は，非常に重要な意味合を持っているように思える。その点に関して言えば，このゲームは非常に良くできている。システムの作りや，ストーリーの持っていき方が，ユーザ自身に思考を課すような方向にうまく働いているのだ。これだけ，自分自身で思考を行い，一個一個の選択肢に対して緊張感を得たのは，初めての経験なのではないかと思う。
もう一つ注目したいのが，雰囲気を盛り上げる小気味良い演出の数々についてだ。この辺りに関しては，さすがカプコンと思わせるものがある。制限された動きの中で効果的な演出を行う手法ってのは，日本のアニメやらゲームやらの中に培われた，ある種の伝統工芸とも言える分野であると思う。老舗の強みが出る部分だ。
ボリュームもかなりのものだ。一気にプレイしてみたものの，２章までしか進めることができなかった。残りの２章で８時間ぐらいは潰せそうだな……。これで ¥4,800 なんだから，コストパフォーマンスについても文句は無かろうと思う。
あとは，年末の暇つぶしにでもとっておこう。ていうか，こういうのは自腹でちゃんと買わないとなあ……。
2002-12-15
gdalgorithms-list の "acos function" スレッドで，ちょっと面白い話題が挙がっていた。元は，「acos(-1.0) が正しい値を返さない」なんて質問から始まったスレッドだったんだけれど，いつの間にか「PS one の cos() は死ぬほど遅かった」なんて話に変わっていた。
http://sourceforge.net/mailarchive/message.php?msg_id=244563...
コサインテーブルの生成を静的配列に置換しただけで，初期化処理が１０秒あまり速くなったってんだから，相当なものだと思う。にわかには信じられない話だけれど， 33MHz の R3000 で倍精度浮動小数のエミュレーションなんてやらせたら……だいたいそんなものなのかもしれない。数年前までは，固定小数点で真面目に 3D をやっていたような世界なんだから，一歩一歩のストライドが妙に広い業界だなと思う。
今でも，倍精度浮動小数点は使えなかったりとか，微妙に IEEE 形式と仕様が違ってたりとか，コンシューマ機には何かと制限が付きまとう。セコいんだよね，微妙に……。一旦 Xbox をやってしまった人とか，絶対に他のコンシューマ機に戻って来たくなくなってしまうのではないかと思っている。
そこから更に興味深いのが，そのコサインテーブルを静的にしたり，倍精度演算を単精度に直したりして，一通りの高速化を図った結果として，なぜかパブリッシャ側から 2,580,000 ポンド（約５億円）の賠償金の支払いを請求されてしまったという話だ。
http://sourceforge.net/mailarchive/message.php?msg_id=244641...
http://sourceforge.net/mailarchive/message.php?msg_id=244755...
これは， Nick Pelling 氏が英 SCi 社の下請けとして "Carmageddon" の PS one 版を制作（移植）していたときの話だ。処々の事情によりプロジェクトが沈みかけていることを察知した彼らは，最初のマイルストーン版を提出したところで契約を終了する約束をとりつけた。しかし，提出が終了した数ヶ月後に「要求されたものが出来ていない」として億単位の賠償金が請求された，という流れだ。
結局，和解には漕ぎ着けたものの，制作費の回収はままならなかったどころか，裁判費用の負担により相当な出費を迫られてしまったとのことだ。裁判において ELSPA (European Leisure Software Publishers Association) に助力を求めたものの，大した助けにはならなかったという話も興味深い。そりゃあ，パブリッシャのために存在する組織なんだから，パブリッシャ対デベロッパの裁判において，デベロッパ側に有利な働きをしてくれるとは思えないんだけど……それにしてもひどい話だと思う。
パブリッシャとデベロッパとの間に存在する力関係については，伝聞レベルで様々な話を聞くものの，パブリッシャがデベロッパに対して支払いを請求した例などというのは初めて聞くような気がする。日本のパブリッシャなんてのは，まだだいぶ温厚な部類なのかもしれないと思う。
2002-12-16
非常に驚く出来事があった。ああ，心臓に悪い……。己の行いから引き起こされた災禍とはいえ，驚かすにも程があるだろうと思う。死ぬるよこれは……。
本当に大切な経験というのは，成功よりも失敗に含まれるものなのだと，切に感じる。こうした辛い経験の積み重ねこそが，プラグマティズム重視のスタイルを鍛える原動力となるのだろうと思う。
http://www.pragmaticprogrammer.com/
低レベルなモジュールには，必ず単体テストを用意しよう。リリース後の改変には退行テストを義務付けよう。実装から動作を特定するのは避けよう……。一度世に出てしまったら滅多に修正する機会の得られないコンシューマ・ゲームソフトだからこそ，できる限り間違いの無い設計を心掛けなくてはならないんだと，肝に銘じたい。
そういえば，ネットワークゲームの一部，特に MMORPG の世界では，リリース後も継続的にコンテンツの追加や調整を行う方式が，一般的な存在になりつつあるような気がする。
http://www.playonline.com/polnews/ffxi/list_upd.shtml
一昔前までのネットワークゲーム（例えばストラテジーや FPS など）では，単なるバグフィクスや対戦バランスの調整を目的として，稀にシステムの更新が行われることはあった。これに対して，例えば "FF XI" や "Dark Age of Camelot" のような MMORPG では，システムの継続更新が，明らかに意図して行われている。これらのゲームはサーバの使用料によって収益を得るタイプのビジネスモデルを採用しているから，ユーザに継続してプレイしてもらうためのネタ作りが必要となるわけだ。
マスターアップした後も同じゲームを作りつづける気持ちってのは，どんなものだろうと思う。とは言っても，ほとんどはデータレベルでの対応で済ますんだろうけど。
何気なく Peter-Pike Sloan 氏のページを見てみた。 "Precomputed Radiance Transfer" のプレゼンテーションとムービーがアップされている。
http://www.research.microsoft.com/~ppsloan/
ムービーはちょっと画質が悪いけど，軽快にリアルタイムで動いていることを確認できると思う。 glossy の方はさすがに重い……。最新の環境で 10Hz 程度ってところかな。ううむ。
今まで気付かなかったんだけど， BRDF の達人こと Jan Kautz 氏と組んで， SH を使った任意 BRDF なんてのもやっているようだ。
http://research.microsoft.com/~ppsloan/shbrdf_final17.pdf
ただし，内容については，前述の PRT 論文とほぼ同じもののようだ。 PRT における glossy self-transfer の解説を前面に持ってきたような感じ，かな。実のところ全然読んでいないので，詳しいことはまったくわからない。たぶん，今読んでも理解できないと思う。まず昔のやつを読み直そう。
BRDF 系の技術ってのは，やってることがわりと地味なので，説得力のあるデモを作ることがなかなか難しいように思える。しかしこの SHBRDF では，ライティングに IBL を導入することによって，見た目の迫力を増すことに成功しているのではないかと思う。 Grace Cathedral の中で，異方性の鈍い輝きをたずさえ，ひとり佇むティーポット，なんてのは，なかなか耽美な図だ。
Kautz 氏の以前の仕事 "A Unified Approach to Prefiltered Environment Maps" なんかも，そういう魅力を持っていたと思う。
http://www.mpi-sb.mpg.de/~jnkautz/projects/unifiedenvmaps/
きっとそういうのが好きなんだ。このひとも。
2002-12-17
昨日から泊まり。おかげで，なんかちょっと風邪気味だ。珍しく暖かい日和なのに。
gdalgorithms の方で，アニメーションデータのキーフレーム圧縮についてのスレッドが立ち上がっている。
http://article.gmane.org/gmane.games.devel.algorithms/3717
その返答の中に，ウェーブレット圧縮を利用してみてはどうだろうか，という提案があった。
http://article.gmane.org/gmane.games.devel.algorithms/3735
ああ，それにしても SourceForge のメーリングリストビューアは使いにくい……。 Gmane 経由で参照した方が，いくぶんましだろうと思うほどだ。
しかし，これもまだ微妙に不満だ。独自にアーカイブを立ち上げた方がいいのかもしれない。
それはともかくとして…… Peyre 氏のポストの中に，参考文献へのポインタがいくつか示されていたので，これを手掛かりにしてウェーブレット関連をざっくりと見回してみようと思う。
例えば， SIGGRAPH 96 のコース資料 "Building Your own Wavelets at Home" なんてのが入門編として薦められている。
http://www.multires.caltech.edu/teaching/courses/waveletcour...
うう，いきなりこの量のテキストはちょっとヘビーかな……。
さらに参考文献をいくつかめぐってみたところ，別の良さげな入門書を見つけることができた。 amara.com の "An Introduction to Wavelets" だ。
http://www.amara.com/IEEEwave/IEEEwavelet.html
ウェーブレットに関して，その歴史や概要の説明，それから簡単な応用例の紹介などが載っている。実践的な要素は皆無なんだけれど，ウェーブレットが一体何なのであるかを知るには適当な資料なのではないかと思う。
この資料を読んでいると，ウェーブレットが意外と新しい技術であることに気付く。本格的な研究と応用が始まったのが 1930 年代だってんだから，それほど遠くない時代の話だ。
ちなみに， "Game Programming Gems 1" にもウェーブレットの解説があるんだけれど……あれはあまり参考にならないような気がする。
2002-12-18
いつの間にか免許の有効期限が迫りつつあったので，とっとと更新手続きを済ませることにした。
いつもよりもちょっと早めに起きて，近所の警察署に赴く。取得して以来ほとんど使うことなく暮らしていたおかげか，知らない間にゴールドライセンスなるものに変化していたようだ。次の更新は５年後になるらしい。
向こう５年間，この丸刈り頭の写真が貼られた免許証を使うことになるのかと思うと，ちょっと焦るものがある。まあ，どうせまた使う機会なんて滅多に無いんだから，気にしないことにすればいいんだ。
ウェーブレット関連のポインタを示していた Gabriel Peyre 氏が， Caltech Multires のことを強く推していたので，久しぶりに Caltech のページを覗いてみることにした。
http://www.multires.caltech.edu/
これは Caltech （カリフォルニア工科大学）に存在する "Multi-Res Modeling Group" のページだ。名前の通り多重分解能関連の研究を行うための組織なんだろうけど， "Multi-Res" の一言で括るには難しいほど多彩な研究を行っているように見える。
http://www.multires.caltech.edu/pubs/pubs.htm
"Surface Drawing" で有名な Steven Schkolne 氏も Caltech Multi-Res Group の所属だ。相変わらず金鋏を振り回しつつ， multiresolution とは何の関係も無さそうなことをやっている。
http://www.multires.caltech.edu/pubs/schkolne_ishii_schroder...
特に興味を引いたのが， "Hacking the GPU" と銘打たれた講義コースの存在だ。
http://www.cs.caltech.edu/courses/cs101.3/
昨今，各所で盛んに研究されている GPU の応用技術をまとめて勉強してしまおう，という内容の講義らしい。こんなかっこいいコース，他に聞いたことないなあ。
GPU を使った流体シムやら， NV30 上での geometry smoothing やら，いきなりマニアックな所を突いてきているのも面白い。 GPU の応用に学術性を持たそうとすると，どうしてもこういった高速ソルバ的な応用法に傾いてしまうのかもしれないと思う。
http://www.cs.caltech.edu/courses/cs101.3/cs101_files/notes....
一週目の宿題は， register combiner と vertex program と Cg の３通りの方法でバンプマッピングを実装してくること，だ。ああ，なんてマニアックな……。
http://www.cs.caltech.edu/courses/cs101.3/cs101_files/homewo...
Caltech やらスタンフォードやら，本場の学校はいろいろ恐ろしいなあ，と思った。
2002-12-19
仕事の進みが少し緩慢になってきているような気がする。だから，ちょっとスパートをかけてみようかと思った。
……とか何とか言ってたら，突然のマシントラブルに見舞われてしまった。これでは，まともに作業を行うことができない。しかも，終電は今しがた出たばかりだし……あああ。
すっかり予定が狂ってしまった。だからと言って，このままぼうっと惚けていても仕方がないので，この機会に，以前から調べようと思っていたことを実行に移してみることにした。 gcc の pch-branch についてだ。
http://gcc.gnu.org/ml/gcc/2002-11/msg01026.html
pch-branch は， gcc にプリコンパイルヘッダの生成機能を導入したブランチ・バージョンだ。詳しい経緯は分からないんだけど， Apple が darwin-gcc に拡張で実装していた pch 生成機能を， gcc の機能として取り込んだものらしい。以前， shinichiro.h さんの所などで話題になっているのを見かけて，ちょっと気になっていたのだ。
http://user.ecc.u-tokyo.ac.jp/~g940455/wp/misc/index.html?20...
さっそく， Keating 氏のポストにある手順に従って pch-branch の gcc3.3 をチェックアウトする。チェックアウトが完了したら，
とかそんな感じでビルド。ここまでは特に問題無く進めることができた。
実験には tvmet を使ってみることにした。
これを， pch 有りと無しの場合でコンパイルしてみて，所要時間の比較を行うわけだ。結果は以下の通りになった。
うーむ，変わっているような，変わりないような……。何度か再試行してみても，やはり同じような結果が得られる。確実に効果は現れているものの，特に重大な変化というわけでもなく，判断に難しいレベルだと思う。
と，ここまで書いて初めて気が付いたんだけど，使い方を間違えているんじゃないかという気もする。 VC++ のように，頻繁にインクルードされるヘッダファイルを列挙した "stdafx.h" を用意して，それをプリコンパイルするのが正しい手順なのではないかということだ。
さっそく確かめてみたいんだけど，家には UNIX 環境が無いし，回線が細いからチェックアウトに時間がかかるし，で，実行に移すだけの気力がなかなか湧いてこない。家の環境も，もうちょっと強化しないといかんなあ，と思う。
2002-12-20
少し思うところあって，球面調和関数の周辺の資料を読み直してみた。
http://graphics.stanford.edu/papers/envmap/
http://research.microsoft.com/~ppsloan/
やっていることは Ramamoorthi の SHIM の方がずっと簡単なんだけれど，原理的にはこちらの方が高度な内容のように思える。むしろ， Peter-Pike Sloan の PRT の方が，ずっとナイーブな仕組みだと言えるのではないかと考えている。
Sloan の PRT は，やっていることはフーリエ解析の類に近い。音響や画像の世界では，フーリエ変換や DCT, KLT などを利用して周波数ドメインへの変換を行うのに対して，ここでは球面調和関数を基底とした変換によって，球面座標系から周波数ドメインへの変換を実現している。球面調和関数自体は量子力学などの分野で利用されるものらしいんだけど，ここでは単に理想的な特徴を持つ基底関数として引用しているに過ぎないようだ。
http://www.uniovi.es/~quimica.fisica/qcg/harmonics/harmonics...
やっていることを一言で簡潔に表せば，「SH 投影を利用したインパルス応答解析」と表現することができる。この場合に解析対象となるのは，「無限遠光源より入力された放射輝度に対する各頂点の応答」だ。
http://web.sfc.keio.ac.jp/~n00161ys/sotsuron/node14.html
ここで重要なのが，一般的なシーンにおいては，この伝達関数の特性が比較的偏ったものとなる，という事実だ。低周波成分が圧倒的に強く出るわけだ。特に，なだらかな環境光と自然的な形状の組み合わせにおいては，これが成立しやすい。逆に言えば，ここで高周波成分が強く出るような条件というのは，ひどく CG じみた環境だと言うこともできると思う。
次に重要になってくるのが，周波数ドメインにおける畳み込み（コンボリューション）定理の存在だ。
http://www.library.cornell.edu/nr/bookcpdf/c12-0.pdf
http://akademeia.info/main/math_lecturez/math_rapurasu_henka...
これは結果的に，時間ドメインにおける畳み込み演算が，周波数ドメインでは単なる内積演算に置き換わることを意味している。これだけだと，まだ有り難みが足りないんだけれど， Sloan の PRT では有効帯域が低周波領域に限定されていることを思い出せば，これがとんでもない効果を生むことに気付くのではないかと思う。
例えば，半球範囲の放射輝度の入力を 64x64 の 2D 画像で持ったとして，これを真面目に畳み込んだら 64^4 回の積和算が発生するわけだ。これが PRT では高々 25 回程度の積和算に抑えられるわけで……その効果は言わずもがなだ。実際にはこれに逆変換のコストが加わるわけだけれど， SH 変換は低周波成分の方が単純になる性質があるので，それほど悪い条件ではないのではないかと思う。
2002-12-21
Ramamoorthi の SHIM も， Sloan の PRT と似た雰囲気を感じ取ることができるんだけれど，実際にはちょっと違う次元の話が混じっているようだ。だから， SH 投影関連の勘を得るには，まず Sloan の PRT 論文を読んだ方がいいのではないかと考えている。 SH の簡単なレビューも付いているし，基礎を学ぶには何かと都合の良い文献だ。
SHIM の出発点は， Ramamoorthi の "Inverse Rendering" 関連の研究にあるようだ。
http://graphics.stanford.edu/papers/invrend/
"Inverse Rendering" とは，ある物体の画像とジオメトリ情報が与えられた場合に，そこから物体のマテリアルや光源の状態などを導出するという手法だ。この技術がどういった分野に役立てられているものなのかは，僕にはよく分からないんだけれど，とにかくそういった需要がどこかの世界には存在しているらしい。
これらの研究の中に，ランバート拡散面における放射輝度と放射照度の関係を解析したものがある。
http://graphics.stanford.edu/papers/invlamb/
この論文が重要な鍵を握っていることは確かなんだけれど，実はまったく読んでいない。結論があまりにもシンプルなのに対して，内容がかなり難しそうなオーラを放っているからだ。当該のページに研究の概要と結論が非常に簡潔なかたちでまとめられているので，これを参照することで済ましてしまおうと考えている。
この中で特に重要な意味を持っているのが Figure.1 の式だ。この式は，ランバート面における放射輝度と放射照度の関係が，周波数ドメインにおいては単純な内積演算に置き換えられることを意味している。さらに重要なのは，ここに登場する係数 Al が， l > 2 の要素についてはほとんど重要な意味を持っていないという事実だ。ランバート面における放射輝度から放射照度への変換が，極端に特性の高いローパスフィルタとして機能するため，ごく僅かな低周波成分を扱うだけでも，ほとんど誤差無く変換を行うことができるということだ。
Ramamoorthi の SHIM は，この式をリアルタイムレンダリングに応用したものに他ならない。この式の持つ特性のおかげで，「どんなシーンでも定数９個」や，「シェーディングは "n * M * n" だけ」のような，種々のアドバンテージを得ることができている。
今まで見落としていたんだけれど，放射照度マップの算出コストが極端に安くつくことも重要な特徴の一つだ。これをナイーブな実装……つまり半球範囲での積分で実現すると，マップ画像のピクセル数の２乗のオーダーになってしまう。これが SHIM では，ピクセル数に SH 係数の個数（通常は９個）を掛けた回数の演算で済ますことができる。つまり，照度マップのピクセル数が 64 * 64 = 4096 ピクセルほどあったとすると， 4096 / 9 = 455 倍程度の高速化が得られるわけだ。これは前計算におけるコストとは言え，意外と侮れない効果を持っていると思う。
と，そんな感じで， SH 関数を使った解析手法は，今までに無い可能性を秘めているように思える。それは決して Sloan の PRT や Ramamoorthi の SHIM にとどまるものではなく，今後も幅広い応用が期待できるのではないかと考えている。しかし，それにしては，一般の注目度が比較的低いような感じがしてならない。
もちろん，一般の注目度が低ければ低いほど，ここがリードの稼ぎどころだと思うのだけれど……結局，ダルくて何にも手を付けていない。とりあえず出来合いのパストレーサは用意してあるんだから，せめて頂点ベースの PRT だけでもやってみようかと考えているんだけれど，はたしていつになることやらと，自分でもいぶかしんでいるところだ。
2002-12-22
"Shinobi" を購入してみた。
http://www.o-works.co.jp/shinobi/
以前，借り物でプレイして以来，ちょっと気になっていたからだ。
結論から言えば，これは素晴らしいアクションゲームだと思う。
このご時世にあって，ここまで純粋なアクションゲームを作ってきたことに，もはや驚きを禁じ得ない。ハイスピードなアクション性と，それを最高に高めるべくチューニングされた操作系。単純かつ多彩なアクションを駆使しつつ，敵を斬っては進み，斬っては進んでいく。余計な謎解きやら，野暮ったいジャンプアクションやらは一切存在しない。マリオでも無ければ，「デビルメイクライ」でも無い。純粋にアクションゲームとしての表現を突き詰めた先に存在するのが，例えばこの "Shinobi" なのではないかと，強く感じた。
とにかく，細かな要素の一つ一つがアクション性を増強する方向へと集中されているように感じる。最も重要なのは，主人公の武器「悪食」の存在だ。連続攻撃によって攻撃力が倍増していくシステムは，プレイヤーに対してスピーディーな動作とアグレッシブな攻撃を誘導するように作られている。この連続攻撃による攻撃力の倍増っぷりが尋常でなくて，うまく使いこなせば屈強なボスも数回の攻撃で倒せてしまうほどのものだ。それだけに，殺陣が決まった瞬間に得られる爽快感は，より一層強いものとなっている。
http://www.watch.impress.co.jp/game/docs/20021205/shinobi.ht...
敵を攻撃した後に再びダッシュが可能となっているのも，重要な要素だ。これのおかげで空中連続攻撃という，非常に "Shinobi" らしい独特なアクション要素が実現されている。システム的には地味な要素なんだけれど，得られる効果は非常に高い。こういったアイデアが考えつくかどうかが，ゲームをデザインできる人とそうでない人の境目になっているような気がする。……と，それはともかく，空中連続攻撃から一気に戦車を粉砕するシークエンスが決まった瞬間などは，まさにこのゲームの真骨頂とも言える。圧倒的な爽快感と優越感を，プレイヤーに対してもたらすのだ。
もちろん不満点が無いわけでもない。例えば，どうにも陳腐なシナリオや，テンポの非常に悪いムービーなど，ゲームに直接絡んでこない部分でのクオリティの低さが目に付く。基本的なアートワークは好印象を残すものなのに，シナリオや演出がそれをスポイルする方向に働いているのは，ちょっといただけない状況だ。
アウトソーシングを実現するためにプリレンダ・ムービーを導入するという考え方は，最近特に強くなる傾向にあるようだ。しかし，安直なアウトソーシングはクオリティコントロールを失う結果に陥りやすいように思える。描画システムや素材が異なるから統一性が失われる，というのも勿論あるし，内容の固まりきらない段階で発注をかけるために曖昧な指示が増えてしまったり，本編との相関性が練られていなかったり，リップシンクできなかったり，台詞とタイミングが合っていなかったり……とにかく，相当な計画性が無ければ，実現できるものではないことは確かだ。
"Metal Gear Solid 2" のカットシーンがすべてリアルタイム・レンダリングだと判明したとき，これは単なる趣味の暴走なのではないかと考えたものだけれど，今になってよくよく考えれば，必ずしもそうではなかったのだと感じることができる。リアルタイムだからこそ高められる要素というのが，確かに存在するはずだ。そういった意味で言えば，コナミの小島組こそが，今もっとも贅沢な制作条件を揃えた集団と言えるのではないかと思う。
2002-12-23
昼過ぎ頃に起きようと思っていたのに，目覚めた頃には夜になっていた。ここ最近の連休の不毛さを象徴するような出来事だ。今さら悔やんでもしょうがないので，とりあえず "Shinobi" をおさらいでプレイしてみることにした。
イージーモードでのプレイは４時間程度で終えることができた。これをノーマル，ハードとやり込んでいったとしても，最終的に１０時間を越えない程度になるかなと思う。暇な年頃のユーザはともかくとして，普段なかなか時間の取れない大人としては，このくらいのお手軽さが適当なのかもしれないと思う。
"Shinobi" をプレイしている間に，裏で gcc pch-branch のチェックアウトを走らせておいた。結局，完了するのに１時間以上かかってしまったようだ。うう，重い。いまどき ISDN なんてやってられん……。
cygwin 上での configure は問題無く通過した。さっそくビルドしてみると，リンク時に ftello と fseeko が無いと言われたので，該当個所をそれぞれ ftell と fseek に置換して再ビルド。機能的には同じものだから問題無いはずだ。
ビルドが完了したらば，さっそく試しにコンパイルをかけてみる。
うう，いきなりなんか出た。しかもダメそうなやつだ……。
空のヘッダファイルを食わせても止まってしまうので，何か根本的な問題なのかと思われる。
ソースを覗いてみると， mmap を呼んでいる辺りで止まっているような雰囲気だ。とにかく，ちょっと見ただけじゃ分からなさそうな感じがする。素直に諦めた方がいいかもしれない。うう，やはりダメか……。
cygwin-XFree86 がまともに動くようになって以来， cygwin ベースってのも意外といけるんじゃないかと考えていたのだけれど，やはり様々な所で無理を生じてしまうようだ。……うう，小さくて速い Linux ボックス，あるいは BSD マシンが欲しい。しかし，そのためにマシンを２台用意するってのも，なんだか野暮ったい感じがしてならない。セカンドマシンとしてノートを導入するって手もあるなあ。
とかなんとか言って，結局は今のままの環境に落ち着かせることになると思う。今の環境でも，やるべきことは山ほど存在するからだ。
2002-12-24
バグ付きカーネルの Red Hat 7.3 を使いつづけるのにも飽きてきたので，いい加減にアップグレードを試みることにした。
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=64984
ローカルな問題ならともかく， LAN を巻き添えにするってんだから，たちの悪いバグだ。 Linux ホストなんて，大抵，入れたら入れっぱなしで使っていたものだけれど，この時ばかりはメーカーサポートの必要性を実感した。ちゃんとアップデートしてかなきゃいけないのね……。
今月号の UNIX USER 誌に Red Hat の 8.0 が収録されていたので，これを入れてみることにした。
Red Hat Linux 8.0 は，なんだか知らないけど GUI が異様に垢抜けていて面白い。これが Bluecurve ってやつか……。
http://www.redhat.com/software/linux/personal/ss.html
こういうのは，どうせすぐに飽きてしまうんだろうけれど，ユーザの裾野を広げるには重要な要素なのかもしれない。これだけキャッチーなインタフェースなら，誰か騙されて使ってくれそうな気がする。
導入作業もそこそこに終了して，本来の仕事の方に復帰。ライブラリのテストを繰り返すうちにバグがボロボロと見つかってくる。今夜は泊まりで修正するつもりだ。
息抜きがてら gcc pch-branch の実験の続きをしてみた。
今回は，作りかけのフォトンマップ・レンダラをサンプルとして利用することにした。ある程度の規模を持ったサンプルを使ってみたかったからだ。まあ，規模っていっても 1,500 行程度しかないものなので，あまり適当とは言えないかもしれない……。
まず普通に make してみると，ビルドに 30 秒以上かかることが確認できる。
これが結構うざいんだ……。テスト用に小さい画像をレンダリングする場合などは， 10 秒ほどでレンダリングが終了するから，レンダリングよりもむしろビルドに時間を食っていると言っても過言ではない。
ここで，ソースから include されているヘッダファイルをリストアップし，それらを common.hh という１つのヘッダファイルに集約する。
次に，各ソースからこれらのヘッダを include している個所を削って，代わりに common.hh を include する文を挿入する。
変更作業が終了したら，さっそくプリコンパイルして make だ。
８秒程度にまで短縮することができた。約４倍の高速化が達成されたことになる。やっぱ効果あるんだなあ……。
今回の例は比較的小規模なものなので，もっと大規模なケースになれば，得られる効果は倍増することになると思う。これが正式機能として提供されるようになれば， gcc での C++ の扱いを激変させることになるかもしれない。
現段階では，いくつかの問題点も見受けられる。例えば，理由はよく分からないんだけど， iostream を使うと確実にリンクが失敗する。なので，今回の実験では， iostream を使用している個所はすべて削除してから実験を行った。
また，プリコンパイルヘッダを読み込んだあとのプリプロセサの動作が不安定になることがあるようだ。これも理由がよくわからないので，なんでもかんでもプリコンパイルヘッダに詰め込んでしまうことで回避した。
2002-12-25
職場の一角にガラクタの山が積み上げられていた。某所のクリスマス・パーティーに行ってきた人たちが，ビンゴ大会でゲットした景品を置いていったらしい。こういうのって，貰った瞬間はすごく嬉しいんだけど，後から冷静になって見てみると，ろくでもないものばかりだったりするんだよね……。
適当にガラクタの山を物色してみると，サンソフトの「メモリアルシリーズ・６」を見つけることができた。これは是非とも頂いておこう。
http://www.sun-denshi.co.jp/soft/cs/sms/sms06/sms6.html
このシリーズ自体は，なんてこともない，単なるアンソロジーもののシリーズ商品だ。ただ，この「６」には，伝説のファミコンソフトこと「ギミック！」が収録されている。ちょっとした思い入れのあるソフトなので，どうせ捨てられるのなら貰っておこうと思ったわけだ。
それで，さっそく動かしてみたんだけれど……ちょっとダメだなあこりゃ。明らかにエミュレータと分かる動作なんだけれど，あまりにも再現度が低過ぎるようだ。動きはやたらぎこちないし，肝心の音源もめちゃくちゃな音を出している。うう，ダメだよこれじゃ……。
いまいち納得が行かないので，腹いせに CDROM の中身を覗いてみた。ファイル構成を見てみると，シリーズの第一弾である「スーパーアラビアン＆いっき」の素材を入れ換えただけであることが容易に推定できる。バイナリを持ってきて，素材を適当に入れ換えて，それで ¥1,500 のソフトが一丁上がりというわけだ……。いくらないんでも，ちょっとボロ過ぎる話のように思える。
これでエミュレータ自体も既存のものの流用だとしたら，とんでもないことだ。幸いにして，そのような形跡を見つけることはできなかったけれど，果たして……。
2002-12-26
やっとのこと，お仕事用のマシンがリプレースとなった。新しいマシンはすごぶる高速だ。数年ぶりのリプレースなので，数値上での性能向上率は３倍以上となっている。なんと言っても，旧マシンに取り付けられている zip ドライブが，このマシンの古さを物語っていると言えよう。ビデオカードは G400 だから， OpenGL との相性が悪くてやたら苦労した記憶がある（結局，最後には諦めることで解決した）。しかし，よくよく考えてみると，とんでもない環境で制作を続けていたものだと思う。
もっとも，重い処理はほとんどサーバに任せている状況なので，個人端末を強化する必要性はそれほど無いのかもしれない。あえて言うならば， Windows 98 から離脱できることが最も嬉しい。なんでもいいから NT 系にしてもらわない限りは，話にならないだろう……。
新しいマシンは，やたら静音性に優れていて，なんだか気分がいい。いわゆる流体軸受け HDD ってやつのおかげで，ハードディスクの駆動音がほとんど無くなっている。カリカリというアクセス音も無いので，ディスク読み込みなどで動作が止まると，一瞬フリーズしたのかと勘違いしてしまうほどだ。
http://home.impress.co.jp/magazine/dosvpr/q-a/0209/qa0209_1....
本体側の空冷装置も静音化が図られているようで，ほんの僅かに残る駆動音も，オフィスノイズのなかにあってはほぼ気付かないレベルとなっている。微かに聞こえてくる低めのハム音は，ビデオカードの空冷ファンから発されているものではないかと疑っている。
それと， 3D アクセラレーションを利用しているときに聞こえてくる小さなノイズが気になってしょうがない。音声出力にノイズが乗るとか，そういうのならともかく，本体から直接カリカリと音が聞こえてくるんだから，なんとも無気味な話だ。このノイズの正体は何なんだろうかと，いつも不思議に思っている。
3D アクセラレーションが働くと，電力消費量が変化してモーターの駆動に影響が出るとか，そんなとこだろうか。それ以上の理屈を思いつくことができない。はて……。
OS は XP になったし，マシンパワーも上がったし……ということで，力試しに Cygwin/XFree86 を入れてみることにした。
ちょっと前までは実験的なプロジェクトとしての性格が強かった Cygwin/XFree86 も，最近ではずいぶんと実用に近づいたようだ。さっそく新しいマシンに入れてみると， Linux 上で動かすのと遜色の無いくらい快適に GNUstep (WindowMaker) が動き出した。こりゃあいいかもしれない……。 Windows 上で X サーバを動かす所までだったら， "ReflectionX" や "AstecX" などのような製品があったものの， Windows をホストとして X のシステム全体が動いているってのは，なかなか珍しい経験だ。
Windows 上で X を動かすことについて意義を見出すのは，少し難しい問題かもしれない。まあしかし，単なるハックとしても面白いものだし， X による遠隔 GUI を必要としている人にとっては有り難い存在だろうと思う。僕の場合は，サーバ上のターミナル (kterm) を呼び出すという目的での使い道がある。以前はこのために VNC を利用していた。 VNC は十分に実践的な方法だったものの，通信負荷が高いというデメリットが絶対的なものとして存在する。その点， X ならば非常に高いレスポンス性能を得ることができるのだ。
しばらくの間は，これで暇つぶしに事欠かないだろうと思う。
2002-12-27
今日は仕事納め。去年よりも人数が増えているためか，会議室での納会は非常に窮屈なものに感じられた。昨日から泊まりだったせいか体調が芳しくなく，歓談もそこそこに離脱してしまった。
席に戻ったものの仕事をする気は起きないので，適当に資料集めなどをしていた。最近，確率関連のテキスト探しに勤しんでいるのだ。
http://www.mathcs.carleton.edu/probweb/probweb.html
http://www.dartmouth.edu/%7Echance/teaching_aids/books_artic...
http://markun.cs.shinshu-u.ac.jp/learn/probability/i_top.htm...
http://omega.albany.edu:8008/cdocs/
これというのも， bee さんの影響で MLT （メトロポリス光伝達法）に興味を持ち始めたことに発端している。
http://graphics.stanford.edu/papers/metro/
メトロポリス法自体は，もとは熱力学方面から導入されたモンテカルロ法の一種らしい。そもそもモンテカルロ法もよく理解できていない僕にとっては，メトロポリス法はハードルの高そうな存在だったので，基礎知識にゲタを履かす意味で確率論のお勉強をしているというわけだ。
せめて原理を理解するところぐらいまでは行けるといいけど……。
ひょんなことから， comp.graphics における「列ベクトル対行ベクトル論争」の切り抜きを見つけた。 Microsoft Research の Steve Hollasch 氏のページに置いてあるものだ。
http://research.microsoft.com/~hollasch/cgindex/math/matrix/...
要するに，ベクトルを縦に書くか，横に書くか，という論点で争っているようだ。 1993 年頃のポストと言うから，ちょうど OpenGL が登場した頃の話なのだろうと思う。
最近の CG 関連書籍では，大抵の場合，列ベクトルを使っているように思える。しかし，例えば Foley, van Dam などは行ベクトルだったような気がする。
関連する問題として，行列をメモリ上にどう配置するかという議論もある。列ベクトルを利用する場合は，列優先オーダー，つまり，
……という順に配置することが多いようだ。ただこれは，メモリの並びとしては，なんとなく直感的でないような気もする。たまに行列の要素を直接操作するコードを書く際に，列オーダーと行オーダーを混同してしまい，見つけ難いバグを埋め込んでしまうことがある。
この論争を見る限りでは，数学屋さんは行ベクトルを使うから，とか，技術書では専ら列ベクトルを使うから，とか，そういった理由付けはあまり当てにならないようだ。数学や物理の世界でも，やはり同じように行と列の派閥が存在し，大したことではないけれど，小さな勘違いの元になっている，ということらしい。