2002-05-01
予定通りというかなんというか，今夜も忙しくなりそうなので，午後のうちに一時帰宅して，また職場に舞い戻った。午後の電車は連休中にも関わらず少し混雑していた。いやむしろ行楽帰りの人の波だったんだろうか。ともかく，空いていることを期待していたので，少しがっかりした気分になった。
TAOS さんが generic programming の手ほどきを書いている。
http://ra.sakura.ne.jp/~taos/tips/index.htm
困ったことに，僕は STL の使い方さえもおぼつかない。とりあえず興味を喚起するためにも Boost C++ にでも手を出してみようかと思う。
こういったヘビーな C++ ライブラリにはコンパイラ依存の問題がつきものだけど， Boost C++ については gcc3.0 ならほぼすべてのモジュールが使用可能になるようだ。しかし，手元の環境では 2.95 や 2.96 がメインになっているので，すべてのモジュールが正常に動くわけではなさそうだ。しかも STL-port を使わない限りは，まともな動作を期待できない模様。
STLport はマルチプラットフォームな STL 互換ライブラリだ。昔 VC++ を使っていた頃は， VC++ に付属の HP 製 STL が使いづらいんで STLport を入れていた記憶が……いや，あれは SGI-STL だったっけ。ああ，もうわかんね。Ｃボケもいいところだ。
2002-05-02
今日もなんとなく泊まり。他部署が連休に入っているだけに，いつもよりも心なしか穏やかな様子なのだけど，一応油断できない日々が続いている。
で，一応 Boost C++ でも触ってみようかってことにしたんだけど，ここで困るのが gcc の C++ コードに対するコンパイル速度の異様な遅さだ。理由は定かではないけれど，とにかく C++ に関する限り gcc は圧倒的に重い。ベタ C コードについては他のコンパイラと比較してもそれほど遜色ないと思うんだけど， C++ については VC++ と比べるまでも無く圧倒的な差がある。
重いことで有名な javac だって，こんなにも遅くはなかったと思う。
試しに Boost C++ に含まれる quaternion テンプレートのサンプルソースをコンパイルしてみると，
こんな調子だ。１ファイルに３分もかかったんじゃ，少なくとも僕にとってはシャレにもならない。これで数十万行規模のプロジェクトをコンパイルしようものなら日が暮れてしまうわけで……ましてや百万行を越えるケースだってあるってのに。
同じような事で悩んでいる人は決して少なくないはずだ。
http://gcc.gnu.org/ml/gcc/2001-07/msg01376.html
gcc3.0 では更に重くなるってんだから，具体的に対処策を練っておかなければ C++ への移行は難しいと思う。しかし「特定の機能を使う度に重くなる」でもなしに，ただ闇雲に重い雰囲気があるから，対処っても難しいものがある。ただ，テンプレートライブラリのようにヘッダに長く書く傾向のソースが増えると負荷が高まるであろうことは想像にかたくない……って，今話題にしているのはテンプレートだろうに，どんどん行動と結論が矛盾してくる。
これは……食えない。
まあこんな調子だから，業務的には，ベタ C と控え目 C++ の混在型とか，そういった方向性に向かっていきそうな気がする。最も C++ の必要性を感じているのは抽象的なゲームオブジェクト（キャラクタ）の管理に関連する部分だから，それ以外の部分は従来のスタイルを継承するという方法も考えうると思うのだ。
ただ，個人趣味的には C++ の導入に努めるようにしたいと思っている。結局コンパイル速度の問題だって，最悪プロセッサのパワーによって解決することだってできるわけだし，少なくとも数年後には解決されるであろうことを見越して，そのときにすみやかに C++ に移行できればいいなと，楽観的に考えている。
2002-05-03
どうにもバージョンが確定しないので， CVS リポジトリにブランチを作って作業を進めることにした。確定しないうちにこの変更をコミットするのは危険だからだ。ブランチのマージ作業はちょっとややこしいけれど，落ち着いて手順を踏めばそれほど難しいことではない。
http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
僕は CVS をコマンドラインから使うのが好きだけど，閲覧には ViewCVS を使っている。
http://viewcvs.sourceforge.net/
久しぶりにホームページを覗いてみると，いつの間にか CvsGraph への対応なんかが追加されていたみたいだ。それほど頻繁にブランチを作るわけじゃないので必要性は薄いかもしれないけれど，見た目がちょっと面白そうだ。機会があれば試してみようと思う。
http://www.akhphd.au.dk/~bertho/cvsgraph/
そんな感じで，今日も一旦帰宅してからすぐ出社。連休明け頃にはなんとかなる予定だけど……。
2002-05-04
メールボックスにプロバイダからのお知らせが届いている。またどうせ下らない内容だろうと決めつけて，ずっと放置してあるんだけど，ちょっと気が向いたので内容を見てみることにした。
なんでも，今月中にアクセスポイントの全面改定が実施されるとのこと。しかも，新しいアクセスポイントではＮＴＴのテレホーダイサービスが使えないらしい。むむ，テレホが使えない番号なんてあるのか。ともかく，テレホーダイをヘビーに使用している僕としては大いに困ったこと。これを機会にＡＤＳＬに入れ換えるのも手だけれど，なにしろウチはＩＮＳライトだから，ＡＤＳＬに入れ換えるにはアナログ回線を新規契約しなきゃなんなくて，初期投資額がかなり大きくなってしまうのだ。だいいち，今月はそんなことをしている余裕もあったもんじゃない。
しょうがないから，フレッツＩＳＤＮに切り換えることにしようと思う。もはや月基本料ではＡＤＳＬとほとんどかわらないんだけど……あーもう。
まあどうせ，今の家にずっと居続けるとも思えないし，ここで下手な投資をするよりも無難に収めた方がいいだろうと自分を納得させることにした。
2002-05-05
今日は日曜日。たしか明日まで休日だったっけな。休日の職場はいつもよりもいくぶん静かで居心地はいいのだけど，ビルの機能が限定運転になってしまうのが少し不便なところだ。今年の連休も，結局ゴミだらけになっちゃったな。
ZZZ online より "Actuality Volumetric 3D Display"
http://www.actuality-systems.com/
http://www.zzz.com.ru/126.html
この装置は，ガラス張りのドーム中に垂直に立てられた反射板を分間約６００回転の速度で回し，そこにボクセルのスライスを投影することによって３次元のボリューム表示を行う，というものだ。原理はずいぶん豪快なものだけど，従来の視差を使った投影装置とは違って，本当の意味でのボリューム投影ができるってところで画期的なのかもしれない。
ボリュームのスキャニングに駆動系を利用している都合上，どうしても制限は大きくなってしまう。 zzz online の Arhines 氏も指摘していることだけど，分間６００回転ということは全体で１０ｆｐｓ程度しか出ていないわけで，実際に肉眼で目視するには相当なフリッカと闘うことになるだろう。暗い部屋なんかでやっと像が見える程度かもしれない。とにかく，実用にはまだほど遠いもののようだ。
しかし，初期のテレビもスキャニングに駆動系を利用していたことは有名だし，こういった装置もそのうち何らかの画期的な技術によって電子的な構造へと進化するときが来るのかもしれない。
http://www.google.co.jp/search?q=%83j%83v%83R%81%5B+%83e%83%...
それはきっと，相当楽しいものになるだろうと思う。
2002-05-06
ここに来て新たなデータ構造が必要となった。本来なら，いつも利用しているテキスト形式でもってデータの受け渡しを行うんだけど，テキストで管理するには少し複雑過ぎる構造になってしまったので，ちょっと路線変更して Excel を使うことにした。
適当にちゃっちゃか書式を組み上げてから，ワンクリックで csv 出力するボタンを組み込めば完成。あとはドキュメントを付けて担当者に渡すだけだ。プログラマ側ではこれを python でパースしてバイナリデータへと変換する。
この辺りのお手軽さは，表計算ソフトというコンセプトの在り処を身に染みて体感するところだ。表計算は，データベースとしてはとても初等的なものだけど，誰もが使い慣れているし，設計にもほとんど手間がかからないというメリットがある。やろうとしていることはもっと高等なデータベースと同じなのかもしれないけれど，その手軽さゆえに利用価値があるってことだと思う。
これがもうちょっと本格的なＤＢソフトを使うようになって，データは XML なんかでやりとりするようになれば，ハイブロウなワークフローを構築することができるのかもしれないけれど，そういった方向性を追求すればするほど，どんどん仕事がＳＥっぽくなってくる気がする。もっとも，いまどきのプランナなら，軽くＳＥぐらいの基礎技術は持っていてほしいってのが本音かもしれない。
ひげねこさんの日記なんかにも時折登場する XML spy ，こういうのをプランナさんに使ってもらうことになるのかな。うーむ。
たしか Access のサイトライセンスがあったはずなので，できればそちらを使いたいところでもあるけれど， XML のサポート具合に不安が無いわけでもない……っていうのを僕が調べるのはめんどくさいので，そこを適当にうまくやってくれるプランナさんが居たりすると，やはり嬉しいと思う。
だから，これからはプランナさんもＳＥの時代ってことでどうかひとつ……
2002-05-07
今日中にこれとこれにカタが付いて，明日はこれとこれを……って感じで，脳内スケジュールの練り直し。メンバーの中では比較的楽な方に位置しているようだから，これからはヘルプの割り合いが増えてくるかもしれない。
最近はわりとこまめに Tim Rowley の SIGGRAPH 2002 paper 集をチェックしている。今日は Doug DeCarlo の "Abstracted Image Stylization" がアップロードされているのを発見した。
http://www.cs.rutgers.edu/~decarlo/abstract.html
この手法は，まあいわゆる一種のノンフォト技法なんだけど，面白いのは，イメージの抽象化に人の目の動きを利用するというところだ。
この手法では，まず "eye-tracker" という機器を通して画像を数十秒間見つめてもらい，その期間における観察者の注視点の動きを記録する。そして次にこれを氏ら独自の心理モデルに適用し "fixation" つまり「固着」……「執着」かな？ ともかく，その fixation データってやつを抽出して，画像の部分における重要度を決定する。
ページに掲載されているサンプル画像を見れば分かるんだけど，信号処理的な画一された変換とは違って，絵の主題に近い部分ほどデテールの高められた変換が行われていることがわかる。こういった画像の抽象的な評価を自動で行う手段は，できたとしてもとても難しいものだろうし，ひょっとすると原理的に不可能なことなのかもしれない，とされているらしい。
2002-05-08
なんとか一段落ついたようだ。うーむ，それじゃあ，これからが本気のラストスパートってことで。
暮らしのひと口メモ。香辛料のナツメグは幻覚剤の効用を持つ。
http://members.tripod.com/wooperbrains/artist/mastabe/drug/n...
http://www.everything2.com/index.pl?node_id=134840
全然関係無いけど，最近，職場に置いてある目覚ましが効かなくなってきて困った。機能に欠陥があるわけではないんだけれど，つまり，単に使用者に耐性がついてしまったってだけのこと。もうちょっとやかましいアラームを用意しなくては。
どうせなら，サンプリング音源でアラーム音をカスタマイズできるやつとか，そうやつがいいなあ。どっかにないかな……
2002-05-09
たまには GDAlgorithms-list なんかも見てみる。例えばこんなのとか。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
アニメーションの回転情報を持たす正規化クオータニオンを圧縮したい，って話題。 Bungie の Chris Butcher 氏（Halo の AI 担当）なんかもポロっと登場してたりして，なんだかお得な気分。 cbloom 氏とか Tom Forsyth 氏とかは，ほんといつも登場するね……
ちょっと昔に読んだこれとか役に立つかもしれない。
http://www.oroboro.com/rafael/algorithms/unitv.html
http://www.oroboro.com/rafael/algorithms/unitv2.html
１クオータニオンあたりの情報量はこれで精一杯絞ったとして，あとは信号処理的な問題に持っていくことになるのかな。しかし，そこからデルタ圧縮やら DCT やらに持っていくにしても，最初にクォンタイズしちゃうのはマズいような……どっちかってえと順序が逆だな。
この辺りの処理で手を抜くと，誤差のせいでキャラクタのアニメーションがカクカクしてしまう。特に末端には誤差が蓄積されやすいから（方式にもよるけど），ちょっと油断しただけで指先なんかがプルプルし始めてしまうだろう。
ＦＦＸのカットシーンのアニメーションがカクカクしていたけれど，あれもおそらく圧縮の副作用なんだろうと思う。ああいったゲームのように，莫大な量の素材を扱うプロジェクトになると，技術的には開発途中で改良を加えることが可能だとしても，すでに蓄えてしまったデータを新たに移行させるのが困難だろうと思う。
2002-05-10
なんとなく今日も泊まり。明日は昼間に一度帰宅しよう……
しばらくぶりに Alpha Conspiracy のページを覗いてみる。なにやら動きがあったらしい。
http://www.alphaconspiracy.com/
どうやら Andrew 氏がポップシンセユニット "Iris" に加わることになったそうだ。
さっそくサンプルをダウンロード……うーむ，いいなあ。特に "lose in wanting" はかなりお気に入り。退廃的な詩に気だるげな歌が合って，良い。ちょっと古めのスタイルだけど，そこに惹かれる人は少なくないようだ。 Depeche Mode とかそこら辺の世代とシンクロするみたい。
そんなわけでスパスパっと amazon.com で購入。今回は Standard Shipping 指定にしてみよう。いつもの Expedited Shipping なら１週間程度で届くけど，通販する度に毎回 $15 上乗せさせられるのも，どうもね。
さて何日ぐらいで届くだろうか。
2002-05-11
昼頃起床。ちょっと作業してから帰宅。家でややまったりしてから，また夜に出社。この週末である程度の区切りが付くはずだ。
暮らしの一口メモ。 Virtual Reality は「仮想現実」なら Augmented Reality は「強化現実」もしくは「拡張現実」だ。
http://www.cs.rit.edu/~jrv/research/ar/
個人的には「強化現実」の方が良い。強そうで。
ここらへんとか面白そうだ。
http://www.cs.caltech.edu/~ss/sdraw/
あと，ちょっと前にミキタさんが言ってた "ARQuake" とか，すさまじく良い。
座標情報のトラッキングには GPS を使用するらしいんだけど GPS でそんなに正確な位置情報が取得できるものなんだろうか。当然のごとく処理遅延による現実世界との時間的ずれも生じるわけで，それに座標測定の誤差も重なるとなると，結果はそうとうひどいものになるかもしれない。おそらく，ちょっと小走りでもしようものなら３Ｄ酔いでゲロゲロになってしまうのではないかと思う。
もちろん，そういった諸問題を解決するためにこういった先生方が日夜研究しておられるわけで……そのうちＡＲなサバゲーとかできる時代がくるのかもしれない，と思うと，ゲーマー的には単純に嬉しかった。
2002-05-12
また GDA-ML をチェック。今度は衝突判定ネタ。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
静的なオブジェクトに対する衝突判定はいいとして，動的に変形するオブジェクト（特に人型キャラクタとか）の衝突判定ってどんなもんかね……って話題。 Alex 氏のネタ振りが上手くて面白いスレッドになっていると思う（基本的にはヨタ話だけどね）。
ここで混乱しやすいのが，ボリューム階層 (BV-hierarchy) 系アルゴリズムと空間分割 (Spatial Partitioning) 系アルゴリズムの区別かもしれない。僕もこの２つをどう使い分けたもんだか良くわからないけど，なんとなく， BV の方は衝突判定に， SP の方はカリング，特にレイトレへの応用を前提に研究されてきたものなんではないかなあ，と認識している。
ここで Pierre Terdiman 氏がすすめているのが Kenny Hoff 氏のプレゼン資料だ。
http://www.cs.unc.edu/~hoff/projects/comp236_ta/hierarchy_pr...
実際のアルゴリズムについてはほとんど触れていないんだけど，前知識を付けるにはいいお話だと思う。
2002-05-13
峠は越えた，のかな。むしろここからがプログラマにとっての正念場なのかもしれないけれど。ううむ……。
また GDA-ML をチェック。今度はメッシュネタ。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
ハイポリモデルのデテール部分をノーマルマップ化して焼付けしつつ，メッシュ的にはリダクションできねえもんかなあ，って無茶な要求にみんなで真面目に答えるスレッド。ていうかそれって，それだけで十分売り物になると思うんだけど。
Cohen やら Hoppe やらがそんなことをしていたような気がするけど，しんどいので調べないでおく。メッシュ怖い……
途中から Peter-Pike Sloan （"Precomputed Radiance Transfer ..." の人）なんかが参加してきて面白いことに。ていうかこの人，なんで GDA-ML とか見てるんだろう。
実力と努力がまったく追いついてなくて情けないんだけど，説得力が無いのを承知で勝手な事を言うならば，えーっと， "Precomputed Radiance Transfer ..." に代表されるような，光の伝播をもうちょっと正確に表現しようって試みは，これからリアルタイムＣＧの表現力を向上させる道程の中において非常に重要な役割を果たしていくと思う。
バンプマッピングや BRDF のような反射モデル／マテリアル表現の技術は，それ自体決して欠くことのできない要素ではあるけれども，これはそろそろ十分なレベルに達しそうな気がする（他の技術と比較してって話だけども）。
グローバルイルミネーションのサンプルなんかを見てよく感じるのは，たとえマテリアル表現の無い（拡散反射のみの）レンダリングでも，光の伝播が正しく表現されていれば，それをリアルと感じることができるということだ。その逆が成り立たないことは，面白い対比だと思う。
っていうか，ＧＩとまでは言わぬまでも，まずは影表現をなんとかしないとなあ……
2002-05-14
本当はとんでもなく忙しいはずなのだけど，なぜか穏やかな一日。止まりそうになっていたガスの料金を払いにガス屋の営業所まで行って，会社の健康診断を受けて，体重を計ったり血を抜かれたりして，地味にデバッグ作業して，夕飯を食いに行って……信じられないほど平和なシーケンスに物足りなささえも感じる。
帰り際にようやくタスクがたまり始めた。明日からはまた忙しい日々になるかもしれない。でも今日のところは，とりあえず帰宅しておくことにしよう。
そんなわけで，ちょっとまったりする隙ができたので，この機会に Wiki の導入なぞを検討してみたりした。
http://www.factage.com/sng/pukiwiki/
Wiki は本来ディスカッションツールの一種として考案されたものだけれど，その「手軽にハイパーテキスト群を生成することができる」という特徴は，本来の用途とはまた別の用途を生み出しているように見える。 Wiki を使えば，ウェブブラウザ以外の特殊なソフトを一切使用することなく，動的なハイパーテキスト群を構築し，それをパブリックにするまでの手順を簡単に実現することができる。
僕は，僕自身が考えていることや感じたこと，それから単なるメモとか，そういうあやふやな思考を少しでも整理して記憶にとどめるために，この文章を書き連ねている。しかし，僕はもともと文章を書くのが大の苦手なので，思考を整理することよりも文章をまとめることに苦心してしまうことがある。また，まともな文章にすることさえもできないような下らないことを記すことができないばかりに，ネタを取りこぼしてしまうようなこともあった。
だから， Wiki を試してみるのはどうだろうか，と思ったのだ。 Wiki なら，不完全な思考の断片群をなんらかの形にまとめることができるかもしれない。少なくとも，今の「日記」っていう，むりやり時系列化された文章スタイルよりも要求に適しているような気がする。
でも，日記ってのは，毎日書かなければいけないっていうルールに最大のメリットがあるんだけどね。そのルールがあるからこそ，積極的に文章を書く姿勢と，駄文でも良しとする適度な妥協線を設けることができるのだと思う。少なくとも，自分の場合はそうだ。
Wiki にした場合，そこら辺の折り合いはどうつけたものだろう，と思う。
2002-05-15
そんなわけで，各種 Wiki の吟味をしてみる。ちなみにオリジナルの Wiki はここ。
http://c2.com/cgi/wiki?WelcomeVisitors
エクストリーム手法の下地となったのがこの Wiki だったらしい。ディスカッションツールとしての Wiki は，変更個所が見分けにくかったり，議論が散漫になりがちだったりと，多くの欠点を抱えていると思うんだけど，その極端なコンセプトがエクストリームに繋がる考え方だったりするのかなあ，と思う。
Wiki クローンのうち，最も有力なのは TWiki のようだ。
perl で書かれたスタンダードな Wiki 。機能は豊富で拡張性も高く実績も十分。普通に選ぶならこれになるんだろうと思う。
日本語対応を気にするならば PukiWiki か YukiWiki 辺りがいいかもしれない。
http://www.factage.com/sng/pukiwiki/?FrontPage
http://www.hyuki.com/yukiwiki/
PukiWiki は開発に勢いがあっていい感じ。無難に済ませるなら YukiWiki でも十分だと思う。なんとなく結城氏のバリューもあって人気があるみたいだ。
で，これらの Wiki はすべて perl で書かれているんだけれど， Ruby や Python を好むのならば，別の選択肢も考えうるだろう。
http://www.todo.org/cgi-bin/jp/tiki.cgi?c=v&p=WelcomeVisitor...
Tiki は Ruby で書かれた Wiki エンジン。 MoinMoin （変な名前だ……）は Python で書かれた標準的な Wiki クローンだ。
と，ここまで一通り挙げておいて，結局のところ MoinMoin を選ぼうと思う。こういうのは自分好みにモディファイすることを前提にして使うもんだから，やっぱ使い慣れた環境じゃないとね。 MoinMoin は他の Wiki クローンに比べるといくぶん拡張が地味なんだけど，まあそこは妥協することにしようと思う。どうせヘビーには使わないだろうし。
Wiki では「連続する文字列の中に２つ以上の大文字を含む単語」を "WikiName" として，自動的にハイパーリンク化する。彼らはこれを "NerdCaps" と呼んでいるようだ。
http://c2.com/cgi/wiki?NerdCaps
ふーむ，しかし， Wiki で関数のドキュメントとか作っていると，関数名が勝手に WikiName になってしまってうざい……いやむしろ便利なのかこれは。ともかく，便利なんだか不便なんだか，正解なんだか間違ってるんだか，わけのわからないところが Wiki の Wiki らしいところではあるんだけども。
2002-05-16
GDAlgorithms-list が，にわかに Bounding Volume / Spatial Partitioning 関連の話題で盛り上がっている。自分でもつい最近まで取り入っていた分野だけに，なにげに面白い。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
適当に読み流してみると，途中で dPVS というライブラリのことが幾度となく話題にのぼっている。
http://www.hybrid.fi/dpvs.html
dPVS は高速かつ高精度な可視判定を提供するライブラリ。フィンランドは Hybrid Graphics 社の製品だ。単体で可視判定のみを提供するライブラリってのも珍しいような気がするけど，産業向けなんかには良くあるもんなのかなあ。とりあえず，開発者の間での評判は悪くないようだ。
ちなみに，ここのリードプログラマである Ville Miettinen 氏は，フィンランドの超有名グループ "CNCD" の元メンバー。あの "Inside" の作者でもあるらしい……ううむ，さすがは達人の地フィンランド。
BV 関連のスレッドに登場していた Andrew Zaferakis 氏の論文が面白そうだ。
http://www.cs.unc.edu/~andrewz/
"Fast 3D Geometric Proximity Queries between Rigid and Deformable Models Using Graphics Hardware Acceleration" は Andrew 氏が Kenny Hoff 氏の元で研究していた題目のひとつで，グラフィックハードウェアを活用した衝突判定……この論文では特に２物体間の最短距離について，を考察したものだ。基本的には外部ボロノイ領域による分割を利用するもので，３Ｄグリッド上に "Distance Field" を展開して（ここまではＣＰＵ処理）そこから画像処理的な手法によって衝突を求める（ここがＧＰＵ処理）というもののようだ。ただ，まだほとんど読んでいないので詳しいところはわからない。それに，ちゃんと理解しようとするならば，氏のそれ以前の研究についても理解しておく必要があるだろうと思う。
2002-05-17
いつものように GamingAgeForum を覗いていると，面白そうなスクリーンショットを見つけた。謎の Xbox タイトル "Duality" だ。
http://gamespot.com/gamespot/filters/products/screenindex/0,...
ゲームの内容はなんとなくメタルギアっぽいんだけど，僕が特に注目したのはそのパンキッシュなビジュアルコンセプトだ。視界を一面に埋め渡す鉄とコンクリートの壁。人の気配をまったく感じさせない空虚な巨大要塞。アイアンパンク，なんて単語は聞いたことないけれど，もしそんな語彙があるとしたら，まさにぴったりのビジュアルかもしれない。
こういった空虚な建造物のなかにひとりぼっちで放り込まれる感覚は "ICO" のコンセプトに近いものが感じられるかな，と思う。昔の宮崎駿みたいな感じ，ってったらひどくいいかげんなものの言いかたかもしれないけれど，まあそんな感じ。
ところで，この "Duality" を制作している Phantagram 社は，韓国を代表する有名なゲームメーカーだ。
http://www.phantagram.com/e_about_1.html
そういえば "Zyclunt" なんてゲームもあったなあ，って思い出した。あの頃は韓国製だというだけで意外性を持たれていたものだけれど，今では韓国発のＰＣゲームも決して珍しい存在では無くなってしまった。特にネットワークゲーム分野での成長はめざましいものがあるけれど，その一方で少々ネタ詰まりな雰囲気も醸し始めている。今後数年間でどのような変化が遂げられるのか，そこが楽しみだと思う。
ところで「なんとかパンク」ってジャンルのつけかたはなかなか便利だけれど，元の定義ってなんなんだろうと思って，ちょっと調べてみた。こういう言葉に定義を求めること自体が無意味なことかもしれないけれど，そこをあえて言葉で説明するならば，こんな感じになるんだろうと思う。
http://www.everything2.com/index.pl?node_id=102120&lastnode_...
「テクノロジーの急速な発展によって引き起こされる文化的衰退」ってのがポイント。２０世紀に人々が見ていた未来そのものの具現なのかもしれない。でも，もう，今なんて，１０年後の未来も今とそう違わないだろうみたいな悲嘆が普通にあるわけで，そのうちサイバーパンクなんていう表現手法もすっかり陳腐なものになるんだろうと思う（ていうか今でも十分陳腐だってばさ！）
結局のところ，ブレードランナーみたいな未来がくるわけでもなくて，５０年後の未来も，今と同じく中途半端にぬくぬくした無刺激な日常が続いているんだろうなあ，って思うのは，庶民ゆえのおろかなものの考え方なんだろうか，って，思ったりした。
2002-05-18
GdAlgorithmsList のスレッド "Projecting a bounding box to screen space fast" より。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
ここで Christer Ericson 氏が関連論文として挙げたのが，これ。
http://www.acm.org/jgt/papers/SchmalstiegTobler99/
ftp://ftp.cg.tuwien.ac.at/pub/TR/99/TR-186-2-99-05Paper.pdf
バウンディングボックス，特に OBB をスクリーン座標系上に投影した際に占める面積を高速に求めるための手法だ。 OBB の場合，スクリーン投影した「シルエット」は，前１面だけが見える場合と，２面が見える場合，３面が見えている場合，の３種類に分けることができる。この場合分けは，立方体の６面８点により分割される２６個のボロノイ領域について固定的に割り当てることができる。あとはそこらへんの情報をテーブルに持たせるようにしてしまえば，投影する頂点の数を最小限に抑えつつ，形状の特定までできてしまう，というもの。
これは小ネタだけれど，役に立つ機会はありそうだ。バウンディングボックスがスクリーン上で占める面積の情報は LOD の決定に役に立つだろうし，バウンディングボックスのスクリーン投影だけとってみても，可視／遮蔽判定なんかに使えるところがありそうだ。例えばビームツリーの構築とか，そこらへん。
謎ＯＳ＆謎言語 "Oberon"
言語的には Modula-2 の末裔に当たるもので，それに OOP のエッセンスを加えた感じになっているらしい。
Oberon は，単体での処理系の他に，専用の実行環境 "ETH Oberon System" を持っている。これは，シングルユーザ，シングルスレッド，マルチタスキング OS であったオリジナルの環境に GUI と永続化オブジェクトの機構を加えたもので，高いモジュール性とデータ抽象化を実現したシステムに仕上がっている，とのこと。
Oberon はもともと ETHZ 研究所のローカルなハードウェアをターゲットとして作られたシステムだったらしい。んで，そのままなら普通によくある話として終わるはずだったんだけど，なんだかとにかく PC に移植してしまったらしい。ここから急に話が面白くなってくる。
Oberon のホームページからは， PC 上で動くネイティブな Oberon システムと， Windows もしくは Linux の HDD パーティション内に寄生するタイプのネイティブ Oberon システム（パーティションの再分割が必要無いのがメリット），それに，ホスト OS の上で動くプラグインタイプの Oberon システムなどを入手することができる。意外に充実したラインナップだなあ。 Mac 用や Amiga 用（！）なんかもあるらしいし。
僕はこういったマイナー環境が醸し出すエキゾチックな匂いに弱いのかもしれない。本当に真面目に取り組む勇気もないのに，つい興味だけが先行してしまう。んでも，売り文句が本物なんだったら，ちょっとはいい勉強になるかもなあ……
暇があったらやりたいことのスタックに，またひとつ，これを積みあげておこうと思う。
2002-05-19
いつもの夕方出勤。わりとゆったりとした始動だけど，少し忙しくなるかもしれない。 E3 が始まる前に済ませておかないといけないことが，少なからずあるからだ。
SF 愛好家のためのポータルサイト "The Infinite Matrix" 内の１コーナー "Schism Matrix" は，サイバーパンクの始祖であるところの小説家 Bruce Sterling のウェブ日記だ。
http://www.infinitematrix.net/columns/sterling/
ううむ，知らんかった。読むか。
Bruce Sterling についてのおさらいはこちら。
http://www.everything2.com/index.pl?node=Bruce%20Sterling
そういえば，最近めっきり SF を読まなくなったなあ。読書の時間が全然無いんだ。たまには活字にも触れなければ……
ところで everything2.com はわりとよくリンク先として使うんで InterWiki 機能（サイト間リンクを実現する WikiName のこと）に加えておくと便利かもしれない。それほど難しくなさそうだし，今度ちょろっと試してみようと思う。
2002-05-20
いよいよ正念場ってことなんだろうと思う。しかし，まだ壁は高いように見える。そろそろバグを取ることに全力を注いだほうがいいと思うんだけど，いまだその明確なターニングポイントが見えていないようだ。僕は純粋なミニマリストだから（うへっ），こういう駆け込み的なコンテンツ詰め込み作業は，しんどいとかつらいとかそういう以前に，生理的に後ろめたいものを感じる。
いや違う違う，ただの怠慢。
DVD の製作作業にはエアダスタースプレーの存在が欠かせない。
http://www.sanwasupply.co.jp/product/syohin.asp?code=CD-22EC...
DVD-R メディアにほんのちょっとのホコリが付着しているだけで書き込みに失敗してしまうことがあるからだ。書き込みに失敗したメディアの表面を見てみると，視認できるほどのシミができていることもある。
こういった些細な事故を防ぐためにエアダスターが必要になる。メディアの表面に付着した埃をエアで吹き飛ばすのだ。 DVD for general のメディアは単価が高いから，そうそう無駄にするわけにもいかないってわけ。
ところで「 DVD を焼く」っていう成句はいかにも日本語っぽい響きを持っているけれど，英語圏でも "burn" という動詞を使うから，実際は外来語のようだ。
http://www.everything2.com/index.pl?node_id=665492
2002-05-21
いよいよ E3 が始まろうとしている。ネット上では早くも画像やら動画やらの流出が始まっている。大きな企業になるとショー前にプリカンファレンスみたいなものを決まって開催するので，そこでの情報が漏れ始めている，ってことみたいだ。 GC の値下げも発表されたことだし，主要な情報はショー前にほとんどネタバレしちゃってるんじゃないかと思う。
個人的には，マリオとゼルダに驚愕。
http://www2u.biglobe.ne.jp/~nanko/e32002/205mario.html
http://www2u.biglobe.ne.jp/~nanko/e32002/204zel.html
やっぱり任天堂なんだよなあ……って，途方もなく大きな存在を再認識した感じ。追いかけていることを意識している限り，それを追い抜くことはできないと感じる。
それはそれとして，値下げしたらさっそく買おう……あ，いや，マリオ出てからでいいや。
Andrew Zaferakis ていうかむしろ Kenny Hoff の "Fast 3D Geometric Proximity ... Using Graphics Acceleration" を読んでみているものの，まったく内容が飲み込めないでいる。どうやらこの論文の内容は Kenny Hoff のそれ以前の研究を下地にしているようで，多くの部分がそれに依存しているように見える。
Kenny Hoff はこれ以前に 2D ベースでハードウェア衝突判定を行う手法について論文を書いているんだけれど，それのさらに下地となっているのが "Fast Computation of Generalized Voronoi Diagrams Using Graphics Hardware" だ。
http://www.cs.unc.edu/~hoff/papers/voronoi/voronoi.pdf
この論文では，グラフィックハードウェアを活用してボロノイ領域への分割を高速に行う方法について述べている。おそらくここがスターティングポイントなんだろうと思う。
正直なところ，このハードウェアを活用した衝突判定手法にはそれほど興味を持っていたわけでもないんだけれど，最初の文献を見ただけじゃ評価も何もできないんで，少しムキになって調べてみている。そのうち飽きてやめるところまで，適当に続けてみようと思う。
2002-05-22
amazon.com からの届け物を受け取るべく，不在通知を片手に郵便局へ出向かった。 Amazon で言うところの "Expedited Shipping" だと宅急便で送られてくるんだけど，今回は "Standard Shipping" を選んだので郵政省メールだ。たしか注文したのが５／１０の辺りだったから，だいたい１０日ぐらい経ったってことかな。 Expedited Shipping でも７，８営業日，つまり２週間ぐらいかかっていたはずだから，両者の輸送方法における所要時間にほとんど違いは無いようだ。つまり Expedited の方がお金を多く取られるだけってこと。次からも Standard を使うようにしよう。
荷物の中身は Iris の "lose in wanting" と "disconnect" 。ＣＤ２枚だけのくせしてＡ４ぐらいの大きさのカートンに入れられていた。大げさだなあ。でも，ヒビの入っていたＣＤケースの代わりにおまけのケースが添付されていたりして，総じてサービスはいい感じだ。
んで，ＣＤの内容もとても良い。特に "disconnect" の "annie, would i lie to you" がお気に入り。かなり初期の曲みたいなんだけど，少々安っぽいながらもポップなアレンジと，それに流れるように乗っかるボーカルが小気味良くて，気持ちいいと思った。
http://home.austin.rr.com/mmorris/Pages/facts-lyrics.html
ちなみにこの曲はアパートのキッチンでレコーディングしたんだとか。ふむ……
http://home.austin.rr.com/mmorris/Pages/facts-FAQ.html
郵便局は電車で二駅先にある。もちろん，家の近くに郵便局はあるんだけれど，集配局じゃないから荷物の受け取りをするには手続きが必要だ。そこらへん，なんだか面倒くさいので，いつも二駅先の郵便局まで直接受け取りに行くようにしている。
往復する電車のなかで "Fast Computation of Generalized Voronoi Diagrams" を軽く読み流す。これはつまり，デプスを点からの距離と対応させるようにすれば，デプステストでもって「最も近い点から生成されたフラグメント」だけを残すことができるわけで，結果的にボロノイ図を生成することができる……ってことらしい。
あとは「デプスがプリミティブからの距離に対応するような立体」をどのように構成するかというところに工夫が求められることになる。ここで工夫を凝らせば，点だけでなく線分や多角形をベースとしたボロノイ図，つまり「一般化ボロノイ図」を生成することもできる。スライスへの投影を使えば，３Ｄのボロノイ図を展開することもできるということだ。
ただ，ここら辺の詳細はあまり面白くなさそうなのでパス。実装するには必須だけれど，この手法の本質とはまた違う問題なので，適当に流しておくことにしようと思う。
2002-05-23
詳しい事情はよく分からないけれど，今日が一応の区切りとなるらしい。早朝，サーバーがミラーリングプロセスによって停止させられる時刻のぎりぎりまで，みんなで黙々と作業していた。僕も最後にちょっと気になったところを手直ししてコミット。最近はさすがに cvs が重くなってきたなあと感じる。次はメインファイルサーバとプログラマ専用サーバを独立させるべきかもしれない。ともかく，僕の今日の作業はこれでおしまい。明日からはまた集中的なデバッグ作業が始まるに違いないだろう。だから，とりあえず今の所は，寝袋の中でささやかな休息をもらうことにしようと思う。
ABA さんの Bullet ML 式斑鳩シミュレータ「業平」を SDL / C++ 化した「業平・ネイティブ版」
http://user.ecc.u-tokyo.ac.jp/~g940455/wp/narihira/
C++, generics, SDL, boost, XML ... その他もろもろと，今まさに調べようとしているネタの集大成のようなものだ。かなり感動，むしろ超萌え。これを教材に勉強するのだ。てういか，ゲームのプログラミングって，人や環境によってここまで違うもんか，って感じ。うーむ，これはこれは……
shinichiro さんのページには他にも面白いネタが盛りだくさん。これをベースに色々と可能性を試していきたいと思う。
今のプロジェクトの完遂もようやく現実的な話になってきた。当然ながら，次のプロジェクトに関することもぼんやりと考え始めている。実際にプロトタイピングに突入するまでに，この付近の話題を自分なりに消化しておきたいんだけど，間に合うかどうか微妙なところ。慣れない概念を把握しきれないまま無軌道に導入して自爆するようなパターンだけは避けたいから，あらかじめ十分な吟味を行っておきたいものだと思う。
結局，いくら教訓を得たところで，教訓とはアンチパターンでしかないので，消去法が１ステップ進んだだけのことなのかもしれない。つまり１００の選択肢が９９に減っただけのことだとしたら，ずばり正解そのものを知っていることと比べて，どんなに役に立たないことだろうと思う。
そんな考え方，悲観的過ぎるだろうか。
2002-05-24
とても暖かい日。空は少し曇り模様だけれど，ねっとりとした日差しがしたたかに気温を上げているようだ。時折吹く湿り気を含んだ風が肌に心地良い。もう５月もおしまいだし，これから雨の多い季節になるんだと思うと少し憂鬱だけど，しばらくの間は今日みたいな気候が続くみたいだ（家にテレビが無くたって，天気予報ぐらいは毎日見てるんだ）。
そんなわけで，半袖のポロシャツでさっそうと出社。今忙しいおかげで今年の夏は少し余裕ができそうだし，そう考えるとなんだか嬉しい気分になってくる。気象庁によれば今年の夏は暑くなるみたい。上等，夏は暑くなきゃいけないもんだ。さあ，カモン，夏。
Ramamoorthi の "Frequency Space Environment Map Rendering" をバインダに挟んで持ち歩いているものの，なかなか通読することができないでいる。数値解析的な話に入るところで，いつも眠くなってしまうのだ。この論文の内容はパッと見で印象付けられるようなものではないために，興味を持続することができないんだと思う。もうちょっとデモの出来が良ければ夢中になったのかもしれないんだけれど。
http://www-graphics.stanford.edu/papers/freqenv/
この論文では Ramamoorthi 氏お得意の SH ベース手法を利用して任意の遠距離照明環境と任意の BRDF の組み合わせを実現する方法について述べている。あ，でも，ちゃんと読んだわけではないので，「述べているようだ」ってとこ。
同じようなことをやろうという試みは，今までにも既にいくつか存在する。例えば Kautz の "Unified Approach to Prefiltered Environment Maps" とか Latta の "Homomorphic Factorization of BRDF-based Lighting Computation" とか，そこらへん。
http://www.cs.ubc.ca/~heidrich/Papers/RW.00_2.pdf
http://www.fh-wedel.de/~ko/Data/Pub/pub_02_01.pdf
前者の方法は環境イメージに対してあらかじめフィルタを施しておくことで反射成分の分散を表現しようというもの。この方法はランタイムのコストが安いというメリットがあるけれど，表現の幅に制限があるのと，フィルタリングに莫大な時間がかかるという問題がある。後者のは "Factorization Method" とか呼ばれている類の方法で，高い可能性を秘めているものの，全般的な BRDF に正確かつ高速に適用できるような理想的な解析方法はいまだ編み出されていないというのが現状のようだ。
そんな中 Ramamoorthi は件の論文で SHRM (Shpherical Harmonic Reflection Map) を使うことでより理想的な BRDF 表現が可能になるとしている。んで，肝心の部分が読みきれていないんで詳細は分からないんだけど……とにかくフィルタリングが早くてデータがコンパクトで精度も高いらしい。ううむ，本気かな。ただし，今回の方法は等方性 BRDF に限られるみたいだ。
まあそんな感じで，僕の集中力が保てなくなってきたので，このネタはこれでおしまい。また BRDF がやりたくなったら読み直すことにしようと思う。まあ結局のところ "SHRM" って用語がこの論文における一番の収穫かもしれない。これでもう "Irradience Mapping" とか「球面調和基底で係数がほにゃらら」とか，そういういまいちまどろっこしい表現をする必要も無くなり "SHRM" 一発で通るようになるかな，と，そういうこと。
2002-05-25
Todd Veldhuizen の "Expression Templates" を読み返しながら， EE の VU0 を使ったベクトル・マトリクス操作をテンポラリオブジェクトを介すことなく実現するインライン関数を作れないかなあ，と，しばし妄想してみた。
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/expr...
しかし，わりとすぐにあっさりと諦めた。できないことはないけれど，とてつもなく無駄くさいコードになりそうだ。やはりここは素直に Dylan の VU0 inline patch に頼るのが正解なんだと思う。
http://www.google.com/search?q=dylan-gcc-patch
そういえば，北米での PlayStation2Linux の出荷が開始されたようだ。公式のコミュニティサイトも立ち上げられている。
http://playstation2-linux.com/
SourceForge ベースのシステムで，自由にプロジェクトを登録することができるようになっているみたいだ。日本のサイトよりも数段アグレッシブな構成になっていると思う。さっそく gcc3.x の導入プロジェクトや，最新の Linux kernel を移植するプロジェクトなどが立ち上げられている。
http://playstation2-linux.com/projects/gcc/
http://playstation2-linux.com/projects/xrhino-kernel/
ps2gl もあれから進化しているようだ。
http://playstation2-linux.com/projects/ps2gl
新しい ps2stuff ライブラリは，国内では metalogic の「ふくごん」さんが試していた方式（専用の DMA バッファを固定的に確保して速度低下を防ぐ）を利用して，ネイティブレベルの描画速度を実現しているようだ。
まあ，まだ立ち上げ段階なんであまりパッとしないけれど，もう少し時間が経てば面白いものも出てくるかもしれない。
Kenny Hoff のハードウェア衝突判定に関する論文をざざっと流しで通読。わりと冗長な内容なんで，ハナからいいかげんに読むのが正しい方法なのかもしれない。
"Fast Computation of Generalized Voronoi Diagrams" にある方法を使えば，フレームバッファ上にボロノイ図を高速展開することができるんだけど，この時点でのデプスバッファには，平面上の任意の点から最も近い "feature" （「突起」とでも言えばいいんだろうか）に対する距離を示す情報が含まれている。また，ボロノイ図の展開と同時に，その feature に対する方向ベクトルや，オブジェクトの ID を示すようなコードをフレームバッファに埋め込んでおくようにすれば，もっと高度な近接情報 (proxymity information) を得ることができる。つまり，フレームバッファとデプスバッファを近接情報の LUT (Look Up Table) として使うわけだ。 Kenny Hoff らはこれらを総称して "Distance Field" と呼んでいる。
と，ここまでが "Fast and Simple 2D Proximity Queries Using Graphics Hardware" の内容。ここから 3D への拡張もあるんだけれど，そこは単に 3D を 2D のスライスによって処理するという，ずいぶん無理矢理な解決法でうっちゃっているみたいだ。まあでも，その豪快っぷりがいまどきの考え方っぽくてかっこいいのかもしれない。
jiro さんからこの件についてコメントを頂いた。ありがたいことです。いつのまにか spin の topic でも取り上げていたんだなあ。気付かなかった……
徐々に Wiki の導入を始めてみている。
http://www.radiumsoftware.com/wiki/moin.cgi
まだあくまでも個人的メモとしての利用にとどめている。むしろずっとそうかもしれないけれど。
2002-05-26
いつもの感じで夕方出社。雨が降ってきそうな空模様だ。でもめんどいので手ぶらで出発。
職場のボスが E3 から持ち帰ったビデオだのチラシだのを見せてもらう。要注目アイテムは体験版付きの "Ratchet and Clank" と "Sly Cooper" 。最近の SCE はどこでも体験版バラ撒きまくりだ。果たして，その効果は疑わしいところだけれど……
北米リージョンのソフトが動く環境を適当に揃えてさっそくプレイ。どちらもそれなりに良く出来ている作品だと思うけれど，個人的には Ratchet and Clank の方が好みだ。十数種類の武器やアタッチメントを駆使しつつ，撃ちまくり跳ねまくりの痛快アクション，って感じ。単純にイドに訴えかける要素がある。洋ゲーはこうでなきゃ，って思う。
逆に Sly Cooper の方はかなりストイックな内容。ギミックの凝り具合はなかなかだけど，少しバランスがシビアな気もする。基本的に一撃死，敵に見つかったら即ち死亡，ってゲーム内容。まあ，そういうコンセプトなんだろうと思うけれど。
他の作品で特に目を惹いたのが，セガの "Shinobi" 。主人公は首に長い布帯を付けているんだけれど，こいつの挙動がやたらヒラヒラしていて面白い。ここまで過剰に演出が入っていると，故意にこう作ったんだなあってのが傍目にもわかって，プログラマ的には本望かなあ，と思う。まあ，そういう雰囲気作りはなかなか良さげ。アクションでもだいぶ楽しませてくれそうだし，かなり期待できそうだ。
逆にちょっと心配だったのが GC のスターフォックス。キャラクタがフォックスだという以外に「スターフォックス」を感じさせる要素に乏しい，という点に疑問を感じさせられる。まあそういう方向転換もありなんだけれど，それでいて前作っぽい３Ｄシューティングシーンは入っていたりと，コンセプト作りに迷いを感じさせられる部分が多い。特に，シューティング部分はそれだけで単体のゲームになるんじゃないかってほどの作りこみようなんだけれど，そうやって２倍近くの労力を費やして１本のゲームを作るってのは，だいぶ割に合わない話だと思う。
いや，割に合わないんですよ実際。
業界の全体的な視野に立ってみれば，大作の存在ってのも欠かせないものなんだろうけれど，個人的には，１本の大作を狙うよりも，もっと多くの作品に関わることで，より多くの経験を積めたらなあ，と願っている。１本の作品に２年は長いと思うし，本当は１年１本ぐらいでコンスタントにポンポン行くのが面白そうなんだけれど……現実的なものの見方をするならば，やはり１８ヶ月から２年半ぐらいが現実的なスパンなんだろうなあ，と思う。
そんな中， Factor 5 の "Star Wars Rogue Leader: Rogue Squadron II" が，事実上たったの９ヶ月で制作されたという事実は，紛れもなく偉業だったのだなあ，と感じさせられる。
http://www.gamasutra.com/features/20020501/engel_01.htm
本体発売前の立ち上げ時期だったにも関わらず，これだけのスピード開発を成し遂げたということは，いやがおうにも「ＧＣは開発しやすい」という説を裏付けることになるのかなあ，と思う。まあ，続編だしノウハウは十分に蓄積されていたので，作るのは全然楽だったってのはあるんだろうけれど，ちゃんとノウハウを活かす努力をしたからこそ開発期間を大幅に短縮することが可能になったわけで，やはり学ぶべきところは多い実例だと思う。
2002-05-27
昨日から泊まり。今日もたぶん泊まり。バグ直しを手伝いたいんだけれど，自分の手で直すことのできないバグがあまりにも多過ぎる。無理矢理変更を加えることによってバグを増やすわけにも行かないし……
ところで，下手な変更によってバグを増やしてしまう行為を「エンバグ」と称することがある。いかにも外来語っぽい響きだけれど，実際に「エンバグ」に対応する英単語は存在しない。いわゆる和製英語だ。
Boost の "Generic Programming Techniques" を読む。一生さんのページからの流れで，なんとなく。
http://www.boost.org/more/generic_programming.html
http://www.issei.org/programming/
読んでいる途中で，もしかして，普通に C++ もままならないのに，いきなり generics に手を出そうとしていること自体が間違ってるんじゃ……って気になってくる。 Traits を使ったディスパッチング処理の辺りなどには軽い目眩さえも感じる。確かにここまでやれば静的な型付けと静的なリンクがベースであるところの C++ でも汎用化が可能になるわけなのかもなあ，と，ちょっと納得。
僕は， C++ を導入するくらいだったらいっそ VHLL （超高級言語）で，みたいな考え方で長い間やってきたから，最近の C++ のパワフルな動きには軽い驚きを禁じえない。特に部分特化を備えたテンプレートの働きには，それ自体で新たな言語系の存在のようなものを感じさせられる。ていうか難しいな，これ。 C++ のクラスや関数は first-class object ではないから，汎用化を進める過程でどうしても「概念上存在するだけのオブジェクト」みたいなものが登場してくるんだけれど，この空を掴むような存在をどうイメージしたらいいものか，よくわからない。
思えば Python の pickle などは，恐ろしく過激かつ奔放な汎用化の例だったのだなあ，と振り返る。
http://www.python.org/doc/current/lib/module-pickle.html
ただしこの例は，とてつもないランタイム負荷を代償としている。やはり最後に頼りになるのはC++ だという思いには変わりがない。ただ，どちらの方がより自分らの開発スタイルに合っているのかという点については，もう少し深い評価が必要だと思う。
2002-05-28
相変わらず GDAlgorithms-list をウォッチング。最近盛り上がった話題２件。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
地形オブジェクトのライティング処理はどうしたもんかねえ，みたいなダベりスレッド。最近はハードウェア側の性能向上が著しく，この辺りで実現可能な技術レベルもしょっちゅう変化することになるから，度々こういった話題がトピックとして上がってくるようだ。ここでは， E3 で話題になったばかりの Doom III 方式，つまり "All dynamic lighting" ，もしくは「ベタ焼き込み」方式，あるいは……？ みたいな話の流れになっている。 Bungie の Chris Butcher 氏は SH ベース方式にご執心なようだけれど， cbloom 氏はそれに対して否定的。 SH 係数を低レートに圧縮すれば，ってアイデアは面白いけれど，誤差が酷くて使いものにならないかもしれない。色彩成分を限定する方が現実的だと思う。
自分で難しいことを考えるのは疲れるんで，こういった方々が自分の考えを主張しながら盛り上がっているのを傍目から見るのは，すごく楽しいし，実際のところかなりおいしいことだと思う。こういった場で出てくるような「生の」アイデアは，あまりにも粗野でそのまま実地に活かすことはできないんだけれども，試行錯誤の期間を縮めるためのいい材料にはなるのではないかと思う。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
遮蔽判定に関するスレッド。ちなみに "Laissez Faire" は「自由放任主義」のことだ。
http://www.everything2.com/index.pl?node=laissez-faire
この辺りは意外とみんな苦心している話題のようで，なかなかの盛り上がりを見せている。結局の所，現在優勢になりつつあるのはハードウェアを利用した遮蔽判定のようだ。そういった手段が使えないシチュエーションにあるならば，ビームツリーベースの遮蔽構造や，このスレッドで例に挙げられたような quad ベースの遮蔽リストなどが役に立つかもしれない。しかしもちろん，ハードウェアの恩恵を受けることのできる立場にあるのならば，それを使うに越したことは無い，ということだ。特に，ソフトウェアベースでラスタライズ遮蔽判定，すなわち "coverage buffer" みたいなものを実装するのは，結局のところ速度面から見てだいぶ効率が悪く，決して薦められない，とのこと。まあそりゃそうだなあ。
そんなわけで NVIDIA の遮蔽判定拡張なんかも試してみたいんだけれど，ビデオカードがなあ……。 NVIDIA といい Matrox といい，ビデオカードはどんどんでかくなる一方で，夢のファンレスＰＣ構想は遠のくばかりだ。 GeForce3 級でいいからもっと小さくしてよ，って，切実に願う。
2002-05-29
徐々に終着点が見えてきたような気がする。バグの数も，やっとのこと増加から減少に傾いてきた。いまだ不安な点は残るものの，仕上げ段階に入ったという確かな実感を得ている。あとはひたすら修正作業を急ぐだけだ。
Impress Game Watch より "Unreal Tournament 2003" のプレビュー記事。
http://www.watch.impress.co.jp/game/docs/20020527/ut13.htm
ゲームの内容はさておき，草のモデリングが面白いと思った。よく雰囲気出てるなあ，これ。たぶん見た目よりも少ないポリゴン数で構成されていると思うんだけど，どんな形なんだろう。草の末端が必ずつながって半円状になっているのが，なんだか怪しい。ふーむ……
なんとなく Gamasutra の Postmortem を読みかえしてみている。
http://www.gamasutra.com/features/20011027/imlach_02.htm
Wayne Imlach 氏はこの Startopia の Postmortem で "Code Ownership" の欠如が開発進行の妨げになった，と記している。つまり，コードを複数のプログラマ間で共有するよりも，それぞれのコード執筆者に対して強い所有権と管理義務を与えたほうが良い，とする考え方だ。例えば，ある他人のコードに少量の変更を加えれば自分の目的を達成することができると判明していたとしても，あえてそのコードの管理者に改変を行わせるようにした方がいい，としている。
これはなかなか微妙な問題だと思う。この例とは逆の「コードの共有化を強く推し進める」という方向性にはある種の正当性が感じられるものの，実際にはモジュラリティの破綻を招く結果に終わる傾向があるように感じられる。書式や方法論をがっちり統一して，プログラマ全員で完璧なコラボレーションを実行する，なんて方法もぼんやりと考えたことがあったんだけれども，冷静に考えると，うまく行く見込みは限りなく小さいように思われる。やはり管理権限を固める方が無難だろう。
まあ，そんなわけだから，いくらヤクザなゲーム屋稼業といえども，コアタイムにしっかり就業するってのは大切なことなんだろうねえ，ってこと。改善案を提示したメールの返答を翌日まで待たなきゃいけないような状態は，ちっとも効率良いとは思えない。
2002-05-30
昨日から泊まり。今夜はまた忙しいので泊まりだ。風呂入りたい……
暇になったら新しい PC でも１台構築したいなあ，と，物欲に思いを馳せる今日この頃。
以前から欲しいと思っていたフットペダル・デバイスが，ようやく汎用的なパーツとして売り出されるようになったみたいだ。以前から Kenesis Ergonomics の拡張部品としてのフットペダルってのは存在していたんだけれども，単品としての製品はこれが初めてではないかと思う。しかもちゃんと USB 対応。 vi 愛好者としては，圧倒的に押す回数が多いくせにホームポジションから遠い位置にある ESC キーなんかを是非とも足に割り当てたい感じ。あとは CTRL キーとかかなあ。小指が疲れるんだ。
http://www.kinesis-ergo.com/prog_fs.htm
あと，キーボードマニアとしては，こんな変態キーボードも要注目株。
まっすぐに整列されたキー配列が，混迷期の国産 PC を彷彿とさせる……かな（ケシゴムキーボードとか）。バックスペースなんかがやたら親指に集約されているんだけれども， CTRL+H が身に付くと BS とか使わない気もする。なんだか微妙に理論付けられてなさそうな怪しげキーボードだ。でも面白そうなので人柱になってみてもいい感じ。
本体はここらへんとか。
http://online.plathome.co.jp/cgi-bin/category.phtml?kitem=11...
フルハイトの PCI が入れられるらしいんだけど， AGP は大丈夫かなあ。だめだったら，いっそのこと超小型を目指してみるのも面白いかもしれない。
http://online.plathome.co.jp/cgi-bin/category.phtml?kitem=11...
Savage4 で GL ができるんだったらこういうのでもいいんだけど，なにしろ S3 のサポートはもう望めないだろうし……うーむ。
とか，やや不毛な妄想でしばらく時間を浪費してみた。本当に暇になってから考えようと思う，こういうのは。
2002-05-31
相変わらず凄い量のバグレポート。これをあとｘ日で処理するの……大丈夫？
バグ繋がりでふと見た bugzilla の "#148232" の通し番号を見て，少し勇気づけられたりする。
http://bugzilla.mozilla.org/show_bug.cgi?id=148232
mozilla とは規模も人数も月日も全然違うけれど，まあこんだけのバグと闘っているひとたちもいるもんだ……ってことで。
しかし bugzilla って意外と下らないレポートも多いんだなあ，と思った。それに比べれば，ちゃんと職業として QA をやっている人たちのレポートは随分洗練されているものだと思う。あたりまえかもしれないけれど，あの人たちの不屈の闘志が製品の品質を支える重要な要素であることは，特に最近，よく思い知るところでもある。