2002-01-01
今日は元日。でも，まあ，とりあえず出勤。年始めとともに仕事始め。これは僕の象徴的なジェスチャーである，とかなんとか。
したら，サーバが落ちてた。
当然だけど，サーバが動いていないと，仕事は何もできない。コードにポエムの一節を加えることだって，できやしない。
アドミンのひとは４日まで来ないと宣言しているし，電話番号は知っているけど，いくら業務といえども叩き起こすのは無慈悲だとおもうし。
サーバのハードウェアは，どこか僕らの知らない安全なところに設置されているらしい。たぶん，監視カメラと対人地雷と赤外線起爆装置の装備されたような，すごいところに。
つまり僕にできることは何もないってことで……なにしにきたんだか。
脱力感に見舞われながら帰宅する僕。しかしそれは，あの想像を絶する地獄の三日間の，ほんの序章に過ぎなかったことに，そのときの僕が気付くはずもなかったのであった。
2002-01-02
あー，これはもしかしたら，全部調べ終わったあとに，結局無駄ってことになるのではー，っていう軽い焦燥感とともに， Geometric Algebra について調べまくっていた。
とりあえずの基礎はここらへん。
http://www.mrao.cam.ac.uk/~clifford/introduction/
http://carol.wins.uva.nl/~leo/clifford/talknew.ps
http://www.mrao.cam.ac.uk/~clifford/publications/abstracts/i...
http://www.cgl.uwaterloo.ca/~smann/Papers/CGA01.pdf
http://www.cgl.uwaterloo.ca/~smann/GABLE/SIGGRAPH01/sig01-c5...
とは言っても，まともに読んだのは talknew.ps だけ。ただ， talknew.ps は，やさしく書いてあるかわりに，それはもうとてもぶっちゃけた書き方をしているもんだから，腑に落ちなかったところはあとの文書で補う必要があるとおもう。
なんとなくの雰囲気はこれで分かるんだけど，問題は実装なわけで，いきなり自前で実装するのはなかなかつらいところ。参考になる実装が欲しいんだけど，これが，なかなかいいのが見つからない。
CLU っていう C++ テンプレートでの実装は見つかったんだけど，ただでさえテンプレートってのは読む方にとって地獄なんで，これを参考にするのはちょいと避けたいところ。
http://www.perwass.de/cbup/clu.html
必死こくって探しまわったら， PyCliff っていう python での実装が見つかった。
http://starship.python.net/crew/kernr/Projects.html
よし，これでいこう。
例えば，
求めようとおもったら，
また，例えば，
だったら
みたいな感じで。
これは talknew.ps の 25 ページの図をなんとなく眺めながら組んでみたんだけど，こんな風に，幾何的な概念を代数的に扱うことができるのが， GA のすごいところなのかもしれないかもしれない。
2002-01-03
なんだかんだで正月休みも今日までなわけで，そろそろ，休日中に調べたことに関して，それなりにまとめでも出しておこうかと，いつものコーヒーを飲みながらまったりとしているところ。
GA を自前で実装するとして，まずやっかいになるのが， geometric product をどう解決するかってところ。 R^3 における multivector の a, b に対して geometric product を取る場合，下の対応表のような感じで各要素の対応を取るんだけど，
これが，まあ，規則性みたいなもんはなくて，やるんだったら，初期化時にテーブルを前計算するか， multivector のクラス毎に式をバカ打ちするしかない。
上の表からもわかるように R^3 で十分にややこしいことになってるんだけど，ゲーム屋さんで利用されるとしたらおそらく R^4 の同次表現による３次元幾何操作だろうから，これは 16x16 の対応表を相手にするってことになる。鬱だ。
まあ， PC や Xbox だったらそれさえもバカ打ちすればいいんだろうけど（それに，それがたぶん最速の手段でもあるわけだし），わざわざベクターユニットを積んでるようなマシンでこれをやるのはちょっと不毛なような気もする。ていうか具体的には PS2 のことを言ってるんだけども。
まあ， PS2 のことは忘れておくにしても，具体的に GA を使うメリットを人に分かりやすく説明するのは，かなり難しいことだとおもう。
例えば，上の R^3 における (1,e23,e31,e12) の部分が，実はクオータニオンの正体なんだけど，だからといって GA を使わなきゃならない理由はなくて，回転だけを扱うんだったら今まで通りクオータニオンを使ったほうが演算も高速だし記憶領域も半分で済む（ R^3 の multivector は８個長の配列で表現される）。
そもそもの GA を使う動機ってのは， GA は様々な幾何的な概念を扱うことができるし，演算手順も簡潔にまとめることができる，ってところにある。 GA の要素や演算は多様性に優れているので， OOP と相性がいいってのもあるかもしれない。少ないメソッドとクラスで，あらゆる演算手続きをカバーすることができるのだ。
だから， GA を高速に処理できるプロセッサと，それをうまいこと包み込んだクラスライブラリが揃ったときに， GA の本当の真価ってのが発揮されるんだとおもう。そのときはじめて「 GA を使わないことのメリット」が消滅するわけで。
だけれど，そのときが今ではないのは確かだ。
４次元ベクトルに特化対応したプロセッサがメインストリームに登場したところから，４元同次表現によるベクトル・マトリクス演算が標準となったように，僕らのパラダイム（嫌な言葉っ）の変化は，まずハードウェアの新化ありきで成り立つのだろうとおもう。
時代の先取りとして手を出しておくのは面白いけど，むりやり仕事に結びつけるのは難しそうだなあ，とおもった。
2002-01-04
不意に訪れた長い休暇も昨日までで終わり。またいつものルーチンに戻るべき時がやってきた。エアコンを消して，ゴミを出し，家を後にする。
でも，一日働けばまた土日，ってことで，世間的にはまだぜんぜん正月気分みたい。行きつけの店も休みばかりで，飯食うのにも苦労してみたりとか，そんな調子の。
レンタルサーバに移行したおかげで， python で cgi が組めるようになった。いちおう python 愛好家を自任するところの僕としては，せっかくだから何かスクリプトを作ってみないわけには行くまい。
で，題材なんだけど，ウェブベースのブックマーク・コレクタを作ってみることにした。僕は普段からブックマークの管理に Yahoo! Bookmark を利用していたんだけれど，これを自前のものに移行しようってわけ。
レンタルサーバにインストールされている python のバージョンを調べてみると， v1.5.2 と表示された。メジャーナンバーが１のやつでは，最も馴染み深いやつ。できれば python2 を使いたいところだけど，まあ，それほど障害もないだろう。わりと python2 の拡張構文に慣れてしまっているんで，ちょっとトチることもあるんだけれど。
そんなわけで，自分ブックマーク cgi を導入完了。ついでだから，リンク集みたいな感じで公開しておくことにしようとおもう。 "Bookmarks" の方が，参照頻度が高くて，かつ揮発生の高いブックマークたち。 "Pointers" の方は資料的価値の高いポインタ集，って感じで。
2002-01-05
なにげに kano さんのとこの掲示板を覗いてみると，フレア系エフェクトのことが話題にあがっていた。最近は単純なレンズフレア以外にも，ポストプロセス系の凝ったエフェクトが流行りつつあるんだけど，ここでちょっと整理しなおさないとね，って感じのノリで。
フレアと言えば "ICO" のそれが独特でいい味を出していたんだけど，さっそく模倣と改良の流れが始まっているみたいだ。
http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/Rade...
レンダリングターゲットにテクスチャが指定できるようになって， PC でもポストプロセス系エフェクトが流行りそうな雰囲気が出てきた。これらのエフェクトはたいてい画面全体に対して処理を行うので，大量のフィルレートが必要とされる。こうして，またどんどんフィルレートに対する要求が高まるわけで……まあこうした力がハードウェアの進化を促すわけだから，がんがんやって欲しいとか，やって行きたいとか。
フレアっていえば，最近見た DVD 版「２００１年宇宙の旅」にちょっと面白いシーンがあったので，デジカメで撮影してみた。いちばん左の画像は，いわゆるダイアモンドリングなんだけど，太陽がシーン外に出る瞬間に縦方向に強いフレアが発生している。
なかなか珍しいタイプのフレアだとおもう（そんなことない？）。「２００１年」はミニチュアセットを使った特殊撮影なんで，きっとそうとう凝ったカメラ設定がしてあって，こういう現象が発生するのかもしれない。
真ん中の画像は，また別のアングルで，太陽がシーン外に抜けた瞬間の画像。横方向に異様に伸びたフレアが発生している。どちらも，発光体が画面内にあったときよりも強いフレアが発生しているところが，なんとも不思議だなあ，とおもう。
ちなみに，いちばん右のやつはおまけで撮った画像。単身でモノリスに接近したポッドがスターゲートに入った直後のシーン。こんな調子で１０分間ぐらいずっとサイケなビジュアルが繰り返されるんだけど，今見てみても，ほんと狂ってるなあ，っておもう。
ＴＶ放映なんかではカットされがちなんだけど，冒頭の「序曲」で呆然とさせられたり（これをＴＶで流したら放送事故扱いだ），いきなり「インターミッション」が入ったり，実はかなり型破りな構成の映画だ。
全編を通してのスクリプトが数千単語しかない，ってのも有名な話。当時のマニアだったら，全部の台詞をそらで言えちゃったりするわけ。そう考えると，とんでもないビジュアル系映画なんだなあ，これは，っておもったりした。
2002-01-06
Plucker Coordinate の ray-polygon intersection への応用，みたいなノリで， Geometric Algebra での ray-polygon intersection ってのを考えてみたりする，って練習。
ちなみに， Plucker Coordinate についてはこっち。
http://www.flipcode.com/tutorials/pluecker/
まず，前提として，３次元空間の表現に４元同次系を使用するものとする。
レイは，「点 p0 および点 p1 を通る直線」と定義し，これは単純に
で表現される。
ポリゴンの方は，前提として「左周りで convex 」であるものとする。で，ポリゴンの各頂点を v[0], v[1], ... v[n] とおくと，ポリゴンの各エッジは
となり，ポリゴンと平行な無限平面は，
で表される。
このとき，各エッジとレイの outer product を取ると，レイとポリゴンが平行でない限りは，各 multivector が線形独立であることから，４次元の blade が得られるんだけど，この量（単に e0123 の係数を見ればいい）はレイがエッジの内側にある場合は負の値になるはず。なので
って感じかなあ。そんなんで内外判定を終え，判定に成功したなら，単純に
で交点を得ればいい。
レイを線分にするならば，始点−終点間の範囲判定も加えなきゃいけない。これには
を求めから，これもまた e0123 の係数を見てやればいい。線分が平面を跨いでいるなら，符号が反転しているはずだ。
これは，普通にやってやればいいところを無理やり GA を使ってみただけなんで，あまり実用的な意味は無いのであって……なんかもっとかっこいい方法無いかなあ。
まあ結局のところ， GA を使ったところで新たなアルゴリズムが生まれるってことは，そうそう滅多にあるもんではないみたいだ。ただ，コード的には清潔感のある書き方ができるんで，精神的には満たされるものがあるのかもしれない。
2002-01-07
まあ，そんなわけで，一般にフレアとかグレアとか呼ばれているものは，目やカメラの中，もしくはそのごく付近で発生する現象のことを特定して指すようだ。一方，空気中の微粒子によって発生する光の散乱現象のことは，一般にチンダル現象と呼ばれる……っていつか学校で習ったような気がするんだけども，覚えてないなあ。いちおう，理系のつもりなんだけど。
http://www.public.iastate.edu/~physics/sci.physics/faq/blue_...
このページを読んでいておもい出したんだけど，空が青いのも，夕日が赤いのも，チンダル現象の影響として説明できるんだった。白色の太陽光が大気中を長く通過するうちに微粒子による散乱が発生し，影響を受けやすい青スペクトルは散乱して空を染め，残った赤スペクトルが地上に届き夕日になる，って感じで。
ただし，俗に言う「大気中の塵が……」ってのは間違いで，実際には酸素や窒素のように大気を構成する主要成分の分子による散乱が要因となっているようだ。澄んだ空気が光を散乱するってのも不思議な感じだけど，地球規模の巨視的なモデルになると，そういうこともあるのかもしれない。
"Blue Haze and Blue Moon" の説明も，豆知識的ネタで面白いとおもう。この調子で，美しくグリーンに光る南国の海，ってのも，それなりに説明できそうな気がするけど。
相変わらず一定のペースで配信され続けるスパムメールに少し嫌気が差すこの頃。新しく取得したレンタルサーバのメールアドレスは，あまり使わないようにして，スパムの脅威から逃れようと目論んでいたんだけど，僕が最初に POP サーバにアクセスしたときには，既に３通ほどのスパムが届いていたわけで。
まあ，速攻，捨てればいいんだけど。
しかし， HTML メールではなくベタテキストのメールなのに "CLICK HERE" とか書かれたそのスパムには，なにか哀愁のようなものさえ感じられるような気がした。送った側にも，送られた側にも，何ら意味をもたらさなかったそのくだらないスパムは，僕のゴミ箱の容量を数百バイト増加させるという健闘を見せた刹那，その存在を無に帰しました，とさ。
2002-01-08
いちおう毎日見ている flipCode の IOTD 。今日のはなんか，いい感じだ。
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=01-07-200...
要するに統合的な地形エディタの一種らしいんだけど，デモ映像の雰囲気が良くて，しばし魅了させられる。
ってわけで，かなりのポリゴン食いなわけなんだけど，でもそれだけポリゴン使えばこのくらいのビジュアルが見せられるんだなあ，ってことで，ちょっと参考になったのかもしれない。
ふさふさの草がとてもいい感じ。 LOD が見えちゃってるような気がするけど，まあ気にしない，気にしない。この背景の中を駆けずり回るアクションゲームとか，やってみたいねえ，とか，しばし妄想に浸ってみたり。
たぶん，次世代ぐらいには，ね。誰かが。
ここで「俺が作るるっ！」って言わないところが，出来るひとと出来ないひとの境界面なのかもしれないのだけど，そこは僕の日和見派野郎的思考パターンのなせる技なわけで。
うっかり見逃していたんだけど， "KOF online" のニュース。
http://www.geocities.com/chtang.geo/gaming.htm
まだ SNK 頑張ってるんだなあ，とかおもいながらぼんやりと無視していたんだけど（失礼な），よく見てみると，どうやら韓国の企業が版権を受け取って開発しているようだ。画面写真を見る限り「スパイクアウト」のオンライン版って雰囲気がするんだけれど，実際はどんなもんなのだろう。
ひとむかし前までは，いやあ韓国わりと頑張ってますよねー，みたいな雰囲気だったんだけど，ここ数年間のうちに着実に力を付けてきているような印象がある。最近では "Ragnarok online" や「ポトリス」などをはじめ，韓国産のネットゲーが話題に挙がることも多い。僕もせめて参考程度に遊んでみたいとおもっている。
おもっているだけで，なかなか時間が無くて出来ないでいるんだけど……そこは，あー，もういいよ。日和見派野郎なんだからさ。
2002-01-09
んで，フレア系のエフェクトなんだけど，シーンの描画後に行われる，いわゆるポストプロセスとして扱われるのが普通だとおもう。ここで重要になってくるのが，描画バッファのフィードバックだ。
http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/Rade...
くだんの ATI のサンプルもそうなんだけど，光源の遮蔽情報を得るために，シーン描画後のデプス情報を応用するようなノリになっている。
ところで，描画バッファのフィードバックが自由に行えるようになったのはわりと最近の話で，ちょっと前までは， API の都合でひどく制限されていたり，もしくはハードウェアにデプスバッファが存在しなかったりで，いろいろと不自由なシチュエーションを強いられることが多かったようだ。
そんなもんだから，比較的昔のゲームなんかだと，衝突判定を利用して遮蔽判定を行っていることも多い。 Quake をはじめとする FPS 系のゲームなんかでは，衝突判定モデルと描画用モデルが全く同じものを使用していることが多いので，こういった方法でもさほど問題にならないんだろうとおもう。
今でも，例えば点光源に付けるレンズフレアのための遮蔽判定のように，比較的単純なエフェクトでは，ジオメトリ的な処理に頼ったほうがいい場面もあるかもしれない。イメージプロセス的な手法では，画面全体にマスクをかけたりする都合上，必要以上にフィルレートが浪費される可能性があるからだ。
あーでも「木の枝の間に太陽が見え隠れする」みたいな演出をしっかりやるためには，やはりイメージプロセスに頼るほうがいいなあ，とおもったりするわけで，やっぱジオメトリに頼るのは，もう金輪際無しの方向性でひとつ。
あと，ちょっと面白いのが Xbox の "DOUBLE-S.T.E.A.L" の画像。
http://www.watch.impress.co.jp/game/docs/20011228/ds.htm
上で挙げたような「デプス情報からマスクを生成して……」のノリじゃなくて，フレームバッファから光源情報をイメージ抽出してフレア加工するようなポストプロセスが行われているようだ。 PhotoShop のプラグインなんかにあるキラキラエフェクトのノリで。
この場合に難しいのが，いつかの例のダイナミックレンジの問題だ。フレームバッファに存在する情報はダイナミックレンジが狭く，またディスプレイの輝度に合わせて正規化されている都合上，輝度がすぐに飽和してしまう。例えば， "0xffffff" のピクセルがあったとして，それが白色光源の飽和された「白」なのか，ただの白い紙が置いてあるだけの「白」なのかを判別することはできない。
これを解決するには，例えば，アルファチャネルに付加的な輝度情報を埋め込んでおく，とか，輝度レベルの分布にスケールをかける，とか考えられるんだけど，どうだろう。
輝度分布にスケールを，ってのは，要するに表示する直前に輝度をｘ倍するってだけの話。色深度は下がるので画質は確実に悪くなるんだけど，拡張された輝度のレンジを得ることができる。んー，でもたぶん，そう単純にうまくはいかないとおもうけど。
2002-01-10
OpenGL でフレームバッファ（カラーバッファ，Ｚバッファ等）の内容を読み取るには， glReadPixels や glCopyTexImage2D といった関数を利用することになる。
glReadPixels はフレームバッファの任意の領域をメインメモリ内へ転送する関数だ。この関数は汎用性を重視した設計になっていて，読み取るバッファの種類やデータフォーマットをかなり柔軟に設定できるようになっている。
しかし，はるばる遠くはビデオメモリから，めったに使わない上りバスを経由して CPU 側に転送し，わざわざフォーマット変換してから低速なメインメモリに格納しようってんだから，かなり無茶な所業であるのは確かだ。お手軽で便利な関数ではあるんだけど，リアルタイム用途にはまったくと言っていいぐらい向いていない。
一方， glCopyTexImage2D はフレームバッファの任意の領域をテクスチャ領域へコピーする関数だ。フレームバッファの再利用には，もっぱらこちらの関数を利用することになるとおもう。
ところで Windows の OpenGL 実装では，通常，レンダリングコンテキストはすべて表示領域を持っているという前提になっている。つまり，すべてのコンテキストは画面のどこかに表示されているってことで，オフスクリーンのコンテキストって概念が存在しない。
これは，フレームバッファに対して多段階にレンダリングするような手法を使用する際には，わりと面倒な制限だ。バッファの最大面積やピクセルフォーマットなどが表示デバイスの状態に左右されることになるので，融通が利きにくくなるのだ。また，複数のコンテキストを並列して使用するような状況でも，けっこうややこしいことになるとおもう。
これをフォローするために用意されたのが WGL_ARB_pbuffer 拡張だ。 pbuffer は「ピクセルバッファ」ってことで，オフスクリーンのフレームバッファのことを指す。
http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuf...
ただし pbuffer はあくまでも描画用のバッファであり，これをテクスチャとして直接に利用することはできない。描画結果をテクスチャとして再利用するには，やはり， glCopyTexImage2D などでテクスチャ領域にフィードバックする必要がある。これは単なるブロックコピーとは言え，帯域を確実に消費する行為なので，ならべく避けたいところだ。
このコピーの手間を省くために用意されたのが WGL_ARB_render_texture 拡張だ。まだ extension registry を斜め読みしただけなんであんま自信ないんだけど，実質的には， pbuffer をロックすることによって直接にテクスチャとして利用できるようにする機構のようだ。
http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_rend...
ただし，この拡張はまだ極少数の ICD でしかサポートされていないようで，これを利用した手法がメジャーになるのは，まだもうちょっと先のことになりそうな雰囲気だ。
"DOUBLE-S.T.E.A.L" の影響でポストプロセッシングに興味が出てきたんだけど，興味があるのはネタの実装と仕組みの検証なんで，とりあえず ReadPixels 等でお茶を濁そうかとおもっている。実装も PyOpenGL で適当にやっつけてしまおう……。
2002-01-11
まずは ATI の light glare ネタのパクりから出発。
http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/Rade...
流れとしては，
こんな感じになる。
とりあえず実装は Python + PyOpenGL の組み合わせで，フレームバッファの読み取りには glReadPixels を使用する。んで，まあ予想通りなんだけど， glReadPixels は重いなあ……。 glCopyTexImage との速度の違いはどのくらいあるんだろうとおもう。あとで比較してみよう。
てきとうにテコテコと組んでみたんだけど，アルファチャネルの操作がうまくいかない。背景を (1,1,1,1) で，ティーポットを (x,x,x,0) で描画してマスクパターンを作ろうとおもったんだけど，ティーポットのアルファが０になってくれない。うーん，どうなってるんだ，これは。
こういう系統のエフェクトでは，テクスチャのバイリニアフィルタを使って画像をぼかすっていうテクニックを使うことが多いんだけど，ここをもうちょっとうまくやれないものかなあ，とおもう。これを普通に実装すると，矩形状にブラーが広がることになるんだけど，本当は放射状に広がって欲しいところ。濃度の低いブラーでは両者にほとんど違いはないんだけど，今回のネタのようにきつくブラーをかける場合は，少なからず差異が出てくるような気がする。
2002-01-12
今日は，げーはなさん主催の謎新年会。僕の縄張りであるところの溝の口にて開催されるということで，余裕で徒歩で出発。途中，ゲーセンに寄って「斑鳩」なんて見ちゃったりして。
むう，パズルゲームですか，これは。ひさびさのトレジャー節にみなさんご興奮の模様。僕もやってみたいけど，恥ずかしいので（下手だから）ちょっとパス。家庭用に移植されたらいいんだけど，縦画面でナオミ基盤だったりするところからして，あんまし移植のことは考えてなさそうな気がする。これはこれで潔いのかもしれないけど。
んで，飲みの方は，業界系のひとばかり集結ってわけで，ものすごーい濃い感じのアレに。僕はいつでも帰れる身なんで，せっかくだからオールナイトで最後まで付き合うことにした。
毎回，けっきょく最後まで残ってるつよぞうさんがいい味出していた。
今回の僕的注目株は DAKINI さん。某社系の方と会う機会はなかなか少ないので，すごく貴重な経験になりましたよってに。なんていうか，知られざる某社のアレがたくさん聞けてアレだった。あと，意外と DAKINI さんは２ちゃ（検閲削除）
そして，結局の所，僕と IF さんの出した結論は「 Bee さん萌え」ということだった。
2002-01-13
で， light glare の続き。アルファチャネルの設定がうまく適用されなかったのは，glutInitDisplayMode で GLUT_ALPHA を指定していなかったのが原因だったようだ。うーむ， GLUT でデスティネーションアルファとか真面目に使ったことなかったからなあ。 GLUT_RGBA にしただけじゃだめ，ってのは，かなり騙し入ってるとおもう。
そんなわけで，「抜き」が正しく合成されるようになった。うむ，なんとなくイメージしていたものに近づいて来たような気がする。フィードバック回数を増やして，それぞれの合成率を低くしてやると，ブラーのかかり具合がキメ細かくなっていい感じだ。上の画像では８回もフィードバックさせているんだけど，実際のゲームなんかでは，なかなかここまで贅沢には出来ないかもしれない。負荷的には４回ぐらいが適当だとおもうんだけど，それだとかなりブロックが見えてしまう気がする。
glReadPixels はさすがに重いので glCopyTexImage2D に切りかえた。なんか，おもったよりも実用的な速度が出てるような気がする。あとは， ARB_render_texture を使ってブロックコピーを減らしたり， multitexture で合成処理を高速化したりとか，そこらへんかな。
今回のネタを "ideas" に追加。しばらくはネタ集めで楽しもうかとおもう所存。
http://www.radiumsoftware.com/ideas.html
2002-01-14
今日は夕方出勤。あー，例のハッピーマンデーってやつね，とか，頭の片隅で考えながら，駅から最寄りのマックまでてくてくと歩いてって，適当に肉を挟んだパンのアレとか頼んだみたりする。
最近はおじいちゃんもうお腹が弱いから，冷たいコーラよりももっぱらコーヒーを頼むんだけど，コーヒーは本来のセットメニューじゃないから５０円増し。でも，普通のコーラは１７０円で，ブレンドコーヒーは１８０円。あ，なんだ，損してんじゃん，自分。
ほんとにどうでもいいことなんだけど，マクドナルドにおける経済概念ってば，正真正銘狂ってるとおもう。僕は，僕が一体何に対して，何を期待してお金を払ってるんだか，全くわけがわからなくなる。
でもそれはたぶん，僕と僕の客の間にも言えることなわけで，そんな疑問を匂わせないぐらいの説得力を持つことが大事なのかもしれない，とかおもってみたりする。
ちょっと前の IOTD @ flipcode のネタなんだけど，こんなの。
http://emsh.calarts.edu/~mondi
VJ パフォーマンスソフトの一種らしい。ただし，バイナリは非公開。オーディオとの連動（ MIDI かアナログかは分からないけど）とか，ちょっぴり複雑系のエッセンスとか，そんなのがごったになった感じのソフトのようだ。
３次元空間上での複雑系の視覚化ってのは意外と面白そうなネタで，たとえばこんなの。
http://www.hypercomplex.org/quats.htm
しかしながら，前者 "mondiSzynth" のビジュアルは，いい具合に洗練されていてかっこいいなあとおもう。こういった仕掛けでは，アナログや複雑系が内包している偶然性とか揺らぎとかいった要素に頼りがちなんだけど，それらとビジュアルとしての洗練度ってのはあまり相関性はなくて，そこには確実に制作者の作為が絡んでくるものだとおもう。
とにかく，実際に動いているところを見てみたいものだ，とおもった。
2002-01-15
んで， glare の次は，単なるフレア。フレアっていってもレンズフレアではなくて，いわゆる "DOUBLE-S.T.E.A.L" 方式のフレア。フレームバッファ上でハイライトになっている部分を抽出し，ポストプロセスでフレア化するって仕組みだ。
まず，マテリアルのスペキュラを大きめに設定して，ハイライトの付いたティーポットを作る。次にハイライト部分を抽出するんだけど，これには加減算合成における飽和演算を利用する。下限値の輝度を持つ白ベタを引いて足すだけだ。
ところが OpenGL にはちょっとした問題があって，ブレンド関数で加算を指定することができても，減算を指定することができない。こういう細かい所での融通の効かなさが OpenGL らしさなんだけど，まあそれを言ってもしょうがない。たぶんこれをカバーするための拡張が用意されているはずなんだけど，今回はそれ以外の方法でなんとかしてみる。
ブレンド関数を
にしてから白ベタで塗れば，色の反転を取ることができる。この状態で加算してからまた反転すれば，減算で飽和させた場合と同じ結果になるはずだ。
とか，そんな感じで，いろいろめんどくさいおもいをしながらも，なんとか画像を出すところまでこぎつけてみた。うーんしかしこれじゃあ，単なるスペキュラのきつい画像だよなあ。
今回，問題になっているのは， OpenGL の標準仕様におけるブレンディング関数の制限がキツいってところ。これを改善する手段を見つけるべく Extension Registry を漁ってみると，それらしき匂いのする拡張を見つけることができた。
http://oss.sgi.com/projects/ogl-sample/registry/EXT/blend_mi...
http://oss.sgi.com/projects/ogl-sample/registry/EXT/blend_su...
次はこれらの拡張を導入してみよう。でも，今日はここまで。仕事も忙しくなってきたしね……。
2002-01-16
たまーに，ふと思い出したように，衝突判定について調べ出してみたりすることがある。
http://www.win.tue.nl/~gino/solid
あてもなく情報収集していて，たまたま見つけたライブラリだったんだけど， GJK (Gilbert-Johnson-Keerthi) というアルゴリズムが初めて耳にするものだったので，ちょっと目を通してみることにした。
GJK は，２つの convex なオブジェクト間の最短距離を高速に導き出すアルゴリズムであるらしい。この，「２つのオブジェクト間の最短距離」という問題は，「２つのオブジェクトのミンコウスキー和と原点の最短距離」という問題に置換することができる，っていうトリックがあるんだけど，この考えが元になっているようだ。
「ミンコウスキー和」ってのも，実は初めて耳にするんだけど，要するに「スイープ」した形状のことを言うらしい。
http://www.google.co.jp/search?q=%22minkowski+sum%22
「ミンコウスキー和」なんて言葉を持ち出すと小難しそうなんだけど，要するに，凸なオブジェクトＡとＢがあった場合に，ＡをＢの大きさだけ太らせてやれば，Ａと点の判定で済ますことができるよね，って話。
これは，昔から２Ｄのゲームなんかでもよく使われていたトリックで，例えば
の衝突判定は
の衝突判定で近似することができる，ってやつ。ただ，これだと矩形の角の周辺での判定が怪しくなるんだけど，まあ，そういうのを気にしない場合に使ってたってこと。
Stan Melax は，このトリックを BSP ツリーに適用して， BSP ソリッドオブジェクト対プリミティブボリュームの衝突判定を実現する方法について，自身のホームページで詳細に述べている。
Melax は MDK2 なんかでこの手法を実際に使用したそうだ。また別のページでは，その応用の際に発生した問題点などについて，何気ない苦労話なんかを含めつつ記述されている。
http://www.melax.com/bsp/feedback.html
ここらへんの「都合のいい話ばかりではない」バランス感が，いかにも現場っぽくていい感じだとおもう。
Melax も指摘しているけど，この手法の元ネタは Quake で使用されていたものだ。 Quake では，何個かの規定のサイズのボリュームに対するミンコウスキー和を求めておいて，それらを静的に使用するような方式になっている。 Melax がやっているような動的な方式は，対処しなければいけない問題が多すぎて諦めてしまったようだ。
ちなみに Quake に関しては， id のサイトでソースを拾ってくれば， world.c なんかの辺りで，その処理の内容を実際に目にすることができる。
で，本題の GJK の方なんだけど，どういった感じに有利なんだか，あまり実感が湧いてこない。うーん。自由な形状（っても convex に限定されるんだけど）に直接に適用できるという点では，優れているのかもしれないなあ。僕はそういうのは，総当り法しか知らないもんで。
ともかく，もうちょっと真面目に調べてみないとわからなさそうだ。また次の機会になりそうだけど……。
2002-01-17
で， flare の続き。
まずは GL_EXT_blend_minmax なんだけど，これは名前からも想像できるように，定数カラーとの min や max を取るもののようだ。んー，まあ，画像合成ネタなんかに使えるかもしれない。
次は GL_EXT_blend_subtract だ。これもまあ名前どおりで，ブレンディングで減算を使えるようにする，ってやつ。これは何かと役に立つだろう。ていうか，むしろ標準で用意されてないのがおかしいんだけど。
他になんか良さげなのはないかなー，と extension registry を漁っていると，なにげにこんなのを見つけた。
http://oss.sgi.com/projects/ogl-sample/registry/NV/blend_squ...
ブレンド関数において，ソース側の係数としてソースカラー自身を，もしくは，デスティネーション側の係数としてデスティネーションカラー自身を指定できるようにする，ってもののようだ。
むしろ，こういう指定が標準では許されてなかった，ってのを全然知らなかった。へへー，なんか得した気分。
これを使うと，簡単に輝度の自乗を取ることができる。ベタ描きでもってデスティネーションの自乗を繰り返せば，輝度が 1.0 未満のピクセルは急激に黒に近づいていくから，カットオフ関数の近似とすることができるかもしれない。閾値の輝度で白ベタを描いて，それから自乗を繰り返すのだ。
あでも，白ベタの時点で上は飽和するわけだから，カットオフってよりかは２値化か。ともかく，これでなんとかなりそうな気がしてきた。
ちなみにこれ， NVIDIA 拡張なんだけど， RADEON や Mesa なんかでもしっかりサポートされているようだ。
んなわけで，調子に乗ってドきついフレアをかけてみたのが上の図。なんつうか，成金趣味やなあ……。それはともかく，矩形状にブロック化してしまう弱点なんかがよく分かるとおもう。さりげなく使うように心がけなきゃいかんのだなあ，とおもった次第。
ちなみに，このカットオフの処理は，輝度値をアルファチャネルにコピーすることができれば，アルファテストとして処理することができるので，ものすごく簡単になる。次はこの方向性で探ってみようとおもう。
2002-01-18
どうにもすっきりしないんで， GJK の資料集めを続けている。とりあえず google でサーチにかけてみると，意外にあっさりと原典を見つけることができた。
http://graphics.stanford.edu/courses/cs448b-00-winter/papers...
なんかこれ IEEE Journal のスキャンみたいだけど……まあいいか。んであとは， Stephen Cameron の "Enhanced GJK" とか， SOLID ライブラリのページに置いてある paper などが主な参考資料。
http://users.comlab.ox.ac.uk/stephen.cameron/distances.html
http://www.win.tue.nl/~gino/solid
コレクションはこの程度にしておいて，さっさと読解に移らねば。んで結局，やってることは単純っぽいんだけど，結論に至るまでの過程が長くて，読むのにやたら苦労している。英語もわからないし，数式もわからないからなあ。とにかく，完読にはまだ相当時間かかりそうだ。
資料集め中になにげなく見つけたページ。フランスのプログラマー Pierre Terdiman 氏の "Coder Corner" だ。
ちょっと前にドジ研掲示板でも紹介されていたような気がする。内容は，高速衝突判定ライブラリ "OPCODE" をはじめとして，氏の様々な実験作品やら文章やらが置かれている。ここでなにげに親近感が湧くのが，氏がデモシーンの出身であるってとこ。デモチーム "BOMB" に在籍していろいろ作っていたらしい。あー，これとかすげー懐かしいんですけど。
http://codercorner.com/ShianLee.htm
たしか，お約束通り GUS でしか音が鳴らなかったもんだから，当時 SB Pro しか持ってなかった僕は BGM 無しで見るはめになったんだけど，それでもすごく衝撃的な作品だったのを覚えている。
懐かしついでに昔の MOD コレクションとか聴きながら仕事したりして，ちょっとノスタルジーな気分に浸ってみた。
http://www.students.tut.fi/~kainiemp
その場のノリでなんとなくサーチして見つけた Quasian 氏のサイト。そうそう， asm'99 で２位だった "second time" とか，すごく良かったんだ。
ftp://ftp.jp.scene.org/pub/scene/music/artists/quasian/scndt...
僕にとってはすごく懐かしい，まさに思い出の中の人物なんだけど，現在も地道に活動を続けているみたいだ。正常進化系な曲以外にも，今でも IT (Impulse Tracker) 曲などを作っている模様。うん，これが世に言う "chip tune" ってやつなのかな。 music セクションに置いてある "happy go lucy" とか "poppy yard" とか，個人的な琴線に触れるものがあって，ちょっと感動してみたりした。
こういった曲を聴いていると，やはり北欧系のミュージシャンの曲は，日本人的嗜好にマッチしやすいんだよなあ，ってつくづくおもう。やはり，泣きの要素が欠落している欧米系の曲は，ド日本人の僕とかにとっては，なんとなく味気なく聞こえてしまうわけで。
2002-01-19
寝袋から抜け出て重い身を起こすと，もう昼間の１２時近くだった。うーん，今日は誰もいないんだなあ，とか言いながら，近くのパン屋まで食料を調達しに行く。
手持ちが少なくなってたんで銀行に寄ったんだけど，マイバンクこと三和銀行が 「 UFJ 銀行」に変わってて驚いた。あーうー，テレビとか新聞とかぜんぜん見ないもんだから，どんどん世間知らずになっていってしまう。社会人としてヤバいレベルかもしれない。
仕事の方がまたどんどん忙しくなってきて，なかなか時間が取れないでいるんだけど，地道にフレアの実験を進めてみたりしている。
おとといのがそうだったんだけど，ブラーの強度をフレアがしっかり見えるぐらいまで上げてしまうと，どうしてもフェイクを使っているのがばれてしまう。この前の light glare のときはそれほど気にならなかったんだけどなあ。
結局，上の画像ぐらいの強度が限界だとおもう。これ以上強くするとブロック化が顕著になってきてしまう。ちゃんとした畳み込みでもってブラーを作成すれば，こういった現象も起こらないんだけど，それにはとうていフィルが足りていないし。
そう考えると，"DOUBLE-S.T.E.A.L" のフレアやらエンボスやらは，かなり大胆にフィルを消費しているような気がする。 Xbox は UMA だからバスが云々ってのは，まったくの杞憂だったのかなあ，とかおもってみたりした。
2002-01-20
急に熱が出てきた。うー，どうも喉をやられたようだ。昔から喉は弱くて，たいていひどい風邪をひくときは喉をやられていたもんだ。まあそんなわけで，今日も出動しようとおもってたんだけどやっぱやめ。明日休むかも……げほげほ。
IGN より Xbox の "Railsport Challenge" プレビュー。
http://xbox.ign.com/previews/17334.html
綺麗だなあ。ちょっとスクリーンショットの解像度が高すぎる気がするけど，実際はどうなんだろうとおもう。
DOA や GTC なんかの例にもあるように，スクリーンショットのために解像度をブーストした画像を生成するなんてのは，最近では訳ない所業だ。つまり，実画面を肉眼で目にするまでは，スクリーンショットを盲目的に信じてはいけない，ってわけ。
http://mediaviewer.ign.com/mediaPage.jsp?media_id=208797&obj...
これの地面のバンプ表現とか，かなり使い方に慣れてきている感じがする。バンプって使いどころが難しいとおもうんだけど，こういった感じで使いこなせるデザイナがいると，プログラマとしてはとても心強いことだとおもう。
2002-01-21
だいぶ熱が引いてきたので，普段通りの出動。風邪の影響だか薬の影響だか知らないけど，やたら眠くて眠くて，何度も眠りの中に引きずり込まれそうになる。
よく変な格好とかで寝てると，中途半端な落下感覚の後にビクッって痙攣して目がさめることがあるんだけど，そういうのが何度も起きて，もうやべーなーって感じで。
だから，今日はわりと早めに帰宅。寝よ寝よ。早くペースを戻さねば。
最近，何かとつけて XML を使ってみることにしている。 XML がなんでこんなに流行っているのかは，僕にはいまだに定かじゃないんだけど，まあ「わりと何でも書けちゃう書式」としては利用価値がありそうかな，と。
http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/index.html
"BulletML" の例からも想像できるように，わりと何にでも使えてしまう感じなので，ローカルなファイルフォーマットを作ってはパーサを書き直すような繰り返しからは解放されるのだとおもう。そこそこ枯れた感じのフリーのパーサがすでにいくつか存在するので，他力本願派の方々にも問題なしって感じだ。
ただ "Markup Language" って言うくらいだから，文書の書式として使うのが本来の用途だとおもうんだけど，それをデータベース的な使い方にしてしまうのはどうなんだろう，とおもう。ここらへん，思想的な所はほとんど調べていないんで，いまいち感覚がつかめないでいる。
2002-01-22
今日もまだ療養中。療養中ったって，普通に仕事してるんだけど。で，気分はだいぶ良くなってきたものの，喉はなんだかますます痛くなってきたみたいだ。喉飴が欠かせない。
だるいんで，昔のデモシーン関連のひとたちのページをまったりと漁ってみたりした。この間の Quasian 氏のページの再発見がきっかけなんだけど。
"The Manga Freak" こと Sunlikamelo-d の tmk 氏は，いつの間にか "wataru" に改名したみたい。なんだそれ。
http://www.error-404.com/sunlikamelo-d/
もうちょっと古い曲の方がクサくて面白いんだけどなあ。 scene.org を掘り返せば見つかるだろうか。
vincent voois も，当時かなり好きだったひと。
http://www.traxinspace.com/Artists/MusicDirectory.asp?Artist...
トラッカー系の曲って，わりと無機質な感じが露骨に表れやすいんで，そこを重厚に畳みかけることによって迫力で押すような曲が多かった気がする。そんな状況にあって，この V.V. のような超ポップ路線なんかにはすごく救われたのだろうとおもう。
そういえば，いつからか個人的に入れ込んでいるはずだった aisth がちっとも音沙汰無くなってしまった。もう１年ぐらい無反応なんだよなあ，とかおもいながら半ば諦め気味にサーチしてみると，なにげに新しいサイトにヒットした。
３つの新曲がアップされている。２曲目の "warm" は，いつかの assembly に出していた曲の新しいミックス。落とさねば。
ついでに katastro.fi を見に行ってみると， brothomStates とか CNCD とか，懐かしい情報がたくさん……もっとも，本人たちにとっては現在進行形なんだけど。
brothomStates は，もと dune だったひとの個人ユニット。 Orange のデモの BGM や，個人での音楽活動でも有名だったひとだ。個人的には，病的な曲ばかり作るひとって印象が強いんだけど，今聴いてみると意外といけるかもしれない，とかおもったりした。
でも，途中で眠くなってくるね……
2002-01-23
数日前， flipCode に大量の新規リンクが追加されてたんで，それらを適当に彷徨してみたりする日々。今日はたまたまこのページ。
http://www.oroboro.com/rafael/
HelixeGames の Baptista 氏のページ。内容は "algorithms" に小ネタが少々などなど。 "High Accuracy Quantized Normals" とか，読んどけば役に立つこともあるかもしれない。
法線ベクトルは普通，正規化した形で保持する。んで，正規化ベクトルはその特性上，表現方法にいろいろと工夫を加えることでメモリサイズを小さくすることができる。固定小数表現にして要素を１つ取り除くだけでもずいぶん小さくなるわけだし。
余談だけど，よく考えると「法線」の定義ってよく知らない。なんなんだろ。たぶん平面の表現方法の一種ってことなんだとおもうけど，それだったら正規化されている必要は無いから，正規化するのは単に計算手順の都合ってだけなんだろうとおもう。
んで，このページでやっているのが，そのまさに，いかにして単位ベクトルを小さなメモリサイズで表現するか，ってとこ。とりあえず x と y に 7bit づつ持たせて 14bit としているんだけど， x と y をそれぞれ２乗しておくと，
から x^2 と y^2 の２つが同時に 0.5 を越えることは無いので，実は最上位 1bit は共有できる，っていうトリック。それぞれに 7bit のレンジを持たせつつ，合計 13bit で表現することができるのだ。
結局，マグニチュード表現に 13bit ，符号表現に 3bit を使って，計 16bit でそれなりの精度の単位ベクトルを表現することに成功している。
ここまでが "compressed quantized unit vectors" の内容。
この方法のように xy 平面への平行投影を使う場合， z=0 の付近で誤差が出やすくなるっていう弱点があるんだけど，これを，投影の方法を変えることで改善するってのが "High Accuracy Quatized Normals" らしい。
んでその方法なんだけど……まだ風邪完治してないし，もう寝るのだ……
2002-01-24
喉が痛い。唾を飲み込むにも痛みを伴う。加えて，頭痛もする。僕はめったに頭痛とかしない方なんだけど，久しぶりになってみると，これはつらいものだ。頭痛持ちの人はこういった労苦を普段から抱え込んでいるわけなんだなあ，とか，ひとりで何かに納得してみる。
そんな状態にも関わらず，微妙な情勢の変化から，突如として継続勤務に移行せざるを得なくなってしまった。くっ，たまにはそんなこともあるのさ。また健康から一歩遠のいてしまったことを嘆きつつも，深夜のデバッグ作業にどっぷりとのめり込んで行く。
他人のソースをデバッグするのは，実はそんなに嫌いじゃない。むしろ好きなのかもしれない，と正直，おもうこともある。それはたぶん，他人のソースをデバッグするという作業に，ハック行為的な要素が含まれているからなんだとおもう。
デバッガでプログラムカウンタを追い駆けながら，ソースコードを地図代わりにスタックの中を駈けずり廻る。ときには監視したり，覗いたり，罠を仕掛けたり……これはちょっとした探偵劇みたいなもの。例えバグが取れなかったとしても気に病む必要は無い。元はと言えば彼のせいなのだから。
これが自分のバグだったらそうも言ってられないわけで。
ところで，こんなときに使うデバッガはもちろん gdb 。デバッガとコマンドライン・インタフェースの相性が，実は良い，ってのは以前より僕が力説しているところ。例えば，あるプログラムに対して「新宿」という地名を渡すのに，わざわざ５万分の１スケールの地図を表示して，そこから新宿をポインティングアウトさせるようなインタフェースはどうだろうか。あるいは，東京中の地名をリスト（もしくはツリー）に長蛇の如く列挙して，そこからたった一つのアイテムである「新宿」を探し出させるようなインタフェースはどうだろうか。それらに比べて，プロンプトから「新宿」と，たった２文字入力するだけの方が何と簡便なことだろうか。
だから僕は，関数 SetMatrixBlendingRatio にブレークをセットするために vcluster.c を開いてからマウスをポチポチ押すようなことはしない。その代わりにプロンプトから
と打ち込めばいいのだから。
とかなんとか言ってるのは VC++ を所有していないが故の跳ねっ返りであって，やっぱ GUI もいいとおもいます。でもたぶん究極はその融合形態であろうという観点から， DDD こそが最強のデバッガであると推して今日のポエムおしまい。
http://www.gnu.org/software/ddd/
2002-01-25
そんな訳で，昨日から泊まり。風邪の影響か，鼻水やら目やにやら出っぱなしで気持ち悪い。あーもう，だめじゃよ。死ぬる。
http://slashdot.jp/article.pl?sid=02/01/22/1515230&mode=nest...
http://www.zdnet.co.jp/broadband/0201/21/ibm1.html
今後，ゲームがよりネットワーク志向に偏っていくのは間違いないところだとおもうんだけど，その際に，どうやってお金を回収するのか，という点については，それほど真面目に考えられてないような気がする。ネットワークゲームというからにはサーバを用意しなきゃなんないんだけど，継続的にサーバを運営していれば当然そこには維持費が発生するわけで，それを回収する手段を何か考えなくちゃいけない。
現在では，一部の MM (Massive Multiplayer) 系オンラインゲームを除いては，サーバ使用料を徴収しないというスタイルが定着しているように見える。 PC 系のゲームなんかは特にその傾向が強いとおもうんだけど，オンラインマルチプレイに対応することにより商品価値と寿命を倍増させ，それによって増えた売り上げでもって諸費を回収しようという算段だ。特に商品寿命が延びると，その後に出る関連製品（エクスパンションキットや続編作品）の売り上げにも影響するため，意外と相乗効果は大きいんじゃないかとおもう。
ちなみに，最近の PC ゲームがやたらエディットやらカスタマイズやらに対応しているのも，ユーザサイドコミュニティの発生を促進することによって商品寿命を延ばそうという意図が含まれているようだ。まあ，本当に効果が上げられているのはごく一部の製品だけだとおもうけど。
あと，今なにげに気が付いたんだけど， PSO って MM じゃないのにお金取ってるよなあ，とかおもった。あれってロビー＋ P2P じゃないんだろうか。ともかく，えーと，全国のサイバープロレタリアのみなさんは，なぜディアブロはタダなのに PSO は有料なのかという矛盾に気付き，そして声高に叫ぶべきだ。金を返せ，と。
んで，えーと，けっきょく何が書きたかったのかというと，ｉモードで儲けようなんてのがそもそも無理な話なんじゃよ，ということなんだけど。
2002-01-26
今週は土日休む予定だったんだけど，その，微妙な情勢の変化から，今日だけは出動することになった。早く健康を取り戻したい……。
気だるげに土曜の勤務をこなしつつ，ふと asahi.com を見てみると，今夜は大雨で，下手すると積雪するかも，とのこと。寒いのはイヤだけど，白く綺麗な雪が地面を覆い隠す様を見られたならば，この鬱屈とした気持ちも少しはマシになるかも，って，おもっていた。
あーでも，結局，積もらなかったね。見事な土砂降りだったわ。もう，やってられんて。
Baptista 氏のページより "real time ray tracing demos" 。
http://www.oroboro.com/rafael/project/raytrace.html
"Nature Still Suxx" は，なかなかいい感じのリアルタイムレイトレのデモ。ビジュアルとしての洗練度ではいまだ "heaven 7" がダントツなんだけど，他の方々もいろいろと頑張っているようだ。 "Nature Still Suxx" がまさにそうなんだけど，下手にスタイリッシュに走ろうとしない所がいいとおもう。こういうちょっと泥臭いパワーは，一時期のデモシーンの雰囲気を思い起こさせる所でもある。
あと，やっぱレイトレといえば CSG ですなー，とおもった。
それとそれと， Baptista 氏のページにも書いてあるんだけど，デモ中に "c" キーでフリーカメラモードになるのがちょっと面白かった。なんていうか，もはやレイトレでもこんだけインタラクティブに動かせちゃうんだなあ，っていうちょっとした感動があったかもしれない。頑張ればゲームとか作れそうだなあ，って。
2002-01-27
そんな訳で，今日はまるごと休日の日。束の間ではあるけれど，たっぷりと自堕落な生活を楽しんでみたりした。具体的には，ずっと寝てただけなんだけど。
radiumsoftware.com のホスティングをお願いしているレンタルサーバ会社からメールを受け取った。どうやら，月間転送量の制限である 1GB/month をオーバーしてしまっているらしい。うーむ，そんなに派手なことをした覚えはないんだけどなあ。しかし冷静に考えてみると，１ページの容量が平均で 30kB 程度だと仮定して， 35000PV 程度で 1GB に達してしまう。実際には画像ファイルやらアーカイブやらが存在するから，もっと簡単に 1GB に達してしまうことだろう。ああ，まさか転送量問題がおのれの身に降りかかろうとは。
しかし，こんなヘボいサイトでも開設初月に 1GB/month に達しているんだから，逆に言えばこの制限がきつ過ぎるのではないかという気もする。それなりに低価格なサービスを利用している以上，あまり文句は言えたものではないのだけど，サーバ移転も考慮に入れつつ，今後の方針を検討しなくてはいけないのかもしれない。
katastro.fi の「完成しなかったデモ」こと "codename chinadoll" を観てみた。
http://www.katastro.fi/www2001/gallery.html
フィルレート酷使型なんで解像度を落として観るのが正しいかもしれない。
畳みかけるようなビジュアルがいい感じかなあ。ねっとりと染み渡る感じの，ある意味とてもネムいデモ。 brothomStates の，一見綺麗なんだけど，やはり狂ってるって感じの BGM もいいかもしんない。
今後も katastro.fi はチェックしていこう，とおもった。
2002-01-28
体調はおおかた回復した感じ。酷い風邪にならなくてよかった。それはなにより。
そんなわけで今日はさっそく泊り込み。これからますます忙しくなってくるわけで，泊まったり睡眠時間を削ったりして稼いでいた個人的な時間も，どんどん減っていくことになりそうだ。
この前の法線ネタの続き "higher accuracy quantized normals" なんだけど，あまり難しいことでもなくて，投影する平面を
に設定するってだけの話。この前の方法では単に XY 平面に投影してたんだけど，これだと面に対して垂直に近い区域（z=0 付近）での精度が下がってしまう。ここで前回の "Compressed Unit Vectors" におけるマグニチュード表現が
の区域のみを扱っていることに注目すると，上のような平面に投影した方が，全域にわたって投影面と平行に近い関係を保つことができて，精度にムラが出にくくなる，ってことのようだ。
http://www.oroboro.com/rafael/algorithms/unitv2.html
前回のネタと併用すれば，精度を保ちつつ高い圧縮をかけることができる，ってことなんだけど，実用性という点ではちょっと計りかねるものがあるかなあ，とおもう。なにしろ単位ベクトルに限定された話だし，既存のアーキテクチャにのっけるのも難しいとおもう（たぶん「あるがままに」実装するしかないだろう）ので，正直どこに使ったもんだか，って感じだったりする。
2002-01-29
いつの日か調べた GJK アルゴリズムについていまだに調査中。とりあえず原書こと "A Fast Procedure for..." を読んでみているんだけど，基礎的な知識にあまりにも不足しているためか，読解がおもうように進まない。件の論文は，基礎となる部分から丁寧かつ正確な解説が展開されているんだけど，それでもやはり僕にとっては馴染みの無い概念が多くて，読み進めるのにとても苦労している。
http://coolee.tripod.co.jp/convex.html
凸包，ぐらいならわかるけど（出っ張ってるだけだからさあ），アフィン独立って？ うー。
あと， "L_2" （ラムダの下に２）って書けばいいところを "L^2" （ラムダの２乗？）って書いてあったりして，かなり戸惑りまくった。冷静に考えればそんなはずは無いんだけど，無いんだけど。
件の論文だけだと不足してたり冗長だったりする部分があるので， SOLID の関連論文 "A Fast and Robust GJK implementation..." とか Zappy 氏のメモなんかを併せながら読んでみている。
http://www.win.tue.nl/cs/tt/gino/solid/
http://www.codercorner.com/gjk00.jpg
http://www.codercorner.com/gjk01.jpg
Distance Algorithm まではそれほど難しい話でも無いんだけど，最短距離を求める要である Distance Subalgorithm が全然理解できない。再帰的に定義された式を必死に目で追って，処理の順序ならなんとなくわかった，って程度でせいいっぱい。なんでこれでラムダが求まるんだか，まったくわかったもんじゃない。
実は GJK はぜんぜん脇道で，本来は OBB の最適化手法とかを調べるつもりでいたんだけど，おもわず脇道の方にどっぷりとはまってしまった感じ。もはや半ば意地で読んでるだけなんだけど，そろそろ諦めちゃおうかなあ，とか，あーでも１回ぐらい実装してみたいなあ，とか，そんな感じで１月も終わりを迎えようとしている，ってわけ。
2002-01-30
「多くの場合において，テキストはそれ自体で十分なインタフェースとなり得る」の名言に従うならば，下手な GUI を数多く用意するよりも，テキストデータによる外部操作を積極的にサポートする方が，よりスマートなアプローチだと言えるだろう。そんなときに頭を悩ませるのが，テキストの構文をどのようなものにするか，っていう問題。以前はちょっとしたデータを記述するのにも，わざわざ専用の構文と専用のパーサを用意して対応していたもんだけど，最近ではならべく XML を使うような方向性を試みている。
http://www.asahi-net.or.jp/~ps8a-okzk/xml/
http://www.python.org/sigs/xml-sig/
XML を導入する以前から使用することが多かったのは， CSV 形式とか， INI 形式とか，そんなところ。 CSV は Excel から「カンマ区切りテキスト形式」として出力することができるので，データの整理・編集にスプレッドシートを使いたい場合なんかによく利用する。あともう一方の「 INI 形式」ってのは，たぶん正式名称ではないんだけど，要するに Windows の .ini ファイルで使われている構文のことだ。これは Python の ConfigParser モジュールで簡単に扱うことができるので， Python との組み合わせでよく利用していた。
http://www.python.org/doc/current/lib/module-ConfigParser.ht...
この他にも，簡単なパラメータ記述程度のものだったら自前で用意することも多い。 lex を使うこともあったけど，けっきょく yacc に手を出すことは無かったような気がする。
XML に手を出す前にパーサジェネレータを調べ回ったことがあったんだけど，最近では "ANTLR" なんてのが有名らしい。 Python なら "Yapps" などが代表的なものとして挙げられるようだ。今回は見送ったけど，そのうちお世話になることもあるかもしれない。メモメモ……。
http://theory.stanford.edu/~amitp/Yapps/
それで， Aba 氏の BulletML を見て以来，データ記述に XML を使う，ってのは，意外といける方法なんじゃないかとおもったわけ。実際に使用してみると，かなり奥が深くて，広範囲に応用できるような構造になっていることがわかってきた。タグのせいで少々冗長になる傾向はあるものの，これは編集に専用のアプリケーションを使用することで改善できるだろうとおもう。テキストエディタでもそこそこいけるけどね。
とりあえず今の段階では， Python から XML 文書へのアクセスを行う方法しか試していない。 Python の XML モジュールは James Clark の expat ライブラリをラップしたもので，インタフェースは SAX 互換と DOM 互換のものが用意されている。
SAX はイベントドリブン（コールバック）的なノリのパーサで，線形的に構文解析しつつ要所でコールバックが呼ばれるような感じ。 DOM の方はもうちょっと高級で， XML 文書をツリー構造状のオブジェクトに変換してしまうというものだ。 DOM の方が扱いも便利だし，より自然な実装だとおもうんだけど，全文書を同時にメモリ上へ展開するので，意外とリソース量が要求されるようだ。 SAX ならばアプリケーションの都合次第でどうにでも組めるので，たいていの場合，実行効率は SAX の方が良くなるんだろうとおもう。
それ以前に Python の DOM インタフェースはあまり最適化が行われていないようで，ロードにやたら時間がかかるという問題がある。 SAX との差は体感で数倍程度のものだ。そんなわけだから，しばらくの間は SAX を使わざるを得ないだろう。
2002-01-31
昨日から泊まり。今日はたまたま睡眠のバイオサイクルと起床予定時刻のタイミングが適合していなかったようで，目覚ましアラームを余裕で無視して睡眠を続行してしまうという暴挙に出てしまった。ようするに寝過ごした。職場に泊り込んで寝過ごしてしまったときほど，自分が間抜けに感じることは無い。なにをやってるんだ，僕は，って感じで。
寝ぼけまなこで Gaming-Age Forum をチェック。海外のゲーム系掲示板ではここを中心にチェックするようにしている。たぶん ign や GameSpot の方がポスト数では勝っているんだろうけど，あまりにもボードが細分化されてしまっているために，チェックするにも手間がかかりすぎてしまうというデメリットがあるのだ。 Gaming-Age の Forum は主として General Forum に一本化されているんで目を通しやすいし，そこそこ盛り上がっているので情報量的にも悪くないレベルだとおもう。
例えば，今日のポストより。
http://pub37.ezboard.com/fgamingageforums2frm0.showMessageRa...
http://www.psxnation.com/news/newsstory?idnumber=000997
どうやら Rez の北米版の生産が発売より数日で停止されたらしい。うーむ。国内よりもむしろ北米や欧州での売り上げを期待されていたような気がするんだけど，やはり向こうでもニッチ的な扱いにされていたようだ。
音モノは難しいなあ……。
セガ繋がりなんだけど， Xbox の "Gun Valkyrie" に期待を隠せない今日この頃。
http://www.smilebit.com/jpn/game/gunvalky.html
ネタ的には Microsoft/SINGLETRAC の "OUTWARS" なんだとおもうけど，そこはセガのゲームパブリッシャーとしての実力に期待したいところ。 "OUTWARS" は，まさに洋ゲーの「詰めの甘さ」とか「大味調整」に泣かされた作品なので， Gun Valkyrie の方はきっちりと和風なコテコテ調整でひとつお願いしますですよ，とおもったりするわけで。
http://www.microsoft.com/JAPAN/games/outwars/default.htm
この手の変態操作系 FPS にはまったく目が無いんだけど，そんな僕としては GC の 「メトロイド・プライム」に期待せずにはおられない今日この頃。とかそんな話をどっかでしたもんなら，必ず満場一致で突っ込まれるんで困る。一般的に見て，そんなにダメなのか，あれは。