2002-08-01
今日は飲みの日。ちゃっかり一次会で帰るつもりが，あれよあれよという間に帰れない時刻となってしまい，結局オールナイトで付き合うことになってしまった。そういう事態は全然想定していなかったものだから，変に体力を消費してしまったような感じがする。うう，喉が痛い……。
久しぶりに Ramamoorthi のページを覗いてみたら，いつの間にかコロンビア大学に移籍していた。
http://www.cs.columbia.edu/~ravir/
今年の夏にスタンフォード大を卒業して，秋からコロンビア大にて助教授として勤務する，とのことだ。まったく縁の無い話ではあるけれど，ホームページの URL が変わってしまったから，ブックマークを直しておかないと。
なにげにおまけページとか見てみたら，僕と同い年であることが判明した。
http://www.cs.columbia.edu/~ravir/biog.html
インドはボンベイ（現ムンバイ）出身のお金持ちさんだったらしい。ふーむ。
2002-08-02
仕事の合間なんかに地道にプレイし続けてきたマリオサンシャイン，やっとシャインが４０個に達した。全部で何個あるんだろう，これ……。だいぶ進めたつもりだけれど，まだこの３倍ぐらいは余裕で残ってそうな感じがする。ゲームのボリュームは十分すぎるほどに十分。その辺りはさすが任天堂と言ったところで，久々にやり応えの感じられるゲームをプレイした気がする。
正直なところ，今時のお子様には少々厳しすぎる難易度設定だと思うんだけれど，これが欧米ターゲットになるとちょうどいい程度なのかもなあ，と思う。向こうのひとは攻略という行為そのものを愛しているから，こういったボリューム感と，「失敗して学習せよ」的な難易度設定は，むしろ喜んで受け入れられる可能性がある。だから，このゲームは欧米で発売されたときが本当に注目すべきタイミングなのかもなあ，と思った。
いい加減，半無限平面や球の組み合わせだけでシーンを構築するのにも限界を感じはじめたので，三角形との交差判定を path tracer に追加してみた。これでやっとポリゴンを食わすことができる。とは言っても，まだ総当りでの交差判定しかサポートしていないから，処理はとてつもなく重く，ごく単純なシーンしか構築することはできない。早急に AABB Tree なりを用意して高速化を施す必要がありそうだ。
実験用にとりあえずレンダリングしてみたシーンが上の図。窓から陽光が差し込むような雰囲気を作ろうとしている。ただ，光源がまだ天球光源しかないので，うまく雰囲気を表現できていない。平行光源が無いと直射日光を表現することができないからだ。これだと，窓の外の空気が強烈に発光しているようなシチュエーションになってしまう。やはり変な感じだ。
あと，処理の重さもそろそろ深刻な問題になってきた。こんなくだらない画像でもレンダリングするのに約６０分ほど費やしている。まったく高速化を施していないのだから重いのも無理無いのだけれど， path tracing 自体の限界に近づきつつあるのも確かだと思う。そろそろフォトンマップの需要が発生する頃合なのかもしれない。
GamingAge Forum より "The Document of MGS2" の情報を得る。
http://www.konamijpn.com/products/mgs2_doc/japanese/index.ht...
「観るだけじゃない， MGS2 メイキング」とのこと。資料集にデータ閲覧ソフトを付けたような内容で，ゲーム中に使用されたポリゴンモデルをぐるぐる回して見たり，任意のカットシーンデモを再生したり，というようなことができるようになっているらしい。
とのことで，なんだかもう全部見せちゃえー，的な気概が感じられる。 ¥2980 という値段設定からしても良心的だし，とりあえず買っておいて損は無さそうだ。
2002-08-03
今日から一週間の夏休み。この前も一週間リフレッシュ休（その実は単なる有給消化だ）を貰ったけれど，今回は会社の定める休業日なので，有給を使わずに一週間休むことができる。それで，それが終わったらまた気を引き締めていくことにしよう。
この１ヶ月というもの，かなり気の抜けた生活をしていたような気がする。またしばらくの間は，素材のアップ待ちが多い都合上，ややスローペースな仕事が続きそうだけれど，他にもやるべきことは沢山あるのだから，むしろこの余裕を有効に生かしていきたいと思う。
思うだけかもしれないけれど。
pathtracer に，実験的に直接照明の処理を加えてみた。丁寧に実装するとなるとちょっと手間がかかりそうなんだけれど，実験的に加えてみるぐらいだったら大したことはない。原理はものすごく簡単な話だからだ。１０行程度のコードの追加で完了した。
それで出来上がった画像が上の図。前回の画像と比べると遥かにリアリティが増したと思う。やや黄味がかった強烈な平行光源と，水色で弱めの天球光源を組み合わせてある。平行光源を黄色くしたのは「太陽光は黄色い」という印象からそうしたのだけれど，これは科学的に正しいものなのかな……。大気層で青色のスペクトルが散乱して「青空」が生まれるのだから，それを透過してきたはずの直接光は黄色である，ってのはおかしくない話だと思う。もちろん，水色の天球光源は青空をイメージしたものだ。
半球ライティングについて学んで以来，普段屋外を歩いているときにもこの辺りの話題を思い出して，ふと周囲に目をやってみることがある。冬の天気のいい日は，外に出ると街全体が青みがかったように見えるようだ。逆に真夏の強い日差しが照りつけるような日には，周囲が黄色がかったように見える印象がある。これは恐らく，冬は日が低いために天球光の方が照り返しが強く，また夏は日が高いために直接光が強調されやすいのだと思う。
GDAlgorithms より "more basic motion woes"
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
アクション系のゲームで，キャラクタの動きを地面に対して制約するには，どのような処理を用いるのが良いか，という話題について議論している。言い出しっぺの cbloom 氏は，地面の傾きをキャラクタの動きに対してどのように影響させるか，という点と，プレイヤーの入力方向を座標系に対してどのように対応させるか，という２点について気にしているみたいだ。
前者の問題に対しては，地面に埋まってしまった分の速度成分をカットする方法や，地面の傾きに合わせて速度成分を曲げてやる方法などが挙げられている。ただし，前者の方法では小さな凸凹で速度が削られてしまい操作性に悪影響を与えるという問題が挙げられており，また後者の方法では動きにプレイヤーの予期せぬゆらぎが発生してしまうという危険性が指摘されている。
途中，ショックアブソーバーのモデル（スプリングとダンパーの組み合わせ）によって地面に張りつける方法とか紹介されているけれど，結局のところ決定的な結論は無いように見える。
また，プレイヤーがジャンプする際に，速度成分をワールド上方向に設定するのがいいか，もしくは地面の法線方向に設定するのがいいか，とかそんな話題も挙がってきている。マリオのようなプラットフォーム・アクションでは前者を採用するケースが多い（操作の安定性に優れているからだ）のに対して， FPS なんかでは後者が使われることもあるようだ。
入力と移動の話題で，ついでに挙がっていたのが，キャラクタアニメーションをベースとして移動速度を決定するという方法。単位時間中にキャラクタのつま先が移動する距離を常に取得できるようにしておいて，移動速度をこれに対応させるというわけだ。この方法ならキャラクタの足の滑りが気になることもなくなるだろうし（「バイオハザード」なんかをプレイしていると誰もが一度は気にすることだと思う），移動速度に微妙なゆらぎが加わることによって「味」のある動きになるというメリットもある。実際に "Halo" ではこの方法を使っているようだ（ただしアニメーションデータから直に求めるのではなく，それに似せたプロセジュアルな関数を用意したとのことだ）。
僕はプレイヤー処理の担当になったことは無いので，この辺りの本当の苦しみは分かっていないのだけれど，当事者に言わせればかなり難しい分野であるらしい。プレイヤーが触って直に感じる部分であるだけに，決しておろそかにすることのできない処理であり，妥協の許されない部分であることは理解できる。そう言った事情から，経験がものを言う分野であると思うので，正直なところ中途半端に関わり合いを持ちたくないところだ。やるなら，本当にそこしか作らないってくらいに，本気で取り組みたいものだと思う。
明日から実家に帰省する予定。実家まで電車で１時間ぐらいの距離なのに，なんだかんだと理由を付けて１年以上帰っていない。たまには両親に顔を見せておかないとね……。
読みかけの本を持って，暇つぶしに出かけてくることにしよう。
2002-08-06
久しぶりの実家は，驚くほど田舎っぽくて，なんていうか，程よく驚いた。
2002-08-07
かなーりのんびりした日。久しぶりの実家暮らしを経て体力回復と思いきや，何故か喉が痛くなってきた。うー，土曜日のはなげ祭りに備えて体力を蓄えねば。別に何をするわけでもないけれど。
当面の目標は，比較的複雑なシーンをレンダリングできるようにすることにある。現時点で決定的に不足している要素は，まともなカメラレイアウトの手段と，高速なレイ対メッシュの交差判定処理。前者についてはいつかやっつけで解決するとして，まずは交差判定処理をなんとかして高速化しなければならない。
交差判定の高速化については今までにも幾度となく調べてきた。大別してボリューム階層 (Bounding Volume Hierarchy) と空間分割 (Spatial Partitioning) の二通りのアプローチが存在するのだけれど，ここは簡単な AABB (Axis-Aligned Bounding Box) Tree によるボリューム階層を使うことにしようと思う。最も手っ取り早く，かつ，それなりの効果を得られる見込みがあるからだ。
ray vs AABB の交差判定処理は， Magic Software の交差判定パッケージに含まれているルーチンをベースにして作成することにした。
http://www.magic-software.com/Source/Intersection3D/MgcIntr3...
上のソースファイルの
という関数がそれに該当する。
高速な ray vs AABB 交差判定には，他に Pierre Terdiman 氏が紹介しているルーチンなどが挙げられる。
http://www.codercorner.com/RayAABB.cpp
安定性や先抜け（いわゆる early exit ってやつ）による高速化を考慮するならば，こちらのルーチンの方が優れているかもしれない。でも，今回はそこまで厳密な評価はせずに，見た目の単純さを重視して Magic の方のを選択してみることにした。また， Magic の方のルーチンには除算が全く存在しないという特徴もある。
Magic 版 ray vs AABB ルーチンには，レイ方向ベクトルと相対位置ベクトルの外積を取るという，ちょっと不思議な処理がある。これは， AABB の各軸について，「軸とレイ方向ベクトルの両方に対して垂直な直線上」に AABB の「幅」を投影する，という処理の一部だと解釈すればいいみたいだ。いわゆる Separating Axis 法に相当する。
これに対して Pierre 氏のルーチンは Woo の方法に基づいている。これについては RTR に概説があるのでそれを参照するといい。
ちなみに， AABB と任意の形状で交差判定を取る場合，実際の交差判定処理を行う前に，まず交差判定対象を囲む AABB で判定を行なった方が良い場合がある。 AABB 同士の交差判定は非常に簡単な処理（数回の加減算と比較のみ）で済ますことができるため，この段階で非交差が確定できれば − つまり "early exit" できれば，複雑な交差判定処理をスキップすることができるからだ。
例えば，線分対 AABB の場合にも，まず「線分を囲む AABB」対 AABB の判定を行うようにする。よほど極端なケース（例えばオブジェクト密度が異様に高いとか）でない限り，かなり効果的な高速化が望めるはずだ。これがあるから，意外と AABB は侮れないんだ……。
ちなみに，今回は線分ではなくてレイ（１個だけ端点を持つ直線）なので，この処理による高速化は期待できるかどうか微妙なところ。機会があったら試してみよう。とはいっても，その前に Octree とかに移行してしまうかもしれないけれど。
2002-08-08
読み残していた「最終兵器彼女」を最後まで読み通したら，なんだかどんよりした気分になってきたので，気付け代わりにと「プライベート・ライアン」の DVD を購入。
あー，ちょっと元気出た。
とかなんとか言ってたら，急に咳き込むようになってきて，なんだか風邪っぽくなってしまった。ダメだ，気合が入らない……。もう寝るですよ。
2002-08-09
早寝したおかげでだいぶ病状回復。休みの間に全快させたいなあ……。
なんとか AABB Tree が動くようになってきた。まだ C++ の使い方がサマになってないもんだから，単純な処理を記述するにしても，えらく苦労しながら書き進めている。下手なくせに勘でデザインを決定してしまうのが，どうも致命的なようだ。全体の形がまとまるまでにえらく時間がかかっている。書き直しもやたら多い。無駄ばかりだ。
現段階でソースファイルと同程度の量のヘッダファイルが存在する。テンプレートを多用するとどうしてもヘッダファイルの容量が増えてしまう。これにどういったポリシーで折り合いを付けていくのかというのも，今後の大きな課題だ。特に大規模なプロジェクトにおいては致命的な問題に発展する可能性がある。どうしたものやら。
ポリゴンの裏面からレイを交差させた場合に，法線がうまく取得できていないようだ。本当なら泥除けの覆い被さっている辺りがもうちょっと暗くなるはずだと思うんだけれど，泥除け部分が板っきれで出来ているもんだから，正しく処理できていないのかもしれない。ううむ，モデルの選択が悪かったか……。
ポリゴンモデルの編集作業には，なんだかんだでまた Blender を使用している。一時は NaN と共に沈没かと思われた Blender だけれど，フリー化への道が拓けたことでまた新たな可能性が見えてきた。まだ楽観できる状態ではないかもしれないけれど， Mozilla みたいに紆余曲折しつつも最終的には一応の成功に辿り着くような感じであればそれでいいんじゃないかなあ，と思う。きっと元 NaN の開発メンバーも合流するんだろうし，少なくとも今までよりも状況が悪くなることはないだろうと思う。
そういえば寄付がまだだった。ほっとけば目標額に達しそうな勢いだけれど（受付開始から三週間経った現在で約３／４の達成率となっている），なにかと世話になっていることだし，一口 ($50) だけ寄付しておこうと思う。
何はともあれ，ソース公開が楽しみだ。
2002-08-10
今日は待ちに待ったはなげ祭り。一路池袋に赴く。なんだか知らないけれど，いつの間にか３０名ぐらいの大集団になっていて，ちょっとびっくり。げーはなさんの人望の篤さを改めて思い知ることになる。ていうかなんなんだ，この集団は，ほんとうに。
侍本の新さんとか，某事情筋のこうのさんとか，今まではお会いする機会のなかった方々なんかがわりといらっしゃって，実に楽しかった。しかし，あまりにもメンバーが濃過ぎる故に，とても１次会の飲みだけじゃ消化し切れなかったのが，ちょっと惜しまれるところ。 nikq さんとか ryoko さんの辺りにも行ってみようかと思ったらもう時間切れだった。うーむ。
２次会以降は，もうまったく帰る気の無いメンバーだけでディープ飲みだべり会。いつの間にか，つよぞうさんとか某仙人とかも居なくなってる。なんてことだ。でも今回は代わりに masa さんと bee さんが残っていたので良しとする。
ここ数日，喉やら腹やらの具合が悪くて，今日も案の定，少量のアルコールで既に気持ち悪くなっている。ポカリが欲しい，ポカリが……。全国の飲み屋さんは，泥酔客による汚染被害を減らすためにも，是非ソフトドリンクメニューにポカリを追加すべきです。それも今すぐ。なるたけ早く。ポカリくれ……。
テンプレート大臣ことみきたさんに C++ 変態道について語ってもらおうとしたら，そういうのはテンプレート仙人の TAOS 氏に訊いて下さい，とかわされた。切ない。なんて言うか，今回のみきたさんは比較的落ち着いていたように見える。もっといつものような危険トークを期待していたのに。
あとは，げーはなさんが PTM について暑く語ったり， Hoppe 氏がいかに狂っているかという話題で盛り上がったり， masa さんが魂抜けたように寝てたり， DAKINI さんがヨガのポーズで寝てたり，つまり比較的みんな寝てた。あと暑かった。
2002-08-11
どうやら誤差の主な原因になっていたのは，光線と三角形の交点を求める際に含まれる数値誤差だったようだ。反射点から散乱させた光線が，再び同じ三角形に交差してしまうという現象が，かなりの確率で発生していたらしい。表裏判定で解決させるのも手だけれど（今まではそうして対処していた），どうせデータによっては表裏ポリゴンとか含まれていることもあるだろうし，ひとまず散乱時の光線の原点を少し法線方向に浮かすことによって対処することにした。
しかしこの対処方法だと，鋭角に凹んでるところとか怪しくなる気もするな……。やはりいずれは表裏判定を行うのが筋だろうか。オブジェクトの形状がすべてサーフェスで表現されるものと前提するならば，その方が綺麗にまとめることができるかもしれない。
やはりぼんやりした光源環境ではつまらないので，またむりやり直接照明処理を追加してみることにした。モデルもせっかくだから入れ換えて，例の「大佐」に再びお出まし願うことにしよう。炎天下に出現した謎のコーネル箱の中に佇む大佐。わけわからん。
ちょっとローポリなのがバレバレのような気がする。やはり法線の補間も入れないとまずいか……。まあ，これはまた後のタスクに回そう。ポリゴンをサポートした本当の目的は，複雑な建築物を表現するため，というところにあるので，曲面表現についてはまだいいや。
結局のところ， Jensen の "The Light of Mies van der Rohe" に憧れて大域照明をやっているわけで，こんな感じのをとりあえず，曲面無し，マテリアル表現無し， BRDF 無し（ランバート面のみ），でやってみるってのが目標なわけ。
http://graphics.stanford.edu/~henrik/images/imgs/mie3pm.jpg
そろそろフォトンマップが必要だと感じているものの，いくつか障害が残っていて，いまだ手を出しかねている。最も大きな問題が平行光源のフォトン射出処理で， Jensen 本の該当部分を読み直してみているもののいまいち要領を得れないでいる。昨日のげーはな祭りのときにも bee さんとかにアドバイスを求めてみたものの，僕自身はまだ確信を得るまでには至れていない。何回かの試行錯誤が必要そうだ。
しかし，そのためだけに実装を遅らせるのもなんだか惜しい気もする。もうしばらくは騙し騙し pathtracing のみで頑張ってみるか……。結局のところフォトンマッピングってのは高速化のための手法なので，一応 pathtracing だけでもやりたいことはすべてできることになっている。ただ，それだと最終的に無限な処理時間を要求されてしまうために，事実上フォトンマッピングが必要になるってわけで。
2002-08-12
ぼやぼやしてる間に夏休みもお終い。結局何もやってないんだよねあなた，って感じ。ボンクラどもの元に夏は永遠に来なくて，ただ暑かった日の記憶だけが嘘か冗談のように残りつづける。もっとも，嘘でも冗談でもないような人生がどこかにあるのなら，是非その話を僕に聞かせて欲しい。そんな話，よっぽど冗談だと吐き捨ててあげるから。
職場や家に分散してしまった資料類を効果的に回収するために， USB 駆動のポータブル HDD の購入を企てる。ヨドバシにでも行っときゃなんとかなんべ，ってことで西新宿のヨドバシに寄ってみるものの，目的の商品は見つからず，敢え無く手ぶら帰還。ああ，もう，とりあえず店舗に行っときゃ買い物ができるなんて法則は，成り立ちゃしないんだ。買う物が決まりきっている場合は，素直にオンラインで取り寄せてしまった方が無難だってことを学ぶ。
最近，レンダリングだのイルミネーションだのばかりで息苦しくなってきたので，ちょっと趣向を変えてアニメーション関連などに食指を伸ばしてみようと思う。お馴染み Tim Rowley の SIGGRAPH 2002 paper コレクションから選んだ最初の標的は "Motion Graphs" 。ウィスコンシン大は Lucas Kovar 氏の論文だ。
http://www.cs.wisc.edu/graphics/GraphicsWeb/Projects/MoGraph...
趣旨を要約すると，キャプチャーされた一連のモーションデータから「繋ぎ」として利用できる部分を自動的に抽出し，それらの遷移状態を表したグラフ構造を生成する，というもののようだ。
とりあえず上のページに置いてあるムービーを見てみると面白い。元データは適当にくねくね歩いているだけの，たった一つの連続したモーションなんだけれど，このモーションから繋げることの可能な部分を自動で判別し，細切れのモーション群に変換する。これを接続するために用意されるグラフ構造が "Motion Graph" だ。
このグラフ構造をたぐりながらモーションを繋いでいけば，切れ目のまったく無いアニメーションを無限のバリエーションで生成することができる。またグラフを巡回する順序をうまく操作すれば，複雑な経路の上を歩かせる，というような高度な応用も可能になる。サンプルのムービーでは，たった１２秒の歩きモーションから Motion Graph を生成し，ユーザ定義されたパスの上をたどるモーションへと再構成する，という応用例が示されている。
カラテのモーションで "Hello" と描かれたパスの上を歩くデモなど，繋ぎの自然さや，パスへの追尾性の良さなど，なかなか印象に残る内容だ。パスの上を歩かせる技術は他にもあれど（ゲームで使用しているような原始的なものも含めて，だ！），ここまで滑らかで自然に，しかも元のデータには一切手を加えずに（遷移時にモーションのブレンディングが入る程度で，キネマティックな処理は一切無い）このような汎用性のある合成ができるというのは，なかなか凄いことだと思う。
問題は，「繋ぎ」の検出方法，言い換えれば，一連のモーションにおいて遷移可能な部分をどうやって抽出するか，という所にあるんだけれど，この論文ではわりと単純な比較方法を用いて判定を行っている。コツは，モーションデータ（「位置＋角度」の情報）をベースとして比較を行うのではなくて，モデルのジオメトリをベースとして比較を行う，というところにあるらしい。この論文で提示されている方法では，モーションによる変形を適用した後のモデルにおいて頂点群の位置比較を行い，その誤差量が最小となる所に「繋ぎ」がある，と判定するらしい。
あとは力技だ。与えられたデータに対してしらみ潰しに比較判定を行っていく。論文の終わりの方には，この処理は簡単に並列化できるから，分散環境でも使えばいいっしょ，みたいな言い訳まで書いてある。いいのか？
この手法の売りは，低コストで汎用性の高いモーションデータセットを作成できる，という所にある。アクターには適当に部屋のなかを歩き回ってもらって，あとはそのデータを Motion Graph ビルダに食わせれば，それでデータの作成は終了。右旋回，左旋回，立ち止まり，歩き始め，ちょっと立ち止まって振り返る……とか，そんな細かい指定を明示的に行う必要は一切無くなり，しかもそこから再構成されたモーションは嘘みたいに滑らか。
本当にそんな感じにできる日がくるのかな……。できるものなら来てほしい。来る方に５００円ぐらい賭けてもいい。
ゲームのようにインタラクティブ性の極めて高いアプリケーションでは，こういった手抜きはなかなか使えないかもしれないけれど，例えばあまり活発でない NPC の動きなんかには十分に応用できると思う。例えば，「メタルギア」の敵兵がこんな感じの滑らかで自然なモーションで忍び寄って来たら……，相当面白いことになるだろうと思う。
2002-08-13
盆休みシーズンということもあって，通勤電車がいつもより多少すいているような気がする。めずらしく席が空いているからって座ってみると，これがたちまち眠りに落ちてしまう。通勤中に活字を読まないと調べものが先に進まないんだけれど……。まあ，立ってても寝るときは寝るんだから，しょうがないって言えばしょうがないのかもしれない。
Tim Rowley 氏のページにいつの間にか（相当前からだとは思うけれど） Graphics Hardware Workshop 2002 の論文リストが掲載されている。これがちょっと面白そうだったので覗いてみた。
http://www.cs.brown.edu/~tor/hwws2002.html
ちなみに Graphics Hardware Workshop 2002 の論文リストは spin にも存在する。
http://spin.s2c.ne.jp/gh2002.html
Rowley 氏のページからもリンクされていた。
当のワークショップの開催は９月頭なんだけれど，内容はずいぶんネタばれしちゃっている。 SIGGRAPH もそうなんだけれど，会報を受け取るまでもなくかなりの数の論文が事前に露出しているようだ。まあ，会場に足を運ぶ機会のない人にとっては，その方がぜんぜん有り難いんだけれど。
"Session 1: Texture Mapping" とか "Session 4: Shading and Shaders" とかは，まあ順当な内容なんだけれど， "Session 2: Ray Tracing vs. Scan Conversion" なんてのはちょっと過激かもしれない。グラフィックハードウェアのワークショップで「レイトレかスキャンラインか」なんて議題を真面目に扱う時代が来たか，って感じ。
例えば２年前 (HWWS 2000) とかは "Session 4: Anti-aliasing" なんてのが旬の話題だったりしたわけで，それが今やレイトレだのなんだの言い始めているような状況。不気味なまでの進化のスピードを感じさせられる。
しかし，いわゆる「ハイエンドＣＧ」と呼ばれているようなものでさえ実はスキャンライン・アルゴリズムだったりするような状況にあって，果たしてハードウェア・レイトレーシングに対して本当に需要があるのか，また技術的な面から見て将来性はあるのか，とか，なかなか微妙なところだと思うんだけれど，あり得る未来像の一つではあると思うので，せめて興味だけは持ちつづけてみたいなと思う。
例えばドイツはザールランド大の "Interactive Global Illumination" とか，現状での応用は難しそうだけれど，可能性の片鱗みたいなものは感じさせる所があると思う。
http://graphics.cs.uni-sb.de/~wald/Publications/2002_IGI
SIGGRAPH 2002 でもコーネル大が同じようなネタの論文を提出していた。 "Interactive Global Illumination in Dynamic Scenes" だ。
http://www.graphics.cornell.edu/~parag/publications.html
面白そうなんだけれど，まだまだ発展途上中の技術である感じがしたので，内容はほとんど読んでいない。 Vincent Ma 氏の "Low Latency Photon Mapping Using Block Hashing" とかも面白そうだったんだけれど，同じような理由で読んでない。
http://www.cgl.uwaterloo.ca/~vma/
http://www.cgl.uwaterloo.ca/Projects/rendering/Papers/
暇があったら読むべきだよなあ。今は暇な時期なはずなんだけれど。
ザールランド大が進めているという "OpenRT" プロジェクトのページがちょっと面白そうだった。
http://www.openrt.de/Gallery/index.html
この付近の技術は，いかに処理の並列化を図るかという点で技術競争があるらしい。 GPU を使って交差判定を云々……とか言うのは，これとはまた別の話。これも近々調べてみたいなあと思う。
2002-08-14
つい最近まで気付かなかったんだけれど，先月末辺りから radiumsoftware.com のコンテンツ総容量がクォータを越えているとの警告メールが届いていた。いつもスパムが送られてくる方のアドレスに届けられていたもんだから，全然気が付かなくて，余裕で無視していた。危ない危ない……。
とは言っても，大したものを置いているわけでもないので，実際の合計総容量はそんなにもならないはず。どうも， Wiki の生成する細かなファイル群が，密かに影響を与えているようだ。ほっとくと過去の diff とか全部保存するんだよね，これ。
ここのサーバを使い始めてから，もう半年以上経過する。ちょっとした不満は残るものの，トータルで見れば良質なサービスにわりと満足している。そこで，これを機会に総容量 100MB までの契約に切り替えることにした。大して値段は変わらないし，このくらい用意しておけば何か役にたつこともあるだろうと考えたわけ。
最近，たまに trait （「特質」って訳すのかな……ちょっとしっくりこない）を使うことがあるので，念のため最適化のテストを行ってみることにした。
テンプレートの部分特殊化を利用して，コンパイル時に型情報から任意の情報を引き出す，というテクニックだ。これを gcc 3.1.1 に "-O2 -fomit-frame-pointer" フラグを付けてコンパイルすると，結果はだいたい以下のような感じになる。
まあ，何の変哲も無い内容。予想通りに最適化されていて，ちょっと安心。 static メンバ関数とか怪しいかもなあ，と思っていたんだけれど，まったくの杞憂だったようだ。こんな感じで，コンパイラの動作を地道に確認する作業もたまには必要になる。ベタな C ならともかく， C++ の generics 系の最適化処理なんて，動作が謎過ぎて想像することすら不可能だからだ。実際に試してみないことにはどうにもならない。
tvmet の使い方にも，そろそろメスを入れたい。このライブラリを実際に使用していると，最も強力な武器であるはずの "expression template" の恩恵を受ける箇所が，意外と少ないことに気付く。だから，その他の部分での使い方次第で多少なりの差が出てきそうな気がするのだ。結局のところ，なにかとコンストラクタを通す機会が多くなるので，やはりテンポラリオブジェクトの生成をいかに抑えるかが，高速化のカギになりそうだ。
ところで，上のソースもそうなんだけれど，「クラス定義中にメンバ関数を記述する場合は inline 宣言を入れなくてもインライン関数扱いになる」ってのは C++ の正式な仕様なんだったっけ？ やはりちゃんとした参考書を手元に置いておかないと不安だ。
http://www.amazon.co.jp/exec/obidos/ASIN/475611895X
「この本が無いと何もできない」って程じゃないんで，ずるずると購入しないままで今に至る。四の五の言わずに思い切って買っておかないと，いつまでたっても買わずに済ませてしまうのではないかと思う。うーむ。
最近，げーはなさんが PTM を布教しているので，僕もちょっと感化されて興味を持ってみたいと思う。今までまったく無視していた要素だったのだ。
スライドをばーっと流し読み。やっぱスライド付いてると助かるねえ……。んで，バンプマップの代替として，こういうのもありだと思うし，「オブジェクト内においてローカルな光の伝播を表現するための手段」の一つとして有望なものかもしれないなあ，とも思った。とにかく，もうちょっと詳しく読んでみることだ。
2002-08-15
jiro さんから Eurographics/SIGGRAPH HWW 2002 の論文 "Comparing Reyes and OpenGL on a Stream Architecture" についての情報を頂いた。
http://graphics.stanford.edu/papers/reyes-vs-opengl/
要するに， "Session 2: Ray Tracing vs. Scan Conversion" における "Scan Conversion" の方に対応する論文だ。しかし，僕の興味と言えばもっぱらレイトレの方にあったわけで，こちらの論文は，なんとなく題名だけ見て無視してしまっていた。
ところが，これを実際に読んでみると，その衝撃的な内容に驚かされることになった。まだ半分ぐらいしか読んでないんだけれど，正直なところ，かなり興奮している。
結局のところ，ハードウェア・レイトレーシングの研究はまだ始まったばかりに過ぎないわけで，その内容と言えば半ば夢物語みたいなレベルのものだ。ところが，これ（ハードウェア・スキャンライン）は違う。話の具体性のレベルが全然違う。実際にスキャンライン法（Reyes アルゴリズム）でレンダリングを行うハードウェアを開発し，その利点と将来性を具体的に提示してきている。これが実に現実的な内容で，もしかしたらもの凄く近い将来にこれが実現されるのではないかという期待さえ抱かせるような内容に仕上がっている。
ところで，この研究で新たにハードウェアを開発したとのことなんだけれど，これは専用のチップを新規に設計したわけではなく， "Imagine" と呼ばれる特殊なデバイスを使って行われたようだ。
http://cva.stanford.edu/imagine/
Imagine はスタンフォード大の CVA (Concurrent VLSI Architecture) グループによって研究・開発されたデバイスだ。大量の信号を処理するという目的に特化されたストリーム・プロセサで，完全にプログラマブルなアーキテクチャと， 20GFLOPS にも達する膨大な演算能力を有しており，その性能は現行の DSP (digital signal processor) の実に１０倍から２０倍にも相当すると言う。
前述の論文を執筆したスタンフォード大の John Owens のチームは，この Imagine プロセサ上で OpenGL と Reyes の２種類のアーキテクチャをベースとしたレンダラを開発した。そうすることにより，現行のアーキテクチャと Reyes アーキテクチャにおける，基本能力の比較と特徴の把握を正確に行おうとしたわけだ。
現行のアーキテクチャのほとんどは IRIS GL （OpenGL の元となった SGI 製の API）の哲学を踏襲している。つまり，三角形を基本プリミティブと定義し，視点座標系におけるバーテクス処理とスクリーン座標系におけるフラグメント処理の２系統を完全に分離するというアーキテクチャだ。これには，ライティング等の比較的高度な演算が要されるバーテクス処理と，基本的に補間ベースで動くために高い冗長性が保証されるフラグメント処理とを住み分けさせることによって，全体としての処理量を極力抑えようという意図がある。
ところが，昨今のハードウェアでは，このバランスが徐々に崩れつつある。 per-pixel 処理（ピクセルシェーダ）の登場によって，フラグメント側で高度なライティング処理等が行われるようになってきた。また，メッシュ密度の増加は留まる所を知らず，１つのプリミティブが画面上に占めるピクセル面積は限りなく少なくなろうとしている。もし曲面分割等の技術がもっと発展して，ほとんどのプリミティブが数ピクセルの面積しかもたないようになってしまったとしたら，バーテクス処理とフラグメント処理を分離している意味はほとんど失われてしまうのではないだろうか？
その疑問を突き詰めた先に存在するであろう解答が，ハードウェア Reyes の実装だ。そしてその実態とは……残りの半分を読んでからのお楽しみだ。
2002-08-16
Reyes と OpenGL のレンダリング・パイプラインを比較する際に，最も際立って見えるのが，両者におけるプリミティブの扱いの違いだ。 Reyes のパイプラインでは，全ての処理に先がけてテセレーション処理（ダイス処理と呼ばれるらしい）が行われ，全てのサーフェスはここでピクセルの４分の１以下のサイズにまで細分割される。こうして細分割された微小平面のことを「マイクロポリゴン」と呼び， Reyes ではこのマイクロポリゴンのみをプリミティブとして扱うことになる。
マイクロポリゴンは十分に微小なため（なんつってもピクセルサイズ以下だし），スムースシェーディングする必要がない。全てのマイクロポリゴンはフラットなものとして扱われ，単一のシェーダによって処理が行われる。いわゆるピクセルシェーダのようなものを用意する必要はなくて，全てが頂点単位でのオペレーションとして処理されるわけだ。
Reyes では高次曲面（例えばＢスプラインなど）がサーフェスの表現としてよく使用されるんだけど，これらの曲面の細分化もダイス処理内で行われる。ダイス処理では全てのサーフェスがピクセルサイズ以下に落とされるため，高次曲面はポリゴンとしての角張りが絶対に見えないレベルにまで適応的に細分化されることになる。このように，ピクセルサイズを基準として相対的に精度を高めることによって，人間の目に違和感をいだかせないような画像の生成に成功しているようだ。
例の論文 ("Comparing Reyes and OpenGL on a Stream Architecture") では，最後の章で，実験から得られた結果の検討を行っている。そこで挙げられている問題点のうち，特に重要視されているのが，細分割処理の重たさと無効なシェーディング処理の多さについてだ。
細分割処理については，まあ，元が重い処理だけにどうにも……って感じらしい。ピクセルサイズ以下に分割するってんだから，相当に分割レベルも高くなるだろうし，根本的にハードウェアでの実装が難しいというのも大きな影響を与えているようだ。特に Imagine のようなストリーム・プロセサとの相性は決して良くないらしい。
ハードウェア Reyes において無効なシェーディング処理が発生してしまうのは，サンプリング処理（いわゆるラスタライジングに相当する）においてピクセルサイズ以下のプリミティブを活用できていないことに起因しているらしい。本来の Reyes では統計的サンプリング処理によってピクセルサイズ以下のプリミティブも有効に活用されるらしいんだけれど，件の論文のハードウェアでは単一サンプリングを使用しているために，ピクセルサイズ以下のプリミティブは無駄に捨てられてしまうらしい。まあ，この件に関してはいずれ良い方向に転じる可能性もあるわけだし，それほど深刻ではないのかもしれない。
この論文を読んで， Reyes (RenderMan) にもちょっと興味が出てきた。レイトレでも三角形ベースでもない所に，こんな世界があったんだなあ，って感じ。 Hanrahan 先生の講義ノート "The Design of RenderMan" とか見て，その哲学みたいなものは何となく伝わってくるんだけれど，もうちょっと詳しい部分を調べてみたい感じもする。例えば，この仕様でスキャンライン法を選択することにどんなメリットがあったのか，とか，影処理にはどうやって対応するのか，とか……。
http://graphics.stanford.edu/courses/cs448a-01-fall/lectures...
いまさら中途半端に手を出した所で役立ちそうな分野でもないけれど，なんつっても現役でＣＧ産業の中核を担っている技術なわけだし，おいそれと無視するわけにも行かなさそうだ。どっかに簡単な資料でも落ちてないかなー。
2002-08-17
知人に拉致られに石神井公園に移動。拉致なのに現地集合とはこれいかに。そして目隠しされて車で搬送。んで，遥か群馬の山奥で降ろされた。ラフティングとかやるらしい。すげー。
ところが，無理なスケジューリングに身体が不調をきたして，いきなり高熱状態に突入。結局，ラフティングは金だけ払ってリタイヤ。１万円をタダ払いに群馬の山奥にまで来たのか。むなしい。
家に帰って体温を計ってみたら，なにげに３９度を越えていた。やばい，死ぬ。帰りの車中はほんと死ぬかと思ったぐらい苦しかった。家に帰って布団に入った瞬間が，今までの人生の中で最も幸せな瞬間だった，ってくらい。ある意味いい経験だったと言える。健康万歳。
そんな感じで，ひさびさに生きることがつらいと感じた一日だった。
2002-08-18
一時期は３９度を突破して死をも覚悟した高熱は，一晩あけたら嘘のように引いていた。体温測ってみたら，むちゃくちゃ平温。こんなに変化の激しい体調を経験したのも久しぶりだなあ，と思った。たいていは，悪くなるのは一瞬でも，回復するにはだいぶ時間を要するものなんだけれど。
pathtracer にポリゴンが食わせられるようになったので，もうちょっと屋内っぽい雰囲気を出してみようと思う。ラジオシティのサンプル画像なんかでは，よく屋内の間接照明を模したものが使われているけれど，僕が好きなのは強烈な太陽光が屋内で複雑な反射を繰り返すようなタイプの間接照明だ。よく分からないけども，こういう極端なエッジの出てしまう照明はラジオシティでは嫌われるんではないかなあ，と思う。
このサンプル画像を生成するのに 1000 path/pixel も使用しているんだけれど，まだ顕著なノイズが残っている。粒度の高いフィルム画像みたいでいいでしょ，とかでごまかせればいいけれど，スペキュラを加えると無視できないくらい見苦しいノイズが発生してしまうし，だいたい現状でも重すぎる負荷をなんとか軽減しないことには，とても実用にならない。
Jensen 先生のコース "Image Synthesis Techniques" より "Irradiance Caching and Photon Maps" のノートとか参照してみたりする。
http://graphics.stanford.edu/courses/cs348b-02/BiasedMC.pdf
やはり放射輝度キャッシュが重要なテクニックとなるようだ。処理の軽減だけでなく，ノイズの軽減にも寄与するのではないかと思う。しかしあの式は何度見ても分からない。 Jensen 本中で最も天下り的な解説がなされている箇所ではないかと思う。ううむ。
放射輝度を全てフォトンマップから求めるようにするのが，最も簡単で実装もシンプルにまとまりそうな解決方法なんだけれど，やはり品質に限界があるようだ。 Jensen 本では最終的に，２次反射以降をフォトンマップによって処理する方法を提示している。しかし，１次反射が最も重い処理であるがゆえに，この方法で満足できるほどの軽量化が得られるかどうかは微妙なところかもしれない。これに対して，放射輝度キャッシングは確実にサンプル数を減らす効果があるので，かなり速くなる見込みがある。うーむ。
そんなわけで，これでやっとフォトンマップに移行することになると思う。とりあえず pathtracer はここで一区切り付けておこう。
http://www.radiumsoftware.com/files/pathtrace.020818.tar.gz
フォトンマップ自体はそれほど難しくないメカニズムだし，重要なところをかなり手抜き（拡散反射のみ，テクスチャ無し）してるんで，たぶん苦労しないはずだと見込んでいる。どうなることやら。
2002-08-19
うう，風邪はすっかり治ったと思っていたのに，今度は急に腹の具合が悪くなってきた。洒落にならないよ，これは……。なにげに台風とか来てるし，なんだか知らないけど，もう大変。
安藤日記の安藤さんから Reyes についてコメントを頂く。ありがたいことです。最近コメント運が急上昇中のようだ。
で，結局のところ， Reyes がスキャンライン法を使用していた理由については，成り行き上そうなってしまったに過ぎない，ってことで結論付けられそうだ。現に，原典 "The Reyes Image Rendering Architecture" ではＺバッファの使用を前提として話が進められている。しかし当時はそんな大容量のＺバッファを扱うことのできるマシンなんてなかったもんだから，スキャンライン法や「Ｚバッファもどき」のような方法を使ってその場をしのいでいた，という事情があったらしい。件の論文の実装では「バケット分割型Ｚバッファ」だかなんだかって感じの方法でメモリ不足を補っている。
ちなみに，原典が発表されたのは８７年の SIGGRAPH 。実装を解説する章には， VAX よりも CCI の方が数倍速かった（CCI ってどこのマシン？），とか，静止画のレンダリングに８時間かかってます，とか，時代を匂わせるキーワードが所々にちりばめられている。またこれは，当時の Reyes の構想がいかにオーバースペックなものであったのか，うかがい知ることのできる一面でもあると思う。
しかしどうやら，彼らのような天才にとってみれば，現状など既に去ろうとしている通過点のようにしか見えないものらしい。 1986 年の時点で，彼らは大胆にも次のような構想を掲げている。
これ，いつごろ実現するつもりで計画立てたんだろうなあ……。 John Carmack のオーバースペック指向にも言えることなんだけれど，出来るやつほど未来に対する目算が大胆だ。凡人が現状にへばり付いて生きていくのに必死になっている間に，既に彼らはどこか見えない所へ跳躍しようと助走を始めている。
せいぜい，その靴の裏にでもへばり付ければ，どこか遠くへと連れて行ってくれるかもしれないけども。
余談だけれど，件の論文を読んでいると， "hither" "yon" という単語が何回か登場してくる。意味が分からないので辞書を引いてみると，それぞれ "near" と "far" に対応する文語（方言）らしい。ふーむ……。
2002-08-20
結局，あの台風は大した雨も降らさずに，どこかへと消え去ってしまったようだ。ただ，台風の余波なのか，強烈な風が一日中吹き荒れていた。涼しくていい気持ち。もう秋かと思わせるような涼しさが，過ごしやすい一日だった。
新しいサーバ用マシンが届いた。さっそく設置しようと場所を探してみるものの，どこにも置く場所が無いことに気付く。机の下とかに詰め込めないこともないけれど，そういうのはメンテが非常にしにくくなってしまう。それは出来れば避けたい……。
結局，余剰機材を入れ換えたり詰め込んだりして，なんとか机の上を確保することができた。ＯＳのセットアップはまだこれからだ。こんな時「機材管理兼シスアド」みたいな人がいるといいんだけどなあ，と思うことがある。みんな掛け持ちでやっているもんだから，なかなか上手く行ってないような気がする。
HWWS 2002 の "The Ray Engine" を読んでみる。
http://graphics.cs.uiuc.edu/~jch/papers/rt2/
GPU を使って三角形の交差判定を高速に行う手法について述べた論文だ。コンセプトは Kano さんの "Dynamic Far Demo" と似たような感じ。 per-pixel 処理（ピクセルシェーダ）を使って，相互に関連の無い複数の演算を同時に解決させよう，という戦法だ。
Ray Engine では，テクスチャ画像に対してレイ情報を埋め込み，頂点属性に対して判定対象（三角形）の情報を埋めこむという方式をとっている。つまり，１回の反復で，単一の三角形に対する複数レイとの交差判定を処理することができるというわけだ。
まず，レイの原点座標の情報を埋め込んだテクスチャと，方向ベクトルの情報を埋め込んだテクスチャと，合計２枚のテクスチャを用意する。これをマルチテクスチャとしてバインドし，画面を覆い尽くす四角形を描画する。このとき，四角形の頂点には属性情報として判定対象の三角形に関する情報が埋め込まれている（４頂点全てに同じ値が渡される）。この情報はバーテクスシェーダ内で前処理され，法線ベクトルや辺ベクトルなど，交差判定に必要な情報がセットアップされる。そして最後に，これらの情報を元にピクセルシェーダの中で交差判定が行われ，その結果がフレームバッファに出力される。
Ray Engine で使用しているレイ対三角形の交差判定は，おなじみ Moller and Trumbore のもの。バーテクスシェーダでのセットアップがあれば，ピクセルシェーダは２０命令程度で済ますことができるようだ。ただし，ピクセルシェーダには除算命令が無いため，そこは texdepth 命令で代用するなど，細かな工夫は必要とされるらしい。
こうして求められた判定結果はアルファチャネルに出力され，媒介変数 (t) はデプス値に変換される。こうすることにより，交差の有無をアルファテストによって判定し，交点の前後に対してデプステストで優先順位を付けることが可能となる。これらのテストを有効にした状態で，次の結果をどんどん重ね描きしていけば，複数の交差判定を続けて行うことになる。最終的にフレームバッファ上には，レイ原点に最も近い交差点に関する情報が残っているはずだ。
ここでまず問題になるのが，フラグメント処理における数値精度の問題だ。判定対象となる三角形の情報は頂点属性として渡される − つまり float 値として渡されるため，十分な精度が保証できる。しかし，レイはテクスチャによって表現される必要がある。一般にテクスチャは整数フォーマットが使用されるため，精度とレンジを確保することが非常に難しい。しかも現行のピクセルシェーダ (PS1.4) は内部演算精度が低い（16bit 固定小数点を使用）ため，演算中に発生する誤差も非常に大きい。 Ray Engine でもその誤差は除去しきれていない。将来的なハードウェアの性能向上に期待する，ということのようだ。
2002-08-21
酔狂で ACM SIGGRAPH の会員になってみた。
というのも， ACM Digital Library を使ってみたかったのだ。
ACM Digital Library は， ACM 関連誌に掲載された文献を網羅する電子図書館だ。ただし利用には ACM もしくは特定の SIG (Special Interest Groups) の会員であることが必須。とりあえずウェブアカウントが無いことにはサーチさえもさせてもらえない（ウェブアカウントは無料で発行している）。
グラフィクス関連の論文だけが目的であるならば， ACM の会員にならずとも，とりあえず SIGGRAPH のメンバーシップさえ取得すればいい。入会費は $27 ，日本円にして ¥3,000 ぐらい。それで SIGGRAPH の会員になれば， SIGGRAH 関連の文献は全て見放題になる。非会員の場合は１回のダウンロードにつき $10 も取られるのに対して $27 で見放題になるんだから，まあ割はいいと思う。専門書１冊買っちゃったぐらいの気持ちで払えばいいのかな……。
実の所，最近は SIGGRAPH 関連で発表される論文のほとんどは著者自身のホームページから入手が可能であるため，わざわざ Digital Library を利用する必要もないのかもしれない。特に Tim Rowley 氏のリンク集なんかを使えば，ほとんど苦労することなく収集が可能だ。しかし，ちょっと古い文献になったりすると，やはりネット上では入手できないものも多く，そうした場合には Digital Library が役に立つこともあるだろうと思う。
で， Ray Engine 。個人的に GPU 活用系の変態テクニックはあまり乗る気がしなかったんだけれど， "The Ray Engine" はなかなか面白くて，楽しく読むことができた。この論文を通して， GPU 活用技に対する見方が，ほんの少し変わったかもしれない。特に，原点からの距離の比較をＺテストで代用する部分とか，意外とうまい具合に仕組みがはまっていて，面白いなと思った。
NV30 では浮動小数点ベースのピクセルフォーマットがサポートされる予定とのことで，現状で最も深刻な問題である精度の悪さも一気に解決されそうだ。そうしたら，本気で hardware accelerated pathtracing とか実装できて，ある程度面白い結果を残すことができるのかもしれない。
Emotion Engine の VPU0 のマイクロモードとか，本来，こういった用途をサポートするために用意された機能なんだと思うんだけれど，あまり上手く使われていない感じがする。やはりセットアップの手間とかあるし， CPU からコプロとして使う場合（マクロモード）と比較して劇的に速度が向上するわけでもないので，なかなか魅力を感じ難いというのが，活用されにくい要因ではないかと思う。せめてもうちょっとメモリが広くて，大量にデータを突っ込んだらあとは回しっぱなし，とか，そういう使い方のできるものであれば良かったのかもしれない。今の仕様だと，まずダブルバッファを作ってから，そこに DMA でデータを突っ込んでは回収したりで， CPU と VPU が二人三脚状態になってしまい，とにかくあまりかっこよくないのだ。
とか言って，本当は，ちゃんとやってる所はやってるんだろうなあ，と思う。ＰＤ社とかＮＤ社とか，あの変態ハードウェアをどんな方法で手なずけているのか，そのコードを一度でもいいから拝んでみたいものだと思う。
Xbox は UMA だから， CPU-GPU 間のデータのやりとりとか，ちょっと楽そうだ。 PC と比較しても強みがあるわけで，こういったテクニックを最も応用しがいのあるハードウェアは Xbox なのかもしれないな，と思った。
2002-08-22
なんだか一日中眠い日。暑くもなく，寒くもない，ぬるま湯のような気候が，生活から緊張感を取り去ってしまったようだ（もともと緊張感無いけど）。部屋の外で，死にかけの蝉がしょぼい声で鳴いている。十分後には死んでるだろう，たぶん。
そうやってまた，何気なく秋がやってきたわけ。大戸屋に行ってサンマ定食でも食べてこよう。
いつだったか読み始めた Wojciech Matusik の "Image-Based 3D Photography using Opacity Hulls" なんだけれど，参考文献が多くてちょっと苦労している。
http://graphics.lcs.mit.edu/~wojciech/
この論文は過去に発表されたネタの組み合わせ技的な側面が強くて，その知識を前提として話を進めている感じがする。 "reflectance field" については Devebec 辺りを， "Visual Hull" については Wojciech の過去の論文を参照するとして，もう一つの重要な要素が SURFELS - "Surface Elements as Rendering Primitives" と呼ばれる技術だ。
http://www.merl.com/projects/surfels/
"Surfel" は，ぶっちゃけた話，点集合から構成されるサーフェス表現方式だ。点集合とは言っても，ボリュームではなく，あくまでもサーフェスというのがコンセプトらしい。各 surfel には法線やらテクスチャやらの情報が与えられるため，通常のポリゴンモデルで使ってるような反射モデルの演算等を適用することが可能だ。 surfel の一応の定義は「形状と陰影に関する属性を持ち，物体の表面を局所的に近似する，０次元のＮ組集合」とされている。よくわからん。
で， surfel 自体はちょっと微妙な技術だなあ，と思うんだけれど， Wojciech の応用はなかなか面白い結果を出していると思う。毛（ファー）や羽根（フェザー）など，通常のキャプチャー技術では取得し難くく，表示することも難しい形状・材質を，点集合ベースの技術によって見事に表現することに成功しているからだ。
今回の Wojciech の論文で最も特徴的なのは，アルファマットの生成により半透明部分の取得と表示を可能としたところにある。詳しい原理は面倒くさいんでで調べてないんだけれど， Smith & Blinn の論文 "Blue screen matting" を元にしているらしい。
http://research.microsoft.com/MSRSIGGRAPH/96/BlueScreen.htm
この論文の概要は，２種類の背景においてキャプチャーを行えば，「色飛び」を防いで正確なマット（マスク画像）を得ることができる，ということのようだ。
それで，２種類の背景でもってオブジェクトの全周囲をキャプチャーしなきゃなんないんだけれど， Wojciech はここで，プラズマＴＶを背景に使用するという，面白い方法を試している。オブジェクトの背後に配置したプラズマテレビ上に濃淡付きの縞模様を表示しキャプチャー，そして濃淡パターンの位相を反転してもう一度キャプチャー。ここから，オブジェクトのアルファマットを生成する。
えーと，そんなわけで，なにげに小技の連携が効いた論文で，なかなか読み終えることができない。ちょっと力技っぽい技術ではあるんだけれど，いままでに無かったような種類の表現が可能となっているわけで，それなりに注目に値する技術なのではないかなあ，と思う。
ていうか，とりあえず動いてるとこ見てみたいんだよなあ。
2002-08-23
Gamasutra の "Game Scripting in Python" を読む。
http://www.gamasutra.com/features/20020821/dawson_01.htm
Humongous Entertainment 社がゲームのスクリプトエンジンとして Python を使用しているって話は，だいぶ前にも聞いたことがあるような気がする。あと Python を使用しているゲームと言えば "Blade of Darkness" あたりが有名だ。
http://www.codemastersusa.com/blade/
ただし Blade of Darkness がスクリプトエンジンとして Python を採用したのには，ゲームの改変 (mod) への対応を強化するため，という意図が少なからずあるようだ。それに対して Humongous 社の方は，純粋に開発コストを引き下げる目的で Python を使用しているのが大きな違いだ。
Humongous 社ではもう一つの候補として Lua を検討していたようだけれど，ドキュメントが心もとないという理由で最終的には Python を選択したそうだ。今でもドキュメントの量で言うと圧倒的に Python の方が充実しているけれど，だからと言って Python の方が優れているかと言うと微妙なところ。 Lua は組み込み用途に特化されているという特徴があり，ゲームのように極度に特殊化されたアプリケーションではその特徴が大きな利点となり得るからだ。
件の記事では， Python をゲームに組み込むにあたってのさまざまな所感が述べられている。結果的にその目論みは成功を収めているようだ。スクリプト言語ではお決まりのメモリ／ガベージコレクタ問題や，パフォーマンスの問題，ちょっと変わったところでは， Python をゲームに組み込むにあたっての法律的な問題や， Python デバッガの問題など，さまざまな意見が述べられている。
特に， Humongous 社が開発したデバッガがオープンソース化されているという事実は非常に興味深い。 Humongous 社では家庭用コンソールにも移植をする都合上，どうしてもリモートデバッガが欲しくなったため，これを自前で開発した。しかし，彼らにとってはゲーム制作こそが本業であり，ツール作りは二の次であったため，これをオープンソース化することでメンテナンスを楽にしようという考えがあったようだ。
Python を使用したことによる利点としては，永続化オブジェクトの手軽さや，マイクロスレッドによるＡＩ処理の簡潔化などが挙げられている。 Python の永続化オブジェクト機構 (Pickle) は，確かにとても重要な要素だと思う。あそこまで手軽にオブジェクトのセーブ・ロードを実現できる手段を，僕は他に知らないからだ。
2002-08-24
普通の休日。なんか知らんけど最近睡眠不足気味なので，とにかく寝まくる。ぐう……。
飯を食うついでにゲーセンなぞに行ってみるんだけれど，付近のゲーセンから「斑鳩」が消えて以来，やるものが無くなってしまって困っている。とりあえず「ギガウィング」でもやってお茶を濁しておこう。それにしても，４面が抜けれないなあ……。
Vincent Ma の "Low Lantency Photon Mapping Using Block Hashing" に手を出してみる。
http://www.cgl.uwaterloo.ca/~vma/
http://www.cgl.uwaterloo.ca/Projects/rendering/Papers/photha...
フォトンマッピングの放射輝度推定において重要になるのが，「任意の点から最も近いｋ個のフォトンを列挙する」という処理だ。これは "k-nearest neighbours (kNN) search" と呼ばれる問題で，既に数学者の間でこれを効率良く解くためのアルゴリズムが研究されているようだ。
http://www.google.co.jp/search?q=%22k-nearest+neighbours%22+...
Jensen が使用した kd tree の方法も，そうした解法の内の一つらしい。これに対して Vincent Ma は "locality sensitive hash" という手法をベースとしてた「近似ｋ近傍」 (approximate kNN / AkNN) を使用している。
http://www.google.co.jp/search?q=%22locality+sensitive+hash%...
これにより，多少の誤差は生じつつも，常に一定の処理量で kNN を解決することに成功しているようだ。詳しい所はもう少し読んでみないと分からない。でも，だいたいの内容はそんな感じだ。
それで，ちょっとこの LSH 方面にも手を出してみようと思ったんだけれど，僕の数学的なバックグランドではとても太刀打ちできなさそうな内容だ。うーむ，まあいいや……件の論文に書かれている内容だけで十分だと思う。
Vincent Ma のページをよく見てみたら，件の論文のスライドが存在した。
http://www.cgl.uwaterloo.ca/~vma/thesis/presentation/N_Block...
ああ，こっち先に読んだ方が良かったなあ……。なんかちょっと失敗した気分。もういいや，眠いので寝る。
2002-08-25
えーと，全然普通の休日。近所の電器屋で USB HDD なぞ買って見た。
http://www.adtec.co.jp/parts/AD-HDD2.5U2.html
thumb drive みたいにポケットに入れて，って訳には行かないけれど，持ち歩くには便利な大きさだ。 USB バスパワーで駆動するのも重要。これで 20GB やら 40GB やら入るってんだから，恐ろしい時代になったものだと思う。
フォトンマップをのろのろと実装中。集中力無くて，あまり進みが良くない……。とりあえずは kd tree を使わずに，素の実装でなんとか組み上げようと思っている。 kd tree を使うとなると，木のバランスの保持だとか，最適化された kNN サーチだとか，気を遣わなきゃならないことが多くなりそうだからだ。
木構造を使わずに，単純なサーチ処理でフォトンを列挙する処理を書いている途中に，ふと，疑問に思うことがあった。 STL のバイナリサーチ系のアルゴリズムと list コンテナの組み合わせについてだ。
例えば，値順にソートされたコンテナ c が存在するとして，これに値 v を新たに追加する処理を考える。 v を挿入すべき場所を探すには以下のような方法が考えられる。
A は find_if を使った単純な線形探索で， B は lower_bound を使った２分探索だ。もし c が vector だったら当然 B の方が速いんだけれど， c が list だったらどうだろうか。線形リストに対しての２分探索なんて，聞くからに遅そうだ。
両者の処理時間を比較するプログラムを組んでみた。なんてことはない。こんな感じ。
結果はこんな感じになった。
左の数値がリストの長さ，右の数値が経過時間だ。サーチ範囲が狭い場合（１００以下とか）は lower_bound が健闘しているけれど，極端に量が多くなると，無視できないぐらいの性能低下が見られるようだ。
まあ，そういうわけで，リストの場合は lower_bound はやめよう……と。それだけ。
2002-08-26
ようやく radiumsoftware.com のサーバ入れ換えが完了したみたいだ。
入れ換え作業の間は Wiki の編集を控えるようにしていた。更新内容が無駄になる可能性があるからだ。それで，移転にあたって久しぶりに内容を見返してみたんだけれど，改めて見るとずいぶん乱雑に情報が積みあげられているものだなあ，と思った。もう少し効率良く，系統立てて整理しないと，どんどんゴミばかり溜まっていってしまう気がする。
なんとなくで辿り着いた "CyberModeler" のページ。えっと……俺ニュースから，かな。
CyberModeler は，市販のデジカメを使って手軽に visual hull を作成する，という内容のツールのようだ。「キャリブレーションシート」と呼ばれるディスク状のマーカを使って座標の取得を行っている。あとはブルーバックさえ用意すれば，それで，お茶の間イメージベーストモデリングの完成というわけ。なるほど，確かに，これならば。
これにリフレクタンスやアルファマットを取得する機能を加えたのが，例の opacity hull なのかな。しかしそこに辿り着くには，複雑な光源装置や背景用のディスプレイ装置が必要となってしまうわけで，この製品のようなお手軽さは到底望むべくも無い。まあそれは冗談として，せめてライティングの問題だけでも，もう少し改善できないものかと思う。
うーむ，こういうときに使うのが，これなんだろうか。
http://graphics.stanford.edu/papers/invrend/
Ramamoorthi の "Inverse Rendering" だ。概要を読む限りでは，不明な照明環境と不明な BRDF の組み合わせにおいて，うまく両者の折り合いを付けるためのコツ伝授します，みたいな感じに聞こえる。本文の方は，球面調和関数が周波数領域でうだうだうだ……って感じの小難しい内容。さすがに気力がなくて，ほとんど読んでない。それに，正確なモデルの形状が分かってないことにはどうにもならんのだよな，これは。
結局のところ，安価な装備でリフレクタンスを得るのは無茶そうなので，せめて，なるべく素のアルベド（反射係数）に近いテクスチャを得るようにすることが，とりあえずの目標だと思う。それにはまず，まんべんなく一様な環境光を与えるようにすることだ。それでも陰ってしまう部分は，セルフシャドウの焼き付けだと思えばいい（いいのかな？）。
しかし，ブルーバックを得なきゃならんのだから，レフ版敷いて解決って訳にも行かなさそうだ。素の照明を当てたらどうしても偏りが出ちゃうだろうし，かといって照明不足だと汚いテクスチャになってしまうだろうし……うーむ。
関連ページを探っていると，「ライティングボックス」なる製品を紹介している部分を見つけた。十分な環境光を得るためにはこの製品を使え，ってことらしい。
http://www.shashin-kagaku.co.jp/division/system/xapros/index...
これで，輝度が飽和している部分は背景だと断定するようなオプションを付ければ，形状の抽出は可能になるかもしれない。色抜けの心配も無くなるかな。
2002-08-27
なんとなく Low Technicians のページを訪問。
http://www.lowtechnicians.com/
いつの間にか "Random Event" の mp3 がアップロードされていたようだ。気付かなかった……。
http://analogaether.com/lowtech/
Low Technicians によるオリジナルミックスが２曲と， Alpha Conspiracy によるリミックスバージョンが１曲入っている。個人的にはアルバムバージョンがお気に入り。 Low Technicians の持ち味であるところのハードなエレクトロ感が，最も率直に出ている曲だと思うからだ。
秋にはフルアルバムも控えているようで，楽しみな限り。その後には iris のアルバムも控えているし，しばらくの間，ここらへん，盛り上がりそうな感じがする。
http://www.diffusionrecords.com/
なにげに，ずんば小林氏 (CYBORG'80s) のアルバムもいつの間にか出ていたので，思わず購入。
http://www18.big.or.jp/~zunba/80s1st.htm
家庭内手工業的通販なんて久しぶりだなあ……。 amazon.com なんかではマイナーレーベルの取り扱いもしているみたいだけれど， co.jp の方にはそういうのは無いみたいだ。もっとも，向こうの amazon は，電化製品や家庭雑貨の取り扱いにまで手を広げているような状態だから，いまさら何を売った所でおかしくはないと思う。クルマだって買えてしまうぐらいなんだから！ （中身は別の代理店だけど）
http://www.carsdirect.com/home?partner=amzn
えっと，まあ，それはともかくとして……こういう個人通販では，銀行振込みの手続きがちょっと面倒くさいな，と思った。 paypal とか使ったら，そこらへん，もっとお手軽にできるのかもしれない。
個人取引でクレジット決済が使えるのは面白いと思う。ただ，クレジットだと手数料を 2.2% + 0.3$ も請求されてしまうらしく，ちょっと割高感がある。
ていうか，銀行のインターネットバンキングを使えばいいんだ。申し込むのが面倒くさくて今まで無視していたんだけれど，これを機に登録しておこうと思う。毎月の家賃の振込みだって， PC からできれば，ずいぶん楽になるだろう。
http://www.ufjbank.co.jp/ib/index.html
新しく買った USB HDD にデータを移すべく，半ばごった煮状態となりつつある HDD の整理をしていたら，なんだか懐かしいデータがぽろぽろと出てきた。 mp3 とか mod とか，わりとまめに収集しているので，そういうのがごちゃごちゃと溜まってしまうのだ。
常盤兼成さんの曲も，そんな懐かしいデータの内の一つ。しばらく動きが見られないと思っていたら， muzie の方に活動の場を移し，地道に作曲活動を続けていたようだ。
http://www.muzie.co.jp/cgi-bin/artist.cgi?id=a000039
さっそく何曲がダウンロード。この人はフュージョン系の曲がいい感じなんだ。
2002-08-28
今週は，先週とはうって変わって調子がいい。日中眠くならないのだ。最近，睡眠時間が増えていたのを，きっちり５時間に戻したのが良かったのかもしれない。４時間は短すぎるし，６〜７時間でも寝足りない感覚が残る。それが５時間だと，なんとなくうまく行く感じがする。
よく言われることだけれど，目覚めの状態と睡眠時間の長さの間には，相関性がそれほど無いように思われる。ノンレム睡眠中に目覚めるようにするといい，なんて話もよく聞く。僕の場合の５時間という時間は，そういうのと関連があるのかもしれない。
ていうか本当はもっと寝るようにした方がいいと思う……。アインシュタインは１日に１０時間近く寝てたと言うし，睡眠時間を短くしたからと言って良い事は何も無いように思える。たぶん，失うものも色々あると思うから。
最近，気まぐれで流体関連をあてもなく調べていたんだけれど，そしたらいつのまにか強化現実関連のページに辿り着いていた。何故だ。
http://www.se.rit.edu/~jrv/research/ar/
前にも一度，ここ通ったなあ。 Steven Schkolne の "Surface Drawing" とか，面白そうだったのを覚えている。
http://www.cs.caltech.edu/~ss/sdraw/
"Surface Drawing" は，強化現実空間上でモデリングを行うツールだ。
http://www.cs.caltech.edu/~ss/pubs/schkolneschroder99.pdf
センサーグローブを付けた手で宙をなぞればそこに面が現れ，それをキッチン・トン（鋏）で掴んで回転させたり，消しゴムで削ったり，マグネットで変形させたり，といった感じで，非常に直感的なインタフェースを実現しているのが特徴だ。
同システムは "Responsive Workbench" と呼ばれる表示装置を使用している。
http://www.google.com/search?q=%22responsive+workbench%22
http://graphics.stanford.edu/projects/RWB/
Responsive Workbench は独 GMD 研究所の Wolfgang Krueger によって開発された装置だ。上面が半透明になっている机の裏側に対して，プロジェクタを使ってステレオ画像を投影する。シャッターグラスを通してこの机を上から覗き込むと，机の上に 3D 画像が展開しているような感じに見えるらしい。
シースルー型 HMD 装置と比較して，視点移動と表示の間にレイテンシが存在しない点や，複数人で作業する場合のコストが安くあがることなどが特徴として考えられる（実際のところは，よく知らない）。何らかのコラボレーションを行う場合なんかには，こういった装置の方が向いているのかもしれない。
Schkolne 氏の研究でもう一つ面白かったのが "Assembling and Rearranging Digital Objects in Physical Space with Tongs, a Gluegun, and a Lightsaber" − 「キッチン・トンとグルーガンとライトサーベルを使った，物理空間上におけるデジタルオブジェクトの編集」だ。
http://www.cs.caltech.edu/~ss/pubs/schkolnelightsaber.pdf
これが， Responsive Workbench とキッチン・トン，それにグルーガン（工作なんかで使う銃型の接着剤）とライトサーベル（！）の組み合わせで Maya に勝てる！ という凄い内容。キッチン・トンはオブジェクトの移動・回転を担い，グルーガンはオブジェクトの結合，ライトサーベルはオブジェクトの切り離しに使用するそうだ。このインタフェースを使ってオブジェクトの組み立て，切り離し，変形といった簡単な作業を複数の被験者に行ってもらったところ，平均で Maya の２倍以上の作業速度が得られたとのこと。うーむ。
ていうか， keyword に "tongs, gluegun, lightsaber, tangilble tools, augmented reality" とか，しれっと書いてあるところが凄い。 tongs ，じゃねえっつうの，みたいな。
"Surface Drawing" の論文とか，図が全部手書きだったりとか，なんか絶妙に味わい深い研究をする人だ。本当の芸術感覚を持つ人の研究って面白いかもしれないなあ，と思った。
2002-08-29
ちょっとした締め切りが間近に控えていて，その影響で今日は泊まり作業。余裕を持っていたつもりでも，どうしても締め切り間際にしわ寄せがきてしまうのは，既にお定まりのパターンだ。その中にあって，僕だけがそれほど忙しくないのも，一つのパターンなのかもしれない。今のうちにサーバの構築作業でもやっておこう……。
VORC 経由の情報で， virt の "fx 2.0" がリリースされたことを知る。
http://virt.vgmix.com/fx2.html
fx 2.0 は前作 "fx" の続編。前作はコナミのドラキュラサウンドを模したものだったのに対して，今作はコナミサウンドの全般的なスタイルをコピーすることに挑戦している。テーマとなるのは "Gyruss", "Topgun", "Contra", "TMNT" など，コナミの NES 時代を代表する名作ばかり。そんな感じで，全ての曲に元ネタは存在するものの，楽曲自体は完全なオリジナルとなっている。
雰囲気は凄くよく表現できていると思う。どの曲も中盤以降において virt 独特のキャラクタであるところの技巧派プログレ色が濃くなっているところも，なんか面白い。当時はメモリの制限がきつかったから，こんな長くて凝った曲は使えなかっただろうなあ，と想いを馳せる。 "bogey at your 6: Topgun" のギターソロとか，当時では到達し得なかったであろう極みを感じさせる。
virt 自身も書いているけれど，多くの mod プレイヤでは正しく演奏できないようなので， mp3 の方をダウンロードするのが無難なようだ。 modplug player や xmplay なんかでもダメで，オリジナルの Impulse Tracker だけが正しく演奏できるとのこと。
また，この人の曲は，当時の原始的なシンセサイザが醸し出すクリスピーな音感を意図的に使っている風があるので， mod プレイヤに搭載されている各種フィルタは切った状態にするのが正しい聴き方のようだ。ローパスフィルタを入れると，音のカドが取れて迫力が薄れてしまう。音色を構成する波形が単純なぶん，その影響は大きいのではないかと思う。三角波とかただの正弦波っぽくなっちゃうしね……。
2002-08-30
久しぶりに机の下から起床。寝袋を家に置いたままだったので，梱包材のエアキャップをシートにして寝てた。他に，エアバックを枕として使用するなど，梱包材・緩衝材の類は寝具としての応用価値が高い。あとは机にカーテンを装着すれば完璧だなあ……。
んで，今日は飲みの日。夜の新宿に繰り出して，適当に飲んで，適当に解散して，家に着いてすぐ寝た。ダメだ，アルコールを採ると末端が痺れてしまって何もできやしない。どうにもアセトアルデヒドの分解が追いつかない体質らしい。
http://www.google.co.jp/search?q=%83A%83Z%83g%83A%83%8B%83f%...
ただ，アルコールを適量に採るとすぐに危険信号が出てしまうので，二日酔いをするほど飲んだことは一度もない。たぶん，そんなに飲んだら，その前に逝ってしまうだろうと思う。
2002-08-31
今日は普通に休みの日。ふらっと立ち寄った本屋で CG World なぞを買ってみた。今月号はゲーム制作現場の特集みたいだし， Houdini の体験版も付いているとのことで，なんとなく購買意欲をそそられたからだ。
それで，ゲーム制作現場の特集なんだけど……うーむ，なんか，かなりハズしてる気がする。
この業界も少し前までは，ハードウェア・ソフトウェアの両面における技術革新が激しく，それに伴って導入されたＣＧツール類が現場の有様を大きく変化させ，制作手法自体が多角的かつドラスティックに変化していく……という流れがあったために，ただ現場のありのままを伝えるだけでそれなりの価値があったのかもしれない。しかし，現在は制作手法についてやや停滞の時期にあるために，漠然としたインタビュー記事だけではみな同じような内容になってしまい，あまり面白い記事にはならないのではないかと思う。よほど変わったプロジェクトでない限りは，もっと各プロダクションの特色みたいな所を積極的に突っ込まないと，中庸な内容に終わってしまうのではないかと思う。
ともかく，今さらエメドラは無いだろう，とだけは言っておきたい。何故……。
フォトンマップをなんとか絵の出る所まで進めてみた。とは言っても，まだまともな絵は出ない。色々と勘違いをかましてしまっているようで，根本的に変な絵しか出てこない。うーむ，誤差でここまで狂うとは思えないしなあ……。
上のバグ付き画像では，フォトンマップの作成に 10,000 個のフォトンを使用し，フォトン密度の算出には 100 個のフォトンを使用している。本当はもっとフォトン数を上げて分散の少ない状態にして，その出力画像からバグの解析を行いたいんだけれど， kNN 探索が重過ぎてなかなかフォトン数を上げることができないでいる。現段階では kNN 探索に逐次全捜査を使っているので，フォトン数に正比例して処理が重くなるのだ。
そんなの，とっとと kd tree を導入すればいいんだけれど，ただでさえバグだらけの状態なのに，さらにバグを混入させるようなことはしたくない。ううむ……。