P/ECE

2001-09-01

きょうは休日なので寝まくり。で，夕方５時ごろに起床。うーん，だいぶ日が短くなってきているもんだから，外はもう薄暗くなりはじめてるみたいだ。今年も何もしないうちに夏が過ぎ去ってしまったなあ，とちょっと感傷的になってみたりしたけれど，それについては深く考えないことにした。

目ざましがてらに，てきとうにウェブを見まわしてみると，オルトアールのＭＬ５にガビン伊藤さんのこんなポストが。

アクアプラスってえと，美少女ゲーで有名な「リーフ」ブランドの本体であるところの会社なんだけど，どういった経緯なんだか知らないけど携帯端末（携帯ゲーム機）を出すことになったらしい。うーん，美少女ゲーってそんなに儲かってたんだろうか。

で，問題の"P/ECE"なんだけど，まあ，わりとあっさりした仕様の携帯マシンで，ＰＣとの接続が前提となってるところ（カートリッジスロットは無くて，ＵＳＢインタフェースが標準でついてる）とか，ロイヤリティーフリーをうたっているところなんかが，変わってるていやあ変わってるかなあ，とおもう。明らかに同人市場にターゲットを置いているわけなんだけど，そこにアクアプラスっていうブランド力が加わると，結果としてどんな世界ができあがるんだろう，ってところには，ちょっと興味があるかもしれない。

個人的には，仕様やデザインの面で，あまり欲深にならずに，わりとあっさりとした割り切りをしているところに，ちょっぴし好感が持てる。身分相応な仕事をするのは，いいことだとおもうのだ（←なにげに失礼だ）。９８００円はちょっと高いかもしれないけど，本体だけでもとを取ろうってことだろうから，まあしょうがないかな，とおもう。

ＤＭＣをクリア。噂には聞いてたんだけど，ラスト付近の進行はいろんな意味ですごいことになってた。ようやるなあ。で，ストーリーの方は，なんていうか，あほらしくなるくらい陳腐ではあるけれども，いちおうストーリーとして破綻はしていないようなので，鬼武者よりかはまともだったかな，ていうことにしておこう。

PyOpenGL

2001-09-02

昼間に起床。夕方，出社。なにげにもう９月なわけで，きっといまごろ全国の小中学生たちがせつない気分になっていることだろうとおもう。まだ残暑ってやつで少し暑さを感じるころあいだけど，前ぶれもなくにわかに涼しくなったりするから気をつけねば，とおもった。

なんとなくPyOpenGLを試してみることにした。PyOpenGLは，名前からわかるようにPythonのOpenGLバインドだ。なにげに思いついたネタを実験してみたり，プロトタイプを作ってみたりするのに便利かもしれないな，とおもって，試してみることにしたのだ。

まずはWindows用で実験。僕はふだん，cygwinに同梱のPython(python2.1,cygwin-nt4.0)を使っているんだけど，PyOpenGLのサイトにはこれ用のバイナリパックが置いてない。しょうがないので，ソースをダウンロードしてビルドすることにした。

ところが，この手順はあえなく失敗。PyOpenGLはcygwin版Pythonにまともに対応していないらしくて，なかなかコンパイルが通ってくれない。いろいろいじくってコンパイルは通るようになったんだけど，こんどはリンクで止まってしまう。なんか，cygwin版Pythonのdistutilにも問題があるようなそぶりが見える。だめだなあこりゃ。

けっきょくcygwin版Pythonを使うのはあきらめて，Python for Windowsと，それ用のPyOpenGLバイナリパックを使うことにした。ちょっと不安だけど（VC++がないので，いざというときにリビルドできないのだ）。

次に，Numerical Python (Numpy)とPython Imaging Library (PIL)も同時にインストール。Numpyは数値配列の演算をネイティブでやってくれるモジュールで，演算の高速化のために推奨となっている。PILは各種フォーマットの画像ファイルを扱うモジュールで，テクスチャ画像を扱うのに便利なアイテムだ。

Windows用の環境は以上で完了。次に，Linux用の環境も用意してみることにした。

ついでなので Python自体も2.1.1 にバージョンアップすることにした。ちなみにPython2.2がもう出てるんだけど，とりいそぎ必要そうではないので見送ることにする。で，Python2.1.1-3のrpmをダウンロードしてインストールしてみるんだけど，rpmがわがままをいって入れさせてくれない。しょうがないなあ。ソースからビルドだ。

ビルド作業は'./configure;make;make install'でほぼ問題ないんだけど，僕はPythonコマンドラインをよく使うので，Modules/Setupのreadlineの項目を有効にしておく。それだけ。

PyOpenGL,numpy,PILのインストールは，ほぼ問題なし。どれも２，３ヶ所変更が必要だったけど，特に大きな問題はなく完了した。

とりあえずサンプルでティーポットを出してみる。

うーん。タイプ量としてはCで書くのとほとんど違わないような気がする。GLの部分にまったく違いはなくて，ほかの部分で手が抜きやすいとか，PILで画像が気軽にあつかえるとか，メリットはそんなとこかな。しばらく触って見極めてみようとおもう。

なにげにのぞいてみたページなんだけど，こういうのに猛烈な郷愁をおぼえてしまうのは，なぜなんだろうとおもう。

Numerical Python

2001-09-03

PyOpenGLを触りつつ，手始めにNumerical Pythonを探ってみることにした。

Numerical Pythonは基本的に数列（Numeric.Arrayクラス）を扱うライブラリで，数列の組み合わせで行列なんかも扱えるようになっている。んで，数値解析とか統計に必要そうな関数はひととおり揃っているみたいなんだけど，どうもＣＧ方面には向いてなさそうな雰囲気がする。使おうとおもえば使えないわけでもないんだけど，関数のセットが違和感出しまくりなのだ。うーん，どうもこりゃ，ちょっとスジ違いだったかもしれないなあ。

しょうがないんでThe Valtsとかをあたってみたんだけど，どうもよさげなライブラリがない。おとなしく観念して，自分で作るしかないかな。あとはBlender方面をあたってみるってのも手かもしれない。ちょっと深追いになりそうなんで，ならべく避けたいんだけど。

ひさしぶりに雨が降って，ちょっと肌寒くなってきた。いわんこっちゃない。ぼろぼろの靴に雨が冷たかったけど，ひさしぶりの雨はなんとなく気持ちいい感じがしたので，あまり嫌ではなかった。

大崎

2001-09-04

今日はCEDEC初日。今年はMark J Kilgard先生の講演があるとのことで，見物しに行きたい気もしたんだけど，いちおう忙しいんでパス。そのかわりっていうか，CDDECの後に開催された謎のイベント「大崎８耐」に参加してきた。

メンバーは，ほんださん，狩野さん，はなげさん，RYOKOさん，川地さん，黒田さん，ミキタさん，Beeさん，つよぞうさん，Masaさん,フラチキさん，よっしんさん，の計１２名。かなりやばい濃度のメンバーだなあとおもう。

８耐ってのはノリのいい冗談かとおもってたんだけど，なんだかんだいってけっきょく，ほんとうに８時間，夜から朝まで飲みあかしてしまった。今日はまだ火曜ですよ，ってに。

まあでも，とびきり濃厚でマニアックで，とにかくたのしい８時間をすごせたんで，結果的には最後まで付きあってよかったとおもう。たまにはこういうのもいいでよ，ってことにしておきたい。

個人的にいちばんの収穫だったのが，狩野さんご本人にお会いできたこと。とても気さくな性格のかたで，軽やかで流れるような語りくちに，深夜も過ぎて眠りまなこの僕は，まるで天上からの神託を授かるかのような不思議な気持ちで，ただ神妙に聞き入っていたような気がする。

正直，よくおぼえてないんだけど。

その後

2001-09-05

大崎８耐で朝まで飲み明かしたあと，帰って休む隙もなさそうなんで，職場に戻って就寝。とにかくちょっとでも睡眠を稼がないと。

けっきょく，６時から５時間寝て，コアタイム突入と同時に起床した。それほど調子はわるくない。今日はてっきり仕事にならないかとおもってたんだけど，わりとむちゃできるもんだなあ，とおもった。

ひきつづきPyOpenGLをちょこちょこと。

けっきょく，Numerical Pythonやもろもろの数学ライブラリの使用はあきらめて，お手製のライブラリでいくことにした。まあ，そんなに小難しいことをやるわけでもないし。

それでも唯一気になるのはPythonの処理速度の重さだ。Pythonは意外とあなどれない重さを持っているスクリプト言語なので，実験用としても油断できないのだ。将来的にはネイティブで作り変える必要がでてくるかもしれない。

ちなみに，個人的な経験や一般的な評価からいって，perl < Ruby < Python の順に処理が重くなるんだけど，とくにRubyとPythonの間には，わりと体感できるぐらいの差があったりする。それでもあえてRubyからPythonに移ったあたりに，ひとつの葛藤があるのだ。

で，PyOpenGLはネタ実験用として使いはじめているんだけど，OpenGL自体に対して勘をなくしかけていて，なかなかこうスムーズにいってくれない。

ディスプレイリストを作るには？ αブレンディングするには？ ブレンド関数の設定は？ テクスチャをバインドする手順は？ テクスチャをモジュレートモードにするには？ 補間をＯＮにするには？

まあ，すぐにおもいだすんだけど，できることなら，マニュアルも見ずにすらすらと書けるぐらいで行きたいもんだねえ，とおもった。

fur

2001-09-06

ちょっぱや

2001-09-07

きのうのfurをWindows上で動かしてみる。予想できたことなんだけど，天と地ほどの速度差があった。Linux上で作っていたときは，Mesaにレンダリングさせていた上に，ＸをＬＡＮ経由で飛ばしてた（しかもＸサーバはPS2Linux）ので，まあこれ以上の遅さはあるまい，ってほどの遅さだったのだ。

ソースのリポジトリをちょいと覗こうとおもってイントラサーバ上のViewCVSにアクセスしたんだけど，あえなくエラー。どうも，２・３日前にサーバをリプレースしたときに，なにか設定をしくじってしまったらしい。ちょこっと調べてみると，どうやらRCSが入ってないためにViewCVSが止まっていたようだ。RCSを直に使ってるのか，こいつは。ついでにViewCVSをv0.7にバージョンアップしておく。

ViewCVSは，SourceForgeなんかで使われているCVSWebのPython版クローンなんだけど，これをWEBサーバに突っこんでおくだけで，CVSのGUIフロントエンドとか必要なくなるんで，けっこう気に入っている。てきとうなブラウザさえ用意しとけば，クライアント側のプラットフォームを気にする必要もないんで，ここみたいな混沌としたマシン構成のところでも安心だ。

なんでもイントラ化して中央集権すればいいってもんでもないんだけど，少なくとも，複数人でのコラボレーションを支援する環境については，イントラ化が役に立つことが多いとおもう。そんなわけで，そろそろ，あの憎きLotus Notesを排して，WEBベースの何かに置換しちゃいたいものだ，と画策している。

今日はさそわれて突然の飲みでしめくくられた。親しいひとたちと，まったりとアルコールを摂りながら，しずかに歓談しているうちに，おもわずうたたねをうってしまう。そんなのって気持ちいいなとおもった。

今は，さっきのアルコールがアセトアルデヒドの残滓となって，頭をがんがん叩いてくる。これは気持ちよくない。アルコールは，やっぱり，あまり好きではないとおもう。

じめじめ

2001-09-08

夕方は６時に起床。土曜日はいつもこんな調子だけど，さすがに今日は寝すぎてしまったようで，逆に調子が悪い。なんだか微妙に喉の奥が痛いような気がする。いつまでも暇じゃないんだから，ちゃんと摂生しないといけないんだけど。

メシでも食おうかと外にでてみると，路面がしっとりとぬれている。雨が降ったのか。そういえば，なんだかすごく湿度が高いような気がする。じめじめ，むし暑い。ひさしぶりにエアコンの除湿機能なんてものを入れてみるものの，効いてるんだか効いてないんだかさっぱりわからない。そんなダメダメな雰囲気のまま，まったりと週末が過ぎてった。

PyOpenGLがそれなりに使えることはわかったんで，ネタ作り環境としてもうちょっと洗練してみようとおもう。まずは，ユーザーインターフェースの改善だ。とはいってもそんな大それたことじゃなくて，オブジェクトの回転操作方法を改善したいってとこ。いまは，単純なオイラー角ベースの回転操作を実装してあるんだけど，これはいくらなんでもやばい。これを仮想トラックボールに置換してみようとおもう。

仮想トラックボールを使うには，とりあえずクオータニオンの基本操作が必要だ。そんなわけで，自前のライブラリvecmath.pyにクオータニオンクラスを追加した。作ってる途中で何度か参考書を見たくなったんだけど，それらの書籍はみんな職場に置いてしまっているので，どうにも参照できない。歯がゆい。

職場で調べものとか頻繁にするようになると，それまで家にためこんでいた資料や機材がほとんど職場に移されてしまう。そうなると，いざ家でなにかを作ろうとおもったときに困ってしまうのだ。どうにかならんもんだろうか……。

おなじような問題はいろいろあって，たとえば，ブラウザのブックマークを管理するのとか，なかなかむずかしい（めんどくさい）とおもう。昨晩家でブックマークしたあのページがいま職場で見たいのに！ なんてシチュエーションがわりとあるのだ。すくなくとも僕は。

ちなみにこれは，Yahoo! Bookmarkを利用することで解決できた。家と職場でまったく同じブックマークを参照・編集できるんで，同期に気を使う必要がまったくなくなったのだ。最近はYahoo! Mailなんかも利用していて，だいぶYahoo!に助けられているような気がする。

あとは，出勤途中に買ったＣＤとか，ほとんど職場に置いてしまってるんで，家にほとんどＣＤがないって状態だったりする。まったくの無音のなかで黙々とプログラミング。まあ，いいとおもうけど。

knots

2001-09-09

昼起床。まだ喉が微妙に痛い。シャワーを浴びてもいまいちすっきりしない。今日は夕方から出勤するつもりだったんだけど，この調子じゃあまりがんばれなさそうだし，無理をして体調をくずすのもばからしいので，ふつうに休むことにした。

メシを食いに街に出る。かぜ薬を切らしてたんで，マツキヨによっててきとうに薬を物色してたんだけど，なぜか狂ったように汗がふきでてくる。やばいんじゃないの，これ。よくあるかぜの症状。出勤しなくてよかった。

夕食は松屋。平日にぜいたくな食事をしてるんで，休日は粗食なのだ。キム・カルビ丼なる新メニューが追加されてたんで，それを食してみる。まあ，想像したとおりの安っぽい味。キムチ牛めしよりも，ちょっとしつこめの味だ。僕は牛めしのさっぱりしてチープな味が好きなんで，こういうのはあんま好きではない。次からはまたキムチ牛めしにしよう，とおもった。

帰りぎわに夕立にふられた。ほんと，シャワーみたいな雨。ずぶぬれになった体を乾かし，本を読みながら寝そべっていると，さっき飲んだ薬の効果か，軽い眠気が忍びよってくる。そのままだるく午睡（もう夜だけど）。ほんとだるい一日だったなあ，とおもった。

あいかわらずPyOpenGLをいじってみる。PyOpenGLにはGLE (GL tubing and Extrusion Library)という，いわゆる「押し出し」を簡単におこなうためのライブラリがついてくる。なんでこんなオマケがついてるんだかちょっと謎だけど，おもしろそうなんでいじってみようとおもった。

ネタ元はPaul Bourke先生の"Knots"。Paul Bouke先生のページと，イームズ先生の"Powers of Ten"は，僕の学生時代のバイブルっていうか，マイベストフェバリットっていうか，センスオブワンダーっていうか，モーストレスペクタブルっていうか，つまるところほんと科学的素敵な人たちです（←単なるミーハー）。

んで，とりあえず作ってみたものの，やっぱり影を落とさないと写実性に欠けるなあとおもった。こういうモデルにきれいにセルフシャドウイングするのは，ちょっと簡単ではないかもしれない。Kilgard先生のシャドウマップでも勉強してみようか。そのまえに，BMRTにレンダリングさせてみるのもおもしろいかも，とおもった。

cubemap

2001-09-10

微妙にだるい。

天候はどうしようもなく不安定だし（いちおう台風が来ているらしい），ねっとりと肌にまとわりつくような湿気が，体の重さをいっそう増しているような気がする。秋ってのは，もっと，からっとした天気をおもいうかべるもんだけど。

ふと，昨日こしらえた"Knots"に金属的な環境マップをつけたらいい感じになるんじゃないかなあ，とおもい立つ。環境マッピングに対する興味がふつふつとわいてきた。

僕は，環境マッピングっていうと，いんちきスフィアマップぐらいしかやったことがなかったんで，まずは環境マッピングのおさらいからやる必要がありそうだ。

まずスフィアマップで問題点となるのは，テクスチャイメージが視点に依存してしまうということだ。まあ「マテリアルとしての環境マッピング」程度だったら，スフィアマップをだましだまし使えばなんとかなるんだけど，車のボンネットの反射とかをスフィアマップでしのぐのは，ちょっとつらい。

そんなスフィアマップの制限を克服するために，視点の移動に追従できるように工夫された手法がいくつか考案された。Kanoさんのページにある"Dual-Paraboloid Environment Mapping"なんかが，それだ。これで静的な環境マッピングについては，なんとかなったわけなんだけど，動的な環境マッピングになるとまた話が違ってくる。これらの方式ではテクスチャイメージの生成方法が複雑すぎて，リアルタイムに対応するのはほぼ不可能だからだ。

そんな変遷があって，最近のトレンドとして注目されてきたのがキューブ環境マッピングだ。こいつは，つまるところ上下左右前後の６枚の画像を用意するだけで全方位の環境マッピングに対応することができる。原理もすごく簡単で，その６枚の画像を無限遠に投影してるだけ。すると，法線と箱の交点から単純にＵＶを求めることができる（←ここかなりいいかげん）。

こんな単純だと，箱のキワのあたりとか歪んじゃうんじゃないだろうか，とかちょっと心配になるんだけど，そこはまあ，あんま気になりませんぜ，ってのがおおかたの同意となっているらしい。

唯一やっかいなのが，箱の切れ目をまたいでしまうようなマッピングになった場合に，１枚のポリゴンに対して２つのテクスチャをうまく貼り合わせなきゃならない，ってところ。むかしは，こういうところだけステンシル＋２回描きとかで解決してたみたいなんだけど，最近では「ハードウェア的に」キューブ環境マップに対応しているため，ぜんぜんそこらへんは気にしなくてもよくなっている。

この「ハードウェア的に」ってのが，レンダリングパイプラインのどこらへんに位置するんだか，さっぱり見当がつかないんだけど，とにかくまあ，ＧＰＵのなかでうまいこと処理されているらしい。最近はすっかりＰＳ２ボケしてしまっているんで，こういう，ＰＣ業界におけるＨＷとＡＰＩの急速な進化についていけなくなってるなあ，と，ちょっとおもった。

テロ

2001-09-11

すさまじくて，ほかのことはどうでもよくなってしまった。

職場でなにげに仕事していると「すごい事件がおこった」とささやく声が。ＴＶの前に行くと，２機めの飛行機が貿易センタービルに激突する映像が流されていた。想像を絶するショッキングな映像に，みんなＴＶの前に釘づけ。あーでもない，こーでもないとわめきながら，しばらくやじ馬見物にいそしんでいた。

そうこうしているあいだに，国防総省にも墜落機が，との速報が入る。え，あのペンタゴンに特攻？ っておどろいていたのもつかのま，こんどは貿易センタービルが倒壊する映像が。

リアルタイムに進展する状況。だれもの想像を絶する映像。まさに前代未聞。

この事件がはたして何を意味しているんだか，そしてこのさき何を引き起こすんだか，僕にはよくわかんないけども，とにかく，とんでもないことが起こったもんだ，という衝撃だけがただ僕の心を昂揚させていた。

Per-Pixel

2001-09-12

PyOpenGLに浸りぎみな昨今。当初は，かるーく３Ｄとたわむれる程度って使いかたを想定していたんだけど，先日やったキューブマップみたいに，意外とディープなつかいかたもできることがわかってきたので，調子にのっていろんな拡張機能をためしてみようか，とおもいはじめた。

とりあえず，nVIDIAのサイトからCass Everitt氏の"Mathematics of Per-Pixel Lighting"を落とし，PSIONのなかにつっこんで家を出る。電車のなかで読むのだ。

僕はいままで，Per-Pixel Lightingっていうと，環境バンプマッピング（Environment Mapped Bump Mapping - EMBM と略すらしい）のことかなあ，とか，そんなばくぜんとした情報しか持ってなかったんだけど，実際には，そんな時代はすでに過去のものになろうとしているようだ。

じゃあ，実際にはどんなかんじになっているのかというと，Per-Pixel Lighthingという言葉があらわすとおり，ほんとうに「ピクセル毎」に「まともな照明演算」をやってしまう，ってノリになっているらしい。

それも，ひとむかし前までは，「内積バンプマッピング」に代表されるように，ブレンド関数をトリッキーに組み上げた手法が多かったんだけど，GeForce3になると，ちゃんとピクセルごとの法線と光源情報から照明演算をおこなうことができ，しかもそれが"Pixel Shader"をつかうことによって，かなり汎用的な書きかたができるようになっている……，ってなところまで来ているようだ。

くだんの資料を読みすすめてみると，僕の知らないあいだに，いろんな手法が生まれては改善され，捨てられては作りなおされ，そしていまのかたちにたどり着いた……，って雰囲気がなんとなく伝わってくる。

GeForce2までは，Per-Pixel Lightingといえばサーフェス座標系で処理されるものだったらしい。この場合，あらかじめ光源のたぐいは頂点ごとにサーフェス座標系に変換しておいて（ここらへんで"Vertex Shader"が活躍してくれる），そのうえで照明演算をやっていた。サーフェス座標系なら，法線マップ（バンプマップ）から得られたベクトルをいじることなく，そのまま内積にもっていくことができるからだ。

ところが，サーフェス座標系での処理には，数式上のいろんな制限が付きまとってしまう。これを克服するには，フラグメントごとにサーフェス座標系→視点座標系への変換行列が得られるようになっていればいいんだけど，GeForce3では，これがほんとうに得られるようになってしまっているのだ。

ひとたび視点座標系に変換してしまえば，いままでどおりの照明計算を使うことができるし，そこからキューブマップなんかに持ってくことなんかも簡単なわけで，もうここまでくるとなんでもありのような気がしてくる。

といったかんじで，なんだかものすごい可能性をひめているような気がするPer-Pixel Lightingなんだけど，なんでもできるように拡張されつづけてきた反面，具体的になにかをするには大変な労力と知識が必要とされるみたいだ。これ自体はあくまでも部品であって，具体的なアルゴリズムと結びついた状態にはなっていないからだ。

単発のデモをつくる程度だったらなんとかなるとしても，ちゃんとしたシステムに組みあげようとおもったら，かなり脳みそがしぼれるんじゃないかとおもう。

まず，実際には何がどこまでできて，何がどうできないのか，ってところがなかなか見当つけにくい。僕だったらたぶん，１作目はもう実験ってことでわりきっちゃいましょー，とかそんなノリになってしまうんではないかとおもった。

EMBM

2001-09-13

一度ぐらいEMBMもいじってみたいものだなあ，とおもい，その筋の資料をあさってみる。しかし，なかなかいいものがみつからない。リフレクションマップやPer-Pixel Lighting関連の資料もあたってみるんだけど，たいていEMBMに対してはネガティブな意見がそえられていて，まともな解説がみあたらない。もう使うなってことですかこれは。

それじゃあとりあえずなんでもいいからPer-Pixelしてみるべえ，と，デモや資料をあさってみるんだけど，GeForce2でまともなPer-Pixel Lightingを実現しているデモってのも，なかなかみあたらない。

とくにおどろいたのが，Demos & Visual Effectsのセクションにあった"2-pass Environment Mapped Bump-mapping"ってデモ。内容を要約すると，ピクセルごとに法線（バンプ）と視線ベクトルを得て，そこから反射ベクトルを求めてキューブ環境マップする，ってデモだ。

まず，register combinerをつかって視線ベクトル画像を描きこむ，ってところまではいいんだけど，そこからどう展開するのかとおもったら，さっきの画像をglReadPixelsでふつうにＣＰＵ側に拾いあげたあと，点プリミティブ（GL_POINTS）を使って１点づつキューブマップしている。おにいさんこれちょっとやばいんじゃ……。

まあ，そんな調子で，nVIDIAのdev-relサイトにある大量の資料をさばけきれずに，むしろその資料の海に中におぼれ沈んでいく感じだった。

なにげに，register combinerに関してほとんど知識がないのもつらいとおもう。だからといって，いきなしOpenGL Extension Registoryとか読んでもむちゃなので，なんかお気楽な資料とかないかなあ，ってあさり回ってみるんだけど，なかなか大量の資料をさばききれずに四苦八苦する。

それに，register combinerって，pixel shaderが本格的に使われはじめたら存在意義がなくなっちゃうんじゃないかなあ，っておもうのだ。それだったら，いま無理に勉強する必要もないんじゃないかなあ。とはいってもpixel shaderを使うためにはGeFroce3が必要なわけで……。もうGeForce3買っちゃうしかないかなあ。

とか悶々としたりする今日このごろであった。

oldschool

2001-09-14

最近，ちょっと睡眠不足傾向にある。いろいろとくだらないことで夜更かししすぎなんだな。それにしても眠い。仕事中には寝ないようにがんばってるけど。いやはや。

なにげにoldskool.orgなぞを読みかえしてみた。ひさしぶり。

oldskool.orgは，HornetのメンバーのひとりであるTrixter氏が，デモシーンを去るのと同時にたちあげたサイトだ。まあ，国内にもわりとよくある懐古系のサイトで，古きよき時代のＰＣ（IBM-PC）シーンのエッセンスについてつれづれと書かれている。

AmigaでもAtariでもCommodoreでもなく，IBM-PCってところがちょっとおもしろいかもしれない。IBM-PCってのは，日本でいうならＰＣ９８みたいなもんで，台数的にはもっとも普及していたものの，ＡＶ機能については考えうる限りの最低っぷりを誇っていた，そんなマシン。

だから，まともに遊びたいひとたちはApple][とかC64を選んでいたわけで，そんな状況であえてIBM-PCをえらんだひとたちってのは，C64みたいなことをPCでやるとすごい！ とか，AmigaみたいなことをPCでやるとすごい！ とか，そういう迂曲したモチベーションとコンプレックスをかかえながら成長していくことになる。

まあでも，そんな限られた機能のなかでいかにがんばるか，いかに模倣するか，いかにフェイクするか，ってところで彼ら（僕ら？）は楽しんでいたわけで，それはそれですごく恵まれていたのかもしれない。

それにしても，ビープ音デバイスでＰＣＭ再生とか，いま聴いても萌えますわ。それでおもいだしたんだけど，当時，むちゃ感動したサウンド系ハックのひとつに，プリンタポートで音声出力ってのがあって，どこのだれが考えたんだかしらんけど，プリンタポート（いわゆるセントロニクス）が音声出力デバイスとなりうる電気的特性と処理能力を持っていると見切ったひとがいて，じっさいにそれで音を出したり，デモを作ったりしてしまっていたのだ。ちなみに音質のほうは，少なくともビープ音よりかはよかったようだ。実際に聴いたことはないんでしらないけど……。

デバイス系ハックでいうと，Ｘ６８ｋのＳＡＳＩをＳＣＳＩとしてつかってしまう，ってのも，かっこよかったなあとおもう。最近は，そういうロマンチシズムなハックはないんだろうか。

ぼんやりデー

2001-09-15

amazon.co.jpで注文した"Game Programming Gems 2"がやっと届く。かるく目を通してみると，うわさどおりっていうか，前作にも増して節操のない品揃えになっているような気がする。まあでも，ゲームプログラミングなんてなんでもありの世界なので，これでいいんでしょう。

OpenGL SDK 5.1をNVIDIAのサイトからダウンロード。約６０ＭＢもあるＳＤＫだ。こんなデカいの落としてられるかー，って避けていたんだけど，やっぱ内容が気になるんで，重い腰をあげてダウンロード。

やっぱりブロバンなのかねえ，っておもうけど，サーバの都合ってのもあるし，下流が速くなったところでしあわせになれるかどうかは微妙なところなんじゃないかな，とおもう。

ところで，NVIDIAって，nVIDIAとか，nVidiaとか，いろいろ綴られててどれが正しいんだかよくわからない。ちょっと気になったんでNVIDIAのサイトで調べてみたところ，'NVIDIA'とすべて大文字で書くのが正しいようだ。ちなみに，読み方は「ぬビディア／にゅビディア」でいいらしい。'n'はギリシャ文字の「ニュー（ν）」をあらわしているのだ。

NV Effects Browser

2001-09-16

いまや，NVIDIAのdev-relサイトにあるデモのほとんどはNV Effects Browser専用となっているんだけど，このEffects Browserがなぜかうちでは動かない。実行するとあっというまに一般保護例外で飛んでしまうのだ。

んな状態のまま，ずっと不思議がってたんだけど，今日なにげなくダウンロードしなおしてみたら，ちゃんと動いた。むふー，なんてこったい。ダウンロード失敗してただけか。何ヶ月ぶんもむだにした気分。

んなもんで，エフェクトをさんざ閲覧。とくにお気に入りは"Bump Refraction"。リファレンスラスタライザでしか動かないけど，迫力はじゅうぶん伝わってくる。ていうかこれ狩野さんのだ。すげー。

ますますGeForce3が欲しくなったけど，あいにく家のＰＣはＮＬＸなんで普通のＡＧＰビデオカードは使えない。ハーフハイトでGeForce3級なビデオカードはすぐには登場しなさそうだし，いっそのこと会社のマシンにぶっさそうかと画策中。でもこれ，公私混同っていうのかもしれない。

おさえて，おさえて。

天気なんて関係ないけど

2001-09-17

朝１１時。100BASE-T仕様の安物ハブが，劣悪なトランスにつきものの共振音を放ちつづけている。これまた安っぽいサンヨーのアラームが，共振音にかき消されてしまうぐらい微かな電子音で定刻を告げると，僕は寝袋のなかから跳ね起きる。おはようさん。今日もいい天気。天気なんて関係ないけど。

どっかのページでSDL版Kobo（SKobo）がリリースされたとの情報をみかけてたのをおもいだす。さっそくダウンロード。んで，とりあえずPS2Linuxでコンパイル。途中，VSyncを取りたさげなところでコンパイルが止まったんだけど（VSync取るのにRDTSC使ってる……），そこをブッた斬ったら，あとはほぼ問題なし。ただ，低解像度で動くんで，640x480の画面に320x240のちっこい画面が出るっていういつものパターン。いいかげんどうにかするべきだなあ。

ゲームのほうは，やっぱりというかなんというか，おもしろい。xKoboがでた当時は，Ｘで動くおもしろいゲームっていう希少価値がバイアスされていたような気がするんだけど，やっぱりこのゲームはピンでも十分におもしろいとおもう。ステージ構成と攻撃パターンの展開のしかたが，なかなかうまいなあ，とおもうのだ。

Windows版も用意されてる。ちょっと流行らせたいかも。

いやなぐらいの残暑っぷり

2001-09-18

さいきんめっきり季節感を失ってしまった僕は，９月っつうと暦の上ではもう秋なんじゃねえのとか勝手にきめこんで，これから涼しくなりますぞーっと無闇にはりきっていたんだけど，これがぜんぜん涼しくなんない。今日もいやなぐらいの残暑っぷり。都会特有のねっとりとした日光がアスファルトの輻射熱となって，昼めしを食いに出た僕たちを容赦なく蒸し上げる。もうやめやめー，残暑やめー。いますぐ秋開始。よろしく気象庁。

「当たり判定１ドット」シューティングこと「サイヴァリア」がＰＳ２に移植される模様。

独房かどこかにで生活したほうが

2001-09-19

ねむい……。家に帰るとつい夜更かししてしまっていかん。無駄な夜更かしのおかげで，家での平均睡眠時間は4.5時間ぐらい。会社に泊まるといつもだいたい6時間ぐらい寝てるんで，会社に泊まったほうが健康的という嫌な生活パターンになっている。

いっそのこと，独房かどこかで生活したほうが，よっぽど効率的な日々を送れるんじゃないかとおもうこともある。その場合の人生の価値についての定義って，かなり難しいとおもうけど。

Game Programming Gems 2の"Micro-Threads for Game Object AI"をななめ読み。マルチスレッドがＡＩの記述に便利，ってことについての説明や，ＯＳのマルチスレッドサービスを使うことに対してのデメリットについてなどは，ほぼ賛同。ほとんど同じことを考えている。

で，この記事では，ＯＳのマルチスレッドサービスの代わりに"Micro-Thread"とよばれるミニマムな仕様の自前マルチスレッドを用意してしまおう，って展開になってるんだけど，この"Micro-Thread"の実装方法については，ちょっとついてけない部分がある。

ようするに，自前でコンテキストの切りかえやスタックの管理をしてしまえば，マルチスレッドを実装したも同然よ，ってノリなんだけど，これを安全かつ確実におこなうのは，かなり難しい所業だとおもうのだ。

まず，コンパイラの生成コードに関する詳しい知識が必要だろうし，カーネルやライブラリの挙動や，ハードウェア・アーキテクチャについても把握しておく必要があるだろう。さもなくば，山のようなトラブルとご対面することになる。

そこまでちゃんとできるひとなら，やってできないこともないんだろうけど，僕はそれにまつわるリスクを抱えられるほどの実力もないし，なにより，そんなことをやっている十分な暇もないだろうとおもうのだ。

そんなわけで，適当なスクリプト言語でコンテキスト多重化，ってシナリオを相変わらず推していきたいですなあ，とおもった。

まあそんな感じで，ぱらぱらとGems2を読んでみてるんだけど，なんだかローテクな話題がわりと多いような気がする。

"Self-Modifying Code"の項なんて，むしろノスタルジックであるかもしんない。そりゃあ，昔の８６系ＣＰＵなんかでは，かなり役にたったわけだけど，もうさすがに時効でしょう。「GameBoyで使用した」ってくだりがあるんで，まあそういうケースもあるのかな，とはおもうけど……。

ほかにも典型的なローテクとして，floatのハックってのが載っている。これはＰＳ２のＶＵマイクロコードなんかでは，たまに役にたつこともある。ある種のfloat演算を整数演算化することにより，演算をＡＬＵに肩代わりさせたり，あるいはその逆をすることができるのだ。

そういった地道な努力によってパイプラインの隙間を減らしていくのがＶＵプログラミングの主なチューニング手法であり，地獄の所業と呼ばれるゆえんでもある。

真・三国無双２

2001-09-20

ついに出てしまった。とりあえず購入。このさき数週間，このゲームによってじつに膨大な時間が無駄に浪費されまくるのかとおもうと心が傷んでならない。でもやるよ。男の子だから。

内容は，良くも悪くも三国無双。むしろあんま変わんない，とはまさにこのことを言うのでしょう。でもまあ，二人プレイは楽しかったかもしんない。よりファイナルファイト感が高まったとも言えよう。

そして，真・三国無双２のラウドネス効果によってAC4とSKY GUNNERがマスキングされてしまったことも忘れてはならない。そんないっぺんにゲームできませんて。

なにげにちゃんクリアまでやってるはなげ先生はえらいですよ，とおもった。

孔明ビームは

2001-09-21

たぶん前々作をやったことのあるひとに対してのサービスだとおもった。

やっと秋らしく……

2001-09-22

目覚めたら，周りが暗かった。時刻は６：３０。１２時間寝ました。さすがに疲れた。さいきんこんなんばっか。

めしでも食いにいくかと外にでると，外気温の低さにおどろいてドアのなかに引き返す。やっと秋らしくなってまいりましたな。

秋分に半日寝てたら，秋になってしまいましたよ（字あまり）

ほんのちょっとうれしそうにしながら，長袖のシャツを着なおして，家を出なおした。

たまには個人サイトめぐりもおもしろい。

あまりにもいい天気

2001-09-23

秋晴。すばらしいまでの秋晴れっぷり。いやこういうのを待ってたんですよ。あまりにもいい天気なんで，衝動的に洗濯してしまった。まくらカバーをね。いやはや。

んで，散歩がてらめしを食いに行く。夕日に照らされながら秋風を全身に浴び，涼しげな気分で街路を歩いていると，なぜか子供のころのことをおもいだす，っていうか，よく，夏の暑い日は子供のころのことをおもいださせる，って言うけど（言わない？），ぼかあ秋の夕暮れがそれさね，とかおもいながら，暗くなるまでほっつき歩いてましたとさ。

もはや三国無双ざんまい。とりあえず，三国それぞれ１キャラづつ終わらす。三国無双なぞ３回クリアさせば十分さ，と自分に言い聞かすも，新しくでてきた隠しキャラが，なにげに気になる。どうしてくれる。

冷静に前作と比較してみると，ゲームシステムとしての変化はほとんどみられない。それよりも，シナリオの増量や，アイテム要素の追加，隠しキャラの増量，といったボリューム面での強化が目立つ。たしかに前作では，シナリオが３種類だけだったり，モーションの使いまわしが多かったりと，わりと質素なつくりをしていたので，今作ではそこらへんをなんとかしようという意図があったのかもしれない。

BRDF

2001-09-24

今日は秋分の日。あれ，昨日だっけ。まあ，本日が世間的に休日だということには間違いないし，そこが唯一重要なところでもあるので，つまるところ秋分の日がいつだって気にしないってことにしておこう。

で，夕方から泊りがけ出勤モード。このごろ，この行動パターンが定番になっている気がする。

先週からChryss WynnのBRDFのpaperをPSIONの中でさんざもてあましてたんだけど，まあなんとなくわかった気になってきたような気がする。ようするにわかってないんだけど。

BRDFは"Bi-directional Reflectance Distribution Function"の略で，ベタ和訳すれば「双方向拡散反射関数」とでもなるんだとおもう。要約すると，ある面にある方向から光が当てられた場合に，どの方向に対してどんくらいの比率で光が拡散しているか，ってのをあらわす関数だ。

このBRDFさえわかれば，ある面に任意の方向から光があてられた場合に，視点の方向に対してどれだけ光が反射（拡散）したか，ってのを簡単に求めることができるようになる。この情報から面の輝度を求める（シェーディングする）ようにすればいいじゃん，ってのが"BRDF-based Lighting"の趣旨だ。

このBRDFのすごいところは，他の算術的な反射モデルとちがって，実世界に存在するマテリアルからBRDFをサンプリングして，それをＣＧのなかで利用することができる，ってところ。木やプラスチックや肌や紙やオレンジジュースもみんな，実物からBRDFをサンプリングしちゃえばいいわけで，もはや複雑な算術モデルに頼る必要がなくなってしまうわけだ。

でも，当然のようにBRDFにも欠点はある。もっとも問題になるのは，データの容量がでかいってのと，既存のコンシューマＨＷでは実装するのがむずかしい，ってところ。

BRDFは，光の入射方向w_iと反射方向w_oの２つのベクトルを引数とする関数だ。ところで，これらの関数は単位ベクトルなので，spherical coordinateを使えば(t,p)ってかんじの２スカラ値であらわせる。とどのつまり，BRDFは(t_i,p_i,t_o,p_o)の４値を引数とする関数になる。

すると，これをテクスチャとして保持するには４次元ボリュームテクスチャが必要だ。３次元ボリュームならまだしも，４次元ボリュームの使えるＨＷが普及するのっていつだろう？ しかも，こいつはかなりかさ張るデータなので，潤沢なメモリも必要になるだろう。

といった感じで，どうやら既存のＨＷでそのまんま実装するのは無理そうなので，近似的な手法をとる必要がありそうだ。これについて検討しているのが２枚目のpaper(BRDFSeparable.pdf)で，要約すれば，マルチテクスチャ（２テクスチャ）とキューブマップを使ってなんとか近似しようとしている。

で，結論から言ってしまうと，かなり無理があるっぽい。なんとなくそれっぽいことはできてるんだけど，誤差の大きさから見るに，ちゃんとしたBRDFには程遠いものなんだろうとおもう。

BRDFってのは関数の性質上，なんらかの偏りは存在するはずなんで，そこらへんでなんとかインチキする方法はあるとおもう。８個ぐらい適当に基底関数をみつくろって畳み込み，とかどうかなあ。

１つのテクスチャのR,G,Bのコンポーネントにそれぞれ別の基底関数（基底テクスチャ？）を格納すれば１枚で３個ぶん入れとくことができるから，１パス４マルチテクスチャなら，２パスで６個の波形成分を含ませることができるかもなあ，とか妄想してみた。でも，うまくいく気がしないんでやらない。

えーと，本来の動機は異方性反射をやることだったはずなので，とりあえずBRDFはここでおしまいにしておくことにする。つぎは，算術照明モデルによる異方性反射ってのを調べてみて，だめだったらBRDFを使う手法に戻ってこようとおもう。

anisotropic filtering

2001-09-25

きのうの流れで，異方性反射（anisotropic lighting）について調べるつもりだったんだけど，なんとなくanisotropic texture filteringについて調べてしまった。anisotropicという響きに敏感になってしまう今日このごろ。恋してしまったのかしら。

ところで，anisotropic filteringってのは，まずなにをするものなのかというと，端的にいえばテクスチャの拡縮フィルタの一種だ。テクスチャの拡縮フィルタと言えば，現行のＨＷではMIPMAPと線形フィルタの組み合わせが一般的だ。スクリーン上でのピクセルの解像度と，そこに投影されるテクスチャの解像度が，ならべく１対１に近づくようにテクスチャ解像度を調整し（ここがMIPMAP），それを線形フィルタで補間しときましょう，ってしくみだ。

でもこの方法にはちょっと問題点がある。テクスチャにパースがかかってくると，スクリーン上でのピクセルの形と，そこに投影されたテクセルの形ってのが歪んだ関係になってくる。パースによって歪んだテクセルが投影されるのだ。こうなると双方の解像度の調整はむずかしい。歪んだテクセルの短いほうに合わせて調整すると，微妙にボケた画像になってしまうし，長いほうに合わせて調整すると，こんどはエイリアシングを起こしてしまうのだ。

……ってのはかなりいい加減な解釈で，ただしくは，"Real-time Rendering"のテクスチャフィルタリングの項を参照すれば，わかりやすくて正確な解説が載っている。

で，これを改善するためのいろんな手法が考案されてはいるんだけど，どれもいまいち欠点が消しきれていない。けっきょくは，複数点でサンプリングしてフィルタリングするしかないよね，って結論になっているようだ。GeForceなんかで実装されているanisotropic filteringも多点サンプリングを使ったもので，確実に数％から十数％のパフォーマンスを吸いとると公称されている。

おなじみNVIDIAのdev-relサイトに行ったら，デザインが一新されてておどろいた。かっこいいですな。これからもぜひ，こういう意味のないところに凝ってほしい所存。

Trrance-Sparrow

2001-09-26

んなこって，気をとりなおして "anisotropic lighting" をキーワードにしてぐーぐりんぐ。ぞんざいな捜索活動をしばらく続けた結果， Wolfgang Heidrich 先生のウェブにたどり着いた。このひとの名前はBBXやなんかでよく見かけているような気がするんだけど，まじめにpaperを読んでみるのは初めてだったりする。

GBA FA-Linker

2001-09-27

唐突にゲームボーイアドバンスの開発に興味をもってみる。ちょっと前に flipcode の IOTD にアップされていた，ＧＢＡでレイトレーシングってネタにちょっと反応するものがあったのだ。ＧＢＡでレイトレ，ってネタ自体には，それほど興味もないんだけど，よくかんがえたらＧＢＡって発売されてからまだ１年も経ってないわけで，そんな時期にみんな意外とお手軽にアマチュア開発しちゃってるらしいってのが，僕のいんちきアマチュア魂に火をつけたのでした。

で，てきとうにＧＢＡ開発関連を捜索。なにはともあれ，まずは www.gbadev.org 。いきなり詳細な資料とコンパイラが見つかってしまった。エミュレータも数種類でてるんで，実行環境もばっちりだ。あーうー，いきなりそろってしまったんですけど。

おかげで風邪をひいてしまったような

2001-09-28

ここ数日暑い日が続いている。その前にすこし涼しい日があったんで着るものも秋物体勢にはいってたもんで，おもいがけない残暑の攻撃に暑苦しい思いをすること数日。今日こそは快適な残暑ライフをおくってやるぜと薄着で出発したんだけど，今日に限って涼しくなりやがったりして，もううんざり。おかげで風邪をひいてしまったような感じがする。ぬー，油断できぬ……。

なんとなく，ファミコン音楽でもＢＧＭにするかと， Winamp に NSF プラグインをインストール。僕のおすすめは BEFiS さん作の nezplug 。一時期，この手の音源エミュレータ系に凝ってたことがあるんだけど，ファミコン音源のエミュレーションに関しては nezplug がいちばんいい音を出してるってのが，そのときの結論。「ラグランジュ・ポイント」みたいな変態的特殊ＨＷをつかったゲームになると，さすがに完璧なエミュレーションとまではいってないんだけれど（それでも対応はしている），それ以外についてはほぼ完璧なレベル。僕の大好きな「ギミック！」（サンソフト）も，実物と聴きわけできないぐらいの再現度だ（実際に聴き比べたことはないけれど）。

久しぶりに nezplug のホームページにいってみると，ちょこっとバージョンアップしていた。あたらしいバージョンではＦＭのエミュレーションがちょっと良くなったような気がする。まだ完璧ではなさそうだけど。

ところで，たいていの音源エミュレータはログ方式（音源チップのＩＯのログを記録して再現する方式）を採用しているのに対して，ファミコンの音源エミュレータってのはＣＰＵエミュレーションをやっているんだとか。つまり，音源エミュレータというよりかはむしろ，ファミコンエミュレータから音源に関係無い部分を切り離したもの，ってノリみたいだ。それって曲データ抜き出すの大変じゃないかなあとかおもうんだけど，しょせんは８ｂｉｔゲーム機ってことで，なんとかなっている模様。そのおかげで曲データがコンパクトにまとまってるってのもあるわけで，いいんだけどね。

Arnold

2001-09-29

もう暗くなったころに起床。風邪っぽいんで寝てるつもりではいたんだけど，半日以上寝てるとはなあ。最近，こんなのばっかのような気がする。どうにも。

めし食いにいったついでに本屋による。 CG World を立ち読み。ぱらぱらと流し読んでいると， Arnold に関する記事を見つけた。画像ばかりで肝心のソフトがちっとも出てこない Arnold なんだけど，どうやら作者氏は Image Based Rendering で有名な Paul Debevec 氏のもとで開発を続けているとのこと。わざわざＬＡまで引っ越したそうだ。ヘッドハンティングってやつなのかなあ。

で，その記事によると， Arnold は分散レイトレーシングをベースにしたレンダリングシステムなんだとか。分散レイトレーシングってのは，名前からも想像できるようにむちゃ重いのが欠点なんだけど， Arnold では独自の高速化をほどこすことによって従来では考えられないような処理速度を達成しているんだとか。仕組みがちっともわかってないんで，ただ信用するほかないんだけど。

そう言われてから Arnold の出力画像をよくみてみると，画像全体にうっすらとノイズがのっているような気がする。以前は，これはマテリアルかフィルタの一種かとおもってたんだけど，分散レイトレーシングに固有のノイズってやつなのかもしれない。

Project EGG

2001-09-30

雨が降ってる。秋雨。いやそんなぬるい雨じゃなくて，わりとドボドボと。今日は夕方から出動するつもりだったんだけど，こうも雨が降ってると，やはり気が重い。わざわざ濡れてまで出動しなくても……，いやいや，忙しいんでした，ぼかあ。仕様の山がおれを待ってるぜ。ぜんぶシュレッダーにかけてやる（冒涜）。ドバっとな。

覚悟をきめて家を出る。たかだか雨でなにやってんだか。

そういえば，会社のひとからこんなのを教えてもらっていたのをおもいだした。