http://www.cbloom.com/3d/index.html

cbloom が主に考えているのは， octree を使って空間分割を行い，その octree のセル毎に視錐台判定と遮蔽判定を適用しようというもののようだ。このときに使用する遮蔽判定のアルゴリズムには beam tree をベースとしたものを利用する。

"beam tree" とは，わりと聞き慣れない単語なんだけど，建築関連の CG 分野ではわりとよく使われるもののようだ。簡潔に言えば，遮蔽物に対して視錐台を構築していき，この錐台群のなかに完全に含まれていれば，その物体は遮蔽されているとみなすことができる，というもの。この錐台群を木構造で保持するため "beam tree" と呼ばれる。

ゲーム関連で言えば， Michael Abrash の "Ramblings in Realtime" などに登場してくる。

http://www.bluesnews.com/abrash/chap64.shtml

この Quake のプロトタイプで使おうとしていたのは，主に２重フィルを防ぐ方法としての beam tree なんだけど， cbloom が述べているのは，これをオブジェクト（ボリューム）単位での遮蔽判定に用いるというものだ。

http://www.cbloom.com/3d/techdocs/beamtree.txt

要するに，主な遮蔽ポリゴンによって構築された beam tree に対してバウンディングボリュームを突っ込み，それがすべて「不可視」な葉に辿り着けば，そのボリュームは不可視であると判定できる，というもの。これをＺ順で処理する必要があるんだけど，これは octree をＺ順で辿るようにすれば，それなりに解決できる。ただし，厳密には入れ違いが発生するので，そこはある程度ルーズに解決する必要があるだろう。

octree って「適応的なボクセル分割」ぐらいの意味合いしかないんじゃないかなあ，っていう不信感があって，今まではわりと速攻で無視していたんだけど，せっかくだからこの機会にちょっと興味を持ってみることにした。

cbloom が薦めているのは Thatcher Ulrich の "loose octree" の手法だ。 "loose octree" は，内容物の最大サイズが特定できるのならば，そのサイズだけ各セルを拡張して扱うことによって，各オブジェクトの中心点をベースとした処理に置換できる，というもの。メリットとしては，点での処理になるために複数のセルにまたがるケースがなくなる，とか，移動するオブジェクトが扱いやすくなる，などが挙げられる。

http://tulrich.com/geekstuff/partitioning.html

構造としては，ただでさえルーズな octree をさらにルーズにするという怪しげなものなんだけど， octree の主な弱点である「形状にフィットしにくい」とか「意味の無い分割が発生しやすい」などを改善できる可能性がある。それに，本来の octree よりも，より「適応的」になっているのが，なかなかエレガントかもしれない。

"loose octree" については，さらに詳しい解説が Game Programming Gems に載っている。題名の字面で無視していたんだけど，予想以上に面白い構造かもしれない。

permalink

http://www.redherring.com/insider/2002/0201/1289.html

これに対してのツッコミが slashdot にある。

http://slashdot.org/article.pl?sid=02/02/04/0219236&mode=thr...

元記事の内容は，まあわりと id を賞賛した感じの内容。いいんでないの。

"loose octree" の Thatcher Ulrich 氏は， cbloom 氏と同じく oddworld inhabitant の従業員で，他にもいろいろと面白いことをやっているようだ。

http://tulrich.com/geekstuff/

個人的には， Lua を "stackless" 化するパッチに注目したい。

Lua は，インタプリタの処理の中でプロセスのスタックを「あるがままに」使ってしまっているため，スクリプトの処理を一時中断することができない。要するに "yield" 関数を実装することができないのだ。

Ulrich 氏が作成したのは，この問題を改善するためのパッチで， Lua インタプリタの中からスタックを使用している部分を追い出したもののようだ。この変更により "yield" 関数の実装が可能となり，インタプリタの一時中断ができるようになった。複数のコンテキストを擬似的に並列動作させることなんかも可能になったわけだ。

ただし，若干のバグが残っている模様。できれば Lua の本仕様に組み込んでもらいたいものなのだけど……どうだろ。

この「スタック問題」は， Lua を使用する上で最も不満に感じていたことなので，このパッチが完全なものになれば，もう Small とか Java VM とか，そういう迷い事を言う必要も無くなるかもなあ，とおもっている。 Lua は十分に汎用的だし，高速だし，なによりメジャーであるという安心感がある。

permalink

http://www.gamasutra.com/features/19991109/moller_haines_01....

Hierarchical Z-Buffering はどっちかってえとハードウェア依存の話なんで，パス。 Shadow Culling は，遮蔽物の「遮蔽度」を数値評価する手法に，ちょっと参考になるところがあるかもしれない。んで，問題は "HOM" だ。

HOM は Hierarchical Occlusion Map の略。 "occlusion map" とは，一般にイメージベースで遮蔽判定を行う手法のことを指しているらしい。 HOM では，然るべき方法によって生成した occlusion map をバイリニアフィルタで段階的に縮小し，階層化する。こうして作られた低解像度の occlusion map では，より少ない比較処理で判定を行うことができる。低解像度での判定で遮蔽状態が断定ができなかった場合は，徐々に解像度の高い occlusion map へとシフトしていく。

HOM については Hansong Zhang 氏のページに論文が置いてあるので，たぶんそちらが詳しい。眺めただけなんでよくわからないけど。

http://www.cs.unc.edu/~zhangh/hom.html

イメージベースで遮蔽判定を行うことの利点は，処理量がジオメトリの複雑度に依存しないことにあるんだろうとおもう。 Zhang 氏の論文に載っている画像なんかにもあるように， CAD 等ではかなり複雑で精密なジオメトリを扱うようだから，イメージベースに転換することで恩恵を受けられるシチュエーションというのは，かなり多く存在するのだろう。

それに比べたら，ゲームなんかで扱われているジオメトリは，そりゃあかなりシンプルなもんだし，根本的に，僕らの求めている「遮蔽判定」と，彼らが言うところの「遮蔽判定」は，微妙にニュアンスが異なっている気がする。僕らのそれは「どうせ見えないところにいるキャラなんて処理したくねーしー」みたいなノリで，もうちょっと大雑把な感覚を求めているわけだ。

もう１つ occlusion map の利点として考えられるのが，小さな遮蔽物の重なりによって結果的に全遮蔽になるパターンに対応することができる，ってとこ。たとえば，木々が生い茂った密林なんかは，木や葉が重なりあうことで視界が極めて狭くなっているはずなんだけど，これをジオメトリ的な処理で対応することは，とても困難だろうとおもう。

そんなわけで occlusion map 的な手法は，滅多なことが無い限り使うことは無さそうな感じがする。

実は "loose octree" の考え方が個人的にとてもヒットで，現在の本命はほぼこれに決まってる感じ。ちょっと実験してみたいなあ。とてもそんな暇無いけど。

permalink

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=03-03-200...

元ネタは，本文にも書いてある通りなんだけど， Gamasutra に掲載された Lasse Staff Jensen の記事。

http://www.gamasutra.com/gdce/jensen/jensen_01.htm

げーはなせんせーに教えてもらって見に行ったこともある記事なんだけど，なんだか小難しそうなんで未読だった。しかしこうして動くものを見せつけられると，なんだかすごく面白そうに見えてくる。こりゃいいなあ。

Gamasutra の記事はたいてい "Printer Friendly Version" が付いてるんで，印刷して読むには便利だ。さっそくプリントアウトしてみたんだけど，やっぱり難しいなあこれ。ほんとにこのテキストだけでわかるんだろうか。スクリーンショットの説明を読む限りでは，固定波と "Choppy Wave" の合成だけで右下の絵ぐらいのは出るらしいんで，そのくらいはどうにかできんかなあ，とおもっている。

ためしに，「元記事の元記事」こと Jerry Tessendorf の論文を落としてみたんだけど，なんだかこっちの方が読みやすそうな気がする。うーむ。

http://home1.gte.net/tssndrf/index.html

噂の企業 "Q-Games" へのインタビュー記事がどこぞのウェブに掲載されていると，職場のひとに教えてもらった。

http://xengamers.com/sections/interviews/6616/1/

Q-Games は，某社の内部制作チームからスピンアウトした数名が立ち上げた新興企業だ。 "Star Fox" 等の制作で知られる Dylan Cuthbert が取締役を務める。

自分たちの手で自分たちのゲームを作りたい，という強い意志が伝わってくる。その意志はもちろん理解できるし，それがこの業界に携わるひとびとの多くの願いでもあることも確かだ。しかしその一方で，ゲーム制作のいわゆる映画産業化というか，制作者個人それぞれの手から離れたところにある，何かすごく希薄で曖昧とした「意志」によって多くの製品（作品じゃなくて）が生み出されているのが現状だったりするわけで……つまり，このひとたちは，これ以上無いくらいに恵まれているんだ，ってこと。

任天堂とＳＣＥ，まさにゲーム業界の最右翼と最左翼（どっちが右で左かは，僕にもよく分かんない）を経験した男が語る「ゲーム作りとは」。わけわからんけどかっこいいなあ。

permalink

http://home1.gte.net/tssndrf/index.html

こちらはとても整理されていて読みやすい。理論の細部はあまり深追いせず，専門知識のないひとにも理解できるような内容で簡潔に説明されている（もともとそういう趣旨のコースなんだろうしね）。最初はとりあえずスライドに目を通してみるのがいいかもしれない。

Tessendorf の手法のベースとなっているのは，波の表面形状を周波数成分に分解し，それに対して統計的なモデリングを適用しよう，というもの。物理モデルによる流体シムは，海のように広大でかつ十分に深い流体に対して適用するには，あまりにも複雑過ぎる。周波数統計モデルなら FFT を使って高速に演算が可能だし，生成された波は「シームレスな」形状をしているので，タイリングして使用することができるなど， CG 的見てに便利な側面も持っている。

それに，統計ベースでも十分に説得力のある表現が可能だということは，この手法が映画「タイタニック」や「ウォーターワールド」でも使用されているという事実が決定的に裏付けている。

詳しい理論はたぶんものすごく難しいところにあるんだろうけど，僕らがやるべきことは実はそれほど難しいことでもない。先人が考えてくれた統計モデルに基づき位相データを生成し，それを FFT につっこめば，それなりにそれっぽい波が出てきてくれる。あとはそれをいかに「それっぽく」レンダリングするかにかかってる，ってことだ。

permalink

http://www.magic-software.com/

たしか，ちょっと前にリリースされた NVIDIA の流体デモが FFT を使っていた気がする。そちらを当たってみることにしよう。

http://developer.nvidia.com/view.asp?IO=ogl_fluid_viz

あったあった。なるほど， FFTW ってのを使っているのか……。

http://www.fftw.org/

FFTW は，文字通り FFT のライブラリだ（ "W" の由来は，よくわかんない）。 FFT のライブラリとしてはかなり有名なものらしくて， google でサーチにかけてみると，非常に優れたライブラリとして FFTW を推す言葉がちらほらとみつかる。ふむふむ。

さっそくダウンロード。で "./configure && make" をぽちっと。 Linux も cygwin もまったく問題無し。

チュートリアルを片手になんとなくプログラミング。だいたいの使用法は分かってきたけど， FFT だのなんだの言ってるのが妙に懐かしい感覚で，なんだか知らないけどおもしろおかしかった。昔は FFT の実装だけで十分暇が潰せたもんだけど，今やこうして単なる「道具」として使っているのが，ちょっと愉快な気分だ。

Alpha Conspiracy のページがいつのまにか更新されていた。

http://www.alphaconspiracy.com/

新曲は "City of Ruin" 。毎度のエレクトロ。落ち着きがあっていいなあ，とおもう。

permalink

http://www.fltk.org/

FLTK は，正直なところ，それほど完成されたツールキットだとはおもえないけど（特にデザインのダサさについては，もっとも物議を醸すところかもしれない），僕自身は特に GUI にこだわりがあるわけでもないので，なんとなく FLTK を選んでしまう。 FLTK は十分にミニマムな実装と言うべきライブラリなんだけど，これは逆に言えば，欲しいもの以外の余計なものが一切存在しないってことなのかもしれない。そういうのは，わりと僕の趣味だ。

もちろん，もっと総合的に優れたツールキットが他に存在すれば，迷わずにそれを選ぶのかもしれないけど，完全にフリーで使えるものに限って言うのならば，いまのところどれもややぱっとしない，ってのが正直な感想だ。

http://www.free-soft.org/guitool/

僕の場合は特に OpenGL との親和性を重視しているところがあるから，そこでちょっと偏見が入ってるかもしれない。 FLTK と OpenGL の連携における優位性は，そこそこ魅力なのだ。 GLUI がもうちょっと機能に富んでいれば，そちら使うことも考えられるんだけど。

http://www.cs.unc.edu/~rademach/glui/

で， FLTK 1.0.11 をダウンロードして make 。案の定一発では通らない。相変わらず cygwin はマイノリティ扱いなのかなあ。まあでも，どれも簡単なエラーなのでちくちくと対処してみる。

あと， OpenGL と併用するのならば， "HAVE_GL" を "1" にする必要がある。 cygwin 環境の場合，デフォルトでは "0" に設定されているようだ。

ていうか autoconf に対応してくれよお。うーむ。

まずは FFTW の練習ということで，乱数からノイズパターンを生成するプログラムを作成してみる。素の乱数を突っ込むと，出力もやはり素のノイズになってしまうんで， 1/f っぽく偏りを付けてやるとそれっぽいノイズになる。 gimp のソリッドノイズっぽいね。

例の波モデルではガウス分布の乱数を使っているんで，とりあえず次はガウス分布乱数だ。ところで，どうやるんだっけ……。

permalink

http://www.taygeta.com/random/gaussian.html

何がなんだかよくわからないけど，短いもんだ。コピペコピペ……。ちなみに親記事はこちら。

http://www.taygeta.com/random.xml

ハードウェア乱数生成器っていうのも面白い。

http://www.protego.se/

こういった装置は，主に暗号処理の分野で用いられているようだ。暗号の信頼性を上げるには， CPU の生成する擬似乱数ではなくて，こういう純粋な乱数生成の手段も必要ってことらしい。そういえば，その昔，ネットスケープが日付から暗証鍵の生成をやっていて，これを見抜いたある学生がクラックに成功した，って事件があった。

http://www.webtechniques.com/archives/1996/08/floyd/

この製品は，それまでの米国の独自規制基準であった 56bit 長制限が緩和され，一般の民生用製品でも 128bit の暗号鍵を使用できるようになって初めてリリースされたっていう，いわゆる「虎の子」バージョンだった。 40bit や 56bit の RSA 暗号では十分な信用性が得られないことがクラックコンテストなどで何度も実証されていて，この 128bit 暗号鍵の導入によってウェブブラウザのセキュア能力が飛躍的に向上するはずだった。ところが，たった２人の大学生がスパコンでもなんでもなく「そこらへんの」ワークステーションを使って数分で破ってしまったってんで，かなり話題になった事件だ。

ところで，ハードウェアで乱数を生成する方法は，ダイオードに電流を流し込み，そこで発生するノイズをシードとして使用する，というものらしい。この方法でもある程度の偏りは生じるので，そこをいかにして理想的な分布に補正するか，という点で技術競争があるようだ。

擬似乱数生成については， jiro さんがドジ研掲示板で薦めていた "Mersenne Twister" が面白そうだ。

http://www.math.keio.ac.jp/~matumoto/mt.html

http://www.soi.wide.ad.jp/class/20010000/slides/03/index_1.h...

原理や数学的な意味合いについてはほとんどわかんないけど，その背景に存在するストーリーがなんとなく面白いとおもう。 Knuth 先生とのやりとりがイカしてるなあ。

まあそれはともかくとして，十分に速くて信頼できるようなので，使ってみて損は無いかもしれない。とりあえず速度の検証はやっておこう。関数を 100*100*100*100 回して，経過時間を GetTickCount で計測してみた。

stdlib の rand には負けてしまっているけど，それでも極端に遅いってことはないようだ。地形の自動生成とか，ならべくバラけた乱数が欲しいシチュエーションというのも存在するので，そいった場合には役に立つこともあるかもしれない。

permalink

http://www.markhilgart.com/code/waves

ていうかむしろ， Mark Kilgard かと一瞬おもった。ニアミスって感じ……。内容は，まあそこそこ参考になるかもだ。ソースも置いてあるしね。

virt の曲が，すごくいい。底なしにいい。最近のお気に入りは "Flowerguy's Pool Party" 。

http://www.splitsyndicate.com/music/mods/v-flower.it

パーカッション以外はすべてブリープ，つまり矩形波と三角波だけなんだけど，まあそこはチップチューンとしてのアイデンティティの付加ってとこ。それとは別に，非常にメロディアスな曲の構成に本質的な魅力を感じる。ちなみに，この曲には本人による「本気バージョン」も存在する。

http://virt.zophar.net/music/Virt_-_Flowerguys_Pool_Party.mp...

どっちもいいとおもう。後者は普通に楽しめるし，フェチだったら前者で萌えることもできる。

なにげに PS2 版「アメリカ横断ウルトラクイズ」の記事を読んでたら，石切山氏の名前が出てきて，ちょっと驚いた。

http://www.watch.impress.co.jp/game/docs/20020305/digicube.h...

氏のゲームを TOWNS で遊んでいた時代が懐かしい。 BASIC で作られたトロいクイズゲームであったけど，ほんと，飽きることなく遊んでいたなあ……。

いまはなんだか，あらゆるものが飽和してしまって，楽しむべきものも楽しめなくなっているような気がする。それは決して時代が変わってしまったということではなく，単に僕が夢の無い大人になってしまったってことなんだけども。

permalink

http://www.red3d.com/cwr/steer/

それぞれのアルゴリズムにおける動作を目で確認しながら読み進めることができるのが，とても面白い。実際にこういった単純なモデルを適用できる機会はそれほど多くないんだけれど，設計に行き詰まりを感じたときなんかに，こういうのをボーっと眺めながら考え事をしていると，なんとなくインスピレーションが得られることもある。

マシンスペックの向上に伴い，ゲームに群集表現を見かける機会も多くなってきた。新しい要素ゆえに高等な技術と見られることもあるけれども，実際には，群体をそれらしく動かすことよりも，１体の NPC をそれらしく動かすことのほうがよっぽど難しい。群集表現ってのは，ある意味では，逃げの手段なのかもしれない，とおもうこともある。

Aba さんのページが更新されている。新作は Windows 版 "Wok" だ。

http://www.asahi-net.or.jp/~cs8k-cyu/linux/wok.html

Linux でゲームする環境が整っていないんで（ VNC 通してるし）二の足を踏んでいたんだけれど，これで普通に遊ぶことができるってわけだ。

SDL ベースなのに移植に手間取った，ってのは，ちょっと面白いかもしれない。この場合は SDL よりも OggVobis に問題があったようだ。ともかく，これで定石ができあがったわけだから，たぶん次からはスムースに移植することができるのではないかとおもう。

でも， Aba さんの手の広さから言って，また SDL で何か作る確率はかなり低そうなんだけれども。

permalink

http://headlines.yahoo.co.jp/hl?a=20020309-00000513-yom-int

いまさらこんな牧歌的な SF も流行らないような気もするんだけれど，最後の２行に言い知れない魅力を感じる。そこにこそドラマがあるってのに。小説にしたら面白そうなテーマだ。

http://www.watch.impress.co.jp/pc/docs/2002/0308/arm.htm

最近ちょっと ARM に惹かれ気味かもしれない。 Arcon は非 wintel な変態系 OS として以前から目を付けていたんだけど，そもそもどこに行けば買えるんじゃい，ってくらいのマイナーぶりで，ほとんど諦めていたところ。まあそれも，究極の ARM プラットフォームであるところの GBA と gbadev が登場したことにより必然性がなくなってきたかもしれない。そんな訳だから，暇があったらもうちょっと GBA に力を入れてみたい。決して，本気で取り組むほどの勇気は無いんだけれど。

そういえば，どこかのゲーム関連のニュースサイトだかなんだかで，怪しげアイテム専門業者として有名な "liksang" と米国内での取引が禁止された，との噂を聞いた気がする。

http://www.liksang.com/

まあ北米での話なんで日本は関係無いとおもうけど，この手のモノの個人輸入に多少なりのリスクが生じることはあるんだろうか，と疑問におもうことがある。 GBA のフラッシュを買うとしたら，ここぐらいしか無いんだけれど，どうしたもんだろう。

あと Xbox 用 VGA box にもちょっと注目。

http://www.lik-sang.com/catalog/product_info.php?category=53...

むしろ Xbox から素で VGA 出力が出てないことがよっぽど解せないんだけど，どうしてなんだろう。 USB の互換性の件といい，妙なところに MS の警戒を感じる。一体何に対して警戒しているのかは，僕にはさっぱりわからないんだけれど。

もっとも，この製品の素性もちょっと怪しいところ。単にビデオ信号をアップスキャンして VGA box と名乗る製品も多いので油断できない。どこかに人柱はいないものか。

permalink

permalink

http://www.google.co.jp/search?hl=ja&lr=lang_ja&q=%83%5E%83E...

QUITER 辺りから，こんなマニアックなニュースが舞い込んできた。一体どこからこんな情報を集めて来るんだか，いつも不思議におもっている。

http://www.raylight.it/blueroses.htm

"Raylight Blue Roses" は GBA 向けの 3D エンジンらしい。パースコレクション無しのテクスチャマッピング，ライティング無し，で秒間 3,000 ポリゴンほど表示可能とのこと。静止画のスクリーンショットではわりと頑張ってるように見えるんだけど，しかし 3,000 ポリゴンは意外と少ないなあ，とおもう。秒間 15 フレーム換算でも 200 ポリ程度しか使えないことになるのだから。ゲームとしての実用を考えるにはかなり厳しいラインだ。

GBA のスプライトには BG と同じくアフィン変換機能が付いているので，それを利用してテクスチャ付きポリゴンのラスタ処理をできないものかなあ，とおもっている（おもっているだけで，決して実行することはないのだろう）。いわゆるサターン的なスプライト利用法ってやつ。ちょっとややこしい方法だけど， GBA では 64x64 サイズのスプライトまで使えるらしいし，それなりに愉快なこともできるかもしれない。

Blue Roses もこれと同種の手法を利用しているのかもしれない。いくら GBA が低解像とは言え， ARM7TDMI の 16MHz にこの量のラスタ処理を課すのは少々無理があるとおもうのだ。仮に内部ループが 10 命令で回ったとして， 240x160 の画面を塗りつぶしたとして，ポチポチ……と計算していくと，不可能じゃないのかもしれないけど，ちょっとつらいような気がする。少なくとも，他に処理を回す余裕は残っていないだろう。

DOOM の背景みたいに限定された 3D 処理だったら，前述のスプライトテクニックもかなり実用的に使えそうな気がする。ていうか DOOM は GBA で出てないんだっけ。 Duke Nukem は出るって言ってたような気がするんだけど，あれも出たんだか出ないんだか……間違いなく日本語版は出ないだろうけど。

permalink

http://www.google.co.jp/search?q=%83%84%83R%83r%83A%83%93+%8...

とにかく実装しないことには説得力が出ないんだけど，その機会は当分の間無さそうだ。ゴールデンウィークまでには暇になるといいな……。

permalink

http://www.blender3d.com/

うーむ。今までも NaN 社の経営状態を危ぶむ声は幾度となく聞こえてきたし，最近の開発状態の不安定さから言っても，だいぶ不穏な空気が感じられていたし，だから，今さら驚くことでもないんだけど……ついにその時がきましたか，って感じ。

これを期にオープンソース化を望む声も多いけど，そういうことは有り得るんだろうか。たぶん blender の権利はどこか外部の会社に売り渡されることになるんだろうけど，これをコミュニティの手によって買い取ることは可能かもしれない。ただ， blender コミュニティ自体がそれほど盛り上がっていたわけでもないので，その可能性は薄いようにも見える。

最近の blender は "Game Blender" だの Web3D だの，あさらさまに商業サイドに媚びた戦略が見え見えだった。そうやって必死で市場に食い込もうとするあまり，本来の方向性を見失っていたようにおもえる。個人的には，そのねじれっぷりが気に入らなかったので，いっそのことオープン開発に移行して清潔な体制に変化してもらった方がありがたいかもしれない。

さて，どうなることだろう。もうしばらくの間，注目してもよさそうだ。

今さら知ったのだけど，ちょっと哀しげな話。

http://www2.justnet.ne.jp/~arp/kataru/m_011114.html

ここのページの濱田さんは，ネット上で活動を続けるミュージシャンの方。数年前に偶然ホームページを見つけて以来，たまにだけど，地道に行方を見守っている。これは，その濱田さんが活動初期にユニットを組んでいたという，伊藤さんという女性ボーカリストについてのはなし。

伊藤さんはとても歌唱力に秀でたひとで，その深みのある歌声を初めて聴いたときは，このひとがアマチュアだとはとてもおもえなかったぐらいだ。ただ，僕が濱田さんの存在を知ったときには，濱田さん自身は既に Arp としての活動を開始しようとしていたところで，伊藤さんの事については特に知ることの無いまま今に至ることになった。しかしそれが，こんな経緯があって，そしてこんな結末が訪れるとは，全くおもってもいなかったことだ。

ためしに検索にかけてみると，伊藤さんのホームページを見つけることができた。

http://www.interq.or.jp/asia/takahasi/Kyrie/

詳しい事情を知っているわけではないので，何とも言うことはできないのだけど，とても惜しい気分だ。

それから少しの間，故人が過去に存在した証をウェブに残すことの意味について考えてみたけど， 僕は哲学者でも思想家でもないので，それについてちゃんとした文章に組み立てることはできない。でも多分，これからも多くの人がそういった行為を取り，そうして多くの記憶がウェブ上に刻まれていくのだろうとおもう。

permalink

http://www.realtimerendering.com/

うーむ。これは願っても無い吉報かもしれない。「とりあえずこれ読んどけ」本として有名な "Real-Time Rendering" も，ハードウェア側の異常な速度での進化（著者曰く「３年で１０倍以上の成長」）に対応し切れず，急速に現状とのギャップが広がってしまった。 RTR は「枯れたトピックを枯れた切り口で取り上げる」という手法をとっていて，時代が変化しても腐りにくい内容の組み方を意識的になされているんだけど（ここら辺が他の書籍との大きな違いだったりもする），それでもやはり「時代から置いてけぼり感」は否めなくなってしまっている。

Vertex Shader や Pixel Shader のように，ここ数年で急速に重要度を増してきたトピックに関して全く触れて居なかったりするのは "Real-Time Rendering" の名を冠する本書としては不本意なことだろう。とにかく，単に第２版という以上のパワーアップらしいので（５１２ｐ→９００ｐ！）もはや購入は必然と言えよう。買うしかないっぺよ。

http://www.famitsu.com/game/info/2002/03/13/263,1016013618,4...

そうそう，忘れちゃいけない。今月はこれが出るんだっけ。これが出る頃は，ちょうどまた忙しくなっているとおもうんだけど，いや買うしかあるまいよ。おもわず特別版を買うぐらいの勢いで。

ところでこのゲーム，デュアルショックじゃとてもじゃないけどプレイできるとは思えない（レバガチャしまくるから）。操作系は一体どうなっているのだろう。右スティックで操作できればなんとかなるような気もするけど……はて。

そもそも完成度の方はどうなのか。画面写真とか全然出てないだけに気になる。うーむ。とにかく発売日を待つしかあるまい。やきもきさせるなあ。

permalink

http://www.google.co.jp/search?hl=ja&q=x-multiply+irem&lr=la...

エミュレータで遊ぶことのひとつの楽しみは，当時は「謎の箱」的存在だったゲーム機のハードウェアについて知ることができる，ということかもしれない。もっとも， MAME のソースぐらいグロくて巨大なものになると，とてもそんなことも言ってる余裕が無いんだけど。

ちょっとした画像処理を自動で行うツールを Python ベタで書いていたんだけど，どうにも動作が重過ぎるので，実際に画像処理を行っている部分だけを C で書き直してみることにした。

Python では画像ファイルの読み書きに PIL (Python Imaging Library) を使用していた。

http://www.pythonware.com/products/pil/

まずはこいつの代替となるライブラリを探さなきゃならない。候補として考えられるのが， FreeImage, GD, DevIL など。

http://www.6ixsoft.com/

http://www.boutell.com/gd/

http://openil.sourceforge.net/

この中では特に FreeImage が有名らしいんだけど，ここはちょっとひねくれて DevIL を使ってみることにしよう。マルチプラットフォームへの対応を重視したのと， OpenGL スタイルの API デザインを採用している点が気に入ったからだ。

OpenGL のデザインはグラフィックハードウェアのステートマシン的特性を考慮したものだから，画像処理ライブラリ（実のところ，むしろ単なるファイル読み書きインタフェースなんだけどね）をそれに似せたデザインにする意味は分からないけど……とりあえず使い心地は悪くない。インタフェースがガチガチに閉じられていて，わけわからんけど無闇に堅牢な感じ，ってのが悪くないね，とおもう。もしかしたら中はドロドロなのかもしれないけれど。

それで C で書き換えた結果，劇的に速くはならなかったけど，それなりの速度にはなったようだ。結局，大量の画像データを LAN で転送する部分で大分の時間を食っているので，プログラムを高速化したところで期待するほどの効果は得られないってことだ。まあ，ライブラリのレパートリーが増えたから，それで良しとしておこう。

ところで DevIL ってどっかで見たことあるなあ，とおもったら，元 OpenIL と名乗っていたライブラリだった。そうそう，こんな事件があったんだ。

http://slashdot.org/article.pl?sid=01/03/29/1718204&mode=thr...

SGI の言い分は，まあ正当なものなんだけと，だからってわざわざ有志のプロジェクトをいじめることはないだろうに……とおもったものだ。結局この事件を期に OpenIL は "DevIL" と名を変えたらしい。 OpenAL はいまだにがんばっているようだけど，はたして SGI とどんなやりとりがあったのか，僕には定かではない。

http://www.openal.org/

permalink

http://pub37.ezboard.com/fgamingageforums2frm0.showMessage?t...

http://insidermovies.ign.com/insider/video/robotech1.mov

"Robotech" は「マクロス」の洋題。よく知らないんだけど Cube でマクロスのゲームが出るらしい。ビジュアルは全体的にちょっとネムい気もするけど，動画を見る限りではそれなりに雰囲気が出ているとおもう。とにかくミサイルを撃ちまくるのは単純に楽しそう。やはりマクロスといえばミサイルというのは共通の見解のようだ。

ところで，ロボ系＋セルシェーディングって組み合わせは，いままでもあったようでで無かった盲点かもしれない。ロボ系っていうと「鉄騎」のような重厚感を求めるものが多かったから，どちらかといえば安っぽくて軽い感じの出てしまいがちなセルシェードを使用することは鬼門とされていたのかもしれない。でもまあ，「マクロス」なら原題の性質から言っても問題なさそうだ。

そういえば，セル系ゲームで半透明エフェクトを使うのはいただけないなあ，とおもう。特に煙。セルならば不透明煙を使わなければ……それこそがリミテッドアニメの極みなのだから。

ちょっと出遅れたけれど Kilgard 先生の新作 "Practical and Robust Shadow Volumes" をチェック。

http://developer.nvidia.com/view.asp?IO=robust_shadow_volume...

あ，ていうか，どっちかっていうと Cass Everitt 氏なんだな。まあ CEDEC 2001 の Kilgard 先生の講演とかぶっている部分も多いので，ネタ元的には Kilgard 先生なんだろうけど。

実は CEDEC2001 のアレも，まだまともに読んだことがなかったので（あのときはステンシルシャドウなんて全然興味がなかった……むしろ Kano さんのパーピクセル話に夢中だったわけで）そっちも併せつつ読んでみる。

で，冒頭に登場するのが，ステンシルシャドウの破綻ケースとして有名な「Ｚニア問題」と Carmack の逆転テクニック（"zpass"方式）の話。ここで既に大きく出遅れているんだけど，このテクニックについても全然知らなかった。うーむ，たしかにこれは，これは……。

「Ｚニア問題」はステンシルシャドウを使用する上での大前提だとおもっていたものだから，このテクニックの存在はステンシルシャドウに対する印象を大きく変えるものになるかもしれない。しかしこの "zpass" ，つまり最近面の裏側の領域に対してシャドウボリュームを適用するという発想の転換も大したものだとおもう。

とは言っても， Carmack 自身もこれを思い付きでやったわけではないようだ。決して一瞬のひらめきではなく，長い試行錯誤の末に解答にたどり着く，という流れは，このひとの話の中に常に見られるパターンだ。

ともかく，まだ読み始めたばかりなので何もよくわかっていない。果たして本当に「ロバストな」ステンシルシャドウの実装は存在するんだろうか。実は半信半疑な気持ちもあるんだけど，まあ，ゆっくりと読み進めてみたい。

permalink

http://developer.nvidia.com/view.asp?IO=robust_shadow_volume...

というわけで早速ダウンロード。ざっと概要を知りたいのならば，論文よりもスライドの方がてっとり早くていいかもしれない。

このネタでの２つ目の衝撃は，視錐体の遠クリップ面を視点座標系における無限遠，つまり (0,0,-D,0) に設定する，という部分。普通，遠クリップ面と言えば「十分に遠い」距離に設定するものなのだけど，これを無限遠にしてしまうことで，シャドウボリュームと遠クリップ面との間で生じる干渉を防ごうというものらしい。

ここで当然のごとく問題になるのがＺバッファの精度の問題。近・遠クリップ面間の距離が広がればそれだけデプス値の精度は低下するはずだ。しかし，Ｚバッファにおけるデプス値の分布特性（Ｚ値に反比例）を考慮するならば，たとえそれが 1:10000 から 1:inf に変化したとしても，それほど深刻な影響にはならないだろう，というのが彼らの主張。確かに言いたいことは分からないでもないけど……信じていいのかな。

「w=0 の無限」に代表されるような同次座標系の特性を用いたテクニックには，常に，何かに騙されているような不思議な感覚が付きまとう。 "Jim Blinn's Corner" の "The Homogenous Perspective Transform" では，そんな同次座標系の不思議な性質と応用法について，より直感的な理解を与えようと試みている。

http://www.amazon.co.jp/exec/obidos/ASIN/1558603875/qid=1016...

この章では，例えば，同次座標系における 「w=0 の無限」は「ラップアランドされる」性質を持つとされている。すなわち，「無限に手前」(+1,0,0,0) と「無限に奥」(-1,0,0,0) は，実は位置的な意味では同じものだということだ。なんだか納得いかないけど，これは (+1,0,0,-0) の意味するところを考えてみれば，確かにそうなのかもしれないという気がしてくる。

さらに面白いのが，同次座標系上における「透視変換」の意味について解説している部分だ。まず，透視変換行列は簡略化すると次のように表される。

これは w 軸方向に対するせん断 (shear) 操作に他ならない。そして，この行列に対していくつか意味ありげな値を突っ込んでみると，なかなか面白い結果を得ることができる。

驚くべきことに，視点が無限の領域に広がってしまったとおもえば，無限に遠いはずだったものが手を伸ばせば届く距離にまで縮んでしまった。ちなみに (0,0,D,1) の向こうに広がるのは，変換前は視点の手前にあったはずの空間だ。つまり「ラップアラウンド」されて，視点の奥へと顔を出したわけ。うーむ……。

"zfail" 法で登場する透視変換行列はここで挙げたそれにいくぶん近いもので，近クリップ面から無限遠の空間を 0.0 -> 1.0 の領域にマッピングするものだ。まあそんなわけで，無限遠や "w=0" の導入に戸惑うこともあるかもしれないけど，同次座標系の奇妙な性質に触れて度胸を付けておけば，それも自然に受け入れられるようになるのかもしれない。

僕はといえば，やっぱりなんか騙されてるような気がするんだけど。

permalink

permalink

http://www.ati.com/developer/indexsc.html

うーん，素晴らしい。レンダリングの品質の高さも相変わらずだけど， "dynamic" と銘打つからには動きの部分も相当印象的なんだろうとおもう。しかし RADEON 8500 は難しいなあ……誰も持ってるひといないよ。家の PC は NLX だから RADEON なんて入りっこないし，どこか店頭デモででもやっといてもらえると助かるんだけど。

技術的な内容についても，個人的にわりとショッキングなもがあった。件のデモには短いドキュメントが付属されていて，そこに簡単な技術解説があるんだけど（これは ATi のひとが書いたもののようだ），どうやらバーテクスシェーダ／ピクセルシェーダに物理系の演算を解決させている模様。うーむ，そうくるのか……。

spin の「ダブルスティール制作者インタビュー」にも，シェーダにメイン処理の一部を負担させるというアイデアに関して触れている部分があった。それを読んだときにもおもったのだけど，この手の exploit 系テクニックは，個人的にあまり突っ込みたくない方向性だなあとおもっている。本来レンダリングのために用意されたはずの機構をメイン処理に利用するという方向性に，少し危険な香りを感じるのだ。過剰にハッキッシュではないかと。

Xbox のようにハードウェア的に制限の課せられた環境ならともかく，究極に汎用的な環境であるはずの PC でそれを行うことに対して違和感を拭い切れない……うーん，いやむしろ，「行うと得がある」という事実を，僕が内心で認めたくないんだとおもう。信義的な意味で。

まあそこらへんはともかくとして，いつになくちょっぴりハッキーな Kano さんのデモに萌え萌えな感じ。せっかくソースも付いてるんだから，読まなきゃ損だ。

permalink

http://k3d.sourceforge.net/

"K-3D" は GTK を使用して作られたマルチプラットフォームな 3D ツールだ。機能的に不足しているし，インタフェースも洗練されていない感じで，かなり不満なんだけど，本当にフリーなのになるとこんぐらいしか見つけられないんだよねえ……。趣味の範疇に過ぎないのだったらこれでもいいんだけれど，「ひょっとすると実用になるかも」ぐらいの線を狙いたいとおもっているので，もうちょっと高みを目指したいところ。

http://digilander.iol.it/2g/moonl-e.htm

"Moonlight Atelier" は Linux 向けの 3D ツールとして有名だった "Moonlight3D" の後継となるソフトだ。かなり期待できるソフトだったらしいんだけど， 2000 年初頭に開発が突如として中止され，それ以来作者とは音信不通とのこと。うーん，こりゃあどうにもならんなあ。

permalink

http://www.cs.brown.edu/~tor/

DAKINI さんのところにも続々と SIGGRAPH 2002 情報がアップされてきているけれど，ほとんどが読めない状態なので悶々としているところ。ここはとりあえず SIGGRAPH 2001 の方をチェックしてみることにしよう。

Rowley 氏の paper リストにぱらぱらっと目を通してみたところ，まず目に付いたのが Waterloo 大学の "Homomophic Factorization of BRDFs" だ。

http://www.cgl.uwaterloo.ca/Projects/rendering/Papers/

http://www.cgl.uwaterloo.ca/Projects/rendering/refl.html

いつか調べた Jan Kautz 氏の "Arbitrary BRDFs using Separable Approximations" の続編にあたる論文のようだ。 Kautz 氏の手法は，結局のところ凝った BRDF になると誤差が大きすぎて使えなさそうな雰囲気だったんだけど，今度のはどうだろう。とりあえず読んでみるしか。

しかしまたこういうのを調べていると，ピクセルシェーダが無いとかで悶々としてきそうな気がする。ビデオカードを買い換えないのが悪いんだけど，家にでかい PC を置く気にはどうしてもなれない。今使っている PC はちょうど Xbox ぐらいの大きさのやつなんだけど，それでも我慢できずにファンレス PC の導入とか考えているくらいだ。ましてや，空冷ファンが必要なビデオカードってどうよ，って感じなんだけど。

全然遅くていいからソフトウェアエミュレーションでピクセルシェーダが動けばいいんだけどなあ。 DirectX ならリファレンスラスタライザを使うって手段もあるらしいけれど，開発環境が cygwin ゆえに OpenGL じゃないとどうにも……。

こうのたけしさんの日記にあったんだけど， scei.co.jp に「ブロードバンドナビゲータ」の使用許諾条件がアップされている。

http://www.scei.co.jp/bn/

実は「ブロードバンドナビゲータ」がどんなものかは全然知らないんだけど，パッケージ構成から見るに Linux のカーネルと基本ソフト一式がまるごと入っているみたいだ。それで， SCEI がライセンスを持つソフトについては DISC 1 に収録して，別途にライセンスを持つものについては DISC 2 に収録するという方法をとっている模様。 BSD ライセンスならともかく（ BSD ライセンスの場合，バイナリの配布に著作表示等は必要とされない） GPL や独自ライセンスのものも含まれているので，このページでこうやって EULA の提示を行っているようだ。

ふーん……って感じでなんとなくリストに目を通していると，その中に "Sylpheed" が含まれていて，ちょっと驚いた。

http://sylpheed.good-day.net/

Sylpheed は GTK で作られた Outlook 似のメーラーとして有名なソフト。「ブロードバンドナビゲータ」は，たぶん DISC 1 に PS2 用 Netscape Communicator がバンドルされるはずなので，メーラーは Netscape のやつを使うもんだとおもいこんでいたんだけれど，そこは敢えて Sylpheed を使わせる気なんだろうか。いや，むしろその方がいいんだけれど。

ともかく，ゲーム機に商用 Linux が積まれる日が来ようとは夢にもおもわなかったよ…… Indrema はともかくとして。

permalink

permalink

permalink

permalink

permalink

http://pub37.ezboard.com/fgamingageforums2frm0.showMessage?t...

鉄拳４は PS2 初のプログレッシブ出力対応をうたっているんだけど，これと同時に VGA 出力もされているということのようだ。

やり方は簡単で，本体設定の「コンポーネント出力」を RGB （デフォルトは YCbCr）に変更して，鉄拳４をプログレッシブモードで起動（△＋×ボタンを押しながら起動）するだけ。ここでおもむろに PS2Linux 付属の VGA ケーブルを接続すると， VGA ディスプレイに映すことができるということだ。

職場に転がっていた鉄拳４でさっそく実験……難なくできた。やはり VGA 出力は綺麗だなあとおもう。好みの問題であるかもしれないけど，このシャープな画像とコントラストの効いた発色は，決して NTSC では味わえないレベルのものだ。ただ，なんとなく PC ゲームっぽい匂いになってしまうところは否めないけど…… NTSC にもそれなりの味があるってことなのかもしれない。

ところで，何故，この時期にあって「初の」プログレッシブ対応なのか，そしてなぜナムコだけにこの技が可能だったのか，そこが問題なんだけど。うーむ。

職場のひとがプレイしていた PS2 版「アメリカ横断ウルトラクイズ」を傍目で観察。動きのぎこちなさ，テンポの悪さは苦笑ものだけれども，雰囲気は十分に出ている。過剰演出だってちょうどいいくらい。長いローディングも，一生懸命にポリゴン留さんを読み込んでるとおもえば許せるよ僕，って感じ。

permalink

http://www.polycount.com/

実際 nVidia の技術デモなんかでも Quake のモデルを利用していることがある。

http://developer.nvidia.com/view.asp?IO=q2_bm_vol_shadows

特にアニメーションデータなんかを自分の手で用意するのはなかなか難しいことだから，それを枯れた形式で揃えることができるのは，なかなか便利なのではないかとおもう。

Quake のキャラクタモデルデータ形式は，初代 Quake の "MDL" から始まり， "MD2" (Quake II), "MD3" (Quake III Arena) と変遷を遂げてきた。 Quake III Arena では "MD4" という骨格アニメーションをサポートした形式も検討していたらしいんだけど，結局は MD3 形式のみのサポートに落ち着いたらしい。

Quake のキャラクタモデルは伝統的に頂点アニメーションを使用している。「頂点アニメーション」とは，一般的に，共通のトポロジー情報に対して複数のジオメトリを対応させ，それらを内挿補間することにより形状の変化を実現する方式のことを指す。

頂点アニメーションは，骨格アニメーションと比較すると，データの扱いがわりと簡単だとか，変形に対する自由度が高い，などといった利点が存在する。しかしその一方で，データがかさばりやすいとか，プログラムからの操作が大変，などといった欠点もある。

特にデータの肥大化は問題になりやすい。キーフレーム毎に全ジオメトリの情報を持つわけだから，ポリゴン数が高くなるほどデータは肥大化する傾向にある。骨格アニメーションなら各骨格の位置回転を保持するだけでいいから，容量も少なくて済むし，圧縮にも都合いい。キーフレーム内挿も骨格の方が断然に有利だ。

また，頂点アニメーションでは単純な内挿しか使えないため，キーフレームが目立ちやすいという特徴がある。これをごまかすにはキーフレームを増やせばいいんだけど，そうすると更にデータがかさばるという悪循環が発生する。

プログラムからの操作がしにくいというのも大きな問題だ。例えば首を注視点に向けるとか，手の位置を対象物に対して補正するとか，そういった単純な操作も骨格情報が無ければ実現は難しくなってしまう。 IK やダイナミクスなどの高等なアニメーション手法も骨格の定義があってのものだ。

そんなわけで，最近では骨格アニメーションの方が圧倒的に扱う機会が多くなってきたんだけれど，頂点アニメーションもその役割を完全に終えたわけではない。フェーシャルアニメーションなどのように，そもそも骨格を使用しないアニメーションの場合は，やはり頂点アニメーションを用いることになる。また，指などのように骨格が密集しているパーツに対しては，局所的に頂点アニメーションに切り換えた方が効率のいい場合もあるだろう。

他にも，洋モノのアニメ（ディズニーとかワーナーとか）のように柔軟かつ「非現実的な」形状変化が行われる場合に頂点アニメーションを用いることが多いようだ。こういったアニメーションは，もはや骨格では表現不可能ってことらしい。例えば「ジャックｘダクスター」のイベントシーンとか，全部頂点アニメーションじゃないかなあって予想しているんだけど（特にダクスターとかね），どうだろう。

あと，今となってはもう関係無いことだけど，昔は骨格の計算や，ウェイト付けによるスキニングを行うのが難しかった関係上，ワンスキンを実現するために頂点アニメーションを用いる，ってケースも多かったみたいだ。 Quake なんかはまさにこのケースに当てはまるだろう。

ちなみに，ここら辺のＣＧ用語はシマによって呼び方が異なるので，微妙に混乱することがある。 SoftImage 的には，頂点アニメーションは "Shape Animation" らしいんだけど，他のツールでは "Cluster Animation" とか "Morphing Animation" と呼ぶ場合もあるらしい。変わりどころでは， Lightwave なら "Gizmo" だし， SCE のひとたちは "MIMe" という呼称を好んで使う……ちなみに "MIMe" は "Multiple Inbetweening Method " の略で，厳密には「２つ以上の複数のジオメトリを任意にブレンドすることによって形状変化を表現する」手法のことをいうようだ。なにげに特許らしい。うーむ。

permalink

http://www.alphaconspiracy.com/

むむむ，どうしたことだろう。これも気まぐれだろうか。まあ CD 持ってるから関係ないけどね……。

というわけで MD3 形式について調べてみることにする。ネット上にはほとんど資料はないみたいだけれど， Q3A はツール部分とゲーム部分のソースが既に公開されているので，それらを参照すればファイル構造ぐらいはわかるはずだ。

ftp://ftp.idsoftware.com/idstuff/quake3/source/

"Q3A_ToolSource.exe" がツール部分のソースだ。もともと BSP コンパイラや Q3Radiant （公式マップエディタ）のソースパッケージなんだけど，基本ライブラリのソースコードも含まれている。便利だからこれをそのまま使わせていただくことにしよう。

ん，とおもったら，長ったらしい EULA が添付されている。たぶんこのソースコードの使用範囲制限が記述されているんだろう。まあ，後でゆっくり読んでみることにしよう。僕みたいな目的での使用がダメなんだったら，改めて自分の手で書き直すだけのことだ……。

基本的なファイル構造については common/qfiles.h の中に書かれているようだ。だいたい md3xxxx_t っていう名前の付いている構造体がそれ。基本的なノリは初代 Quake の頃からあまり変わっていないようなので，雰囲気を知るためには Quake のドキュメンテーションも役に立つかもしれない。

http://www.gamers.org/dEngine/quake/spec/quake-spec34/qkmenu...

Q3A で新たに加わった要素については，モデル製作者向けの解説を参考にしてみることにしよう。例えばここらへんとか。

http://www.planetquake.com/polycount/cottages/wrath/tutorial...

Q3A では，プログラム側からの姿勢の制御をある程度可能にするために，モデルが上下半身および頭部に分割されている。本当は骨格モデルにしたかったんだろうけど，まあ，間に合わなかったんだろうなあ。 id Software はいまだに少人数開発体制を貫いているんで，ここいらの仕様は意外とミニマムなものが多い。

permalink

http://www.mame.net/

permalink