淡々とプログラミングする日

2001-10-01

今日から１０月が始まる。この１０月は，たぶん，僕にとって修羅の月。近年まれにみる多忙なスケジュールが差し迫ってきている。まあ，その後にも地獄のような進行が待っているわけで，特にいまテンション上げるってわけもなく，いつものように淡々とプログラミングする日。せめて明日は晴れるといいなとか，朴訥におもってた。

職場で定期購読している CG World を閲覧。いままでは他のＣＧ雑誌といっしょくたに，ぞんざいに扱ってたんだけど，よくみてみるとかなり白眉であるような気がしてきた。うーむ，DAKINI先生が毎月話題にしてるんで，あやしいとはおもってたんだけど（早く気づけ）。んなもんだから，これからは少し真面目にチェックしてみようかとおもった。

とくに倉地紀子さんの連載コラム（名前わすれた……）とか，かなりおいしいんではないかとおもった。最新の技術を多彩な図表を交えて概念的に説明しようとしているんではないかと。もちろん，技術者としてはこれでは不十分で，ここから元の文献をたどって勉強するところが重要なんだろうけど，そのきっかけとなる窓口が低くて入りやすいところにあるってのは，きっと悪いことではないはずだとおもう。

なにげに開いたＡｌｔ−ＲのＭＬ５で，スタパ斎藤さんのこんなポストが。

ぬぬ！ そうだこれだ！ まさにこれだ！ これからの２１世紀を生き抜く僕らにはまさにこういう素敵ハックこそが必要なわけで……。ところで，某飲みの席では，ＳＧＩマシンはもはや温風機ってことで結論づいてたんだけど（ｂｙかわち先生），それがまさか冷蔵庫になるとはなあ。ジムクラークも本望だろうに。

ＧＣＣとか

2001-10-02

職場のひとと世間話。そのうち，会社の「もと」有名人，ディルこと Dylan Cuthbert の話題になった。どうやら，彼の個人ホームページがあるってことらしい。こんなときは，さっそく google だ。

ローギア気味に運転中

2001-10-03

仕事のほうが本格的に忙しくなってきたんだけど，ちょっと風邪っぽい気分なので，ローギア気味に運転中。

期日が詰まってくるにしたがって，仕事の内容もだんだん変わってきた。いままでは，どちらかといえば設計方面の作業が多かったんだけど，最近では実装作業が増えてきている。ちょっと楽しげになってきた気がする。

設計の段階では，机に向かってあーでもないこーでもないと考え詰めていることが多い。どうしても考えがまとまらない場合は，とりあえずコードを書いてみて，元のコードが残らないくらいリファクタリングを繰り返す。こういう試行錯誤はそれなりに楽しいとおもうんだけど，最後は妥協と諦めでしめくくられることが多いので，後味が悪い。１００％満足な設計なんて，なかなか味わえないもんだとおもう。

それに対して実装のプロセスってのは，設計段階で生み出された抽象的な部品たちを組み上げ，実体へと変換する作業。たとうなら，半分くみあがったジグソーパズルを完成に持っていくときの，すいすいとピースがはまっていって実像が見えてくるときのような，そんなスピード感とカタルシスがある。

ＸＢＯＸのマイクロソフト発タイトルについての発表会があったようだ。

秋特有の粒子

2001-10-04

涼しくていい天気。やわらかな日差しと涼しげな秋風が心地よい朝（世間的には昼）。なぜか風に秋の香りを感じるのは，気のせいなんだろうか。なんかの話で，秋の風の香りっていうのは，植物類の出す秋特有の粒子成分ってのが大気中にただよっていて，それを嗅いで秋を感じるんだとかいうような理屈があったような気がするんだけど，現代に舞い降りたクリミナルシティこと溝ノ口駅周辺なんて，じっさいには排気ガスとスモッグぐらいしか大気中にはないわけで，やっぱそんなの気のせいだよなあ，とかおもうのだった。

先日，在庫切れのために買いそびれたフォトンマップ本をふたたび検索してみると，在庫が補充されたとある。１週間程度で届くそうだ。んじゃあ買いますか，とおもむろに "1-Click Order" ボタンを押す。次の瞬間には注文が終了していた。やや唖然。すげー。

amazon の１クリックオーダーは初体験だったんだけど，ほんとうに１クリックで購買に関するすべての作業が終了してしまうことに，いまさらながらおどろいた。この経験はかなりショッキング。買い手にはもはや，購入意欲を失うだけの時間は，わずかながらも与えられない。脊髄で通販してしまうようなノリのひとにとっては，すでに死刑宣告といえよう。いやまじ怖いっすよこれは。

string hashing

2001-10-05

ＧＤＡ−ＭＬで，文字列のハッシングについての話題がでていた。

Mesa3.5

2001-10-06

昼起床。夕方出動。今月は忙しいから，土日月出動体制で行くつもり。

んで，ぽちぽちとプログラミング。いまいち眠くて気合が入んない。わりと睡眠はとったつもりなんだけどなあ。寝だめってのは，やっぱり効果がないみたいだ。

気分転換にと， Mesa3.5 をサーバマシンにインストール。今は Mesa3.4 が入れてあって，それほど不自由もしていないんだけど， 3.5 ではかなりの数のエクステンションが追加されているので，入れておいて損はないはず。おもに OpenGL1.2 仕様を中心にサポートが追加されているようだ。

最初はライブラリアーカイブだけダウンロードして make したんだけど，なんだかうまくいかない。どうやら，デモアーカイブも同時に展開しておく必要があるらしい。んでもって "./configure; make" 。今度は問題なし。

とりあえず自前のプログラムをリンクしてみるも，うまく動いてくれない。シェアードライブラリが見つからなくて失敗しているようだ。 /usr/local にインストールしたんだけど， /usr/local/lib はパスが通ってないのかな。うーん……。

ちょっと調べまわってみると，シェアードライブラリのパス設定は /etc/ld.so.conf にあるらしい，ってことがわかった。さっそく /usr/local/lib を追加して， /sbin/ldconfig を実行。 ldconfig をかけておかないとサーチキャッシュが更新されないので，変更した内容が反映されないようだ。落とし穴っぽいなあ。

以上でインストールは無事終了。 3.5 で追加されたエクステンションのなかに ARB_texture_env_combine とか ARB_texture_env_dot3 があるので， per-pixel っぽい実験とかできるかもしれない。できれば EXT_vertex_shader も欲しいところだけど，こちらはエクステンションとして登録されたばかりなんで，サポートされるとしてもまだそれなりに時間がかかるだろう。だいいち，サポートする気があるかどうかもわからないし。

しかしながら， Mesa は意外とあなどれないなあ，とおもった。エクステンションがやたら充実しているのだ。気合の抜けたメーカーの気合の抜けたＩＣＤよりも，よっぽど多くのエクステンションをサポートしているとおもう。３Ｄボリュームテクスチャなんかもしっかりサポートしていたりして，驚かされる。それでいて動作も安定しているから，用途によっちゃあこっちの方が有利かもしれない。

finalRender

2001-10-07

昨日から泊り。土日連続はひさしぶりだなあ。んで，マックで昼食。マックは輸入牛だっけ。まあ，そこらへんはあまり気にしないことに。マックだし。

昼食ついでに本屋で CG World を購入。なにげにぱらぱらと目をとおしていると， finalRender という製品の紹介記事に目がとまった。

gmax

2001-10-08

夕方に起きて，夜に出動した。軽い雨がしとしとと降っていて，ちょっと肌寒い。おもわず忘れてしまうんだけど，今日は月曜日。たしか体育の日だったわけで，今日運動会をやってたところとかあるはずだ。どうだったんだろう。こんな微妙な空模様で。

国内のゲーム業界には SoftImage 神話みたいなのがあって，いまだに旧 SI を使っているところも少なくない。次世代版 SI こと XSI （ "Sumatra" のほうがかっこよかったんだけどなあ）に移行するところもあれば，この機会に Maya に乗り換える動きもあるようだ。スクェアなんかはむかしから Alias 系だから，ずっと Maya なんだっけな。ナムコもいまは Maya 中心になったと聞くんだけど，どうなんだろ。まあとにかく，国内大手デベロッパについては， XSI と Maya の２極化された状態になりつつあるんだとおもう。

ところで，雑誌記事や，社外のひとの話なんかを聞いていると，最近では 3D Studio MAX の勢力もだいぶ強まってきているような気がする。特に海外での 3DS の人気は高いようで，デベロッパ向けの雑誌やウェブの記事では，かならずと言っていいほど 3DS の名が出てくる。プラグインなんかも 3DS 向けのものが用意されていることが多い。

そんなわけで， 3DS についてちょっと探りを入れてみようかとおもって，開発元の Discreet 社のウェブをのぞいていたんだけど，そのうち本題から外れてこんなのを調べていた。

GTS, domelight

2001-10-09

気がつくと目覚ましを止めたままの体勢で固まっていた。あぶないあぶない，２度寝してしまうところだったよ。寝袋からもそもそと這い出て椅子に座る。うーん，そろそろこの寝袋，買い換えようかな……。

いつものように flipcode を閲覧。 Doxygen が 1.2.11.1 になってる……。まあいっか。ぱらぱらとヘッドラインを読みすすめていると， GTS (GNU Triangulated Surface Library) の 0.5.0 がリリースとある。なんだろ，これ。

GTS は，その名前の通り，三角形によって構成されたモデルを扱うためのライブラリらしい。概要を見ると，デローニ分割による三角分割や，ブリーアン演算，リダクションにリファインメント， Kd-tree の構築や，トライアングルストリップ化など，けっこういろんな機能が含まれているようだ。しかも，これらの処理を高速に行うってのを売りにしているらしい。

どれも基本的な処理なんだけど，いざ自分で組んでたりするとなかなか手間のかかるもんで，こういうライブラリがあると便利かもしれない。いずれ試してみようとおもう。

統計的にみて晴れ

2001-10-10

今日は１０月１０日。本来なら今日が体育の日なんだな。外ではバケツをひっくりかえしたような強烈な雨が降っていて，しまいには雷まで鳴りだす始末。たしか１０月１０日ってのは，統計的にみて晴れの確率が高いから体育の日として選ばれた，ってはなしだったとおもうんだけど，どうしたもんだろうね，とおもった。

キューブマップの応用のひとつに，正規化キューブマップってのがある。

となるような画像をキューブマップで張りつければ，フラグメントごとに正規化された法線ベクトルがカラー値として得られる，ってものだ。この値をもとに register combiner や texture shader を使ってライティングを行えば，フォンシェーディングっぽいことができる，ってことになっている。

詳しいところはわかんないんだけど，どうやら，キューブマップの (s,t,r) は同次座標系上で線形補間されるらしい。んだから，とりあえずパースの正しい補間ではあるらしい。でも線形補間である以上，変化のはげしい部分では補間にムラができるはずだ。

これがどんくらいまで耐えられるもんなのか興味があったんで，なんとなく実験してみた。上の画像がそれで，左から６＊１２分割，９＊１８分割，２４＊４８分割のトーラスとなっている。いちばん右のが理想なんだけど，まんなかのは，んまあギリギリですかな，ってレベル。いちばん左のは問題外。ムラっていうか，あからさまに誤差がでている。

まんなかのも実は微妙なレベルで，よく見ると対角線方向にスジがでてるし，キワのあたりはかなり残念な感じになっている。まあ，面積が小さければ許せるレベルかな……。あとは，これをもとにスペキュラの演算なんかをやった場合に，どんだけ誤差が浮き出てくるかってところなんだけど，これもまあいつか試してみたいな，とおもった。

ちなみにこのプログラムは， Linux マシンで Mesa 3.5 + PyOpenGL を使って作ったんだけど，Mesaのキューブマップはフィルタに手抜きがあるようで，画像の切れ目のあたりで黒い線が出る現象が起きた。画像をまたいだ補間ってのができてないのかな。近傍サンプリングでは同様の現象は起きなかったので。

Maya Builder, blender

2001-10-11

今日は昨日とうってかわっていい天気。最高気温２７度だって。あちー。あまりにも暑いので，おもわず寝坊してしまった。それにしても，会社に泊まりながらにして遅刻とはどういう料簡ですか。

くだんのソフトこと gmax のことを職場のひとと話題にしていると， Maya にも "Maya Builder" というサブセット版があるよと教えてもらう。いやあ，そんなもんあるならはやく教えてくださいよー，といいつつウェブで調べてみる。

TGS'01

2001-10-12

今日は東京ゲームショーのビジネス公開日。なんだか妙に天気が良くて，ゲームショーってよりかは，むしろ，幕張公園のベンチで昼寝するのに適しているって感じ。ところで，いちおう入場券は確保しておいたものの，仕事の方がかなり詰まってるんで，おとなしく職場で留守番プログラミング。本当は XBOX の動いてるとこが見たかったんだけど……。

おととい作ったテストプログラムに致命的なミスを発見。キューブマップを法線の正規化に使うには NORMAL_MAP_ARB でもって TexGen してやんなきゃいけないんだけど，間違えて REFLECTION_MAP_ARB でマッピングしていた。ぐはあ，これじゃあぜんぜんだめだって。なんかおかしいなあとはおもってたんだけど。

んで，正しい結果は上の図のような感じ。まったりとした感じになりました。

ゲームショーから帰還してきたひとたちにおみやげを見せてもらう。今年は大手メーカーがこぞってプロモＤＶＤを配っていたようだ。プロモビデオを配ってるところなんかいままで見たことなかったけど，時代も変わったもんですなあ。

んで，ＸＢＯＸ（電撃王）とセガ，ＳＣＥのプロモＤＶＤを閲覧。うーん，まあ，どこも特に隠し球はなかったんで，どっかで見たことのあるような画像ばっかだったような気がする。ＸＢＯＸタイトルについては，はじめてみるのがちょこっとあったけど。

「格闘超人」は，うーん，３０ｆｐｓなのか。僕は実のところ３０ｆｐｓ支持者だったりするんで，そこらへんあんま気にしないんだけど，世間的に許されるかどうかは微妙なところ。非難の的になりそうな気がする。まあ，伊能さんのキャラデザが妙に渋くてかっこいいんで，それでＯＫってことで。

おみやげのなかに入っていた "Jak and Daxter" の体験版をプレイしてみた。美麗でいて物量感の高いステージモデリングや，ダイナミックかつ滑らかなキャラクタアニメーションなど，ＣＧ的な質の高さはさすがは Naughty Dog といった感じで，あいかわらずハイレベルだなあ，とおもった。ちょっと格ゲー的な Jak の動きとか，新機軸でいいんじゃないでしょうか。あと，Jak の呼吸音（「はぁ，はぁ」とか「んはっ！」ってやつ）がいい味出してるなあとおもった。洋ゲーっぽくてさ。

ワールド同士がシームレスに連結されているところとか，ちょっと目立ちにくいけど，なにげに頑張っているんではないかとおもった。こういうのは，非同期なデータ読み込みとか，動的なリソース割り当て，あと座標系の問題なんかもあったりして，技術的には意外と難しかったりする。こういうのをなにげにやってのけてしまうところが，大域的な技術力の高さっていうか，一芸ではない安定した技術力ってのを感じる。

しかし，唯一気がかりなのがインターレスレンダリングを使ってるってとこ。もはやＰＳ２では，よっぽどの理由がないかぎり全ライン（４４８ライン）レンダリングが当然となっているとおもうんだけど， Jak and Daxter ではインターレス２２４ラインを使っているようだ。なんかへんなフィルタをかましてごまかしてるっぽいんだけど，やっぱりちらつくのは否めない。慣れてくるとそれほどでもないんだけどね。

いちおう per-pixel

2001-10-13

先日，キューブマップを使って正規化された法線を張りつける，ってのをやったんだけど，これと ARB_TEXTURE_ENV_DOT3 と ARB_TEXTURE_ENV_COMBINE を使ってディフューズライティング，ってネタを，こんどはやってみた。

機能的なことを言えば， ARB の渋い拡張よりも， nVidia 拡張の NV_REGISTER_COMBINERS とか使ったほうが派手でいいのは違いないんだけど，せっかく ARB 拡張として ENV_DOT3 と ENV_COMBINE がコミットされたんだから，こっちを使ってみることにした。 ARB 拡張なら Mesa とかでもサポートしてるしね。

で，上の画像が実行結果。いちばん左のが正規化キューブマップと DOT3 を使った「いちおう per-pixel 」なライティングによるもの。真ん中のが普通のグーロシェーディングによるもの。右のは理想的な出力（分割数を上げたもの）だ。

ぱっと見てわかるのが， per-pixel と per-vertex で最終画像がほとんど変わりないってとこだ。ここまでそっくりだと，なにか根本的に間違えてるんじゃないかと不安になるんだけど……，どうなんだろ。

たぶん， DOT3 による per-pixel ディフューズと，頂点ライティング＋グーロシェーディングでは，数式的には違うものになるとおもうんだけど，実際にはなにがどう違うのか，深く考えてみたことはない。結果から言えば「たいした差はない」ってことになるんだけど，なんかちょっと納得いかないなあ。

たぶん，スペキュラを求めるときにはグーロより有利になりそうな気がするんだけど，この場合は，演算精度の問題が表面化するんではないかとおもう。しょせんはダイナミックレンジ８ビット（符号付きで７ビット）の演算だから，何度も乗算していると誤差で暗くなってきてしまうはずだ。まあ，実際のところ，そんな累乗できるわけじゃないらしいんで，そんな心配も余計かもしれないけど。

そろそろバーテクスオペレーションに手を出してみたい感じなんだけど，いまいちスタンダードが見えてこないのがいやな感じだ。 EXT_VERTEX_SHADER の登場で， NV_VERTEX_PROGRAM の位置付けもあやしくなってきたし，何を信じればいいのかちょっと判断しかねる状況だ。はやいところ ARB 仕様を出してもらいたいところだけど，どうせまた何年もかかったりするんだろうなあ，とおもってしまうあたりが， OpenGL の唯一の弱点だったりする。

ひさしぶりに sketch のサイトをチェック。ミュージシャン系のサイトは半年に１回ぐらいチェックすると，新しい曲がアップされてたりして，いい感じだ。

Blinn Model

2001-10-14

夕方起床，夜出社。先週と同じことを書いてるな，とおもいつつ，実際そうだからしょうがないとおもう。今年の年越しは職場で迎えることになりそうだな。春には暇になってるといいけど……。

僕の使っている環境が貧弱なせいもあって（最高スペックが GeForce2MX ）， per-pixel 方面にはさすがに限界を感じつつある。そんなわけで，ちょっと時代を逆行して，前世代向けのレンダリング手法をおさらいしてみようとおもった。

とりあえずやってみようとおもったのが， Torrance-Sparrow モデルを安上がりに実装する，っていうネタ。参考にするのは，以下の資料。

お気楽かつめんどくさ

2001-10-15

まずは，拡散関数Ｄとフレネル係数Ｆを固めこんだ２Ｄテクスチャを作ってみる。前回同様， Python + PIL でちゃきちゃきっと作成。リストにがんがんピクセルを詰め込んでセーブするだけで png とかできちゃうから，お気楽だよなあ，とおもった。

で，とりあえずトーラスに張り付けてみようとおもったんだけど，これがなかなか思いどおりにいってくれない。 Heidrich 先生の paper では，テクスチャ座標として

ってのを使っていて，これは GL_NORMAL_MAP_ARB を使えば楽勝かなー，とかおもってたんだけど，どうやら GL_TEXTURE_NORMAL_MAP_ARB で生成されるのは (nx,ny,nz,0) であって，つまり微妙に違うらしい。違いは微妙なんだけど，致命的にだめだなあ，こりゃ。ぬぬ，自分で法線立ててテクスチャ座標を作ってやんないとだめそうだ。うー，めんどくさ。

ちなみに， PS2 ばっか触ってると，テクスチャ座標の q ってパースコレクトに使われるから下手にいじれないんじゃないの，とかおもっちゃうんだけど， OpenGL 的にはパースコレクトってのはラスタライザの処理に閉じ込められているようで，この段階ではどう使ってもいいらしい。便利だなあ……。

そんなわけでやっとこさトーラスを生成して，いざ張り付け。法線を回転させるのに逆転置行列が必要かも，とかおもってどきっとしたけど，回転行列しか使ってないから，このさい必要ないや。あぶないあぶない。

んなこって，まだぜんぜん素材がそろってないものの，とりあえず張り付けてみた結果が上の図。左から，１６＊２４分割トーラスでのフォンモデルのバーテクス版（つまり OpenGL 標準の照明効果），その次が同じトーラスでの仮 Torrance-Sparrow モデルの２Ｄテクスチャ版。その右２つは分割数を３２＊４８に上げたもの。

まだ半分くらいしか実装してないわけで，フォンモデルと違うのは拡散関数がガウス分布になっていることぐらいなんだけど，これだけでもわりといけてるかなあ，とかおもってしまった。こうしてみると，フォンモデルってスペキュラがきついんだなあ。

積分してむにゃむにゃ

2001-10-16

次はジオメトリ減衰式Ｇの実装。これは，物体の表面に存在する微小な溝によって光線がさえぎられる現象を考慮したものらしい。 HyperGraph に載っているやつは，溝がＶ字型であると仮定した場合の式だそうで，３つの余弦を使ってこの割り合いを求めている。

今回の実装では，関数の値を２Ｄテクスチャに固めこむ方法をとっているんで，パラメータは２つなのが理想だ。 Heidrich によれば， Smith が余弦２つからこれを求める式をあみ出しているらしい。こっちは小平面がガウス分布にしたがって分散していることを仮定として導き出しているそうで，もとのバージョンのアッパーコンパチみたいなもんのようだ。

で，あてずっぽうに資料を探してみたんだけど，なかなか見つかんない。気を取り直して Heidrich の Thesis を見なおしてみると，この式がそのまんま載っていた。む，灯台もと暗し。

ついでにその周辺を見なおしてみたんだけど，それによると， Schlick がこの式の簡単な近似を求めているとある。せっかくだからサーチしてみると，意外と簡単に見つけることができた。うーん，名前がめずらしいとサーチしやすいなあ……。

paper を見てみると，たしかにこっちの方が計算は簡単そう。どうせそんな高尚な目的じゃないんだから，こっちを使わせていただこう。ところで， Smith の式にもあったんだけど，式中にある erfc って関数がよくわかんない。 error function のことらしいんだけど……。なんだそれ。

これもさっそくサーチ。いやあ， google がなかったら，こういう調べもんももっと大変になってることだろうに，とおもいつつ。んで，どうやら， erfc ってのは相補誤差関数のことで，分散が０．５のガウス分布を積分してむにゃむにゃ……，したものらしい。そういえばそんなのも習ったような習ってないような。統計の教科書にはよだれの跡ができてたからなあ。

そんなわけで，めんどくさいんで近似式を使わせていただく。楽ちんですなあ。ちょっと楽しすぎな気もするけど。

渋さを味わい楽しむ

2001-10-17

んなこって，資料はなんとか揃えられたんで，さっそく実装してみる。とりあえず絵を出してみたいんで，ちょっとぐらいの疑問は無視して，とにかく式をがしがし突っ込んでいく。しかしこんな汚いソースじゃ，どっか間違っててもなかなかわかんないだろうなあ，とかおもいつつ。

ややあってテクスチャを生成する部分は完成。係数とかかなりいいかげんだけど，まあなんとかなんべ。次は３Ｄと合成の部分だ。

合成にはマルチテクスチャを使う。まず D*F を固めたテクスチャをデカルで張り付けて，次に G/cosB を固めたテクスチャを乗算で重ね張りする。最後に， OpenGL の標準の照明を使った拡散光を加算する。この部分には TEX_ENV_COMBINE とダミーのテクスチャを使う。本来ならテクスチャカラーが加算されてしまうところを， TEX_ENV_COMBINE でもってプライマリカラーと入れ換えてしまうのだ。ダミーテクスチャを使うところがちょっと無駄っぽいけど， ARB 拡張で実装しようとおもうと，どうしてもこうなってしまう。マルチパスでやる方法もあるけど，それよりかはずっと高速だろう。

nVidia 拡張があれば Register Combiner とかでもっとダイレクトに対応できるんだけどね。それにくらべると， ARB 拡張はずいぶん地味だ。でも， OpenGL の堅実さってのは，こういう渋めの思想からちゃくちゃくと積み上げられたものなんで，あなどれたもんでもない。 nVidia みたいなのは，どっちかっつえば異端ですな。むしろ，この渋さを味わい楽しむのが， OpenGL との正しい付き合いかただろう，とか勝手に決め付けてみたりした。

それからややあり，とりあえず出来あがったのが，上の図。左ふたつは７２＊４８分割トーラスで，いちばん左がラフネスの低いもの，その右がラフネスの高いものだ。右のふたつは分割数を１／２に落としたもので，ラフネスはおなじものを使っている。

左のふたつは分割数が十分に高いんで，ちゃんとスペキュラがでて当然なんだけど，問題は右のふたつだ。実はこれでもわりと分割数の多い方だとおもうんだけど，スペキュラはかなり潰れてしまっている。ラフネスの低いほうはそれなりの質感が出来てるような気もするけど，これに２レイヤーはちょっとコスト高いかな。光源の数だけ合成が必要になるわけだし。

雨の日

2001-10-18

今日は雨の日。冬なみの寒さになるってことらしいんで，ちょっとあったかめの格好をして家を出る。駅まで歩くあいだ，安っぽいビニール傘が狭くて苦しくなった。傘ぐらいまともなの買えよ，っておもうんだけど，なかなか普段，傘買おうなんておもい立つことがないんだよね。雨の日ことなんて，すぐに忘れるから。

blender がバージョンアップ。 OpenGL とのコンパチビリティが向上したらしく， Matrox のビデオカードでも問題なく動くようになったとある。そうそう， blender はなぜか Matrox のビデオカードだと動かないんだっけ。僕も職場では Matrox の G400 がささってるマシンを使ってるんで，いままで blender が動かなくてくやしいおもいをしていたのだ。

さっそく落としてインストールしてみたんだけど，絶妙にまったりとした動作に愕然となる。なんじゃこりゃあ。ポップアップの描画が目で見えるよ。うーん，やっぱり Matrox のドライバはまともじゃないとおもう。 LightWave の動作もいまいちあやしかったし……。

そろそろ mlvwm にも飽きてきたんで，別のウィンドウマネージャを物色してみる。んなわけでピックアップしてみたのが， evilwm だ。

もはや不可抗力なんじゃ

2001-10-19

仕事がいよいよ佳境に近づいてきた。こういう忙しい時期に限って体調をくずしてしまうってのは，よくありがち。案の定，職場にも風邪をひいてしまったひとがいるみたいだ。しょっちゅうけほけほ聞こえてくる。

僕は，風邪ってのはひくときはひいてしまうもんで，もはや不可抗力なんじゃないかとおもってるんだけど，とりあえずひととおりの用心はしておくことにする。手洗い，うがい，風邪をひいたひとに近づかない，死体を焼く（土葬はダメ），ケツにネギを突っ込む，えーと，あと何よ。

今週の Gamasutra の 特集 "Implementing Crack Protection for SPYRO: Year of the Dragon" を斜め読み。 "Spyro: YOTD" のクラックプロテクションに関する話だ。本文によると， "Spyro 2" のときは１週間足らずでクラックされてしまったのが， "Spyro: YOTD" ではクラックプロテクションの強化によって２ヶ月もたせることができたんだそうだ。がんばってプロテクションかけて，それでもたった２ヶ月ですか，ってなとこなんだけど，ソフトの最終的な売り上げの半数近くは発売から数ヶ月以内に売れるもんなんだそうで，最初の２ヶ月守られたというのはそれなりの意味があるらしい。

はたして北米圏にどんだけの潜在的なクラックユーザがいるんだか，よくわからないけど，こんなふうに真面目に取り組んでるぐらいだから，そうとうな数がいるのかもしれない。東南アジア圏での違法コピーの蔓延っぷりはよく耳にするけど，日本では，それほど深刻な話は聞いたことがない。

しかし，たとえ少数でもクラックされている現状を認識しながら対処せずにいると，それを暗黙の容認と解釈されかねないってこともある。クラック行為を拒否する意思表示としても，プロテクションってのは必要なのかもなあ，とかおもった。

ところで，この記事を読んでいると，なんとなく，古きよき国産ＰＣ時代のころの，コピープロテクションのことを思い出す。 Gamasutra のくだんの記事には，凝ったプロテクションはかえってクラッカーの楽しみとなってしまう危険性がある，とか，プロテクションを即座に作動させてしまうとクラッカーにヒントを与えてしまうことになるので，ならべくわかりにくい効果を仕掛けておくといい，とか，いろいろ書かれているんだけど，こういうのって，当時，僕も実際に身をもって体験したことのあることばかりだ（もちろん，そのときはクラックする側だったんだけど）。だからどうってわけでもないんだけど，なんだか，とても懐かしい気分になった。

パン屋まで

2001-10-20

昼，机の下から這い出して，顔を洗い，昼食を取ろうと近くのパン屋まで道を歩いていく。なんだか今日はとてもいい陽気で，春の日のようなやわらかな日差しにつつまれて，なにげに気分もあたたかになってくる。毎日こんな調子だといいんだけど，きっと忙しくてあくせくしているうちに，とっとと冬になって，雪とか降り出したりしちゃうんだろうなあ，とおもった。

先日組んでみた２Ｄテクスチャによる blinn モデルの実装を，キューブマップに拡張してみる。キューブマップは，単純に使えば，２つのベクトルを変数に持つ関数の固めこみに使える。 blinn のモデルでは，

の３つに割ると都合が良さそうだ。フレネル係数については，「平行光源および平行透視」って近似のもとでは全ピクセルで同一の値になるから，ベースカラーとして組み込むことにする。

とまあ簡単にできそうな感じだったんだけど，ちょっとした落とし穴があった。 OpenGL （や多くのＡＰＩ）では，カラー値ってのは [0,1] の値でしかない。上の３つの式のうち， D と G'/(L,N) はかなり広い値域を持つので，そのままテクスチャに固めこむと潰れてしまう。

これを避けるには，値に 0.25 とかスケールをかけておいて，合成後に４倍とかすればなんとかなるんだけど， OpenGL のαブレンディングでは１以上の値を設定することができないので，拡大方向にスケールをかけようとおもったら，ちょいと苦労することになる。

って感じでやっと２倍。４倍しようとおもったら，これをもう一度繰り返さないと……。

texture environment の中では GL_ALPHA_SCALE の指定によって，αを２倍もしくは４倍にスケールできるんで，こういった処理もだいぶ楽になる。しかし，うちの GeForce2MX はテクスチャユニットが２つまでなんで，上の３つの式を合成するには， texture environment のなかにはぎりぎりおさまらなくて，どうしてもマルチパスになってしまうのだ。

そんなわけで，いろいろ試行錯誤した結果，とりあえず妥協してみたのが上の図。ここでは

ってしているんだけど，こんなので４パスはどう考えても無駄過ぎ。それに，パス０の時点で，ほとんど濃淡のない画像になってるんで，ほとんど関数Ｄだけでハイライトが決まっているって状態。こいつはどうにも無駄過ぎる……。

テクスチャユニットが４つあれば，それなりにうまくまとめることができるとおもうんだけど，そもそも G や G' までキューブマップにする必要性ってのはあまりないのかもしれない。ハイライトを特徴的にしているのは，やはり D の存在なので，こいつだけキューブマップにして，あとは前回の２Ｄテクスチャの方法を使うのがいいかも，ってとこだ。これだったら２テクスチャでもうまくまとめることができそうだ。

月見のやつ

2001-10-21

今週も日曜は夜出動パターン。マックで月見のやつを買って職場につく。ところで，この月見のやつの月見の部分って，やけに正確なかたちに焼けてるんだけど，どうやって焼いてるんだろう，といつもおもう。

僕が考えるに，まず卵を白身と黄身に分離して，シリンダー形の容器でもって白身の柱を作り，その芯をくり抜いて黄身を流し込み，固めて金太郎飴状態の月見ができたところで，スライサーにかけてあのひらべったい月見を作っているのではないかと。まあもしくは，月見形の卵を産む鶏を遺伝子合成してるんだろうな。

AKIBA PC Hotline! によると， RADEON 8500 と GeForce3 Ti の販売が始まっているようだ。どちらもそれなりに安い。これは買いかもなあ。どちらの会社も OpenGL ドライバの品質は高水準をキープしているようなんで，この際どちらでもいいかなあ，とおもう。

Delphi3D の OpenGL Hardware Registry を見るかぎりでは，どちらも欲しい機能はほぼ満たしているんで，あとは派閥の問題かな。将来的には ATI の EXT_VERTEX_SHADER の方が有利になりそうな気がするけど……，どうかな。

スタックに積まれた仕事

2001-10-22

忙しい……。息つく隙もなく仕事してるってのは珍しいことかもしれない。それだけふだんダラけてるってことなんですけどもな。

でも実は，いつもみたいに悩みながらプログラミングしているよりも，いまみたいに単純に作業をこなしている方が楽だったりするかもしれない。何も考えずに，スタックに積まれた仕事を POP, POP, POP ……。そんなわけで，せめて来週には一息つけるといいな，とおもった。

先日作った中途半端な Torrance-Sparrow のアレを，てきとうにネコに張り付けてあそんでみる。ネコの素材は 3D Cafe から拾ってきたもの。フリーの３Ｄ素材集サイトなんだけど，いまいち権利関係のあやしい素材がたくさん置いてある。質はあんま良くないけど，テストプログラムに使う程度だったらこれでもいいだろう。

屈強なこれたち

2001-10-23

忙しい，忙しい……。まさに忙しさ満開。未実装の仕様書とバグ報告の山に囲まれた僕たちは，先を争うように新しいコードをコミットし続け，リポジトリには分刻みのリビジョンコードが刻まれていく。それと， make の連打攻撃を受ける Linux サーバたち。普段は屈強なこれたちも，今日みたいな日はさすがに重ったるい動きになってくる。ツイストペア経由で人意を受け，怒涛のような勢いで１００Ｖ電流を熱と電磁波に変換しつづけている。熱力学的に見ればこいつらも単なる熱変換機なんだけど，僕らはむしろこれをたくさんのお金に変換しようとしている。それは成功するかどうかわからない。でもたとえそれが成功したとしても，それは今こいつが熱を大気中に延々と放出し続けているのと同じくらい，どうでもいいことなのかもしれない。どうでもいいことなのかもしれないけど，そうするしかないんだから，そうなんだよ，とおもったりした。

PS2 と HHK

2001-10-24

今日も今日とて，ぽちぽちとコーディング。がしがしと打鍵する手を休め，端末として使っている PS2 Linux のキーボードをふと覗き込んでみると，キートップの刻印がはがれ始めているのに気がつく。もうぼろぼろだ。まだ数ヶ月しか使ってないのに。

PS2 の純正のキーボード＆マウスは，おおよそ安っぽさの目立つ製品だ。キーボードはくだんのとおりだし，マウスも接触ローラー式のだめっぽいやつだ。いちおう色とデザインは統一されているんで，セットにするとそれなりに格好はつくんだけど，単体で見ると，ただの脱力感あふるる製品でしかない。ゲーム機だからってこういうところをおろそかにしちゃうのは，まずいとおもうんだけど……。たとえコスト的な理由だあるとしてもだ。

僕は PC ではもっぱらハッピーハッキングを使ってるんだけど，こいつはそれなりの値段がするだけあって，かなりまともな作りをしている。初代 HHK の方はかれこれ２年ぐらい使ってるけど，刻印がはがれることも，バネがヘタることも，いまだ気配もない。基本的なコンセプトの時点でいろいろ考えることはあるものの，純粋に製品の品質を評価するならば，十分に合格点に達する出来だとおもう。

峠

2001-10-25

うー，忙しい。今日，明日が峠っぽい。なんとか今週を乗り切れば少しは楽になるとおもうんだけど……。

あんまり忙しいんで見逃してたんだけど，セガの PS2 ソフト第一弾こと "Rez" が，いつの間にか出てたらしい。このゲームは，ちょっとかっこつけすぎっていうか，内容が濃すぎてカジュアルなユーザには着いてけないんじゃないかなあ，って気がしないでもないけど，開発コスト安そうだし，ぜんぜんＯＫなのかな。

まあとりあえず，いちどやってみたいです。時間ないけど。

フォース

2001-10-26

朝日を見つめながら寝袋に身を沈めるのが定型になりつつある今日この頃。ファーストフードは友達です。そしてモスバーガーは，やっぱりファーストフードじゃないよな，と確認した。

「バーチャロンフォース」がやっと稼動開始らしい。ずいぶん前から話はあったような気がするんだけど。初代「バーチャロン」と「オラトリオ・タングラム」は，人差し指の付け根にタコができるぐらいプレイしたんだけど，なんかもうさすがについてけないです，最近は。

「フォース」は， NPR を意識しているのか，静止画像の見た目はかなりのっぺりした感じがする。あいかわらず不透明エフェクトが多いような気がするんだけど，もはやこれは「味」と割り切ってしまっているんだろうか，とおもった。 MODEL2, MODEL3 でやってたころは，ハードウェアが半透明に弱いってこともあって，やむをえず不透明系のエフェクトを模索してたんだとおもうけど， NAOMI (NAOMI2?) にもなって同じことをやっているってのは，たぶん作為的なものがあるんだろうとおもう。

前世代（ PS1 とか）では，ラスタライザ側の制限もあって，加算系のエフェクトが多用されていたんだけど，最近では，さすがにアルファブレンディング系のエフェクトが増えてきた。しかし，アルファブレンディングではＺソートが必要なんで，やはりちょっとコスト高な印象がある。よっぽど制限されたゲーム（三国無双みたいなのとか）では，まだ加算エフェクトの出番が多いとおもう。

次回はぜひとも，パーティクルエンジンをＶＵに閉じ込めてしまいたいなあ，とかおもってたんだけど，Ｚソートのことを考えると，なかなか頭が痛い。点パーティクルとかだったらソートしなくてもぜんぜんいいんだけど，煙とかみたいな大きなスプライトを使うやつでは，やはりソーティングがないと違和感が出てしまうとおもう。もちろん，シーン中の半透明物との相関も考えなきゃいけないわけで……。あーやっぱり半透明はめんどくさいなあ，とおもった。

肩こり

2001-10-27

うーん，いままで１日ごとに１泊ペースを保っていたんだけど，ついに２泊する日が来てしまった。絶妙なタイミングで終電を逃してしまったのだ。締め切り間際は時間的拘束がきびしくなるんで，たとえ仕事量的にはたいしたことなくても，乱れた生活になりやすい。

まあ，そんなわけで夜中も仕事。朝帰って家で寝ようとおもったんだけど，時間通りに起きれる自信がなかったので，会社で昼まで寝たのちに，風呂のために帰宅する。んで，着替えたらすぐ出社。こういうときに，家が中途半端な距離にあるのが，とても恨めしくなる。

それほど根をつめているわけでもないんだけど，なぜか肩が痛くなってきた。肩マッサージ機欲しいなあ。あと，足ツボマッサージ機なんかもいいかもしれない。ああ，もう，おやじくさくてかなわんわ。どうしてくれる。

indent

2001-10-28

最近，異様に忙しくなっていた仕事に，ひとつの区切りがついた。長く続いた拘束から開放され，朝の電車で家に帰る。これでやっと一息つける……。まあ，またじきに忙しくなるのはわかりきっているんだけど。

職場のひとに，自動生成されたコードが読みにくいと指摘された。オブジェクトの挙動制御とかって，普通にのっぺりと C で書いてると定型的な処理が多くなるんで， python で作った簡単な生成プログラムを使ってソースを吐かせているんだけど，この生成コードは人が見ることを想定していないんで，かなり汚い出力になっているのだ。

んじゃあってわけで， GNU の indent というソフトを試してみる。 C のソースファイルを整形するフィルタだ。前から名前は聞いたことがあったんだけど，使ってみるのは初めてだったりする。

とりあえず，適当なコードを書きくだしてみる。

特にこだわりはないんだけど，なんとなくいつもこんな感じで書いている。んで， indent に GNU 式の整形をさせてみると，こんな感じになる。

うーん。 emacs とか使ってる人には馴染みあるのかもしれないけど，ふたんから素でこう書いてるひとはなかなか珍しいんじゃないかとおもう。中カッコが中途半端にインデントされているところとか，かなり独特な気がする。これには，それなりの理由があるらしいんだけど。

んで，次は K&R 方式。つまり正統派ってことになるのかな。

こんな感じで書くひとは，わりと多く見かけるような気がする。密度が高いんで，それなりにさっぱりして見える。

最後はバークレー方式。 BSD のソースで使われていたものらしい。

コメントまで整形されてしまった。変数宣言がタブされていたりとか，全体的に間延びしているような印象がある。

まあこのさい，書式なんてどれでもいいかなとおもうんだけど，何もルールがないと書き方に迷ってしまうことがある。そういったときに，既存の書式や，機械変換に頼るっていうのはいい方法かもしれない。そこであえて車輪の再発明をする必要もないだろう，ってことで。

glib

2001-10-29

ひさしぶりにゆったりした朝。昨日まではあんなに殺気立っていた職場が，ひっそりと静まり返っている。オフィスのご近所さまであるところの某チームは，数年間に渡って続いたプロジェクトについに終止符を打ち，しばしの間の休息に入っているようだ。そんなわけで，職場はいつになくとても静か。ゆっくりとまずいコーヒーを飲みながら，最近の ign の記事は insider 向けばっかでうざったるいなあ，とかおもったりしていた朝だった。

やっとこさ， glib に手を出してみることにする。よさげなチュートリアルが見つかったからだ。

glib for Win32

2001-10-30

glib の使いかたはなんとなく分かった気がするので，さっそく GTS を試してみることにした。

triangle strip

2001-10-31

なんだか知らないけど，昨日の夜から微妙に胃腸の調子が悪い。職場でそのことを話してみると，わりと多くのひとが同じような症状を訴えていた。うーん，今年の風邪は腹に来るってことなんだろうか。それ以前に，風邪をひいてる自覚がほとんどないんだけどなあ。

昨日に引き続き， GTS で独立三角形のストリップ化をこころみる。とりあえず，ファンになっているところを無理やり切断して出力するようにしてみたんだけど，どうにも無駄が多い。上の図の，左の方が GTS の出力するストリップそのもので，右が加工を加えたもの。ひと目でわかるように，右の方がだいぶ破片が多い。左のストリップは３０００頂点で構成されているんだけど，これを加工する過程で６５５回の切断が発生して，右のストリップでは４３１０頂点になってしまっている。

まだぜんぜん適当に作ってるんで，だいぶ改善できるところがあるはずだ。切断の検知や，頂点の送りなおしの部分とか，かなり何も考えずに作ってあるんで。

ストリップでおもい出したのが， Hoppe 先生の "Optimization of mesh locality for transparent vertex caching" 。ただ単に繋げられるだけ繋いどくんじゃなくて，頂点キャッシュの構造を考慮して，局所性のあるストリップを作るようにするといいんじゃないの，って内容のようだ。