
2001-11-01

喉がかすれる,眠い,だるい,おなかの調子が微妙に悪い,そんな感じでまったりとした風邪の症状が続いている。でも,めしを食ったりすると治ったりして,なんかもう,ほんと微妙です。今は先週のアレほど忙しい状況でもないんで,素直に帰宅することに。流行ってるみたいだから気をつけないと。
GTS を使ったストリップ化なんだけど,とりあえず,今まで適当にやってたのはさらっと水に流して,素の状態で作り直してみることにした。すると,いままでやっていたのがそうとう適当だったのか知らんけど,こんどは2,3回のトライ&エラーですんなり通るように。なんだかなあ……。
んで,メイン部分は,こんな感じ。
三角形 tri において,そのひとつ前の三角形との共有辺 com に含まれない第3点 v[2] を次々に出力していく。ここで,ひとつ前のステップで出力した点 v[sw] と v[2] によってなす辺が,次のステップの共有辺と一致しない場合,そこがファンになっているとみなす。ファンを検出した場合は, v[2] を出力するまえに v[sw^1] を出力して,辺の構成を入れ換えておく。これをリストの末尾までくりかえすだけだ。
ファンを作るさいに頂点を再出力している部分は,ようするにストリップを「まくりなおしている」だけなんで,実際に描画する必要はない。頂点スキップをサポートしている API なら,スキップを使うべきだし,ストリップ中の頂点スワップをサポートしている API ならば,それを使って再出力を避けることができる。
こんな感じで,ファンになっているところは頂点1個を余分に出力することでストリップ化することができる。昨日と同じモデルを変換してみると,総計で3655頂点になった。このモデルは実際には2918トライアングルで構成されているんで,1トライアングルあたり1.25頂点ぐらいの割合になる。……まあこんなもんかなあ。
次は, GTS の頂点オペレーションをちょっと調べておこうとおもっている。頂点の法線を算出したり,テクスチャ座標を持たせたりするのに必要そうだからだ。
2001-11-02
なんとかストリップ化までは漕ぎつけられたんだけど,まだ頂点の法線が得られていない。 GTS には平面の法線を求める関数しか用意されていないんで,頂点の法線を得るには,自分でその処理を組む必要があるのだ。なんに応用するにしても,とりあえず頂点の法線ぐらいは必要なので,まずはここんとこを解決しようとおもった。
ところで, GTS のドキュメントには
とある。つまり,頂点構造体には座標情報しか含まれていないんだけど,これに法線情報を加えようとおもったならば, GtsVertex を自分で拡張してくれい,ってことになるらしい。そんなわけでまずは, GTS におけるクラス継承の仕組みを調べる必要がありそうだ。
GTS は glib/GTK+ の流儀に従っているようで,ようするに C でむりやり OOP っぽいことをやっているんだけど,これがまた微妙にめんどくさいっていうかなんていうか……きみたちそんなに C++ が嫌いかー,って感じなんだけど,僕も嫌いなのでむしろ望むところとしておこう。
うーむそれにしても……
んで, GTS 自体のソースを参考にしつつ,みようみまねで GtsVertex2 クラスを作ってみた。
これで,
とすれば, GtsVertex のポインタで GtsVertex2 のインスタンスを生成できる。これと gts_vertex_replace を使ってすべての頂点データを GtsVertex2 のインスタンスに入れ換えてしまう。んで,属する面の法線を総和するような処理をすべての頂点に対して適用すれば,頂点の法線が求まるはず……ってところ。
2001-11-03

今日はなぜか突然,飲みが催されることになった。メンバーは,げーはなさん,ミキタさん, kuni さん,ネットアイドルさん,僕,の5人。よくわかんないけど,なんとなくドジ研的メンバーですな。そんなわけで,上野にゴー。
で,今日は飲みに行くついでに買い物をしてくことにした。まずは御茶ノ水の L-Breath に移動。ここはアウトドアスポーツ用品の専門店。こんなところでなにを買うのかってえと,寝袋。職場で使ってる寝袋が古くなってきたんで新調しようとおもったのだ。
さすがは専門店だけあって品揃えは十分。そのなかから夏用の薄くて小さいやつをひとつ選んで購入した。「夏用だから10度以下では使えませんよ」って言われたけど,室内(むしろ机の下)で使うんだから,そんなのどうでもいいの。
せっかくだからって店内を物色してみると,チタン製のマグカップってのが良さげで気に入った。軽くて丈夫で肌にやさしい,ってのがチタンの特徴らしいんだけど,たしかにステンレス製のとくらべるとだいぶ軽い。まるで紙コップみたいな軽さだ。んじゃあこれも購入。職場に持ってって使うことにしよう。
御茶ノ水−神田周辺ってのは,実は,僕が通っていた学校の周辺だったりする。明大のでっかい建物ができてたり,なにげにスタバができてたり,ほんのちょっと見た目は変わっていたけど,基本的にはあの頃のままの風景。つまり,古ぼけた中背のビルが立ち並ぶ,70年代のオフィスビル街。古本とトランジスタのよく似合う,ちょっとくすんだコンクリートの密林,って感じ。なにげにいい雰囲気の街です。
御茶ノ水で買い物を済ませると,そのまま徒歩で秋葉原まで移動。 Games Ark に行ってアップスキャンコンバータを物色してみる。結局その後,ソフマップで電波新聞社の XRGB-2 を購入した。
XRGB-2 はすでに家に1台あるんだけど,今回買ったのは職場用(自腹)。ほかの製品はだいたい5千円くらいなのに対して,こいつだけは2万以上するっていう高級な品。ガンマ補正とか走査線抜き機能(!)まであるマニアックな品なんで,まあ値段相応ってことなのかもしれない。 PS2 じゃなくても使い道はあるんだし,無駄な投資にはならないだろう,ってことにして,2台目の購入に踏み切った,ってとこ。
そして上野に移動して飲み。微妙なメンバーで,微妙な話に盛り上がる。そうかー,ミキタさんはもう就職活動かー。まあ適当にがんばってください,とおもった。
んで,帰って寝た。
2001-11-04

おとといの続きをぽちぽちと組み上げる。今回は,特に問題もなく完成させることができた。いつもこんな調子だといいんだけど。そんで,その出力を pygl に流し込んでレンダリングしてみる。
スペキュラをきつくして観察してみると,ちょっと法線が荒れているような気がする。もともとローポリってのもあるんだけど,それにしても変な法線が立っているみたいなのだ。頂点の法線を求めるのに,属する面の法線の平均,ってのを使っているんだけど,これが良くないのかもしれない。よく考えてみると,角の大きさに応じて加重平均とかやんないといけないんじゃないかなあ,って気がしてきた。
いままで,法線ってったらたいてい,モデラの出力する数値に頼っていたから,まじめに考えたことが一度もないかもしれない。うーむ,こりゃあちょっと,調べてみないといかんかも。
やること増えちゃったかもなあ。
2001-11-05
月曜日はミーティングの日。どうやら,向こう1ヶ月,また忙しい日々になりそうとのことを告げられる。うーん,まあ,そんなもんだとはおもっていたけどね。せわしない日常がまた始まるのかとおもうと,ちょっと切ないかもしれない。
昨日の続きで,頂点の法線を求める方法について調べてみるんだけど(調べてみるってったって Web で検索するだけなんだけど),凝ったものは特には見つけられなかった。属する平面の法線の平均っていう,ごく単純な方法に関する記述がちらほらと見うけられただけだ。
平面の法線は幾何学的に意味のあるものだけど,頂点の法線ってのは,シェーディングの特性を操作するコントロールポイントみたいなもので,数学的というよりかはむしろ意匠的なものだ。
だから,自動で設定するにしても,曲面の構造を考慮してそれらしい法線を立てる必要があるとおもうんだけど……あまりそういうのは流行らないのかなあ,とおもう。メッシュの密度が高くなれば,個々の頂点の問題はそれなりに緩和されるし,最近のアプリケーションでは算術曲面やサブディビを扱えるようになってきたから,メッシュのオペレーションにこだわる必要性はそれほど無いのかもしれない,とおもった。
資料を求めて Web をさまよっている最中に,こんなのを見つけた。
http://graphics.stanford.edu/courses/cs248-videogame-competi...
スタンフォード大学の CG 過程の最初のコース,ビデオゲームコンペだそうだ。僕の通った学校にゃあ,こんな気のきいた授業は無かったなあ。それはともかく,作品の平均的なレベルの高さにも興味をひかれた。特にむちゃくちゃレベルが高いってわけでもないんだけど,普通の大学の普通の学科で,そこそこなレベルの作品がこんだけ上がるってのが,わりとイカスかもなあ,とおもった。僕は情報系の学科に通ってたけど,C言語を使える人の方が少数派だったような気がするんで。
2001-11-06

昨晩は帰宅するつもりだったんだけど,なんとなく泊まってしまった。またあのせわしない日常がやってくるかとおもうと,今から気がせってしまう。慌てたところで意味はないのは,分かっているはずなんだけど。
普通のアプリではどんな感じで頂点の法線を立てているんだろうと気になって, blender を例に調べてみることにした。 blender が一般的な例として認められるかどうかは,疑問の残るところではあるけれど。
まずは,いつもサンプルに使っている頭のモデル head.gts を bleder で扱える形式に変換しなくてはならない。法線情報の含まれない形式がいいなってことで, DXF で食わせることにする。 DXF を扱うのなんて久しぶり。とりあえずフォーマットについて調べないと。
ファイルフォーマットと言えば "Wotsit's Format" とか "My File Formats" とか。どちらもあまり当てにはできないんだけど,手抜きで調べるにはかなり役立つとおもう。
んで,適当に変換。 DXF のフォーマットは,やっぱりどうにもこうにも古臭い。 AutoCAD ってそんなに力が強かったんだろうか。こんな変な形式でも,いまだに多くのアプリが対応してるんだから,たいしたもんだなあとおもう。
こうして変換したモデルを blender 上に取り込み,適当にスペキュラと光源を与えてレンダリングしてみると,自分のものと似たような荒れが確認できた。まあけっきょく,頂点の法線がどうこうという問題よりも,メッシュ自体の構造や質に問題があるんでしょう,ってことで無理やり結論づけたいとおもった。
2001-11-07
晴れた。洗濯,洗濯。明日も雨は降らないらしいんで,洗濯物を外に干して家を出る。泊まり常習者は,明日の天気も確認しないとろくに洗濯もできないのだ。まあ,そんなノリで職場に到着。冷静に来月までの見積もりを立ててみると,あまりにも手にあまる要求量に冷や汗が出るかもしれない。とほほ。またなんだかんだいってまた足が出ちまうね。
突然だけど,レイモンドの「伽藍とバザール」を読む。何で読み始めたのかは忘れたけど……2ちゃんのスレッドが元だったかな。まあ,そこはわりとどうでもいいんで忘れたままにしておこう。
http://cruel.org/freeware/cathedral.html
僕は,そこはかとなくオープンソース派を気取ってみちゃってたりするんだけど,実はこんな基本的な文献も読んでなかったりして,ちょっぴり恥ずかしいのかもしれない。イデオロギーに首を突っ込みたくないからってのが理由で,あえて読んでなかったりすることもあるんだけど,基本的にはめんどくさがってるだけですな。
で,内容に関しては,なんていうか,かなりポジティブシンキングなおじさんのオープンソース手法に関する1考察ってところだとおもうんだけど,どうせオープンソースにするならここをこうすればっ! 的なアドバイスにはなっているんじゃないかなあ,とおもった。
ところで,僕はなにしろ山形浩生が嫌いだったりするんだけど,こういうのをがんがん翻訳してくれたりしちゃうんで,やっぱり頭が上がらないです。基本的にすごく頭のいいひとだし,考察も鋭いんだけど,無闇な毒の強さと,ときどきどうでもいいことをさらし上げては論争しちゃってる「甘さ」が,どうにも納得できないというか……
とか言っちゃってる自分が,すごく日本的で痛いなあ,とおもった。どっかの頭の堅いひとの言葉みたい。やべー。
なんとなく Virgill の MP3 サイトを訪問。
http://artists.mp3s.com/artists/251/virgill.html
僕のお気に入りは "I'm Free" 。 Mekka Symposium 2001 の mp3 コンポで first prize をとった曲だ。なんつうか,超こてこてな曲ではあるんだけど,この渋さがいんですよ,ってことにしておく。他の曲もなかなかのお気に入りだ。この人は Amiga 時代からの歴史がある人なんで,詳しいひとに語らせれば,いろいろと面白い話が聞けるのかもしれないなあ,とおもった。
2001-11-08
ところで Blender のマニュアルを数週間前に amazon.co.jp で注文したはずなんだけど,いまだに届く気配がない。 web で調べてみると,どうやら在庫を切らしているようで,取り寄せにもう数週間かかるとのこと。うーむ,やる気が萎える前に届いてほしいものだけど。
まあそんなことは気にせずに, Blender の python スクリプトの復習をば。以前ほんのちょっとかじったことがあるんだけど,すっかり忘れてしまったので最初から復習だ。資料は乏しいながらも徐々に増えつつあるんで,以前より状況は有利かもしれない。
まずは基本中の基本,スクリプトの実行のしかたから。
http://jmsoler.free.fr/didacticiel/blender/tutor/english/pyt...
まあこんな感じで,内蔵エディタとコンソール出力でもってある程度の試行錯誤がその場でできるようになっている。ただ,ちょっと気をつけなきゃいけないのが,標準出力の flush をしなきゃなんないってとこ。
こんな感じで最後に flush を実行してやんないと出力が更新されないんで奇妙な動作を拝むことになる。ちなみに, Linux 版だと flush なしでも大丈夫。まあ,そこらへんはね,文化の違いっつうか。
Blender の python モジュールには NMesh っていう低レベルなメッシュ入出力の手段が用意されている。もっぱらメッシュばかりに興味のあるひとのために特化されたモジュールで,頂点の座標や法線,マテリアルの情報とか,そん程度の簡単な情報だけをコンパクトに取り扱うことができる。
http://www.blender.nl/support/complete/scripting/nmesh.php
んで,試しにこいつでポリゴンのダンプをとってみる。
これでシーン中にある Sphere ってオブジェクトのポリゴンリストが標準出力にテキストで出力される。
こんな感じで,簡単な応用ならまったく問題ないことは既に分かっているんだけど,もっとヘビーな応用,たとえばボーンアニメーションとか,頂点アニメーションとか,またはシーンデザインやレベルエディタへの転用とか,そういうところまで対応できるかどうかは,まだ未知数。応用例をあまり聞いたことがないだけに,自信は無かったりするんだけど,せっかくだから突き詰めてみたいなあ,とおもっている。
2001-11-09
最近 prefiltered environment mapping 系の手法に興味を持って調べてみているんだけど,そんな矢先にこんなのをミキタさんが教えてくれた。んで,わりとビビってみたりして。
http://graphics.stanford.edu/papers/envmap/
そもそも prefiltered environment mapping (以下「前フィルター環境マッピング」……なんかしっくりこないけど)ってのは,環境マップに対して BRDF に応じたフィルターをかましておけば,マテリアルを考慮した環境マッピングってのができるだろう,って手法のこと。
いわゆる普通の環境マッピングってのは,反射ベクトルを求めた後にそのベクトルの指し示す先しか参照してないんだけど,実際のマテリアルでは物体表面の BRDF に応じた拡散がなされているはずで,参照先も1点ではなくもっとぼやけた感じになっているはずなのだ。
このぼやけかたは,ランバートモデルやフォンモデルでは一様になるので,前処理でやっとくことが可能だ。自由な BRDF に応じてってのは難しいらしいんだけど。
この前フィルター手法にはちょっとした問題がある。例えばランバートモデルの前フィルターはものすごく特性の高いローパスフィルターとして働くはずなんだけど,このとき積分する範囲がとても広すぎて,一枚の画像をフィルタリングするにも,もの凄い時間がかかってしまうのだ。
1ピクセルにつき半球分の範囲のピクセルを積分しなきゃなんないわけだし,環境マッピング画像ってのはたいていあまり素直な形になってない(歪んだ分布になっている)から,単純化しようってもなかなか難しい感じがする。
そこら辺は,おなじみ Heidrich 先生が高速化手法なんかを試してみている。
http://www.mpi-sb.mpg.de/~jnkautz/projects/unifiedenvmaps/in...
ここに載っている Banks モデルによる異方性な前フィルター環境マッピングとか,なかなか面白い絵になってるなあ,っておもったのが,そもそものきっかけだったりする。
んで,いろいろと PDF を覗きながら,原理は簡単なのにいまいちめんどくさそうだなあ,とか,でも食わず嫌いもなんだしねえ,とか,もやもややっている最中に,件の論文をミキタさんに教えてもらったわけだ。
ランバートモデルの前フィルターがものすごく特性の高いローパスフィルターとしてはたらくはず,ってのは前述の通りなんだけど,んじゃあまじめにテクスチャとして保持する必要もないかもしれないよ,ってのが件の論文の内容。フィルターによってごく低周波な成分しか残っていないなら,数個の基底関数で表現できてしまうだろうということだ。
jpeg 圧縮なんかで高周波成分を切り取ってしまうようなノリなんだけど,この切り取りっぷりがすごくて,たったの9つの基底関数で十分! って言い切っている。こんな大胆な単純化でも問題ないくらいランバートモデルのフィルタってのは特性が極端ならしくて,最大の誤差は10%以下になるんだとか。
さらに,この9つの基底関数は, DC 成分,1周波,2周波,程度しかないんで,2次関数で近似できてしまう範囲にある。そんなもんだから,ここで9つの係数を固めこんだマトリクスを M ,法線ベクトルを N としたときに,
って演算で輝度を求めてしまうことができる,と述べている。
これは, vertex-shader が使える環境ならば,たった3つのマトリクス(色成分ごとの M )と,それほど難しくない頂点オペレーションだけで, per-vertex にランバートな前フィルター環境マッピングが1パスで(しかもテクスチャユニットを消費せずに)実現できてしまうわけで……うーん,なんかすごいことになってきたような。
前にミキタさんやげーはな先生と飲みに行ったときもこの話をして,いやあたった9つの係数で表現できちゃうわけないですよねーぐわっはっは,とか言ってたんだけど,冷静になって PDF に目を通してみると,いやもしかしてこれはすごいかも,とかおもい始めてきた。
まだちゃんと理解しているわけじゃないんだけど,いくつか問題になりそうな点はあるような気がする。まず,これって基本的にスフィアマップをベースにしているみたいなんで, view-dependent なんじゃないかなあ,って点。一発デモとしては view-dependent でもおもしろいんだけど,ちゃんとした所に応用するには,やはり view-independent であってほしいとおもう。
演出として環境マッピングを絡めるってノリだったら view-dependent でもいいとおもうんだけど,僕は,既存の点光源・平行光源による光源表現を Image Based Lighting によって完全に置換したいと考えているから(理由:2つ同時にやるのはめんどいから),やはり view-independent である必要があるのだっ!って力説してみました。
あとバーテクスシェーダに手をださないと実装できなさそうだ,って点。バーテクスシェーダ無しでもなんとかなるかもしれんけど,またやばいくらい複数パスになっちゃいそうな気がする。ならべくバーテクスシェーダには手を出さないようにしているんだけど,そろそろ限界かもしれない。
例のごとく PSION にこの PDF を突っ込んで通勤中に読んでるんだけど, PSION の PDF ビューアが数式をちゃんと表示してくれなくて困る。数式が連続しているところとか,なに言ってるんだか全然わかんないや。また紙メディアに頼ることになるんでしょうか。なんだかなあ。
2001-11-10
今日は休日。来週からはまた休み無しかなあ。というわけで,長期戦に備えて髪を切っておくことにする。忙しくなると髪を乾かすのもじれったいからさあ。んで,その帰りに本屋に寄って, "GNU Autoconf / Automake / Libtool" をなんとなく購入。家に帰って本読んだり Blender の続きをやってたら,急に眠くなってきて,コーヒー飲んでも眠くて,しょうがないから寝た。
Blender の続きをやっている。いろいろと資料を調べなおしていると,どうやら API が新旧2種類存在するらしいってことがわかってきた。
http://www.blender.nl/support/complete/scripting/index.php
これが古いので
こっちが新しいの。
古い方の API もそれなりに使えるっぽいんだけど,いまいち機能が不足しているように見える。例えば,新規にオブジェクトを作成してシーンに追加,みたいな処理はできないようだ(既存のオブジェクトをモディファイすることはできる)。なので新しい方の API を使いたいんだけど,なぜかデフォルトは旧 API になっていて,新 API へアクセスすることができない。どうなってるんだ,これ。
いろいろ調べまわってみると,なんとなく事情が飲み込めてきた。結論から言えば,新 API は "Blender210" モジュールの中に格納されているようだ。
http://www.blender.nl/discussion/read.php?f=4&i=10255&t=1022...
http://www.blender.nl/showitem.php?id=191
Blender 2.10 で python API の仕様が大幅に変更されたんだけど,当然その影響で多くのスクリプトが動かなくなったんで,結局旧 API に戻されたっていう経緯があるらしい。いずれ新旧の API が統合されるようなことが書いてあるけど,実際にはその作業はほとんど進んでいないようだ。
旧 API の方は明らかに仕様が古いというか, Blender 本編の変更に追従していない部分が見うけられる。とは言っても,新 API の方もあからさまに不完全だし,新 API ではあまりプラグインを作らないようにしたほうがいい,みたいなコメントもある。
うーん,まさかこんなに混沌としているとはおもってもいなかった。やろうとしていることはそれなりに実現できるっぽいけど,いまいちすっきりしないし,将来的に大きな変更がかかるとすると,今の段階で本格的に手を出すにも気が引ける。さて,どうしたものか。
2001-11-11
昼過ぎ,卓上電話のモーニングコールを爪先で止めながら,中途半端な格好でまどろんでいると,おもむろにインターホンのベルの音が聞こえてきた。まあどうせセールスだろうし,無視,無視。するとセールスマンは隣の部屋へとターゲットを変えたみたい。相変わらずまどろみながらも密かに耳をそばだててみると,どうやらそのひとは光ファイバーによるブロードバンド接続を売り込みに来たみたいだった。ここで初めて知ったんだけど,隣の部屋の住人は通信関連の仕事をしているようで,やけに話が通じている。同業者と知ってか,セールスマンの売り込みにも次第に熱が入ってくる。しばらくすると,どうやらその住人が大家に相談してみるってことで折り合いが付いたみたいだった。光ファイバーかあ,僕のところなんてまだ ISDN (しかもテレホ)ですよ,とおもいながら相変わらず中途半端な格好でまどろんでいると,またしょうもなく眠くなってきて,そのまま夕方あたりまで寝た。
IE6 をインストールする。とはいっても, IE 自体はわりとどうでもよくて,すべては Google Toolbar を利用するためだ。
http://toolbar.google.com/intl/ja/
IE5 でも大丈夫そうなことが書いてあるんだけど,なんだかいろいろと残念なことになりますよ,って途中で脅されたので,おとなしく IE6 を入れました。これもすべていとしの Google のためだ。しょうがあるまい。
世の中には Google をスタートアップページにするほどのマニアな方々もいらっしゃるぐらいで,僕はそこまでは行ってないものの,やたら Google にはお世話になっているような気がする。
案の定, Google Toolbar を入れたら,なんか知らんけど妙に便利感覚になってしまった。うひ,いつのまにか Google にどっぷりと依存してたんだなあ。そんなわけで,世の中の Google 大好きっ子すべてに Google Toolbar を強くおすすめしていきたいとおもった。
なんとなくメモ。
http://www.gnu.org/manual/gperf/html_mono/gperf.html
http://sharl.haun.org/gperf.html
GNU の gperf というツールで,文字列群を入力するとそれに対する完全ハッシュ関数を生成してくれるそうだ。基本的にソースジェネレータなんで,固定的な文字列群にしか適用できないことになるけど,それなりに役に立つ機会はあるんじゃないかなあ,とおもう。
とか言いつつ,いまだに使う機会がやってこない。半年くらい前に仕入れたネタなんだけどなあ。とりあえず,忘れないうちにメモしておこうとおもっただけ……
2001-11-12
例の Ramamoorthi の「照射環境マップ」もそうなんだけど,さすがにバーテクスシェーダ無しでやりくりするのもつらくなってきた感がある。まあいろんな理由があってバーテクスシェーダ/レジスタコンバイナは避けてきたんだけど(おもに怠惰),そろそろ手を出してみようかなあ,とおもいはじめた。
ということで GL_NV_vertex_program 拡張に手を出してみることにしたんだけど,同時にこれを, cygwin 環境上で NVIDIA 寄りな OpenGL アプリケーションは組めるのか? って検証にもしてみたいとおもっている。もちろん,こういうのは VC++ と DirectX の組み合わせで行くのが素直な方法なんだろうけど, Windows と Linux の間をふらふらと行ったり来たりしている僕にとっては,ポータビリティに優れる手段を常に尊重したいとおもっているのだ。
まず最初にフレームワークライブラリの選定から。今回は SDL (SDLGL) を試してみようともおもったんだけど,やはりとことん楽したいんで GLUT を選択。 GLUT はいまいちいい加減なところがあって気に入らないこともあるんだけど,いい加減に作るにはやっぱ便利です。うへ。まあ SDL はいつか使わせてもらおう。
次に GL_NV_vertex_program エクステンションのインポートを試みる。 sgi のオープンソースプロジェクトサイトには glext.h っていう非 ARB 系エクステンション定義を集約したヘッダファイルが置いてあるんだけど,これはサポートが中途半端で(あまり熱心に更新されてないみたい)ちょっと今回は使い物になりそうにない。
http://oss.sgi.com/projects/ogl-sample/ABI/
まあたぶん sgi のヘッダはだめだろうなあ,って予想していたんで,すっぱり諦めて NVIDIA の OpenGL SDK を当たってみることにする。こっちの glext.h では,さすがに NVIDIA の拡張定義はすべて網羅されているみたいだ。
この glext.h を単純にインクルードすると cygwin の gl.h となんだかかちあってしまうんで,手動で必要な部分を切り取ってインポートすることにする。あんまこういう方法は保守性の面からいってよろしくないんだろうけど,ここらへんの拡張仕様はどうせ数年後には廃れるんだろうし,気にせずガリガリ刈り取っていく。ノープロブレム。
次にサンプルを調達したいところなんだけど, NVIDIA のサンプルはどれも NVIDIA のユーティリティライブラリでガチガチに固められていて,素から作ろうとしている僕にはあんま嬉しくないものばかりだ。ユーティリティを使うのは結構なことなんだけれども,なにしろぜんぶ VC++ 用に作られているもんだから, gcc でコンパイルが通るようにするには一苦労することになるかもしれない。それはできれば避けたいところ。
まあそんなわけで,ここもすっぱり切り捨て。ただ唯一 nvparse だけが気になる存在。なんのライブラリだかさっぱりわかんないんだけど,どのサンプルでも使われているところを見ると,よほど一般的なものらしい。レジスタコンバイナやピクセルシェーダを便利に扱うためのものらしいんだけど……無視して大丈夫かなあ。
2001-11-13
僕は普段,職場と家のデータのやりとりに ThumbDrive を使っている。そんな大したデータは持ち歩かないんで, 64MB のやつでたいてい事足りている。家でエンコードした MP3 を職場に持ってくときなんかは,ちょっと不足気味になるけども,足りなくなることってったらそれくらいかなあ,とおもう。
自作ツールのソースファイルなんかもこれに入れて持ち歩いているんだけど,ディレクトリ丸ごとコピーなんかだとバージョンの管理が大変になってくる。たまにコピーを取り忘れてしまうだけで,とたんにバージョンの整合性が取れなくなってしまうのだ。
家の回線が常時接続なんかだったら CVS サーバを立ち上げておくんだけど,いまんとこそれは無理な話。 SourceForge を使ってみるってのも魅力的な解決案だけど,なにしろ公開するのもはばかられるようなゴミっぽいプログラムばかりだし,仕事内容にちょっとでも関連性のあるものだと公開するわけにはいかないので,これもちょっと無理な話。
そんなわけで, ThumbDrive の中に CVS リポジトリを作って管理してみることにした。ところで,家のマシンは Win2k だからぜんぜん問題無いんだけど,職場は Linux がメインなので ThumbDrive に直接アクセスすることができない。しょうがないから, Win98 マシンに ThumbDrive を挿してドライブをフルアクセス開放で共有する。んで Linux マシンから samba クライアントでリモートマウント。 smb-client パッケージを入れたら,意外とすんなり mount でリモートマウントできてしまった。
さらにちょこっと試行錯誤したら autofs でオートマウントできるようになった。これで普段はほとんど意識せずに ThumbDrive を使うことができる。意外とうまくいくもんだなあ,とおもった。
ゲーム製作技術@2ch掲示板からコピペ。 Java VM の仕様書。
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpe...
スクリプトエンジンとして Java VM を使うってのは,僕の理想にかなり近いんだけど, VM を実装する手間が現状ではどうしてもネックになってしまう。フリーの Java VM (たとえば waba とか)を参考にする限りでは,仕様を大胆に割り切りつつ,それなりの労力を注ぎ込めば自前でも実装できるような雰囲気がするんだけど,その他にもやりたいことはたくさんあるんで,これだけに労力注いじゃうのはちょっとリスキーだなあ,と考えている。
それだったらすでに完成している small とかを使わせていただこう,と。ちなみに waba は GPL なので,ライセンスの問題により選択肢から外されている。惜しいんだけどね。
2001-11-14
一昨日から引き続きバーテクスプログラムのお勉強。とりあえずお手本を参考にバーテクスプログラムをバインドするところまでやってみるんだけど,バーテクスプログラムを glEnable した途端に表示が消えてしまう。まあ,うまくいってないってことなんだろうけど,エラーハンドリングの手段がほとんど何も用意されていないんで,どこがどう悪いんだかさっぱり検討もつかない。正しくロードできたかどうかも確認できないんじゃなあ。
前回,あっさり導入を諦めた nvparse だけど,普通はこれがエラーチェックをしてくれるような仕組みになっているらしい。ほかにも, DirectX のバーテクスシェーダの構文を変換する機能なんかもあるらしくて,ということはサンプルのバーテクスプログラムも鵜呑みにすることはできないってことなのかなあ,とおもった。
また,ゲーム製作技術@2ch掲示板から。
http://game.2ch.net/test/read.cgi/gamedev/1005582865/
「ドッター」「ドット職人」って言葉はよく聞くけど,「ローポラー」「ローポリ職人」が存在するとは存じませんでした。
まさに!
例えば,X68kとか,ファミコンとか,FM音源とか,限られた性能のなかで技を極め続けた結果,本来持ち得る機能までも凌駕してしまったハードウェアってのが過去にいくつか存在するんだけど,プレステもわりとそれに近い域にまで達していたような気がする。
特にこの3つのゲームの極めっぷりはなかなか燃えるものがあったなあ,とおもう。個人的にはデュープリズムの快活なキャラクタアニメーションとか好きでした。当時の僕にはショッキングだったなあ。
2001-11-15

最近 kano さんのところなんかで話題になっている hemisphere lighting なんだけど,いまいち基本的な情報に不足していて,なんのことだかさっぱりわからない。 IF さんの解説でなんとなく雰囲気はつかめてきたんだけど, kano さんが MS の提示している内容に疑問を示していたりして,状況はさらに混迷をきわめているわけで。
http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/...
http://cgi3.tky.3web.ne.jp/~tkano/columns/20011024.shtml
http://www5.tok2.com/home/IF/hemisphere/hemisphere.html
仕組み自体はわりと簡単そうなんで,ちょっと調べてみることにした。
hemisphere lighting は,上の図のように,上半球 (sky hemisphere) に均一の radiance を与えられ,下半球 (ground hemisphere) には別の均一の radiance を与えられた環境下における,ランバートモデルの反射輝度を求めたもの,ってことのようだ。
ちなみに radiance ってのは,単位面積に対して単位立体角から入射する光量のことを言うらしい。これを総和して単位面積あたりに入射する光の総量を求めたものを irradiance と言うようだ。
Jassen 先生の photon map 本によれば,単位面積に与えられる irradiance は, solid angle w における raddiance と, w ベクトルと法線ベクトルの内積値をかけたものを,天球範囲で積分したものになるそうだ。
で,普通は spherical coordinate を使って面積分するんだけど, hemisphere lighting はかなり単純な radiance の分布になっているんで, spherical coordinate を使う必要もないかもしれない。面積分するのがめんどくさいのだ。
そんなわけで,ちょっと手抜きをして,上の図の赤い領域みたいな「ミカンの房」を単位として使うことにしてみる。この場合,角度表現は1次元でいいから,これを theta とおく。ただし theta = 0 が地面を表すことにする。このとき,
となる。なので E は
ところで,
となるから, E を phi 以下と phi 以上に分けて積分することにすると,
このまま進めて,
ここで
とおくと,
で irradiance が求まった。ランバートモデルの場合 BRDF が全域で均一だから,とりあえず上天球の立体角 2pi で割ってから係数 k_d をかけてやって,
ってことにする。
結局どういうことかというと,上下半球内でそれぞれ均一な入射光が与えられる環境内では,その拡散反射はくだんの式で求まるってこと。法線とベクトルの内積をとるんで,なんとなく指向性のあるライティングを連想してしまうんだけど,本当は単なる環境光の一種といったところだ。新しいライティング手法というよりかは,従来の単純な環境光表現を置換するもの,ってのが実際に近いとおもう。
だから, hemisphere lighting を使う場合は,指向性のある光源をイメージしてはいけない。例えば, sky color に部屋の照明光とか,太陽光とか,そういうのを設定するのはあまりよくないとおもう。これらの光源は少なからず指向性を持っているからだ。
まあやはり,屋外シーンで空の色と地面の色を設定しておくのが本来の使いかたなんでしょうな。そいういうのをモデル化したものなんだし。
ほとんどの場合,半球環境は傾けずに使うことになるだろうから, cos(phi) を求める手間は省けるかもしれない。単に法線の y 成分でいいはずだ。
2001-11-16
今日は久しぶりのアルコール摂取デー。実はこの前の仕事でお世話になったひとたちが続けざまに会社を辞めることになったので,挨拶がてら久しぶりに飲みましょう,ということになったのだった。
僕がこの会社に入ってから,それまでのゆるやかな流れからは信じられないほどのダイナミックな変化が立て続けに起こってきた。まあそんなわけで,最初の仕事でお世話になった方々の大半は,なんらかの形でこの職場を去っていくことになった。
辞める理由はひとそれぞれ,さまざまにある。けども,そのたびにおもうのは,この会社はおもったよりも複雑な理論によって動いてるということ。「新しい会社だから」なんて言い訳は通じないくらいの年月が既に経っている。いまだになんのポリシーも持たずに動いているその様は,流動的というよりかはむしろ混沌そのものだろう。
たとえ可能性を秘めた人材が集まっていても,統制が取れてなければ,ただの烏合の衆に過ぎない。現状を激しく否定する気はないけれども,もうちょっと本来あるべき姿を取り戻してもいいんじゃないかな,とおもった。
以前,ここの日記で ghost master ってゲームを話題にしたことがあったんだけど( photon mapping でライトマップを生成してるってネタで flipcode の IOTD に掲載されていた),そこの関係者の方からメールをいただいた。どうやらサイトを移転されたようで,元ページの方がリンク切れしているとのこと。新しい URL は
http://members.tripod.co.uk/GHOSTMASTER_STUFF/
だそうです。とは言ってもこちらもアクセスできないんだけど……
しかし,どうしてまたこんなマイナーなページにたどり着いたもんだろうとおもう。 google で引っかかったんかなあ,とおもって,ちょっと試してみたんだけれども,箸にも棒にも引っかからない。
そのむかし GDAlgorithm-ML で suzuna さんが晒し上げられる事件などもあったりして,なかなか海外は油断できない。噂によると kano マニアや Masa マニアも海外各所に存在するらしい(という宇宙電波を受信した)。まったく恐ろしいことだ。
http://www.geocrawler.com/mail/msg.php3?msg_id=6067726&list=...
2001-11-17
うーん。「あの式で天球の面積求めると pi**2 になるけどいいのか」とか「微積分の基礎概念がわかってなさすぎなので高校からやりなおしてください」などという電波が聞こえてくるよう(部屋の隅で体育座り状態で縮こまりながら)。
基本的に「分かったつもりになるために」やってることなんで,細かいことは気にしない方針なんだけど,あれはあまりにも駄目過ぎるので,最後のあがきとして修正してみることにした。恥の上塗りとは知っていても。
……で, spherical coordinate を使って面積分する。 spherical coodrnate ってのは
みたいな座標系のことで,このとき dw は
で表されるそうだ。ところでこのとき,半球環境の傾きの軸を phi の軸と同一にとり,法線方向を (theta,phi) = (pi/2,pi/2) となるようにとってやると,面積分がやりやすそうだ。半球環境の傾きを psi とした場合に phi=[0,psi] (ground hemisphere) と phi=[psi,pi] (sky hemisphere) の範囲に分けて積分すればいいからだ。このとき,
となり,
ここで
だから……(中略)……けっきょく
となる。
Jensen 本とか読んでいると,僕らがいままで単なる内積 (L,N) で済ませていたことが,最先端の世界ではこんなにも複雑に進化しているものなのか,と驚かされる。僕らのいうCGが,白いキャンバスに絵の具で描いている世界だとしたら,先生たちのCGは物理学と熱力学の世界。 radiance の単位が [W/m2sr] なんてことを僕らが気にするものだろうか。
今まで僕は,ライティングモデルって微小面積の中で完結しているはなしなんで,ほかの諸々の問題と分離しやすくて面白いなあ,とかおもっていたんだけど, Jensen 先生の BSSRDF なんかになってくると話が違ってくるらしい。
湿った肌のようなマテリアルでは,入射した光がすべてその点において反射・吸収されるとは限らない。薄い表面層のなかで複雑な分散・屈折・反射を繰り返したあげく,ほんのちょっと横にずれた点とかから出て来る光もある。それを厳密にモデル化しないことには,ああいったマテリアルをリアルに表現することはできないだろう,ってことなんだとか。
ここまでくるとさすがに追いつける気がまったくしない。僕が現役でやってるうちは,どうがんばっても,せいぜい BRDF 止まりだろうなあ,とおもった。
2001-11-18
昨晩はさんざ夜更かしして,寝に入ったのはとうとう朝の6時ぐらいだった。
すると,僕がちょうどノンレム睡眠に入ったあたりで,部屋の電話機が不快な音を立て始めた。いつも目覚ましに使っているモーニングコールが作動してしまったのかとおもって,僕はとっさに飛び起き,電話機のボタンを連打する。
だけど,ここでいつもならすぐに黙りこくるはずの電話機が,今日という今日は,なぜか全然収まる気配も見せない。まるで悪夢のように鳴り続ける電話。
そこで僕は,どんな強靭な電話でも一撃で黙らせることのできるとっておきの必殺技「受話器を上げて降ろす」を実行すべく受話器を取り上げる。こいつがどんな電話にも効く事はJISも保証済みだ。ところが,受話器を取り上げたところで,何故か人の声のようなものが聞こえてきて,僕は一瞬ひるむ。
あれ,モーニングコールのPCMと,電話のベルの音と,人のしゃべる声と……記憶と実体が結びつかないような不思議な感覚のまま,僕はそれ以上思考するのをあきらめて,受話器を降ろしたのちにまた睡眠へと戻っていった。
つまり,僕に早朝電話をかけるのは避けたほうがいい(少なくとも,何か伝えたいことがあるならば)とおもった。
バーテクスシェーダ (NV_vertex_program) の習得と平行して, blender の吐く VideoScape 形式のオブジェクトファイルを C の配列形式にコンバートするプログラムを作成してみている。こちらは, glib と GTS を使う実験も兼ねている。まあ,そんな気張ったもんでもなくて,主な用途はサンプルプログラムに使う素材を作ること。
でも,こんどはそれなりに丁寧に使い方を調べながら組んでみている。前回は動くものを作るのが精一杯だったから,それはもうむちゃくちゃなプログラムだったのだ。
そういうわけで,エラー終了は g_error とか,メモリ取得は g_malloc とか,そんなところからこつこつと調べながら組んでいく。まあもっとも,そんなところから glib に染める必要はないんだけれども。
GTS は,その名前が表しているように,3角形を基本プリミティブとするライブラリだ。ところが VideoScape の obj 形式は多角ポリゴンもサポートしているんで,入力時に3角分割する必要がありそうな気がしてきた。これはたしか, GTS のデローニ分割モジュールを使えばできるのかもしれないけど……今回は残念ながらパス。先にやりたいことがたくさん残っている。
ところで VideoScape ってなんなんだろうとおもって軽く調べてみたんだけど,どうやら Amiga で有名だったCGソフトの名前らしい。なんでも,あの LightWave3D の原型となったソフトなんだとか。
http://ewhac.best.vwh.net/amiga/anims/videoscape2/
http://www.google.co.jp/search?sourceid=navclient&q=videosca...
ふむ,なるほど。ところで, Blender の GUI と LightWave のそれは,よく見てみるとなかなか似ていないでもないような気がする。ボタンが無節操にポロポロと置いてあるあたりとか……勘ぐりかもしれないけども,そういう経歴を持つマニアが Blender を作っているのかもしれないなあ,とおもった。
2001-11-19

再びバーテクスシェーダ (NV_vertex_program) のお勉強。意外と OpenGL でバーテクスシェーダってノリの資料(しかも cygwin )は少なく,そろそろ埒があかなくなってきた気がするので, extension registory に手を出してみることにした。
http://oss.sgi.com/projects/ogl-sample/registry/NV/vertex_pr...
雑学はだいぶ身に付いてきているんで,それほど苦労もせず読むことができた。どうやら,エラーハンドリングの手段もそれなりに用意されている模様。貧弱なものではあるものの,僕ぐらいの段階ならこれで十分なはずだ。行ってみよう。
で,エラーチェックの処理を入れてみたんだけど,どうやらバーテクスプログラムは正常にロード&バインドされているっぽい。しばらく何が悪いんだろうと思案する。はて。
ふと,テスト描画として使うつもりだった glutSolidTeapot を削り, glVertex で生三角形を流し込んでみる。うまくいった……
試しにいろいろ突っ込んでみると, glVertex や glutSolidSphere は大丈夫で, glutSolidTeapot だけがおかしくなることがわかった。つまり,これはたぶん glu の evaluator 経由だとうまくいかないってことなんだろうとおもう。あのティーポットはベジェ曲面で定義されているはずで,当然 evaluator を使っているだろうからだ。うーん,確かにここら辺は怪しいところではあるんだけど。
まあ,そんなわけで,罠は1つ解除。もうこれ以上罠は無いことを望むけど。
バーテクスシェーダ自体の使いかたはむちゃくちゃ簡単。特に swizzle やブロードキャストを自由に扱えるのは,はっきりいって便利すぎ。 PS2 ではベクトルの要素を入れ換えるだけでも,かなり不自由な思いをしていたもんだけどなあ。ほんと,涙が出るほどに便利だとおもった。
行列計算が積和ベースではなく内積ベースになっているってのも,なにげに重要かもしれない。 PS2 にレイテンシ4の内積命令があれば,それなりに便利になっていたとおもうんだけど。
そんな調子で,バーテクスプログラミング自体はサクサク終了。ためしに組んでみているのは Ramamoorthi & Hanrahan の "Irradiance Envmap" ネタなんだけど,これはようするに
を頂点毎にやるだけなんで,バーテクスシェーダがあればボロいもんだ。しかもありがたいことに,この論文には Devebec の実写環境画像をパラメータ化したものが掲載されている。これさえあれば,あとは何も考えずに式に突っ込んでやるだけ。ガリガリっと勢いにのって組んだら,すんなり出来上がってしまった。
ってのが上の画像。たった3個のマトリクスでこれだけのライティングができる(しかもイメージベースで)ってのは,わりとすごいのかもしれない。3個マトリクスがあれば,12ベクトルでもって……平行光源6個ぐらいは置けるから,それを考えるとどっこいってところかもしれないけど,実はわりと深いことを,想像も付かないくらい単純な手段でやってしまっているってところの優越感にひたることで,この手法の利点としたいとおもった。
というよりも,今日はむしろバーテクスシェーダに感動。楽しいオモチャを手に入れた気分。ありがとう nVidia ……
2001-11-20
なんだか知らないけど,昨晩ぜんぜん寝付けなくて,ちょっと寝不足気味。最近微妙に睡眠時間が短くなってきているような気がする。気をつけないと。
コンバータ作成の続きをちょろっと進める。読み取り部分が完成したところで,前回さんざ作り散らかしたストリップ化のルーチンと結合。動作は問題ないみたい。まあこんなもんかな。
今回は勉強がてら作った小品なんで実用性はものすごく低いけど,次の段階では, Blender の python スクリプトと組み合わせて,もう少し高等なデータ形式を扱えるようにしたいとおもっている。しかし,どういった形式をサポートするのがいいのか,ってのは少し悩みどころだったりする。
そもそも, 3D CG の分野にこれといって標準的な形式が存在しないのが不便だ。あえて挙げるなら VRML がそれに当たるんだろうけど,あまり流行っているようにはおもえない。どうしても,って場合の中間形式に使うことはあるけど,どちらかといえば軽視されている存在だとおもう。
3D CG におけるデータ構造ってのは複雑かつ多様で,それをなんでもかんでも忠実に表現できるような形式ってのは,やはり難しい要求ではあるとおもう。
アプリ屋さんの立場としては,ツール上での挙動をできる限り忠実に再現したいから,持ち得る限りのデータを正確に読み取りたいって要求がある。ところが,標準形式に変換する段階で,データの精度や具体性っていうのは,ある程度確実に失われてしまう。
また,標準形式は独自形式にくらべてデータの冗長性が高かったり,アクセスにかかるコストが高かったりすることが多い。 3D CG の世界では,常にリソースの限界まで要求されるのが宿命だから,ちょっとしたコストアップも積み重なるととても無視できない量になってしまう。
まあ,そんな事情もあって,ほぼ単一のツールと独自形式の組み合わせってのが標準的なパターンになっているとおもうんだけど,複数のツールを組み合わせて作業を行うには,やはり標準的な形式がないと不便だ。さもなくば,コンバータ屋さんがずいぶん儲かるわけで……
2001-11-21
で,データフォーマットは何がいいかなあ,ってことだったんだけど,とりあえず目を付けてみたのがこれ。
この 'XGL' は, OpenGL のディスプレイリストを XML で記述したような形式。できることといえばプリミティブ列の定義やマテリアルの指定ぐらいで,アニメーションとかについてはまったく機能が用意されていない。だからこれ自体は応用範囲がかなり狭いんだけど,プレビュー用のフォーマットとかには無難な線だとおもうし,なにより XML の勉強材料として適しているんじゃないかなとおもう。
そんなわけで XML にも同時に興味を持っているわけなんだけど,これは,データを保持する一般的な手段として利用できるんじゃないかって期待があるから。ぶっちゃけたはなし,データをすべからく XML で持つようにしちゃえば,パーサやらインタフェースやらなんやらを1つ用意するだけで済みそうだ,ってこと。
それに, XML みたいに広く応用されている形式ならば,ツールやライブラリや専用機材が充実しているから,なにかと利便が効くだろうって思惑がある。特にゲーム屋さんなんかにはありがちなんだけど,ファイルサーバ上に共有されたファイルを手でコピーしたり,編集ツールはテキストエディタのみだったり,ファイルロックは人力(今から編集するぞー,と叫ぶと Lock )だったりとか,そういう悲しげな状況なんで,ここらへんを改革する原動力にしたい,というのがその意図。
なんとなくやればできるような気もするんだけど,唯一難しいとおもうのが,開発バージョンとリリースバージョンの住み分け。開発バージョンでは高級なインタフェースとネットワークの組み合わせで動かすんだけど,リリースバージョンでは狭いメモリで高速に動作するようにしなきゃいけない。しかもデータを保持するのは円盤メディアだ。
この2バージョンを同時に開発するのは,想像するよりも苦痛な作業だ。たいてい途中で志が低くなってきて,デバッグモード付きのまま出荷しちゃうようなソフトもあるわけですな。その気持ちはわからんでもないなあ,ていうか他人事じゃないし,とかおもった。
2001-11-22
来月,都内某所(未定)でドジ研のオフが催されるらしいんだけど,ちょうど仕事が立て込む予定なんで,あえなく断念。せっかく熱い漢たちのポエムがたっぷり聞けるとおもったのに……残念だ。
そんな調子で,年末年始はけっこうせわしない感じになりそう。
なんとかコンバータと描画への連携は動き始めた。 blender.nl から落としてきたイルカのモデルとか表示させて遊んでみる。調子に乗ってスムースをかけたハイポリモデルとかをコンバートしてみようとおもったら, stackdump を吐いて止まってしまった。うへえ。バグってるや。
デバッガで追いながらちろちろっと調べてみたんだけど, GtsVerte の継承の手順を間違えていたのが原因だった模様。修正したらハイポリモデルも通るようになった。しかし,この「むりやり OOP 」はいまいち使いにくい。 C++ を知っていなければこういうデザインはできないとおもうんだけど,当の本人たちの気持ちはいかなるものだろう,とおもう。満足なのかなあ。
フリーの素材を求めて 3D Cafe や Avalon をうろついてみるんだけど,やはりどうにも質に問題があるような気がする。フリーだから文句は言えないけどね。しかし,実験用の素材といえども,やはり形状的におもしろいものを使いたいところ。
http://www.cc.gatech.edu/projects/large_models/
スタンフォード大の超ハイポリモデルアーカイブ。いわゆる Stanford Bunny とかが置いてあるんだけど,ちょっとハイポリ過ぎて,軽い実験なんかには向いていない。とことんハイポリなモデルが欲しいひと向けですな。
スタンフォード大のリンクから見つけたページ。なかなか無難なモデルが揃っている気がする。ちょっとパクりっぽいのが多い気がするけど,いいのかな。 Quake のレベルデータをコンバートしたやつとか,明らかにヤバいんではないかとおもうんだけど。
2001-11-23
今日は世間的には休み。どうやら勤労感謝の日ってことらしい。ところで,普段ちっとも勤労していない僕のところには,勤労感謝の日はやってこないみたいだ。悪さをする子の元にはサンタはやってこないのだろう,とかなんとかチープな言い訳を捻りながら,ちっとも勤しまずに労働した。
なんとなく everything2.com で調べものをしていて,なにげにこんなのを見つけた。
http://www.everything2.com/index.pl?node_id=448500
http://www.everything2.com/index.pl?node_id=448517
"shotgun debugging" ってのは,ようするに,やたらめったら見当でコメントアウトしまくって,なんとなく直っちゃったらいいね,って感じのデバッグ手法のこと。デバッグ手法って言っていいのかどうか疑問だけど。
で,2つめの "trampoline debugging" ってのは,例えば
こんな感じの一節があってバグが確認されたとする。んで,いっしょうけんめいデバッガで追いかけて,よく原因は分からないんだけど,なんとなく flag が 2 のときに飛ぶってことを掴んだとする。そしたら,
ってやって実行。んでうまく動いたら修正完了ってことにしちゃう,って手法(「ことにしちゃう」の部分が手法です)。これ,むしろバグ増やしてるんじゃないのって感じなんだけど,実はわりとポピュラーな方法なんだとか( everything2.com には「MS内で……」って書いてあるけど,そこに限った話でもないでしょう)。
末端の部分ならともかく,基幹の部分でこういうことをやられると迷惑極まりない。でも,こういうノリのコードをいくつか見たことがあるような気が。それも基幹の部分で。いいんだろうか。
なんとなく宇宙ヤングのページを訪問したら,新曲が上がっていた。さっそくチェック。
http://www.fuki.sakura.ne.jp/~hexacafe/uchu-young.net/girl.h...
僕はもうすっかり新・笹公人のボーカル(あるひと曰く「郷ひろみと田原俊彦を物質転送機の失敗ではからずも合体してしまったかのような強力ヴォイス」)に慣れてしまったんで,世間的に許されるラインかどうかの判定はできないんだけど,個人的にはOKなノリ。
新生・宇宙ヤングは昔にくらべてネタ寄り傾向が微妙に高かったんで,最近ちょっと心配になっていたんだけど,こういう微妙な範囲もカバーできることが判明して安心した。笹氏言うところの「SFジュビナイル特有の浮遊感」ってのも共感できるところ。ただ,僕にとってのSFジュビナイルっていったら「ドラえもん・のび太の宇宙開拓史」のことなんだけど。もしかしたら,今でも泣けるかもしれない。
ついでに,作曲担当であるところの HIDE-AKI 氏のアルバム情報もアップされていた。
http://www.fuki.sakura.ne.jp/~hexacafe/blossom/index.htm
こっちは宇宙ヤングとはうって変わってオサレ系。なにげに作詞は笹氏らしい。このひとたちの芸風の広さはすごいなあ,とおもった。プロとしての技術の広さってことなんだろうけど。
2001-11-24
特に理由はないんだけど,コーディング規約について調べてみた。まずは,たぶん最も有名であろう(少なくとも以下の3つに比べれば) GNU Coding Standards から。
http://www.gnu.org/prep/standards.html
コード自体の書き方に始まり,ドキュメンテーションの手順や, Makefile の書き方などについても触れられている。ある特定のプロジェクトについてではなく,一般論としてのコーディング規約について,これまで詳細に規定しているのはなかなかないんじゃないでしょうかもっとも, GNU 自体が1つのプロジェクトなんだっていえば,そうなんだろうけど。
これに対して, Linux カーネルのコーディング規約はずいぶん奔放のような気がする。
http://www.google.co.jp/search?q=cache:9iGP8gsvf8E:www.linux...
GNU や MS を小馬鹿にしてるのがおもしろい。なんか嫌な思い出でもあるんでしょうか。「C言語はスパルタン」と割り切った上での意見なんだな,とおもう。「もっと殺伐としてるべきなんだよ」みたいな。
これを含め,意外と8タブを前提としているケースっては多いみたいで,4や2でインデントする場合はスペースを使うのが普通みたいだ。僕はてっきりCファイルは4タブが普通なもんだとおもってたけど,これも MS の影響なのかなあ,とおもった。
次は Mozilla のコーディング規約。スタイルについての明確な規約は無いみたいなんだけど,モジュラリティと C++ のポータビリティについて触れている部分に興味を引かれた。
http://www.mozilla.org/docs/modunote.htm
http://www.mozilla.org/hacking/portable-cpp.html
Mozilla では Windows の COM を真似てモジュール化を行っているらしい。 COM そのものを使ってしまうと Windows 依存になってしまうんで,アーキテクチャ的には CORBA のものを借りてきているらしいんだけど,あまり詳しいことについては分からなかった(知識が無いので)。ただ, COM を真似ているってところが意外だっただけ。
C++ の規約については,かなり厳格に定められているみたいだ。テンプレートは不可,例外も不可, RTTI も不可, 'using' も不可……などなど。 C++ は標準化が進んでるといえども,まだコンパイラによって仕様がまちまちな状態だから,まともなマルチプラットフォームを目指そうとしたら,これくらいストイックにならなきゃいけないんでしょう。
Mozilla は,単一のプロジェクトとしては,オープンソースプロジェクトの中でもっとも巨大なものだろうから,得られるものはいろいろあるとおもう。一度挫折を味わったことのあるプロジェクトだけに,負の面でもいろいろ参考になることがあるかもしれない。
最後は Apache HTTPD プロジェクト。たぶん,オープンソースプロジェクトの中ではもっとも成功している例だとおもう。
こちらはもろC言語な感じのコーディング規約。ところで, Apache は開発の進め方についても詳しいガイドラインが設けられているのがおもしろい。 Apache 自体については詳しくないんで勝手なことは言えないんだけど,まさにバザール方式を具現化したものなのかなあ,とおもった。
2001-11-25
Mozilla 関連の資料を当たっているときに,ふと, Mozilla 初期の頃のロゴデザインが,すごく共産系の匂いを漂わせていることに気がついた。
http://www.mozilla.org/party/1998/mozilla.gif
赤い色調に太い輪郭,角張ったフォント,工場のシルエットと背景に赤い星。共産圏でよく目にするプロパガンダ・ポスターの書式。いままで気づかなかったのがおかしいぐらいかもしれない。
Mozilla はようするに Netscape のオープンソース版なんだけど,開発の主導が独占的企業からオープンコミュニティに受け渡されたことを象徴化したデザインだったんだろうか,とかおもった。
ちょっと気になったのでサーチしてみた。
http://bugzilla.mozilla.org/show_bug.cgi?id=32218
http://bugzilla.mozilla.org/show_bug.cgi?id=43647
どうやら,ここらへんは幾度となく物議をかもし出している要素のようだ。個人的にはかなり不毛な議論だとおもうんだけど,当人たちの心境はいかなるものだろう。自分が善意もしくは趣味で労力を提供しているプロジェクトが,勝手にイデオロギーに染められてしまったら,まあ確かに嫌かもしれない。
ただ,この場合そこまで深刻な話じゃないとはおもうけど。ロゴを赤く染めたのは,半ばジョークなわけで(本気だったら,僕もちょっと嫌かもしれない)。
もしかしたら,アメリカ人はコミュニズムに対して嫌悪感をいまだに持っているのかもしれないなあ,とかおもったんだけど,そういうもんでもないみたいだ。特にオープンソース系の企業なんかでは,企業イメージ戦略として,こういった象徴的なデザインを用いる場合もあるらしい。
http://boldra.com/features/socialist_art/
たしかに ActiveState 社のウェブなんかをみてみると,もうこれでもかってくらい赤に染まってる。すげー。
RedHat が云々ってのはちょっと勘ぐりっぽいけど。
2001-11-26
なにげに Kano さん(先生って呼ぶと茶化してるみたいなのでやめた)の BBS を覗いてみると,おもしろい話題が繰り広げられていた。フレネル効果はどういうふうに適用するのが正しいのか,みたいな考察だ。
Heidrich の論文には,非金属のように屈折率が比較的低いマテリアルではフレネル効果が必須で,鏡面反射の成分にこれを適用するといい,みたいなことが書いてある。さらに,拡散反射の成分も絡ませると,透明な皮膜がかけられたみたいな効果が得られるとか,わりとアバウトなことが書いてある。
このアバウトさについて Kano さんが突っ込みを入れている感じなんだけど,それに対する Masa さんのまとめ方がうまくて,ちょっと感動した。よって,名言としてここに転載するものである。ぬふふふ……
で,フレネル効果ってそもそもなんなの,ってことで,困ったときの Jensen 本を引っ張り出してきて調べてみた。
均一でまっ平らな面における光の反射量ってのは,マクスウェルの式から導出することができるらしい。もうこの時点でやばい気がするんだけど,めげずに読み進めると,空気の屈折率を E1 ,マテリアルの屈折率を E2 とした場合に,
Rp は入射平面に平行な電界に対する係数で,Ro は入射平面に垂直な電界に対する係数になる……うむむむ(←まったく分かってない)。
で,金属なんかの場合は E2 が複素数になるんだろうで,虚数部は入射面で吸収される光の成分のことを表しているんだとか。従って金属は不透明になる,と。もはや理解は諦めてるけど。
つまり,ちゃんと原理から調べるとさっぱりわからないということだ。
ちなみに,金属の場合は屈折率がものすごく高い値になるため,フレネル効果はほとんど無視していい,ってことになるらしい。金属の屈折率は,アルミニウムの場合で 200 程度の値なんだそうだ。どうやって求めたんだか知らないけど。理論上の値なのかな。
2001-11-27
PSION で PDF の数式が見れない問題を解決すべく, mBrain Software の "PDF+" と "FontMachine" を購入してみた。オンライン決済で計 $48 ,えーとつまり ¥6,000 ぐらいかな。
んでさっそくいれてみたんだけど…… FontMachine を入れたとたんに PC との接続ができなくなってしまった。なんてこったい。
職場の PC とも接続できなかったことから察するに, PC 側の問題ではないようだ。繋がらないんじゃにっちもさっちもいかないんで,ハードウェアリセットをかけてみたところ,普通に接続できるようになった。でも FontMachine を入れるや否や接続できなくなってしまう。くう。
うーむ。ちょっと時間ができたら作者にメールしてみよう。いまはそんな気もおきないや。忙しいっつーの。
先日 Makefile をゴキゴキと書き換えていて,はじめて gcc の -MMD オプションってのを使った。これは,コンパイルと同時に,そのファイルがインクルードしているファイルのリストを拡張子 ".d" のファイルに吐き出すってオプションだ。なんていうか,たったひとつのオプションでいろいろやってくれるもんだなあ,とおもう( gcc の病的なオプションの細かさから比較するならば,だけど)。
http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_3.html#SEC14
make ではファイル間の依存関係を明示的に記述してやんなきゃいけないんだけど,これを手で書くことはめったになくて,たいていは makedepend とか,そういう自動生成の手段を使うことになる。 GNU make のマニュアルには
ってな感じで,1ファイル毎に依存関係を記述した ".d" ファイルを生成するといい,みたいなことが書いてある。
http://www.gnu.org/manual/make/html_chapter/make_toc.html#TO...
で,最近はこれを gcc 側でサポートするようになった,ってことみたいだ。うー,そうならそうと書いてほしかったよ,あんた。
2001-11-28
ここ数日,Paul Debevec のサイトに入り浸ってみている。
Paul Debevec は Image Based Modeling / Rendering / Lighting の分野でもっともアクティブな研究者で(たぶんね),くだんのページではそれに関する大量の資料や論文を閲覧することができる。
そのなかでも意外とたびたび目にするのが, High Dynamic Range (HDR) 画像のはなし。最初はダイナミックレンジがそんなに重要なことなのかなあ,っていぶかしんでいたんだけど,これがわりと重要な問題らしいのだ。
ごく普通に言うところのテクスチャマップってのは,マテリアルの反射係数 (albedo) の分布を画像で持ったもので,個々の係数は 0.0 から 1.0 の範囲の値になる。だから,これを 8 bit/channel の整数値で持つのは自然だし,たいていは十分な精度になるだろう。
http://www.treasure-troves.com/physics/Albedo.html
ところが,環境マップ画像ってのは,周囲のライティング情報,もっとそれらしく言えば Radiance の分布情報ってことになるのかな……とにかくそういうもんなので,最低は 0.0 で,上はどこまでも,って感じになる。太陽みたいな光源だったらとてつもなく大きな値になるだろうし,屋内における環境光みたいなやつならごくわずかな値になるだろう。
しかも環境マップの場合,小さな値も大きな値もそれなりに重要な意味を持っている。大きな方に合わせて正規化してしまうと,環境光がほとんど消えてしまうし(消えてしまうならまだしも,醜いマッハバンドが現れてしまうのは困りもの),小さな方に合わせると,こんどは強い光源がほとんど潰れてしまって,鋭いテカりが失われてしまう。
SIGGRAPH 2001 の講義では,ここらへんの話を集中的にやったようで,下のページでそのときのスライドなどをダウンロードすることができる。余談だけど,スライドは論文ほど気合をいれなくてもなんとなく目を通すことができるから,概要を知るにはとても便利だとおもう。
http://www.debevec.org/IBL2001/
まあそんなわけで,環境マップ画像や,セパレートテクスチャを使ったライティング手法なんかでは,ダイナミックレンジの広いフォーマットを使用するのが理想的だ。 GeForce2 以降では,レジスタコンバイナやらピクセルシェーダやらを活用することで,なんとか 16 bit/channel の整数値を扱うことができるみたいだけど,ここはやはり浮動小数点値を使いたいところ。
http://www.ict.usc.edu/~jcohen/hdrtm.html
32 bit/channel とまではいかずとも, 16 bit 浮動小数点とかだったらなんとかならんもんかなあ,とおもう。まあここらへんは,放っておいても NVIDIA あたりがそろそろやってくれるはずだろう。わりと優先度高めに置かれてるみたいだしね。
2001-11-29
そんなわけで,ハードウェアの問題は時間が解決してくれそうなんだけど,次に問題になるのが, HDR 画像をどうやって生成するかってとこだ。カメラにもフィルム/デジタルにかかわらずダイナミックレンジが存在するわけだから,普通に撮影したんでは HDR 画像を作ることはできない。
これを解決するには,同じシーンに対してレンジの異なる画像を複数用意する必要がある。レンジを変化させるには,カメラの露出や絞りを調節してやればいい。こうして得られたレンジの異なる画像群を,色補正しながら合成することによって HDR 画像を得ることができるんだとか。
ちなみに,この補正処理のために作られた HDRShop っていうソフトが Debevec 氏のサイトで配布されている。
http://www.debevec.org/HDRShop/
環境マップ画像は 360 度の全方位パノラマ画像なんだけど,これを撮影する方法にもいろいろあるみたいだ。わりと昔, OhX! にデジカメを使って QuickTimeVR 用の全方位パノラマ画像を作成するって記事があったんだけど,そこでもひどく苦労していたような記憶がある。特殊な三脚を使ってカメラの角度を少しずつ変化させながら何十枚も画像を撮って,さらにそれを手作業で合成してたもんだから,それはもう大変な労力だったようだ。
Debevec 氏がよく使っているのは,ミラーボールを利用した撮影法のようだ。直径数インチのクローム製のボールに周囲を映しこんで,それをカメラで撮影するって方法。とうぜん,ボールには撮影者も映りこんでしまうんで,90度横にずれた画像2枚を合成することによって撮影者を消す。これで半球分で,全方位の画像を得るには,この手順を反対側で繰り返す必要がある。さらに, HDR 画像を得るにはそれぞれの過程で何枚も撮影する必要があるので,けっきょく何十回も撮影してやっと一枚の画像が得られるってノリ。これもなかなか根気のいる作業のようだ。
http://www.debevec.org/Probes/
たぶん,ボールの半径やカメラからの距離に依存して画像が歪んでしまうだろうから,それを補正するにもめんどくさい手順があるんだとおもう。それでもやはり歪みや滲みは出てしまうようで,最終的にはフォトショップで手補正に頼ることもあるようだ。
とにかく,それなりのカメラの知識と,相当の根気が必要とされる作業であることには想像に難くない。なかなか素人にできるもんでもないようだなあ,とおもった。難しいなあ。
2001-11-30
そんなわけで,いままでいいかげんに扱っていたダイナミックレンジってのが,意外と重要な問題なんだってことがわかってきたような気がする。この前,マルチテクスチャを使った Torrance-Sparrow モデルを実装したときに,ダイナミックレンジが足りない/決められないで苦心した覚えがあるんだけど,その「ちょっと困ったなあ」が,明確に「だめだなあ」になった感じ。
ところで, PS2 は頂点輝度を 32bit 整数値で入力するんだけど(!),それぞれのチャネル (R/G/B/A) は 8bit 幅になるわけで,これは 0.0 から 2.0 の値域にマップされている。すると,出力される輝度は最高でもベースカラーの2倍にしかならないわけで……僕にどうしろと!?
ところで,将来的に浮動小数点ベースの輝度表現なんかがHWで対応されたとして,レンダリングコンテキスト内では高いダイナミックレンジを得ることができても,最終的にディスプレイ装置から出力される画像は,やはり制限されたレンジ内に収められることになる。ディスプレイ装置(たいてい CRT だよね)の出力レベルに限界があるからだ。
だから,最高出力レベルに合わせて輝度を正規化したり,もしくは単純にクランプしたり,っていうような加工が加わえることになる。まあ,たいていクランプなんだけど,輝度をクランプしてしまうと明るい部分の輝度情報が失われてしまうんで,絵に迫力がなくなってしまう。レンズフレアなどの特殊効果は,この失われた輝度を補うために必要な処理なんだと,一般的に言われている。理屈っぽいけどね。
たしか Masa さんが,残像エフェクトっていうのも本来その類の効果を狙ったものなんでは,とかどこかで言っていたような気がする。 CRT が肉眼に残像を発生させるぐらいの強烈な輝度を出力できれば,残像エフェクトなんかもいらないはずなんだけど,そうもいかないよね,みたいな感じの名言だったような気がする。
するってえと, PS / PS2 なんかで多用されているフィードバック系残像エフェクトも,輝度に応じてアルファを立てるような工夫を加えるといいのかもしれない。フィードバック回路のアレをああして……できないかなあ,お手軽に。
ところで, PS2 の仕様って, PS2Linux の登場によって事実上開示された状態になっているわけで,これを機にむちゃくちゃなハックをかけてくるひととかでてこないかなあ,とか当初は期待していたんだけど,なかなかそうもいかないみたいだ。まあ,理由はわからんでもない気がするけど。
けっきょく,あの極悪 DMA が半分封じられてしまっている以上,面白さも半減してしまうような気がする。ポリゴンの出ない PS2 なんて PS1 じゃん! まあそこらへんは metalogic.co.jp 氏の今後の活動に期待することにしよう,とおもった。
http://homepage1.nifty.com/fukui/ps2linux/
ハックと言えば,はやく Xbox のハックをやるひと出てこないかなあ,とおもいながら毎日 slashdot をチェックしてるんだけど,まだでしょうか>ハッカー。そんで, Xbox で Linux が動くようになれば,かなりいい感じなんだけど。 $300 でそれなりの Linux box が手に入るようになるわけで,ラックに積み重ねてコンパイリングクラスタでも構築したろうか,と画策中。まだかなあ。