2002-10-01
台風が来た。もの凄い暴風雨。裏のコンビニへ行くまでの間にびしょ濡れになってしまった。傘さしてたはずなのに……。
そんなわけで，今日は泊まり。台風のことを気にしながら急いで帰るのもせわしないし，作業もそこそこ残っているし。
へんてこギークニュースこと ZZZ online より "Serious LEGO: CubeSolver" 。
http://jpbrown.i8.com/cubesolver.html
LEGO Mindstorms を使ったルービックキューブ・ソルバだ。 "LEGO Cam" から USB 経由で送られる画像を PC 上で解析し， Mindstorms で構成されたロボットアームを操作してルービックキューブを解いてしまう。
Mindstorms の魅力の１つに，可能性の幅の広さというものがあると思う。多彩なパーツと汎用コンピュータ "RCX" によって生み出される組み合わせは，単なるロボットの類だけにはとどまらない。例えば，基本セットに含まれる光センサを利用して簡易スキャナを作ってしまう人などもいる。ちょっとの工夫と創造力さえあれば，あらゆるメカニクスが Mindstorms によって表現される可能性を秘めていると思う。
このメカの作者である JP Brown 氏の本業は環境コンサルタント (Environmental Conservator) だそうだ。馴染みの無い職種だけれど，ええと，つまり，重要建築物の経年変化などを調査する仕事であるらしい。あまり Mindstorms とは関係無いかな……。氏のページには他にも力作がたくさん展示されている。
http://jpbrown.i8.com/index.html
僕のお気に入りは，２足歩行ロボ "Biped_II" 。見た目の迫力がいい感じだ。すげ……。
http://jpbrown.i8.com/biped_ii.html
その昔，突如として Mindstorms が欲しくなる衝動に駆られ，思い切って手を出してみようかと思ったことがあるんだけども，たまたま時を同じくして仕事の方が忙しくなってしまい，断念した経験がある。結局そのまま今に至るわけで，一度取っ掛かりを無くしてしまうと，なかなか手を出せなくなってしまうものだと思う。
衝動が発生した瞬間こそが，買い時なのかもしれない。衝動買いも悪くない，ってことにしておこう。
2002-10-02
台風の影響で昨日から泊まり。なぜか寝汗をかいてしまった。嫌な感じ。
Gamasutra に GDC Europe 2002 における講演の資料が転載されている。どれも充実した内容で面白い。中でも興味深かったのが IDG アナリスト Simon Price 氏のスライド "What Sells Where and Why?" だ。
http://www.gamasutra.com/gdce/2002/simon_price.zip
同氏の講演は，北米及び欧州におけるゲーム市場の現状について解説した内容だったらしく，それに関する詳細な情報がスライドに載せられている。国内の市場ならまだしも，海外の市場に関しては本当に漠然とした情報しか持っていなかったので，非常に参考になるものがあった。
個人的に特に興味深かったのが，各国におけるコンシューマ機と PC ゲームのシェア比較だ。日本では PC ゲームと言うと散々な状況だけれども，日本以外の各国では PC ゲームが市場の全体においてかなりのシェアを保持している。特にその傾向は欧州に強く，ドイツなどでは全体の売り上げの４割近くを PC ゲームが占めているらしい（同国における PS2 のシェアは２割程度）。しかも本数ベースに換算すると市場の約半分を PC ゲームが占めているというから驚きだ。ちなみに，本数ベースにすると PC ゲームの割合が増えるのは，安売りソフトやバンドルソフトが多く存在するという理由かららしい。
ゲーム市場そのものを見ると，欧州全体の市場規模は北米単体でのそれを下回っている。やはり，世界的に見て最も重要な市場は北米におけるコンシューマゲーム機市場である，という事実には疑う余地が無い。 PS2 の普及台数も日本のそれを既に突破していると言うし，市場自体が順調に拡大傾向にあることも多々伝えられている。その北米において Xbox がある程度のシェアを確保しているという事実は，なかなか重要な意味を含んでいるように思われる。
まあシェアに関してはそのくらいにしておいて……，次に面白かったのが，欧州各国におけるゲーム市場の事情解説だ。例えば，ドイツ人はホーム・エンターテインメントに馴染みが薄くて，どっちかっていうと本が好き。ブランドやメディア戦略に対しては比較的冷静で，なぜか古いマシンをいつまでも大切に使い続ける……とか，そんな感じ。最近は洪水の影響でずいぶん苦労しているらしい。話には聞くんだけれど，経済に深刻な影響を与えるほどだったとは知らなかった。
フランス人はクルマ好きで有名。ＧＴシリーズが最も人気のある地域だそうだ。ちょっと面白いのは "Loi Galland" −「ガラン法」の存在で，採算を無視した安売りが法的に禁じられている。小規模な小売業を保護するための法律らしい。
http://www.google.com/search?q=loi+galland&lr=lang_en
http://www.corporatewatch.org/news/curbing_supermkts.htm
同様の法律は欧州各国に存在するそうだ。経済の話はよく分からないけれども，いかにも欧州らしい流れだな，と思う。
北米・カナダ・イギリスは単一の言語（英語）で済ますことができるけれども，欧州には各国に多彩な言語が存在するわけで，本格的なローカライズを行うにはそれなりの手間が伴うことになる。それに，英語ならば片言ながらも理解することができるかもしれないし，文化についてもそれなりに馴染みのあるものだけれど，ドイツやフランスともなると言語はまったく通じないし，文化のギャップもより深いものとなる。そんな状況でのローカライゼーションが幾多の苦労を伴うものであろうことは，想像に難くない。
http://www.watch.impress.co.jp/game/docs/20020302/nintendo.h...
しかしながら，ローカライゼーションに必要とされる費用なんて本番の制作費に比べればタダみたいなもんなんだし，それでうまく行けばそれなりの利益を上げることが可能なわけだから，それを逃す手はないのかもしれない。
2002-10-03
どこからともなく細かな仕事がわらわらと湧いてくる。僕は比較的手が空いているので，パイプラインに加わって作業を手伝うことにした。ひたすら単調な作業の繰り返し。こういうのはやっていて楽な仕事ではあるけれど，あまり愉快なものではないな，と思う。
また週末にドタバタしそうな雰囲気が漂ってきた。今日はとりあえず帰っておこう……。
引き続き GDC Europe 2002 のネタを漁ってみる。なにはともあれ Mark Cerny ネタは放っておけまい。
http://www.gamasutra.com/gdce/2002/mark_cerny.zip
「ゲームプロデューサ」としての Mark Cerny が，ゲーム制作の方法論について述べた講演だ。その名も "The Method" （うへえ）。メインテーマは pre-production −「試作版」の重要性。試作というプロセスがいかに重要であるか，また，試作とはいかに進めるべきか，ということについて論じられている。
いろいろ書いてあるんだけれど……要約すれば，「試作版：物量以外は製品レベル」，「試作ですべての検証を済ます」，「試作に失敗したら制作を中断すべき」とか，そんな感じ。試作版は製品の一歩手前の状態であり，そこでゲームがゲームとして成り立っていなければ，その後にも成り立つはずが無い！ という理屈だ。逆に言えば，試作を確実に全うすることで，その後に発生するかもしれなかった様々なリスクを回避することができる，ということでもある。
「試作版に適正な費用は１億以上」との意見もある。もし試作に失敗したとしても，更に資金を浪費する危険を未然に防ぐことができたのだから，決して無駄な投資ではないという主張だ。
http://www.gamasutra.com/features/20020906/mclean_01.htm
言っていることはもっともだし，制作側の都合としても大いに受け入れられるものだと思う。しかし大抵の場合，制作のスケジューリングや，ゲームの製品としての性質などというものは，会社（パブリッシャ）側の都合が大きく影響する範疇の問題だ。そういった状況では， Cerny のようは方法論はなかなか受け入れられないのではないか，という不安がある。
しかし，これが制作側の人間の希望論ではなくて，ゲームプロデューサ，つまり制作をコントロールする立場の人間である Cerny から語られているからこそ意味があるのかもしれない。つまり，彼の元でなら，こういった方法論で制作を進めることができるよ……っていうアピールかな，と。
ちょっと関連する話題で "Jak and Daxter" におけるスケジュール管理の話がある。ちなみに "Jak and Daxter" の制作にも Cerny Games （Mark Cerny の会社）が絡んでいる。
http://www.gamasutra.com/features/20020710/white_02.htm
Jak and Daxter では「マクロ式スケジューリング」の手法が取り入れられていたそうだ。この手法では，長期での詳細な計画を固めるのを避け，その代わりに，ごく近い将来における達成目標をなるべく詳細に取り決めるようにする。長期の計画には曖昧な部分が多く，結果的に不正確で当てにならないものになりがちだ。それに対して短期の計画ならば，現状の分析から正確な予測を割り出すことが可能であり，「嘘偽りの無い」計画を立案することが可能なはずだ。
そして，この計画が達成されなかった場合には，決してそれを放置したりせず，その失敗の要因を詳しく分析する。その結果に応じて制作規模の減量や担当者の入れ換えなど適切な対処を行い，次のサイクルには計画が厳密に達成されるような体制を立て直す。こうしたマクロレベルでの確実なスケジューリングを繰り返すことにより，無理のない制作進行を行うことができるということだ。この方法ならば，嘘ばかりの計画に辻褄を合わせようと余計な犠牲を払ったり，度重なる計画の変更によってメンバーの士気を低めたりとか，そういった不安材料を回避することができるってわけ。
2002-10-04
集中的にタスクを消化する。さすがに疲れた。つら……。
GDC Euro ネタから "Hard-Tuning the PS2" 。 SCE Europe の R&D チームに在籍する Jason Doig 氏の講演だ。
http://www.gamasutra.com/gdce/2002/jason_doig.zip
内容は主に "Performance Analyzer" の紹介と， PS2 における高速化の要点の解説から構成されている。
"Performance Analyzer" は，ハードウェアで PS2 のプロファイリングを行う装置だ。 CPU や GPU ，それに各種バスの負荷をかなり詳しいレベルまで解析することが可能らしい。しかし，こんなもん使ってる所はそうそう滅多にあるもんじゃないので，僕も詳しいことは何も知らないし，むしろこのスライドを見て初めてその存在を確認した，ってぐらいだ。
上の写真はスライドからの切り抜きなんだけれど，たかがプロファイリングのためにこんな大そうな機器をわざわざ用意するってのが，もはや尋常じゃないと思う。確かに，こういうのがあれば便利な局面が存在することは理解できるけれど， EE に内蔵されているパフォーマンス・カウンタ類だけでもかなり詳しいプロファイリングが可能なのだから，わざわざこういった装置を使ってみようという気には，なかなかならない。それ以前に努力すべきことも沢山残っているわけだし……。
ただし， GS （描画プロセサ）の負荷を詳しく測定できるのは面白いかもしれない。 PS2 はアーキテクチャの特性上， CPU から離れた箇所にボトルネックとなる要因が多々存在し，通常のプロファイリング手法ではそれを特定するのが難しいからだ。 PA を使えばこれも一目瞭然なわけで，描画担当のエンジニアにとっては心強い味方になり得るだろうと思う。
2002-10-05
各方面における尽力が実って，作業は予定通りに完了。あとはいろいろチェックして……と。結局，帰るのは明日になりそうだ。
少し前から Nick Foster 氏の "Structural Modeling of Natural Flames" を読んでみている。炎のシミュレーションに関する論文だ。
http://www.cs.brown.edu/~tor/sig2002/StructuralFlames02.pdf
Foster 氏の論文には流体のときにもお世話になった。この論文で紹介している手法も PDI/DreamWorks 社において実際のプロダクションに応用されているものだ。最近では映画「シュレック」で利用されたそうで……ていうか，むしろ「シュレック」のために開発した手法なのかな。
内容は，どちらかと言えば流体シミュレータの応用に近いことをやっている。あくまでも「炎のように見えるもの」のシミュレーションをやっているだけで，実際の酸化現象を厳密にシミュレートするものではない。実際に炎の動きを科学的にシミュレートし視覚化する手法はまだ確立されていないそうで，どんなに頑張ったとしても結果論的な手法には頼らざるを得ないようだ。
基本的に炎のエレメントはＢスプライン曲線によって構成されている。スプラインを一定間隔でポイントサンプリングし，そのポイント（パーティクル）を風量フィールドの中へと流し込む。適当なオイラー法によって流体演算を行ったのち，移動後のパーティクルを結ぶようにスプラインを構成し直す。そして次のステップでは，そのスプラインから再び一定間隔でポイントを生成し，同じ処理を繰り返す。こうすることによって，パーティクルを適当な密度に保つという仕組みになっているらしい。
レンダリングは主にボリュームレンダリングをベースとして行われる。前述のスプラインを軸としてポテンシャル・フィールドを展開し，そのフィールドから等位面を構成することによって視覚化する。フィールドの強さや，等位面上の色付けについては，アーティストがパラメータによって与えるようになっている。そこらへんは，完全に見た目をベースとしたやり方だ。
……と，こんな感じで，完全自動のリアルなシミュレーションってわけでは無い。それなりにリアルな炎の動きをデザインするための強力なフレームワーク，と考えればいいかもしれない。
当初は，リアルタイムに応用できる要素があるかなあ，と思って読んでいたんだけれど，とてもそういうレベルの話ではないようだ。論文に転載されている「シュレック」のドラゴンが炎を吐くシーンで，だいたい１５０万個のパーティクルが使用されているとのことだ。やはり，本物の炎のような動きを見せるには，それなりな数のパーティクルが必要とされるらしい。それでしかもボリュームレンダリングしなきゃなんないんだから……リアルタイム屋にはちょっと無理な話だ。
そんなわけで，リアルタイムの世界では，当分の間，単純なパーティクルエフェクトが主流になるだろうと思う。もしくは，プリレンダ・ムービーを貼り付けたビルボードとか，そんなとこかな……。優秀なアーティストが居るならば，それで十分なクオリティが保証できるだろうと思う。
2002-10-06
作業は早朝に終了して，帰宅。朝帰りだ。
そして，ずっと夜まで寝てた。
2002-10-07
最近， GDAlgorithms の流れが微妙に緩くなっているような気がする。先月の異様なポストの多さとは対照的だ。今のうちに過去ログでもさらっておこうかと思う。数ヶ月分溜まっちゃってるんだよな……。
"Few Questions About Racing" 改め "Resource Formats" 。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=Resource+...
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
元は，レースゲームを作るにはどうしたらいいのかなー，みたいなほのぼのとしたスレッドだったんだけれど，途中から，複雑化するリソースを如何に効率良く制御するか，みたいな熱い討論に切り替わってしまっている。もちろん，後者の方が議題として面白いので結果オーライだ。
主な焦点となっているのは，モデルデータをどういったフローで処理するか，という問題についてだ。一例を挙げるならば，モデラに専用プラグインを用意して，コンバート作業をすべてプラグイン上で行うという方法が考えられる。もう一例を挙げると，モデラ固有のフォーマットを解析する手段を用意して，出力ファイルからコンバートを行うという方法とか……，まあ，そんな感じで，他にも様々なフローが考えられる。
お馴染み Bungie の Chris Butcher が薦める方式は，モデラからプラグインを使って中間フォーマットを出力し，そこから外部コンバータによってゲーム固有のフォーマットへと変換する，というフローだ。このとき，中間フォーマットはなるべくシンプルで情報量の豊富な仕様にしておくことが肝心だ。
http://www.geocrawler.com/archives/3/4856/2002/8/350/9234613...
この方法にはいくつかの利点がある。まず重要なのは，中間フォーマットを出力するまでの機構（具体的にはフォーマットの仕様とツール類）については，複数のプロジェクトにおいて再利用が可能であるという点だ。また，中間フォーマットとツールを使い回すことができるということは，それを保守する担当者についても使い回すことができる（！）ということを意味している。これによって，プラグインを作成するための特殊な技能を持った人材の必要数を下げることができ，人的リソースの面でも利点が発揮されることになる。
他にも，中間フォーマットはツールに依存しないため，複数のツール（例えば Maya と MAX）に対してプラグインを用意すれば，複数のツールを使い分けることが可能になるという副作用もある。これは，ツールのライセンス料が負担になるような小中規模のデベロッパではメリットになることがあるかもしれない。あまり重要でない部分にはお古のツールを使ってもらうわけだ。
もう１つ重要なのは，フォーマットの変更に対する柔軟性だ。中間フォーマットはありったけの情報を冗長に保持するようにしているため，このフォーマットを変更する機会はめったに無いだろう。これに対して，ゲーム固有フォーマットは，ゲーム本編側の仕様の変更に伴って変更を迫られることがある。プロダクトの開発が進んでからの仕様の変更はなんとも耐えがたいことだけれど，固有フォーマットの仕様はメモリ効率やローディング速度に影響を与える部分でもあるので，仕様変更がやむを得ない場合もあるのだ。
そんなときに，中間フォーマットを使ったメソッドは効力を発揮する。適当なバッチプロセスによって「一晩のうちに」仕様変更を適用させることが可能だからだ。これに対して，プラグインで直接に固有フォーマットを出力する方法では，データの再エクスポートを迫られることになるだろう。これは，開発の中盤以降においては非現実的な選択肢だ。バージョンアップコンバータを用意する方法もあるけれど，中間フォーマットの方法に比べたらはるかに煩雑な手順になるだろうことは明らかだ。
で，中間フォーマットを具体的にどういう仕様にするかということになるのだけれど……，個人的には X3D に注目してみようと思っている。
しかし，まだ全然評価していないので何とも言えない。もし仮に X3D が中間フォーマットとして十分な仕様を持っていて，さらに各モデラが標準で X3D に対応するような状況になれば，わりとおいしい思いができるかもしれない。実際にはそう上手く行かないのが常なのだけれど……。
件のスレッドでは， x 形式を拡張して使っているよ，なんて話も出ていた。確かに現状では適当な方法かもしれない。 Xbox + MAX なんて組み合わせだったら，いかにもそんなのがありそうだ。
少し関連する話題で，モデルのプレビュー作業を如何にスムースに実行させるか，という問題がある。件のスレッドでは，モデラ上に「実機になるべく近い出力を実現するプレビュア・プラグイン」を実装して，そこでプレビューと調整を行う，なんて話も出ていた。しかしこれは，専用プレビュアの実装と保守の手間を考えるとなかなか難しいものがあると思う。
これはつらいので，せめて「ボタン一発で実機プレビューまでこぎつけるような仕組み」で勘弁して欲しいな，と思う。ただしこの方法（実機上でプレビューを行う方法）だと，マテリアル／シェーダのパラメータ調整の手順が煩雑になる可能性がある。実機プレビュア上にそれらの調整を行うインタフェースを用意し，さらにその調整結果を元データにフィードバックさせるようなフローが必要になるからだ。
まあ，そこはうまく住み分けを行えばなんとかなるかな，と思う。ましてや PS2 ならば，だ。 Xbox なんかだと相当に複雑なシェーダ構成が可能になるわけで，この辺りの管理は困難を極めることになるのかもしれない。
2002-10-08
週末に変な生活を送っていたもんだから，昨日今日と寝起きが悪くてしょうがない。今朝はなんだか中途半端に雨が降っているし，どうにも心地の悪い朝だ。
今さらながら， Windows の COM アーキテクチャについて調べてみている。特に， Python を絡めた形での利用法を模索している。最終的に Python + Tkinter/wxPython + ActiveX で RAD 環境を実現できないかなあ……と目論んでいるわけ。
http://www.python.org/windows/win32com/COMTutorial/index.htm
Python (Python for Windows) から COM を呼ぶには "win32com" モジュールを利用する。
http://www.python.org/windows/win32com/
標準の Python for Windows パッケージには win32com が含まれていないので，別途に追加でインストールする必要がある。これには， Starship サイトに置いてある win32all パッケージをインストールすればいい。
http://starship.python.net/crew/mhammond/win32/Downloads.htm...
win32all には win32com 以外にも Windows 固有の拡張モジュールがいろいろ含まれている。特に，専用の IDE である "PythonWin" はかなり強力なツールなので，是非とも導入しておきたいところだ。キーワード補完や「折りたたみ」 (folding) を持つ強力なエディタとか， GUI ベースのデバッガ環境とか，とにかく標準の統合環境 (Python IDLE) を遥かに凌駕する機能が含まれている。ううむ，知らなんだ。
PythonWin は IDE の名称であるとともに， MFC のラッパ・ライブラリの名称でもある。
http://www.python.org/windows/pythonwin/
前述のエディタやデバッガも，メイン部分は Python で記述されているので，ユーザが独自に拡張することが可能なようだ。
えーと，それはまあ置いといて…… win32com をさっそく使ってみよう。手始めにメディアプレイヤーでも呼んでみる。
とりあえず問題無く動作しているようだ。 Excel のセル値の取得ぐらいだったら，この調子で造作なく実現できるだろうと思う（自宅マシンに Excel が無かったので実験できなかった）。
そう言えばつい先日， perl で xls ファイルを読む方法とかを四苦八苦しながら調べていたけれど，先にこっちを当たっておけば良かったのかもしれない。まあ，あれはあれで便利なんだけどさ……。
基本的に COM オブジェクトなら何でも呼べるようなので，努力すれば DirectX 関連を呼ぶことも可能なはずだ（ほんとかな？）。出来たところでさほどメリットは無いんだけれど，ネタとしては面白いだろうと思う。
2002-10-09
普通の日。仕事はそれほど忙しくない。先行きは透明のような不透明のような。最近起こった身近な出来事と言えば，机の上に常備してあるコーヒーが切れたことぐらい。まったくもって中庸だ。つまらない。あまりにもつまらないから，今日は職場に泊まっていこうと思う。
今週（？）の Gamasutra の特集は "Shader Integration" 。 GameCube の初期タイトルとして有名な "Star Wars: Rogue Leader" (Factor 5) を例にとって，リアルタイム・レンダリングにおけるシェーダの管理手法について解説している。
http://www.gamasutra.com/features/20021002/sauer_01.htm
とりあえず目を通してみているんだけれど……なんかしっくり来ない。本格的なシェーダ開発の経験が無いためか，書いてある内容に対してほとんど実感が湧かないのだ。最初の数章を読んだところで，すでに「ふーん……」って感じで，なんだか他人事みたいになってきてしまった。ううむ，これは記事が悪いんじゃなくて，自分が時代から取り残されてしまっていることを示しているのかもしれない。みんな楽しそうだな……。
そんなわけで，最初の１ページ半ぐらいしか読んでいないんだけれど，まあだいたいの内容は「私たちはこんな感じでシェーダを小奇麗にまとめることができました。どう？」って感じだと思う。著者のシェーダ構想とゲームキューブのハードウェア特性がうまく整合したみたいで，なにやらとても幸せな気分が伝わってくる。そこはいい感じだ。 PS2 だと，そんなことを考える隙間さえも無いわけで……いや，それ以前に，僕は業務では全く描画系に関与していないから，偉そうなことを言えたもんじゃない。
やはりどうにも無難な内容なんで，それほど面白い記事ではないかもしれないけれど，ゲームキューブでレンダリング・エンジンを作っているような方々には，参考になることや，同感できる点などがあるのかもしれないなと思った。
2002-10-10
職場で寝ていたら，思わず寝過ごしてしまった。ただ寝過ごすのも嫌な気分だけれど，職場で寝過ごすのはもっと間抜けな気分だ。目覚ましが虚しく鳴り続けるところとか，阿呆みたいに目覚ましを叩き止めるところとか，たぶん誰かに見られてしまったんだろう。……ダメだ。いい加減，目覚ましを買い換えないと。
目覚ましでも買おうかと thinkgeek.com を見てみた。どうせ買うなら面白いのがいいと思ったからだ。
以前ここで多機能な原子時計を見かけたような気がするんだけれど（もちろん「原子時計」とは言っても実際には「原子時計と同期する電波時計」に過ぎない），今は置いていないようだ。まあいいか……どこか他を当たるとしよう。
しかし相変わらず変なものばかり売ってるなと思う。へんてこガジェットの充実度ではまさに随一のサイトだ。
http://www.thinkgeek.com/stuff/computing/5a82.shtml
http://www.thinkgeek.com/stuff/fun-stuff/59e0.shtml
http://www.thinkgeek.com/stuff/fun-stuff/3884.shtml
http://www.thinkgeek.com/stuff/apparel/321a.shtml
さすがにこのクロックじゃ使い物にならないな……。 Linux のカーネルマップなどは，デザインの脱力っぷりがポイント。これでは間違ってもインテリアになりゃしない。半端ではなく本当にオタク向けの商品を置いているからこそ thinkgeek の存在意義があるってものだと思う。
へんてこインテリアといえば，最近目を付けているのが despair, inc の "Demotivator" シリーズだ。
http://www.despair.com/sacrifice.html
http://www.despair.com/stup24x30pri.html
http://www.despair.com/connot.html
Demotivator の発案者である E.L. Kersten 博士によれば，同社の「消沈」商品群には，人々が本質的に持つ過度の期待を抑え，間違った行動へと向かう可能性を取り除く効果があるという。
http://www.despair.com/indem.html
……もちろんこれは冗談で，これらの商品は，オフィスなんかに張ってあるスローガンやプロパガンダを掲げたポスターに対するアイロニカルなジョーク商品である。しかしデザインが非常に秀逸であることと，その独特のセンスから人気が出ているらしい。特に日本人にとっては英語が直接的に伝わってこないという副作用があるから，隠れたニヒリズムのシンボルとして活用することができるかもしれない。
ちなみにインチキ博士の Kersten 氏は実在する人物で， despair, inc の創立者の一人でもあるそうだ。それにしちゃ，おいしいキャラだよなあ……。
http://www.dmagazine.com/february01/street0201.shtml
2002-10-11
使い古しの Windows マシンに Linux をインストールしてみた。実験用マシンとして再利用するのだ。 Linux のインストールは何回も繰り返しやっているので，さすがにこの辺りの手順には慣れてきた。 Linux ばかりもなんだから，次は BSD でも入れてみようかな……。整然とした環境が好きなので，きっと BSD の方が性に合うに違いない。また退役マシンを見つけたら，そのときに試してみようと思う。
最近， Linux マシンのキーボード／マウスの接続を USB を使ったホットプラグに切り換えている。サーバをコンソールから直接に操作することは滅多に無いので，平常時はキーボードとマウスを切り離しておくわけだ。これだけでもだいぶスペースの節約になるし，無駄な配線も少なくなる。できたらラック筐体にして，もっと効率良く配置したいんだけれど，ラック筐体は意味も無く値が張るので躊躇している。中身は普通のＰＣでいいんだけどさあ……。
GDAlgorithms から小ネタ "Real time smoke" 。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
煙エフェクトで大量の半透明を使っているんだけれど，カメラが近づいたときにフィルレートがまるで足らなくなってしまう，どうにかしたい……ってのが質問の内容。遠くのエフェクトについてはまったく問題が無いにしても，煙の中にカメラが突っ込むぐらいに接近すると，下手すると画面を覆い尽くすぐらいのフィルが何回も発生してたりするわけで，普通にやってたんじゃとても追いつかなくなってしまう。処理落ちを一種の迫力表現として受け入れるって逃げはダメかな……。
返答の中にある Hargreaves 氏の手法は， Masa さんが CEDEC の講演で披露していた「縮小バッファ」とまったく同じ方法だ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9234024&list=...
同氏は返答の中で，ピクセルフォーマットの制限から現状の D3D では実装が難しいと指摘している。まあだから，恐らく Hargreaves 氏も Xbox で実装してみたんだろうと思う。氏は Climax 社の "MotoGP" のスタッフだから，製品でそのテクニックを使っているかもしれない。
ちなみに Climax MotoGP はナムコの同名ゲームとは直接関係は無い。どちらも有名なロードレース世界選手権 "MotoGP" を題材にしているということだ。
ロードレース・サーキットというのは意外と単純な照明環境だから，リアルタイムＣＧの題材としてはなかなかおいしい題材なのかもしれない。もうしばらくすれば，実写と見間違うようなリアルが画像がゲームで楽しめるようになるだろうと思う。目標は，こんな感じ。
http://www.motograndprix.com/en/motogp/popup.html?id=82943&w...
Climax MotoGP と言えば Gamasutra の Postmortem が印象的だった。
http://www.gamasutra.com/features/20020626/hargreaves_01.htm
そしてこの記事の筆者が Hargreaves 氏だ。記事の内容は，ツールは自前でガンガン作っちまおう！ みたいな過激な内容。 "MotoGP" ではモデリングに使うツールのほとんどを自社開発でまかなったそうだ。曲面でのモデリングや，マテリアルの編集を行うツールなどが例として示されている。自分達の要求に合わせて開発を進めた結果，市販のツールには無いようなユニークな機能の揃ったツールに仕上がったとのことで，なんともうらやましい話だと思う。下手すりゃ，これだけでも売り物になっちまうだろうに……。
微妙な不満点を抱えたまま市販のツールと心中を決め込むか，もしくは多大なリスクを負ってまで「もしかしたら使いやすくなるかもしれない」インハウス・ツールを開発するか……。これはかなり難しい判断だと思う。どちらを選択するかは，時々のシチュエーションによって大きく異なってくる。ただ，人材資源の活用効率という面を考慮するならば，ツールはなるべく一般的なものを採用するようにした方がいいと思う。一般的なツールならば，ラーニング無しに新しい人材を投入することも可能になるかもしれない。また短期で投入される人材とかは，できれば外でも役に立つ技術を覚えたいと思うだろう。
例えばセガの「アニマニウム」や CRI のツール群のように，本気で開発して最終的にミドルウェア化し，それ単体で採算ベースに乗せてしまう，という考え方は面白いかもしれない。自分達が不満に思っていることは，恐らく他でも不満に考えているわけで，そこに需要を見出すのは間違っていないはずだ。それを本気で商売にされてしまうとこっちも後込みしてしまうけれど，妥当な価格で提供されれば，業界全体がちょっと幸せになれるかもね……，と思った。
http://www.cri-mw.co.jp/products/index_j.htm
2002-10-12
今週はそれほど忙しくもなかったので、普通に休暇を取ることができた。
で， "Real time smoke" の続きはと言うと，途中でもう一つの方法が提案されている。現在の描画リソース消費量を推定して，そこからパーティクルの総量を調整するようにしてみてはどうか，という案だ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9233946&list=...
しかし，この方法については Chris Butcher 氏から反論が挙げられている。 "Halo" の開発中に同様の方法を試してみたものの，パーティクルのちらつきが目立ってしまってしょうがなかった，とのことだ。確かに，高いフィルレートを消費しているということは，一つ一つのパーティクルがスクリーン上において面積を占めている状態にあるわけだから，そのパーティクルを突然消してしまったのでは目立ってしょうがないだろう。
そこで出されていた折衷案が，フィルを消費しそうになったら早めにフェードアウトさせてしまうという対処法だ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9234742&list=...
個々のパーティクルがスクリーン上で占める面積を逐次算出し，それがある程度の数値を超えたら強制的にフェードアウトを開始させる，という仕組みだ。計算量を食いそうな感じもするけれど，パーティクル毎の計算を行う前にバウンディングボリューム単位で判定を行うようにすれば問題無いだろう。スクリーンを覆い尽くすほどの面積をもつエフェクト群など，ごく少数に限られるだろうからだ。
根本的な解決という意味では縮小バッファ法が優れているけれども，実装の面で厳しい条件が残る。簡単な対処を施すには今回の方法が適しているかもしれない。ただ，見た目に対して動的な変化を与える方法なので，画像に荒れが出てしまう可能性も考えられる。その辺りは実際に試してみないと評価は難しいと思う。
2002-10-13
少し前から HDD の調子が微妙に悪くなっていたので，新しい HDD と取り替えてみることにした。「微妙に」調子が悪いというのも，派手に壊れているわけじゃなくて，たまに読めないファイルがあったり，たまに起動できないアプリがあったり……とかそんな感じ。なんていうか局所的に致命傷で，この先無事に使っていける気がしなかったのだ。
新しく買ったのは IBM ブランドの 30GB HDD 。 120GB とか，なんだかもう無謀な容量のも売ってたりして微妙に動揺したんだけれど，落ち着いて無難にヘボいのを選んでおくことにした。 30GB だって使い切れやしないって。
んで，あとはひたすら再インストール。 NLX 筐体だから，普通の HDD は１台しか内蔵できない。移行作業はバラした状態で行う必要がある。今この上にコーヒーとかこぼしたら一発で終わるなあ，とかぼんやりと考えながら移行作業を進めていった。
まずはディスプレイドライバを入れて，次に IE6 を入れて，あとはひたすら Windows Update を繰り返す。いまだに回線が ISDN だから，つまらないパッチ当てにもずいぶんと時間を食う。 cygwin を入れる頃になると，もうだいぶ面倒くさくなっていて，ローカルに残っていたダウンロード済みのアーカイブを再インストールして済ませてしまった。別段メジャーバージョンアップがあったわけでもないし，こんなもんで十分っしょ。
まともに動くようになったのは，もう朝の４時ぐらいのことで，きりが無いからそれで終いにして寝た。
2002-10-14
苦労して HDD を換装したにも関わらず，また怪しげな挙動を見せるようになってきた。ううむ，無駄な処置だったか……。古いドライブと新品のドライブとで，ほとんど同じ症状が見られていることから察するに，ドライブ側の問題ではなかったようだ。明らかに駆動音がおかしくなっているから，電源系のトラブルかもしれない。なんにしろ，迷惑な話だ。ＰＣは当面買い換えないつもりでいたんだけれど，そうも言ってられなくなってきたらしい。
新環境構築のついでに，ライブラリやツール群も新しいものに入れ換えてみようと思う。ちょうど時を同じくして boost の 1.29.0 がリリースされたようなので，そいつを入れてみることにした。
1.28 からの変更点は，と……。個人的には， uBLAS が標準セットに加えられたことが，最も大きな変更点かもしれない。
http://boost.org/libs/numeric/ublas/doc/index.htm
uBLAS は基礎的な線形代数ライブラリだ。ただ，どっちかっつうと数学屋さん向けな匂いがする。いずれ試してみるつもりだけれど， tvmet をメインで使っていくことに変わりはないだろうと思う。
あとは…… Format ライブラリや Date-Time ライブラリなどが気軽に便利そうだ。
http://boost.org/libs/format/index.htm
http://boost.org/libs/date_time/doc/index.html
これはすぐにでも導入できると思う。
MultiDimensional Array なんてのも登場したようだ。 boost::array 並の動作をしてくれるなら，使い所もあるだろうと思う。
http://boost.org/libs/multi_array/doc/index.html
unix/cygwin ユーザなら Signals ライブラリも便利かもしれない。 Windows な人にはほとんど（つうかまったく）意味無いかな。
http://boost.org/libs/signals/doc/index.html
"Preprocessor Subset for C/C++" なんてのもあったりして，使い方はよく分からないんだけれども，なにやら妙に不穏なオーラを感じる。なんなんだこれは……。
http://boost.org/libs/preprocessor/doc/index.html
そして boost::python が version 2 になっていた。そうそう，これもぼちぼち試してみなければ……。まあ，いずれ TAOS さんが詳しく解説してくれると思うので，それまで忘れておいてもいいかもしれない。
http://boost.org/libs/python/doc/index.html
忘れかけてたけど boost::test なんてのもあったんだった。ゲーム屋さんはほとんどテストコードを書かないので（職場にもよると思うけれど，少なくとも僕の所では，過去に一行も書いた例が無い），この辺りは自主的に調べてみなければと思っている。
http://boost.org/libs/test/doc/index.htm
結局，なんだかんだでほとんど重要な変更だったのかもしれない。うう，調べるの大変だ……。
なにげに tvmet の 0.5.0 がリリースされているので，これもバージョンアップしておこう。
ただしこちらは，さほど目立った変化は見られない。最近は STL への対応とソースコードのリファインが主な更新内容となっているようだ。そろそろ 1.0.0 になってもよさそうなものだけれど……。
2002-10-15
最近，データベース方面で密かに暗躍している。 developerWorks やら @IT やらを無節操に読み漁り，今さら付け焼き刃で知識を得ようと必死になっている様は，なんだか少し滑稽ですらあるように思える。一体いつから IT 屋さんの真似事なんてするようになったんだろう……。今さら他の業種で食って行こうなんてのは無理な話なんで，もっと特化された知識を身に付けていくべきだと思うんだけれど，どうしても中途半端な役回りに引き込まれてしまう性分であるようだ。
http://www.atmarkit.co.jp/flinux/rensai/postgres01/postgres0...
http://www-6.ibm.com/jp/developerworks/xml/001215/j_xml-matt...
アセットの管理やデータの保持に RDBMS を利用する，なんてのはごく基本的な方法論のように思えるけども，業種の性質によるものなのか，なかなかそういったメソッドを導入しているケースは少ないように思える。
http://www.geocrawler.com/mail/msg.php3?msg_id=6488502&list=...
まあこれは魅せられてしまった人の例だけれど……，プログラミング・インタフェースの手堅さや（もうパーサを書く必要は無いんですよ！），拡張性の良さ，運用面での安定性など，利点はいくらでも挙げることができると思う。長い歴史をかけて洗練されたシステムだけに，既存の方法論や優れたツール群（MS Access/VB で既に感動ものだ）を使いまわすことができる点にも注目したい。
http://www.ensemblestudios.com/openjournal4/story/marselas01...
何度もネタにしている Ensemble Studios (Age of Empires II) の例。 Alienbrain や FileMaker などの "COTS" (Completely Off The Shelf) − つまり「完全に出来合い状態」な選択肢をすべて却下し，多大なコストを費やしてまで独自のワークフローを構築しようと考えたその動機とはいかなるものなのだろうか。
結局のところ，既存のツールで管理を行ったとしても，製作用ツール (Max, Photoshop, etc...) やゲーム固有のツール／コンバータ／フォーマットとの統合を行おうとすると，やはり相当なコストが必要とされるわけで，それと導入コスト（実はこれが侮れない……）を総計すると，必ずしも "off the shelf" なソリューションが優れているとは言えなくなってしまう，という事実が背景にあるようだ。
しかし例えば， Macromedia Flash のようなオーサリング環境（プラットフォームと言ってしまっていいかもしれない）が極度に進化して，すべてのコンテンツの作成が画一化されたフレームワークの中で完結されるような時代が来たとしたら，独自のアセット管理がどうのこうの……なんて考える余地も無くなってしまうかもしれない。まあ，そんな理想的な環境が完成されることはまず無いだろうけども，あながち絶対無いとは言い切れないような気がするんだよな。
2002-10-16
なぜか泊まり。今週はもう一回泊まる予定。どうなるかは週末次第だ。
GDAlgorithms より "Cooperative Multiprocessing that yeilds" 。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
最近，グラフィック関連の話題を追いかけるのに疲れてしまったので，こういったシステムの根本部分に関連する話題を好んで読んでいるような気がする。内容は，マルチプロセッシングとそのスケジューリング方法についての話だ。「描画プロセスと挙動プロセスの分離」を焦点としつつ，まあいつもの調子で取りとめの無いダベりを繰り広げるスレッドとなっている。
個人的に意外だったのが，マルチスレッディングに関して否定的な意見を持っている人が非常に多いということだ。マルチスレッディングを嫌うその主な理由は，キャッシュが無駄に壊されるからダメ，とか，リソースを無駄に消費してまで導入する理由が分からない，とか，そんなとこ。しかし，キャッシュの破壊云々といった問題は，時分割でプリエンプティブなマルチスレッディングにおいてのみ発生する問題であって，一般的なマルチスレッディングに対しての問題点として挙げようってのは，ちょっと違うと思う。
Phil Wilkins 氏がその正確な言葉で示しているように，長期間に渡ってフレームをまたぐ処理を書く際にマルチスレッディングは非常に役に立つ。全体的な処理の流れを意識した読みやすいコードを書くことが可能となるのだ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9526887&list=...
さすがにコプロセサ（例えば PS2 の VPU）のコンテキストまで保存するとなるとオーバーワーク気味だけれど， CPU のコンテキストスイッチ程度ならば，それほど難しい所業でも無いはずだ。オブジェクトの挙動制御などに用途が限定されるのであれば，複雑な同期処理も不要になるだろうし，極力シンプルな機構で済ますことができる。
それにしても，同じ SCE America の R&D に所属しているはずの Ericson 氏と Wilkins 氏が GDAlgorithms 上で討論しているのは，何やら滑稽な図のように思える。 PS2 Linux によって PS2 のアーキテクチャが公然のものとなっていることにかこつけて，わりと開けっぴろげな議論を交わしていることがあるようだ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9506677&list=...
http://www.geocrawler.com/mail/msg.php3?msg_id=9506755&list=...
ここで何度か登場する「非時分割で非プリエンプティブ（協調型）なスレッド」のことを "fiber" と呼ぶことがあるらしい。
http://msdn.microsoft.com/library/default.asp?url=/library/e...
MS 方面のタームかもしれないけれど，いちいち「非プリエンプティブな……」云々などと言うのは通りが悪いから，こういった固有の名前を与えるのは良いことだと思う。それに "thread" に対してのアナロジーであるこの名前は，なかなかいいネーミングだと思う。そう言えば， String （文字列）を強化したから "Rope" ，なんて命名をした人たちも居たっけ……。
http://www.sgi.com/tech/stl/Rope.html
僕がつねづね必要だと主張しているのはこの "fiber" のことだ。逆に，完全な（プリエンプティブな）マルチスレッディングを使いたいと思う場面の方が少ないぐらいだ。 I/O などのウェイトを伴う処理を制御する場合には，任意のシステムイベントやタイムスライスで励起することのできる「完全な」マルチスレッディングが効果的に働くのだけれども，ゲームの挙動処理などにおいて自動的なスレッドの励起を使う必要性はほとんど感じられることが無い。
fiber に関して簡単に調べてみると，いくつかの記事を当てることができた。 Evan Jones 氏の "Implementing a Thread Library on Linux" は， fiber に相当するものを Linux 上で自前で組んでみる，という内容の記事だ。
http://www.eng.uwaterloo.ca/~ejones/software/threading.html
実装には UNIX 系のシステムコールである swapcontext を使用しているようだ。また，もう一つの実装方法として，標準Ｃライブラリにある setjmp/longjmp を使用する方法も挙げられている。
もう一つ。 "GNU Portable Threads Library" − 略称 "GNU Pth" は， setjmp/longjmp 等の比較的ポータブルな手段によってマルチスレッディングを実現した本格的なライブラリだ。
http://www.gnu.org/software/pth/
それにしても， setjmp/longjmp なんて，まず使う機会が無いから，いきなり言われてもどんなものなのか思い出すことができない。こんなもん使うな，と教え込まれた記憶さえある。
もしかしたら今後必要になることもあるかもしれない。それまでに復習しておこうと思う。
2002-10-17
マルチスレッドに関してはさておき，件のスレッドの本題は挙動処理と描画処理を分離させるということにあった。これを実現する仕組みはそれほど難しくない。挙動処理を一定のタイムスライスに分割し，現在の実時間と一致するまで反復を行い，最後に描画処理を発行する。この手順を延々と繰り返すだけだ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9519982&list=...
PC の場合は環境によってリフレッシュレートが異なるから，一定のゲームスピードを保つにはどうしても挙動と描画を分離させる必要がある。これに対して家庭用ゲーム機は常に一定のリフレッシュレート（例えば 59.94Hz）で動作するため，挙動と描画を同期させることを前提に設計することも可能だ。これはあまり良くない方法なんだけれど，いまだにこういった古来の流儀を通している所は少なくないように思える。
規定のステップ幅で処理を反復させるのではなく，前回のステップから現在までの時間差をダイレクトに入力する方法（つまり "ProcessPhysics(curtime - prevtime)" のようにする）も考えられるけれど，このような方法は挙動が不安定になりやすいことから一般的には用いられていない。純粋な物理シムとかならともかく，ゲームではステップ単位で状態遷移等を行うため，ステップ幅を変更されるとゲームとしての挙動が変質してしまう危険性があるからだ。
だからと言ってステップ幅を固定にしてしまっていいってわけでもない。ステップ幅を可変にしておくことには確かなメリットが存在するからだ。例えば，挙動と描画のステップ幅をできるだけ小さな公倍数を持つ値に設定すれば，動きのブレを軽減することが可能だろう。家庭用ゲーム機でも NTSC や PAL などのようにリフレッシュレートの異なる規格が複数存在するから，このような対応には大きな意味がある。グローバルに売り込むことを意識しているのならば，なおさらだ。
アクションゲームでは操作性の問題からできるだけ描画と挙動を同期させることが求められるけれど，ゲームのジャンルによっては必ずしもそうとは限らない。例えば群集を扱うゲームなどで CPU に極端な負荷がかかる場合では，挙動を 30Hz で駆動させて描画は 60Hz をキープさせる，なんて方法もあり得るだろう。挙動処理の途中に割り込みで描画を行うのだ。
このように挙動よりも描画の方が細かく処理される場合には，内挿を用いることによって実際の内部挙動よりも滑らかな動きを見せることができる。
http://www.geocrawler.com/mail/msg.php3?msg_id=9519992&list=...
Glenn Fiedler 氏によれば "Freedom Force" ではオブジェクトの種類によって異なる更新レートを適用しているそうだ。弾丸などのように特に高い精度を要求されるものについては 100Hz 程度の高い更新レートを適用し，その他の動きの遅いオブジェクトやゲーム的に重要でないオブジェクト（例えば破片など）については，その半分の 50Hz を適用する，といった感じだ。
また Tom Forsyth 氏によれば "StarTopia" の挙動処理はたったの 6Hz で動作しているとのことだ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9523206&list=...
ここまで冗長な更新レートでも，内挿によってある程度滑らかな動きを実現することが可能らしい。例えば箱庭系ゲームのように，インタラクティブな PC （プレイヤーキャラクタ）が存在しないシステムでは，操作と挙動の間に存在する遅延はそれほど重要な問題ではなくなるのかもしれない。 UI さえ十分なレスポンスを維持していれば，操作性に影響は出てこないのだろう。それにしても 6Hz ってのは極端な例だよな……。
内挿を用いることにはデメリットもある。内挿を行うにはサンプル点が２つ必要となるため，どうしても描画に余分な遅延が発生してしまうことだ。
http://www.geocrawler.com/mail/msg.php3?msg_id=9527065&list=...
内挿の代わりに外挿を用いることで遅延を無くす方法もあるけれど，一般に外挿は誤差が大きくなる性質があるため（特に見た目に不快／理不尽な影響を及ぼすことが多い）通常は用いられない。ただしネットワークゲームのように安定した更新間隔が保証されない場合には，外挿を用いた方が良い結果となることもある。内挿だとレイテンシが大きくなり過ぎて十分な操作性を与えられなくなる可能性があるからだ。
http://www.geocrawler.com/archives/3/4856/2002/9/350/9527126...
2002-10-18
週末はいつも騒がしい。なんとか明日の朝にまでは終えることができそうだけれど，夜間の作業は免れそうにない。
マルチスレッド関連で話題に上っていた Intel の "Hyper-Threading Technology" 。
http://cedar.intel.com/cgi-bin/ids.dll/content/content.jsp?c...
ここでは，従来のインストラクションレベルでの並列化技法（スーパースケーラ等）を ILP (Instruction-Level Parallelism) と分類しているのに対して，マルチスレッディングに特化された並列化技法のことを TLP (Thread-Level Parallelism) と呼び，新たな分類として加えようとしている。そしてこの TLP に対する Intel のアプローチが， Xeon プロセッサに搭載されているという "Hyper-Threading Technology" だ。
Hyper-Threading テクノロジは，簡単に言えば，１つのプロセサの中に仮想的なプロセサ（論理プロセサ）を複数持つと言う機能だ。基本的に演算ユニットや実行ユニットは１つしか持っていないんだけれど，そこに実行ステートを複数接続できるような仕組みになっている。
http://www.intel.com/technology/itj/2002/volume06issue01/art...
結局のところ，命令の実行を担当するユニット群は１つしか存在していないので，微小的な見方をすれば同時に動作するプロセスは１つでしかない。しかしこれをマイクロ命令単位で順次入れ替えることによって，同時に２つのプロセスが動作しているような状態を作り出すことができる。またこのとき，ストールの発生に応じてリソースの割り当てを変化させることによって，通常なら無駄に捨てられてしまう処理時間を効果的に活用することができる。一方がつっかえている間にもう一方を加速させるのだ。
実際に Hyper-Threading を導入したとしても，マルチスレッディングを効果的に使用していない限りは，通常のプロセサとまったく同じ速度で動作することになる。普通に PC を利用していて並列動作の恩恵が受けられる場面というのは，実はそう多く存在するわけではない。例えば Windows でも多数のカーネルプロセスが常駐しているものの，そのほとんどはシステムコールや特定の割り込みタイミングで励起されるプロセスであって，常時稼働しているってわけではない。 MPEG のエンコードと CG のレンダリングを同時に行いながらウェブのブラウジングをしたいとか，そんなヘビーなシチュエーションだったら効果が得られるかもしれないけれど，ごく日常的な作業においては 0.1 sec 間隔程度のタイムシェアリングで十分な並列感が得られるはずだ。
それでも Hyper-Threading が重視されているのは，機能の追加に対して必要とされるハードウェアリソースが比較的少ないためだ。実際， Xeon に Hyper-Threading を追加するのに必要とされた拡張は，全体のダイサイズの 5% 以下に過ぎなかったと言う。それにもう一方の並列化要素である ILP 関連の技術は，既に極度に複雑化された領域にまで達しており，この先しばらくは大幅な技術革新を見込めないかもしれない。それよりもまだ進展の余地がある TLP 方面に力を注ぎたいと考えるのは自然な流れだと思う。
なんにしろローエンド用途には売り込みにくい技術のようだ。 Xeon はハイエンドおよびサーバ用途向けの製品なので，このような並列化技術は比較的効果を発揮しやすいと思う。他にもいろいろと政治的な理由が絡んでいる面もあったりして，この手の技術がローエンド製品にまで降りてくるのにはしばらく時間がかかりそうな雰囲気だ。
http://search.impress.co.jp/cgi-bin/namazu.cgi?query=hyper-t...
2002-10-19
夜間を通しての作業も終わり，早朝の電車で帰宅。
始発付近の電車には独特のオーラがある。さわやかな朝を迎えたであろう人などは，その中ではマイノリティーに属する。みんな，うっすらと酒の残る息を吐いていたり，不健康そうに目をギラつかせていたり……そんなのばっかだ。
夜までずっと寝てた。起きたらもう真っ暗。どこに出かけるでもなしに，適当に牛丼食っておしまい。それで一日が終わった。
たぶん今日一日死んでいたとしても，あまり何も変わらなかったと思う。
2002-10-20
結局，今日も暗くなるまで寝ていた。さすがにこんなことばかりでは不毛だと思うのだけれど，特に用事が無いものだから，油断するとすぐにこんな生活に陥ってしまう。
来週は髪を刈りにいこう。とりあえず身近な目標からこなすんだ……。
ここ数日， Altova の "xmlspy" を試用してみている。
感触は上々。非常に使いやすく安定感のあるインタフェースだなと感じた。「拡張グリッドビュー」や「スキーマデザインビュー」の使い勝手は，テキスト入力を基本としたエディタでは到底得られないであろうレベルのものだ。
http://xmlspy.com/features_views.html
特にスキーマとの機能の統合が優れている。とりあえずスキーマのデザインさえ済ませてしまえば，あとのほとんどの機能が自動的にそのスキーマに従って動作するようになっている。
http://xmlspy.com/features_schema35.html
他にも，スキーマに基づいたバリデーションや，各種リポジトリとの統合機能，スクリプト言語による自動編集， XSL 変換， XPATH クエリへの対応， SOAP デバッガ， C++ コードの自動生成，等々……。とにかく驚くほど多彩な機能がこのひとつの環境に統合されている。このような優れたツールが存在するという事実が XML の存在意義を変化させるのではないかと思うほどだ。
コード生成や SOAP デバッガの搭載された Enterprise バージョンは $990 とちょっと値が張る。そこまでヘビーなことをしないならば Professional Edition で十分で，これは $390 程度。 XML の編集が主な用途でスキーマデザインも不要ならば Home Edition というのがあって，これなら $99 で済む。まあ妥当な価格設定かなあ……。
ただ気になるのは，結局のところ導入のお手軽さという面では Excel に到底かなわないということだ。 Excel ならば皆が使い慣れているため，形式さえ指定してしまえばあとは各個人がいいように管理してくれる。それを例えば xmlspy に置換したとして，同じように運営することができるのだろうか，という疑問が付きまとう。例えば「この……ここのカラムにある『攻撃力』って値をさあ，一括で 1.3 倍したいんだけどさあ，ねえ……」とか何かを望むような目つきで迫られたら，僕はどう答えたらいいんだか分からない。 Excel ならば，そんなのみんな自力でどうにかしてくれるのだ。
http://higeneko.netfirms.com/austin/diary/02/0910.htm
どうだろう……もう少し考えてみる必要があると思う。幸いなことに，考える時間はもうしばらくありそうだ。
2002-10-21
軽く小雨が降る中，眠い目をこすりながら出社。最近不規則な生活が多くて，ずれたサイクルを元に戻すのが難しい。たしかうちのチームにはコアタイムなんて取り決めがあったはずなんだけれど，イレギュラーなスケジューリングが続くうちにその効力をすっかり失ってしまったようだ。こんな時期だからこそ規律を取り戻したいと思いつつも，うっすらとつきまとう倦怠感が目覚めをいっそう悪くしているように思える。机に座ってキーを叩いていてもなお眠りから覚めることはなく，そのまま終業時刻まで半睡眠状態が続く。まったくもってゲーム脳だ。いろんなものが駄目になりつつあるらしい。
日中があまりにも不毛だったものだから，職場に泊まって継続勤務することにした。そうやっていつか目覚めることを期待しているんだけれど，なかなかその機会は訪れないようだ。
最近 Tom Forsyth 氏ってほんとヒマそうだよなあ……とか思いながら GDAlgorithms を読んでみている。投稿者別のポスト数の統計でも採ってみようかと思う。
これもまたちょっと前のネタから "triangulation in 3d" 。そういえば３Ｄの三角分割のちゃんとした資料って見たことないです……っていう Charles Bloom 氏のポストが発端。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
僕も以前，どうしても正確な三角分割が必要になったことがあった。そのときは，ツールで出力する前に三角分割することを義務付けてもらって，あとはコンバータ側に３頂点以上のポリゴンが来たら即 ASSERT とか，そんな脱力な方法で解決した記憶がある（それは解決してないんじゃないかという話も……）。
件のスレッドは，途中から Magic Software でお馴染みの Dave Eberly 氏が参加してビシっと決めてくれたおかげで，珍しくまとまった流れになっている。 Dave 氏の指摘によれば，３次元空間上の任意のポリゴンが三角分割可能であるかどうかという判定は NP 完全問題に属するそうだ。
http://www.geocrawler.com/archives/3/4856/2002/8/150/9307033...
NP 完全問題の厳密な定義はよく分からないんだけれど，ともかく，三角分割を一般的に扱おうとすると，とてつもなく難しくなるんだということが分かったので，それで良しとしよう……。
http://www.na.cse.nagoya-u.ac.jp/~reiji/lect/alg99/sec8-4.ht...
とは言っても，ほとんどの場合，僕らが必要としているのは「平面上に存在するポリゴンを三角分割する方法」であり，これは簡単なアルゴリズム（例に挙げられていた "ear clipping" 等）で対処することができる。そのポリゴンがひしゃげている（平面上に存在しない）と，ちょっとめんどくさいことになることもあるけれど，人の手で作られたデータである限りはほとんど問題無いだろうと思う。
2002-10-22
昨日から泊まり。今週もちょっと作業が多そうだ。「多そうに見えて，実はぜんぜん」ってパターンに希望を託す。
MS Office 関連の雑用が増えてきたので，これを機会に自動化に手を染めてみることにした。ともあればマンパワーで解決することも可能な問題だけれど，そればかりじゃ面白くないので，たまにはこういうこともやってみよう思ったわけだ。
こういう仕事は恐らく VB が適任なんだろうけど，最低限のこだわりとして Python を使ってみようと思う。 Python for Windows と win32com の組み合わせならば COM オートメーションを利用することができる。基本的には VBA 相当のことが実現可能になるはずだ。
http://www.python.org/windows/win32com/
こういうのをまさに題材とした本が存在する。
http://www.amazon.co.jp/exec/obidos/ASIN/1565926218
なにげに購入済みなんだけれど，家に置いてきてしまったので，結局，素の状態から調査開始。ううむ，積読してる場合じゃなかった……。
OLE/COM/ActiveX 関連はまったく前知識が無いので，ほとんど手探り状態。どの辺りを探ったら回答にたどりつけるのか分かったもんじゃない。いまいち勘が働かないみたいだ。
http://www.microsoft.com/japan/developer/library/default.asp...
しかも Win98 上で作業しているもんだから，たまに固まってみたり青くなってみたりしながら，おっかなびっくり作業を続けている。せめて OS 入れ換えておくんだったな……。
とりあえず目的を果たすことはできたものの，やたら処理が重くてもどかしい。オートメーションでオーバーヘッドが生じているのか，プロパティを覗くだけでもそうとう待たされているみたいだ。 Excel のセルを全走査しようものなら，とんでもなく悠長な思いをさせられることになる。まるで 8bit パソコンの画面書き換えを待っているような気分だ。
やはり素直に VB にしときゃあ良かったかなあ，と軽く後悔しつつも， Python と Windows のネイティブな結合に少し手応えを感じている。今までは cygwin 付属の Python ばかり使っていたものだから， Windows らしいことを何一つやっていなかったのだ。
たぶん今さらこんなとこに突っ込んじゃダメなんだと思うけれど…… "Dr.GUI" はノリがおかしい。
http://www.microsoft.com/japan/developer/library/dsmsdn/drgu...
http://www.microsoft.com/japan/developer/library/dsmsdn/msdn...
技術解説の部分だけを抜き出せば至極まともな記事なのに，要らんところで MS テイストを演出してしまっているのが天然っぽくて良い。なんていうか，こういうバタ臭い文章をネイティブで書ける人になりたいなあ，とか思った。
2002-10-23
調子に乗って Python + win32com と戯れてみている。ただ，インタフェースがコマンドプロンプトではどうにも寂しいので，フロントエンドとして Qt (PyQt) を使うことを考えてみた。 Qt ならば C++ ネイティブだから Python との親和性も良さそうだし，マルチプラットフォームへの対応も簡単そうだったからだ。
http://www.trolltech.com/products/qt/index.html
http://www.riverbankcomputing.co.uk/pyqt/index.php
さっそく Trolltech のサイトをいろいろと嗅ぎ回っていると，ふと次のような表記に遭遇した。
http://www.trolltech.com/developer/faqs/noncomm.html#Q7
要するに，インハウスツールに Qt Non-Commercial Edition を使用してはいけない，ということだ。他にも，アカデミックな用途に使用してはならない，などという表記を見つけることもできる。いかに教育用途と言えども，学校と生徒の間には金銭のやり取りが生じているわけで，それが "Non-Commercial" の示す意図にそぐわない，ということのようだ。とにかく，少しでもお金の匂いのする所には使ってはならない，という取り決めがなされているらしい。
KDE のオープンソース・コミュニティにおける成功を知っていると，この辺りの Trolltech の毅然とした態度には，むしろ違和感さえ覚えさせられるものがある。それが好きとか嫌いとかいう問題じゃないんだけれど，こんな微妙な線引きでうまくコントロールできているものだと，不思議に感心してしまう。
ともかく， Qt で行く線はもう無さそうだ。やっぱ Tk が適当に気楽でいいや……。
ただ， Linux Zaurus と "Zaurus Python" + PyQt の組み合わせは，ちょっと面白そうな匂いを感じる。
http://www.riverbankcomputing.co.uk/zaurus/index.php
http://sl.ezaurus.com/top.html
最近， iPaq や Zaurus SL シリーズなど， Linux を搭載した PDA が続々と（？）登場している。一応プログラマの端くれとしては，モバイルでプログラミングできるかどうかが気になるんだけれど，スペック上の問題から gcc を動かすのはとても無理のようだ。 Zaurus はかなりの部分が Java で駆動しているようなんだけれど， javac を動かすのも恐らく無理だろうと思う。
そんなわけで，モバイルプログラミングには Python みたいなスクリプト言語が適任なのではないかと思う。それで何をするってわけでもないんだけれど……，まあ，小回りを効かせるための PDA だからこそ，自らの用途に合わせた小回りの効くツールを作りたいと思うのは，比較的自然な流れとしてあり得るのではないかと思う。
ひょんなことから突然 PDA が欲しくなることもある。そんなときのための評価要素の一つとして心に留めておきたいと思う。
2002-10-24
少し前から，コナミの ZOE 2 (Anubis) のページに，最新のスクリーンショットが掲載されている。
http://www.konamijpn.com/products/zoe2/japanese/download.htm...
まず突っ込むべきは，その異様な解像度の高さにあると思う。
http://www.konamijpn.com/products/zoe2/japanese/pic/screensh...
1600x1200 の超高解像度スクリーンショット。もはや，これが実際の動作画面だとか言い張る気はまったく無いようだ。もっとも，実機で生成された画像には違いないだろうから，スクリーンショットと称するのは間違いではないかもしれない。プロモーション素材の制作手法としてはとても安上がりで効率的なものだし，許される限り綺麗な画像を見てもらいたいという制作者側の心境は理解できる。個人的には，色調や輝度の補正までしちゃったらアウトかなあ，とか，そういう基準で考えるようにしている。
上のスクリーンショットをよく見てみると，わずかにエッジが滑らかになっているのが分かる。実際にはこの 2x2 倍ぐらいの解像度でレンダリングを行い，縮小をかけてアンチエイリアシング効果を得ているようだ。すると，元画像は 3200x2400 ぐらいの超々高解像度ってことになるんだけれど，もちろん VRAM 4MB でメインメモリ 32MB の PS2 にそんな画像が収まるわけがなく，数回に分けてレンダリングを行うことになる。通常の解像度が 640x480 だとして（複雑な事情で，ゲーム中はさらに狭くなっていると思う）， 5x5 で 25 回レンダリングとか，そんな感じだろう。
エフェクトの厚みもさることながら，フレア処理がなかなかいい味を出していると思う。恐らく，フレア用のレイヤ（オフスクリーンバッファ）を別途に用意し，最後に合成をかけるような構造になっているのではないかと思う。
こんな感じかなあ……。 PS2 は VRAM が狭いから，フルスクリーンエフェクトを使うには何かを壊さなきゃならない。あっちを壊してあれを描いたら，こっちを壊してコピーして……みたいな感じで，ハノイの塔さながらの所業となる。
ともかく，フレア処理にはちょっと凝ったことをやっているようだ。上の推測（妄想？）はさておき，フレア系エフェクトを別系統で扱っていることには間違いないように思える。そうすることによって，セルアニメにおける透過光エフェクトのような，燦然として透明感の高い表現を可能にしているのではないかと思う。通常のパーティクルエフェクトではフレア部分が障害物の後ろに隠れてしまい，いまいちまぶしさが強調されない表現になってしまう。強烈な光でオブジェクトのエッジがぼやけるような感じを与えるには，どうしてもフルスクリーンでのポスト処理が必要になるのだ。
PS2 は，マシンパワー云々以前に，機能的に不足している要素が非常に多く，統一的なレンダリングパイプラインを構築することはもはや不可能だというのが一般的な見解だと思う。だから，進むべき方向性としては， VRAM をキャンバスに見立てて，画家が絵の具を重ね塗りたぐるような感じで，あり余るフィルを VRAM に叩きつける，みたいなノリになるのではないかと思う。例えば， "Anubis" のスクリーンショットに見られるようなパーティクル＋レイヤーエフェクトの乱れ撃ちとか， "ICO" に見られるような独特の雰囲気を演出する濃厚なポスト処理とか，そういうやつだ。
2002-10-25
急に寒くなってきたせいで，風邪をひいてしまったようだ。くしゃみと鼻水が止まらない。うう。
幸いなことに，仕事の方は案外すんなりと終了させることができた。風邪ひいた状態での泊まり作業は，なんとしても避けたかったのだ。
そんな感じで，終電前には帰宅。金曜の夜の電車は，本当にいつもよく混んでいる。
Python for Win32 でぼちぼちと遊んでみている。オートメーションがやたら遅い問題は early-bound （初期結合？）オートメーションを利用することで解決できるようだ。
http://www.oreilly.com/catalog/pythonwin32/chapter/ch12.html
Python for Win32 Extension に付属の "makepy" ツールを使うことで， early-bound を行うための Python スクリプトを COM タイプライブラリからを自動生成することができる。これをあらかじめ生成しておくだけで，あとは自動的に Dispatch インタフェースに対して early-bound が適用されるようになる。使う側がまったく意識せずに勝手に解決してくれるのは，なかなか便利な機構だ。
この辺りの機構に関する Windows の知識はほとんど無いに等しい状態なので，件の PythonWin 本に頼りきって勉強を進めている。実践を重視した内容の本なので，使い方を覚えるには手っ取り早くていいと思うんだけれど，この本に書いてある以上のことをやろうってなると，なかなか難しいことになると思う。個人的には，オートメーション以外の形で COM を利用したりとか， OCX を呼び出すとか，そこまで突っ込んでみたいんだけど……。
2002-10-26
寝まくり。おかげで体力は回復した。
飯がてら寄った本屋で Interface 誌を購入。今月号は文字コード特集だ。
http://www.cqpub.co.jp/interface/toku/2002/200212/if12_toku1...
最近ゆえあって多国語対応に興味が出てきていたので，これ幸いと買ってみることにした。内容はなかなか良さげ。少なくとも自分にとっては参考になる所があったと思う（まだ全部読んでないけど）。
例えば Python や Perl などはネイティブでの Unicode 対応が進んでいて，ほとんど意識することなく多国語対応を実現することができる。例えば Python で EUC の文字列を処理するには，
ってな感じで unicode 化しておくだけで，あとは普通の文字列として扱うことができる。 "text[1]" とかすると，ちゃんと "げ" が出てくるわけで，決して "0xB0" が出てきたりはしない。マルチバイト文字に非対応だった頃と比較すると，大した進化だと思う。
Unicode と言うと，なぜだか知らないけど，漠然とした悪い印象が付きまとう。たぶん TRON 方面のプロパガンダが刷り込まれてしまっているんだと思う。実際には MS Office や Win2K が UCS2 （Unicode 2.0 相当？）で動いていることからも分かるように，日常的な文章を扱う分においては Unicode でほとんど問題は発生しないようだ。もちろん，人名や特殊な固有名詞を扱う場合にはこの限りではなく，そういった分野では TRON コード等の研究が生かされることになるのだろうと思う。
http://www.horagai.com/www/moji/juki.htm
とりあえず，ごく普通のゲームに使われるようなテキストデータであれば Unicode でほぼ問題無くカバーすることができるようだ。漢字だけの問題ならともかくとして，ドイツ語やフランス語，スペイン語なんかも特殊コードがぐしゃぐしゃとひしめいている状態なので， Unicode 化を進めることで手っ取り早く解決してしまいたい。意外とここら辺のインフラが抜けているんだ……。
Python for Win32 の次なる野望として Windows MediaPlayer Control とか DirectShow に手を出してみたものの，敢え無く撃沈。 WMP はさておき， DirectShow の方は普通に CoCreateInstance して QueryInterface すればインタフェースを引き出せるかと思ったんだけれど，どうもうまくいってくれない。
http://www.microsoft.com/japan/msdn/library/default.asp?url=...
うう，だめかもだめかも……。ムービーと同期を取るためのツールをちょこっと作りたかっただけなんだけれど……。
どうにもうまくいくような気配がしないので，この件に関しては諦めようかと思う。 win32com の使用はオートメーション経由でのアクセスにとどめておいた方が賢明そうだ。
2002-10-27
GDAlgorithms より "tristripping shadow volumes" 。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
http://www.geocrawler.com/mail/thread.php3?subject=FW%3A+%5B...
スレッドタイトルからは，シャドウ用のステンシルボリュームをストリップ化する技術に関しての議論のように見えるけれど，実はそんな受け答えは最初の２ポストで終了しており（そんなに難しい話ではないためだ），その後は，ステンシル方式のシャドウに時折見られる "popping" 現象（要するに目障りなゴミのことだ）についての議論に切り替わっている。途中から NVIDIA の "Robust Stenciled Shadow" でおなじみの Cass Everitt 氏が参加していたりして，なかなか興味深い内容となっている。
で，とりあえずシャドウについては置いといて……個人的に注目したのが，スレッド内で話題に挙げられていた "Halo 2" の予告編ムービーだ。
http://www.bungie.net/site/1/site/halo/features/halo2_links....
このムービーが公開されたのは今月の始めのことで，その頃さかんに話題に挙げられていたような気がするんだけれど，いろいろあって（主にムービーのデカさから腰が引けて）未チェックだった。で，改めて見てみたんだけれど……これは凄い内容だ。
まず最初に，高画質版ではジャギーが確認できることから，正真正銘実機上での実働画像であることが推測できる。その辺りの事情は制作者のインタビュー記事からも確認できることだ。
http://www.bungie.net/perlbin/blam.pl?file=/site/1/news/stor...
キャラクタモデルは一体しか出てないものの，ステンシルボリュームを使った統合的なライティング／シャドウイング・モデルが実現されているのは素晴らしい。統合ライティングについては，これまでに実験的なデモがいくつか示されていたものの，現行のハードウェア上で動作し，しかもプロダクトレベルの品質のものを打ち出したのは，この予告編が初めてではないかと思う（DOOM III については……この予告編の比較対象としては相応しくないと思う）。
それ以外にも，とにかく現状で実現可能なエフェクトのてんこもりだ。まず目に付くのはバンプマッピングの利用法。「ただデコボコしてる」だけではなく，表現として非常に洗練されたレベルに達しているのが素晴らしいと思う。確信は持てないんだけれど，例えば下のスクリーンショットにおける金属面のザラつきのような，非常に微妙な質感表現の補強にも活用されているようだ。
http://www.bungie.net/images/site/halo/screenshots/scrn_111....
現状で PS2 しか触ったことのないようなデベロッパは，ノウハウのまったく無い状態からこのレベルを追いかけなきゃならないんだから，ちょっとぞっとしない話でもあると思う。
ライティングに関しては，他にも面白いことをいくつかやっているようだ。例えば，輝度の追加情報をアルファチャネルに埋め込むことで HDR もどきを実現している。これにより，超高輝度のピクセルからはグレアが発されるようになっている。このテクニックに関しては BUNGIE の Chris Butcher 氏が投稿の中で明らかにしている。
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgori...
これは "DOUBLE-STEAL" で使われていた手法とほぼ同等のものと考えていいだろう。 DS では見た目を強調するためにややディフォルメ気味の利用がなされていたけれど， Halo 2 のそれは比較的抑えめの効果となっており，カメラ効果としてより写実的なものになっていると思う。ドアから登場するシーンのグレアなんかは，ちょっと強すぎる感じもするけれど……このスクリーンショットなんかは非常に美しい効果を発揮していると思う。
http://www.bungie.net/images/site/halo/screenshots/scrn_115....
とは言っても，これ，グレア部分が認識できるほど出ているわけではないんで，それという確証は実は無い。でも……スペキュラ部分にグレア出てるよね？
それはともかくとして，このカットは予告編の中で僕が最も好きなシーンだ。もしジャギーが無かったら実機画像だとは考えなかったかもしれない。そのくらい表現が洗練されていると思う。
……だから，もし本当に見た目に自信のある画像を作り出すことができたのなら，ジャギーは残しておいた方がいい。そうじゃないと，疑いにかけられてしまうから。
どうでもいいことだけれど，この予告編でもう一つ気になったことがある。ムービー全体を支配するアメリカ的ヒロイズムの香りだ。何かこう，「アルマゲドン」や「インディペンデンス・デイ」のような，「俺が合衆国を救うっス〜！」的なオーラをひしひしと感じるのだ。
とは言ってもこれは決して悪くなくて，むしろ良い傾向だ。やっぱ肉食って育ってるやつらにしか出せないものってあるよな……とか，ムービーを見ながらぼんやりと考えていた。
2002-10-28
……で，本題の popping 現象についてだ（実はこれも本題じゃないんだけど……）。
http://www.geocrawler.com/mail/msg.php3?msg_id=9516011&list=...
Chris Butcher 氏はこの投稿の中で，件の Halo 2 予告編ムービーでも popping を完全に除去することはできなかった，と述べている。しかし，氏の言う "popping" が具体的にどの部分を指しているのかは，僕には分からなかった。件のムービーにおけるシャドウ処理は，まずいところなど何も無いぐらい上手く出来ているように見える。もしかしたら，同じような問題を抱えたことのある人なら，その欠陥を見抜くことができるのかもしれない。少なくとも今の僕にはそのスキルが無いようだ。
popping の正体を探る前に，昨今のゲームにおけるシャドウボリュームの生成方法について触れておかなければならない。
NVIDIA の "Robust Stenciled Shadow" デモでは，シャドウボリュームの生成に "possible silhouette" （「包括的シルエット」とでも呼ぶべきか……）を使用していた。この方法では，まず投影する側のモデルについてエッジをしらみ潰し的に検査し，シルエットとなる可能性のあるものを全て列挙する。そして，このエッジに沿って「押し出し」することでシャドウボリュームを生成する。これは聞くからに効率の悪そうな方法だけれど，明らかに正しい結果を導き出すことができる。 Cass Everitt 氏が主張するところの "Robust" な方法としては望ましいものと言えるかもしれない。
これに対して昨今のゲームでよく使われている手法は，もう少し簡略化されたものであるようだ。その方法とは……，モデルを構成する各頂点において法線ベクトルと光線ベクトルとの内積をとり，これがプラスであった場合には，この頂点を光線方向に無限遠まで突き飛ばす……，たったこれだけ。これにより，モデルの陰側の半身がスイープされたような形状の，いわゆる「尾っぽつき」のモデルが生成される。
この手法には，明らかにいくつかの利点がある。そのうち最も大きなものは，これが頂点シェーダのみで実現可能だと言うことだ。シルエット法にあったような複雑な CPU 処理はまったく介すこと無く，頂点シェーダとレンダリング・ステートを入れ換えてから同じモデルを飛ばすだけでステンシルを生成することができる。また，元のモデルデータを流用することから，別途にストリップ化などの配慮をする必要がないというのも，ひとつの利点だ（これで，本題であった「ボリュームのストリップ化は……」という話題は，たちまち終わってしまった）。
逆に弱点もいくつか考えられる。最も大きそうなのは，各頂点における法線ベクトルの定義が曖昧であることだ。頂点の法線ベクトルと光線ベクトルの内積が０である地点がシルエットのエッジ上にあるという前提は，決して成り立たない。だいたいそんな感じになるだろう，という前提のもとに成り立っている手法だと言える。このことが見た目に及ぼす影響は，モデリング方法やプログラム側の微調整によって大きく変化する余地があるため，実験してみないことには分からないものがあると思う。
さて，これでボリュームの生成は完了した。さっそくステンシルを使って影部分のマスキングを行うんだけれど，ここに来て一つのジレンマが発生する。スムースシェーディングが与える擬似的な連続性と，ステンシルエフェクトの離散性。この２つの間に存在する矛盾が，致命的な見た目の競合を引き起こすのだ。
2002-10-29
Chris Butcher 氏は，件の投稿の中で次のような指摘をしている。
現在主流となっているリアルタイム・レンダリング方式では，頂点間において数個の主要なパラメータを補間内挿することによって，サーフェスに擬似的な連続性を与えている。例えばグーロシェーディングや，キューブ環境マッピング等の技術がそれに当たる。
ところが，ステンシルを利用したエフェクト類は，これらの補正を完全に無視して，元のモデル形状に忠実な形で適用される。これは，ジオメトリが十分な密度で与えられている場合（つまり，ハイポリな状態）では深刻な問題にならないものの，密度が十分でない場合（ローポリな状態）では非常に目障りな効果を引き起こす可能性がある。これが Butcher 氏の指摘する "popping" 現象だ。
具体的な障害の例としては， Butcher 氏の指摘にあるような「シャドウ適用範囲の非連続的な変化」が挙げられる。この現象は，物体の陰の側のシャドウ適用範囲において確実に発生する。影のキワの部分（シルエット・エッジに当たる部分）において，ボリュームとモデルのポリゴンが平行をなすためだ。平行な状態からちょっとでも陰側に傾ければ，たちまちポリゴン全体が影の中へと入り込んでしまうだろう。
件のスレッドでは，この問題を改善する方法について，いくつかの提案がなされている。最も単純なものは，ライティング・モデルに手心を加えるという方法だ。
本来，シルエット・エッジの部分は光源の影響が限り無く０に近くなっているはずであって，これが真ならば「非連続的な変化」は発生し得ないことになる。しかしほとんどの場合，この前提は成り立たない。グーロシェーディングを使う限り，光源の影響が０になる地点は，必ず頂点ないしは辺の上に存在するからだ。
このことは結果的に，本来は陰で真っ暗であるはずの領域に微かな明るみを漏らすことになる。そうなれば当然，件の「非連続的な変化」が現れることになる。
この現象はつまり，本来陰である領域に明るみが漏れてしまっていることが原因なのだから，早めに光源の影響を打ち切ってしまえば問題を解消することができるかもしれない。 Butcher 氏は件の投稿の中で， DOOM III がこの系統のテクニックを使って popping を解消しているのではないかと予想している。ライティング・モデルの拡散項を余弦に対して非線形に割り当てて，輝度が急速にアンビエントへと近づくようにしてあるのではないか，ということだ。
2002-10-30
NVIDIA の Cem Cebenoyan 氏は，問題となっている "popping" 現象を防ぐ方法について， Cass Everitt 氏を含めた数人の NVIDIA 技術者と討議を行ったと報告している。
http://www.geocrawler.com/mail/msg.php3?msg_id=9516990&list=...
http://www.r3.nu/~cass/shadow_volumes/
この中で Everitt 氏は，「陰の側については２重にマスクされている場合のみを影として扱う」，という方法を提案している。
http://www.r3.nu/~cass/shadow_volumes/NonPoppingShadowVolume...
前述のように，ポリゴンの分割度が十分でない場合には，陰の部分に対してシャドウを適用すると，見た目に良くない影響が現れる。それだったら「陰の中の影」については省いてしまった方がいいかもしれない。ただし，「影の中にある陰の影」については，確実にマスキングを行うようにしなければならない。そうでないと，影よりも明るい陰が出てきてしまうかもしれないからだ。
話をまとめると，日向（ひなた）の部分と，影の中の陰の部分，この２つの部分にシャドウ適用範囲を絞りこめばいいようだ。この要求を満たすには，光源に対して背面を向けたポリゴンについて，ステンシルカウントが１以下の場合のみマスキングを行うようにすればいい。ちなみに，光源に対して前面を向けたポリゴンについては，通常のマスク処理（カウントが０の場合のみマスキング）を適用する。
Everitt 氏の用意した画像を見てみると，この処置によってかなり良好な効果が得られていることがわかる。
http://www.r3.nu/~cass/shadow_volumes/backfaces_popping.jpg
http://www.r3.nu/~cass/shadow_volumes/backfaces_nopopping.jp...
したたかに負荷を食いそうな処理だけれど，フィル量が増加するわけではないので， CPU やバーテクス・ユニットに余裕がある場合には問題にならないかもしれない。それらの理由も踏まえると，よりローポリな場合に向いた対処法だと言えると思う。
2002-10-31
Tom Forsyth 氏は，法線と光線の内積判定に手心を加えてみてはどうだろうか，と提案している。
http://www.geocrawler.com/mail/msg.php3?msg_id=9516223&list=...
http://www.geocrawler.com/mail/msg.php3?msg_id=9516916&list=...
頂点の押し出しを始める境界が，通常は０に設定されているのに対して，これを少し正の側にずらしてみる。ボリュームが少し内側に片寄るような感じかな。シャドウの影響範囲が多少縮まるんだろうけど，ちょっと変に歪んでしまいそうな気もする。形状への影響をイメージするのが難しい……。
この処置によってどの程度の軽減効果が得られるのか，僕にはよく分からない。ただ確実に言えるのは， Everitt 氏の方法とは違って，陰側のマスキングを確実に無くすものではないということだ。また Forsyth 氏自身も指摘しているように，調整すべき量はポリゴンの分割度によって異なってくるだろう。勘によって決めるしかないのだから，難しい調整になると思う。
まあ，多少ながらも popping を軽減する効果はあるだろうと思う。追加の負荷はほとんど要求されないのだから，おまじない程度に入れておくのがいいのかもしれない。
こんな感じで本スレッドの内容はおしまい。ステンシル方式のシャドウ処理でジオメトリの密度に依存する要素があるとは知らなかったから，個人的には参考になる内容だったと思う。ステンシルシャドウって頂点処理量が一気に増加するきらいがあるから，なるべくローポリ構成にするんだろうなあ，とか思っていたんだけれど，どうもそう単純に決めてかかるわけにもいかない事情が存在しているようだ。
ともあれ，今後のシャドウ処理のトレンドがステンシル方式であることには変わりがないように思える。特殊な条件のもとではシャドウマップ法などが用いられつつも，メインストリームはステンシルで行くことになるのだろうと思う。