2004-12-01
先日，ガジェット系ブログサイト Engadget において，ハッキングされた電光掲示板の話題が取り上げられていた。
http://www.engadget.com/entry/1234000533021514/
http://www.engadget.com/entry/1234000680021625/
http://www.nbc6.net/news/3946937/detail.html
この事件は，フロリダはウエストパームビーチの市長であるロイス・フランケル女史が，ノースディクシー・ハイウェーの再建設工事現場に電光掲示板を設置したことに発端している。この掲示板には，工事の遅延が交通に影響を与えていることに関して，市民に対しての同情を表した市長のメッセージが表示されていた。
これは一見ユーモラスな試みであるものの，冷めた目で見れば酷く牧歌的な行為であり，一部の人々の感情を逆撫でしかねない雰囲気もあると感じられる。実際にこのメッセージは，一人のハッカーを行動へと移させるのに十分な効力を持っていたようだ。ある日の朝の通勤時間帯に差し掛かる頃，この電光掲示板のメッセージは，ある「粗暴な反論」へと書き換えられてしまう。
しかも入念なことに，このハッカーはメッセージを書き換えた後に，操作ボックスに錠を掛けてから現場を立ち去っている。現場作業員達はメッセージを修正することができず，電源を切断することもできなかったため，このメッセージはしばらくの間放置されることになってしまう（しかし，彼らが本気でこのメッセージを修正しようと努力したかどうかは怪しいものがあるけれど……）。
他にも電光掲示板のハッキング例は色々と存在するようだ。
http://www.engadget.com/entry/7280753642028487/
http://sparkyb.net/thoughts/entry/60.html
実のところ，この手の単純な電光掲示板は，管理者の目を盗むことさえできれば，書き換えることはそう難しくないと予想される。活動的な若者にとってみれば，壁に落書きするのとそう違わない感覚かもしれない。もとより，今回の件に関しては，市民に対する歩み寄りの方法を誤ったフランケル女史に非があると言えなくもない。
2004-12-05
先週，帰宅中に道端で転んで負った擦り傷が，徐々に治り始めている。小指の背を擦ってしまったので， alt キーを押すときに少し痛む。それにしても，転んで擦り傷を負うことなど大人になってから滅多に経験するものでも無いので，相当にショックだった。いくら運動不足とは言え，何の変哲も無い歩道で転んでしまうのは，少し油断が過ぎていたと思う。打ち身が無かっただけでも幸いと言うべきか……。
先日，音楽ガジェット系ブログ "Music Thing" において，改造版 Speak & Spell のシミュレータ "Speak & Roil" が紹介されていた
http://musicthing.blogspot.com/2004/12/virtual-speak-spell-i...
http://www.roilnoise.com/flash%20stuff.htm
このシミュレータの元ネタであるところの "Speak & Spell" は， 70 年代末から 80 年代にかけて Texas Instruments 社から販売されていた子供向けの学習用玩具の一種だ。音声合成によって発音される単語の正しい綴りをキーボードから入力すれば正解という，単純な内容のクイズゲームではあるものの，当時としては斬新な技術を応用した製品であったことから好評を博したようだ。
http://www.99er.net/spkspell.html
http://www.datamath.org/Speech/SpeaknSpell1.htm
http://smithsonianchips.si.edu/texas/t_074.htm
また，この合成音声が非常にユニークな風味を持っていることから，今でも愛好家を中心として根強い人気が存在している。テクノミュージックの音ネタとして利用されることも多く，実際に Kraftwerk や Aphex Twin を始めとする著名アーティストが Speak & Spell をネタとして利用している。
そうした愛好家の中には，回路に改造を施して狂った音を出すことに熱情を注いでいる人も存在する。その「狂った音」を PC 上で再現したのが前述の "Speak & Roil" であるということだ。この手の改造文化の存在はビンテージシンセとは切り離せない関係にあるのだけれど，その情熱には毎度驚かされるというか……変態的な愛情表現が奥底に感じられる。
http://www.casperelectronics.com/old_default.htm
http://www.datamath.org/Story/CircuitBending.htm
http://www.wired.com/news/culture/0,1284,62894,00.html
「まともな」 Speak & Spell のシミュレータとしては， Jake Smith 氏の Flash シミュレータや，みやぼう氏の "Speak & Spell 1978 Simulator" 等が挙げられる。見た目と手軽さの点では前者が良くまとまっているものの，再現度の面では後者の方が優れているようだ。
http://www.miyavoux.com/download/sands/intro.html
Speak & Spell の開発経緯に関しては， IEEE Spectrum (1982/2) の記事 "Design case history: Speak & Spell learn to talk" に詳しい。
http://www.99er.net/cgi-bin/schlabo/dl.pl?snsdesign
技術的な背景や，種々の技術的・企画的判断，モニタリング結果の反映による改良など，製品が完成形に辿り着くまでの過程が詳しく語られており，非常に興味深い内容の記事となっている。
Speak & Spell の音声合成処理に用いられたチップである TMS5110 シリーズは， Speak & Spell 以外の製品にも応用されている。著名なところで言えば， Atari 社のアーケードゲーム "Gauntlet" の音声合成にもこのチップが用いられている。
http://www.dsplib.com/chips/tms5220.html
前出の記事によれば， TMS5110 で用いられている音声合成方式は LPC (Linear Predictive Coding) を基本としており，更にコーディング方法に工夫を凝らすことによって平均で 1.2 kbps 以下という非常に高い圧縮率を実現している（もちろん，相応に音質は悪い）。ここで用いられている LPC は，昨今の携帯電話等で用いられている CELP 符号化方式の原始的な実装の一種であり，音声合成方式としては今日でも一般的に用いられているものであるようだ。
http://en.wikipedia.org/wiki/Linear_predictive_coding
http://cnx.rice.edu/content/m10482/latest/
2004-12-07
メールを使って情報のやりとりを行う際に，その情報の重要性を分かりやすく伝えるには，どのような方法を用いるべきだろうかと考えることがある。メールの「重要度フラグ」を利用するか，あるいは題名に「【重要】」と入れておくか，あるいはメールの冒頭に「読まないと一生損します」とでも書いておくか，あるいは……。しかし，そのような小手先の工夫を持ち出したところで，やはり無視されてしまうことは多分にあるというのが実情だ。
先日，社販のキャンペーンを通知するメールが「【重要】」と銘打たれて送られてきたのを見て，なんともやるせない気持ちになってしまった。明らかに重要ではなく，しかも一切業務に関係していないメールが「重要」なのだから，こちらが改めて「重要」という言葉を添えたところで，その本来の意図が伝わることは期待できないだろうと思う。
重要な事実を確実に伝えるべく，繰り返し印象的な方法を使って伝達を行ったとしても，それがついぞ伝わることがなかったというのはよくある話だ。自分はそのような状況に出くわす度に， Scott Meyers 氏が "Effective C++" において持ち出していた逸話を思い出してしまう。
http://parris.josh.com.au/humour/work/PayAttention.shtml
残念ながら，氏の提示する「パブリック継承は "is-a"」というルールは，存外に伝わっていないことが多いと感じられる。
David Smallberg 氏は，この逸話に対して，よく似た別の話を挙げている。
http://www.aristeia.com/BookErrata/ec++2e-errata.html
どんなに簡単なことや重要なことであっても，それを確実に伝えることは難しい。伝わっていないことが判明した場合に，「あれだけ言ったのに何で知らないんだ！」と怒鳴り散らすのは，インパクトのある補足方法ではあるかもしれないけれど，あまり穏やかな解決法ではない。そんな気持ちを少しだけ抑えつけて，改めて相手に伝わるよう努力する配慮も必要だ。あるいは，情報の伝達を少なく済ませられるようなシステム作りが求められることもある。
2004-12-09
"ea spouse" 氏の訴えを発端としたゲーム産業の労働環境を問う議論は，まだその温度を保っている。先日は， EA 社のシニア・バイスプレジデントであるところの Rusty Rueff 氏が社員に対して釈明を行ったメールが外部に流出し，一部で話題になっていた。
http://www.joystiq.com/entry/1234000307022360/
http://www.gamespot.com/news/2004/12/03/news_6114405.html
内容としては，段階的な改善を行っていくという意思表明となっている。ただし，近日中の具体的な改善を確約するものではないため，メールを受け取る側としてみれば，なんとなく言い包められてしまったような感触があるのではないかと思う。いずれにせよ，一通の匿名投稿が社会問題化し，経営陣を動かすまでに至ったというのは，面白い状況ではあると思う。
そして，やはりというか， "Games from Within" の Noel Llopis 氏も，この件に関して反応を記している。
http://www.gamesfromwithin.com/articles/0412/000054.html
http://www.gamesfromwithin.com/articles/0412/000056.html
過去の記事 "Cowboy Coders and the Hero Programmer Culture" においてゲームプログラマーのヒロイズム主義的傾向を揶揄していた氏は，今回の記事 "All Work No Play, Makes Jack a Dull Game Developer" において，ゲーム産業が一般的に「修羅場」 (crunch) の存在を容認する傾向にあることを批判している。
氏の労働環境に関する意見には，何か頑なな信念のようなものが感じられる。もちろん，より良い製品の創出には相応の努力が必要であり，勤労の道徳が尊ばれるべきではあるものの，それを単なる根性や，無謀になることと取り違えて，無用な美化を行ってしまえば，労働環境は純粋に悪化し，生産性が損なわれると共に人材の流出が発生してしまうと考えられる。
2004-12-12
仕事の方は，穏やかながらも忙しい日々が続いている。スケジュールに様々な要素が絡むようになってきたために，先行きを予測することが難しくなってきていると感じられる。もう，当分の間はこのような状態が続きそうだ。
残っていた仕事を片付けるべく休日出社すると，職場にはほとんど誰も居ない状態だった。つい先月までは，フロアに必ず誰かが居るような状態が続いていたのだけれど，今月に入ってからは，誰も居なくなった職場を自分が戸締りすることも多くなっている。年末発売のタイトルや携帯機関連の仕事が一段落ついたということなのだろうと思う。
休日出勤して片付けた仕事は，リポジトリにコミットせずに帰宅する。わずかな変更ならばコミットしてしまうこともあるものの，できればこれも避けた方が良い。コミットしたソースに不具合があった場合に，コミットした本人が居ないと復旧に手間取ってしまうことがあるためだ。
よくあるミスは，新規作成したファイルのチェックイン忘れや，依存関係を持つファイルの片方だけをコミットしてしまうケースなどだ。コンパイルエラーの発生する不正なソースがコミットされているケースは非常に少ないものの，ごく稀に見かけることもある。そのほか，ビルドには成功するものの，ハングアップが頻発するようなバグが混入されていて問題となることもある。いずれにせよ，コミットしてから席を外さずにいれば影響を軽減することができる。席を外す事情があるならば，できるだけコミットは避けるべきだ。
もし，新入社員に対して最初に教える「作法」をいくつか挙げるとすれば，その中のひとつとして「席を外す前にソースをコミットしてはいけない」というものが含まれるかもしれない。もっとも，そのような場合には，バディ・システム（コミットを行う際に相方による確認を義務付ける仕組み）を用いるのが適切であると考えられる。
以前， Ned Batchelder 氏は，自身のブログにおいて，ビルドを破綻させたプログラマに対する「儀式」を紹介していた。
http://www.nedbatchelder.com/blog/200403.html#e20040325T0840...
http://www.bobcongdon.net/blog/2003/09/brozilla-is-staring-a...
「容疑者」の席には，ビルド破壊の象徴である "Brozilla" の人形が置かれる……容疑者のキュービクルを「危険 立入禁止」のテープで覆ってしまう……等々。奇妙な風習ではあるものの，単に修正して何事も無かったかのように済ませてしまうのではなく，見た目に分かる行為によってその「罪」を残しておこうというのは，面白い試みではあると思う。気分を害さない程度に遊びの要素を組み込んでみるのが良いのではないかと思う。
この話題から，個人的に何となく連想されたのは， "Linux Kernel Fuck Count" のページだった。
http://www.durak.org/sean/pubs/kfc/
http://www.vidarholen.net/contents/wordcount/
これらのページでは， Linux カーネルのソースコードに含まれる「ある特定の卑語」の数を集計している。グラフを観察してみると，これらの出現数はかなりランダムな増加を経ていることが分かる。ただし，「１行辺りの出現率」の方を見てみると，これが一定の値へと収束する傾向にあることが分かり，なかなか興味深い。現在の stable バージョンである 2.6.9 の時点では "crap" が最も出現率の高い卑語となっているようだ。腐ったものを表す一般的な表現として用いられているのだろうと思う。
自分の職場では，ソースコードに卑語や攻撃的な単語が混ざることは（ほとんど）無い。ただし，マスターアップの済んだソースコードに対して "TODO" や "FIXME" で grep をかけてみると，結構な数が検出されるのが少し恐ろしくもある。願わくば，それらが不具合や必須仕様に関するコメントではなく，「余力があれば」の類であってほしいと思うのだけれど……。
2004-12-13
前出の Bob Congdon 氏の Brozilla に関する記事では，余談として，大規模ソフトウェアプロジェクトにおけるリファクタリングの難しさについて触れられている。
http://www.bobcongdon.net/blog/2003/09/brozilla-is-staring-a...
ここで Congdon 氏は，その難しさを，ボストンで現在も続けられている大規模建設プロジェクト "Big Dig" になぞらえて表現している。
"Big Dig" は，ボストン市内を走る高架道路を地下通路化するという都市改造プロジェクトだ。 1991 年に着工して以来， 10 年余が経過した現在も工事が続けられている。 2004 年末の時点で進行度は 95% ほどであり， 2005 年内にはすべての工事が完了する予定となっている。
http://en.wikipedia.org/wiki/Big_Dig
Big Dig プロジェクトが市民の注目を集めている理由には，その規模の大きさもさることながら，いつまでも膨らみ続ける費用にも一因がある。着工当時の見積もりは総額で 58 億ドルほどであったのが，年月を追うごとに膨らみ続け， 2003 年末の時点で総額は当初の予想を遥かに上回る 146 億ドルにも達してしまっている。これは，アメリカの歴史の中で最も高額な高速道路プロジェクトであるとのことだ。
http://www.tokyochuo.net/news/press/2004/11_08/press_01.html
Big Dig の建設費用が膨らみ続けた理由には様々な要因が挙げられるものの，技術的な問題に着目した場合にまず指摘されるのは，既存のシステムを稼動させながらも建設を行わなくてはならないという制約に伴う難しさだ。例えば，既存の高架道路を生かしながらも，その下にトンネルを掘ったり，既存の地下鉄を生かしながらも，それを横切るようにトンネルを掘るなど，様々な難題が提示されてきた。これらの問題を解決するには "slurry wall" と呼ばれる特殊な工法を駆使する必要がある。何も無い土地に地下道を建設するのとは違って，既存の構造物を崩壊から保護するために多大な労力が払われたということだ。
これは，ソフトウェアプロジェクトのリファクタリングにも似たことが言えると Congdon 氏は指摘する。単独で行うプロジェクトでもない限りは，リファクタリングを行うにあたって現状のシステムを破綻させてはならない。さもなければ，自分以外の全員に多大な迷惑をかけてしまう。たとえ少なくない労力を費やすことになってしまうとしても，既存のシステムの動作を保証しつつもコードの変更を可能にするような手法を用いなければならない。
この場合に，既存のシステムを崩壊から保護する "slurry wall" となってくれるのは，十分な量のテストコードの存在だ。テストコードを実行することによって，リファクタリングが既存のシステムを破綻させていないことを保証することができる。逆に言えば，テスト手法が確立されていればこそ，リファクタリングは可能であると言うことができる。
自分が，いまだにリファクタリングが不得手である理由は，ここにあると考えている。小規模なモジュールに対する単体テストならまだしも，高度に複雑化したゲームシステムに対して包括的にテストを行う手法を，まだ自分は知らない。ゆえに，安全にリファクタリングを行う手法も知りえないと考えられる。
今の自分にとって，リファクタリングは大きなリスクを伴う手法だ。喩えるならば，天井を支える骨組みを作らずにトンネルを掘り進めるような感覚かもしれない。調子に乗って掘り進めば，いつか穴は崩壊して，自分は生き埋めになってしまうことだろうと思う。
2004-12-15
最近はなかなか暇が無いのだけれど，隙を見ては Micron と FL Studio をいじってみている。せっかく購入したのだから，やはり使わないと勿体ない。操作にはだいぶ慣れてきたものの，十分に使いこなすまでには至っていない。どちらも使いこなすとなると相当に奥の深いツールであると思う。しばらくの間はこれで遊んでいられそうだ。
FL Studio を導入してからは， VST プラグインを利用することが可能となったため，フリーのプラグインを探してきては，色々と試してみている。この辺りは，フォトショップや CG ツールのプラグインを拾ってきては試してみる感覚に近いかもしれない。多くは一度試してから捨ててしまうようなものばかりなのだけれど，たまに見つかる「お宝」を探し求める行為自体が楽しくて，ついつい色々と物色してしまう。
最近見つけた中でも一番のお気に入りは， E-Phonic の "LOFI" エフェクターだ。
http://www.e-phonic.com/vstplugins/lofi.html
このエフェクターは，音に歪みを加える各種のエフェクトを集約したものだ。ピッチシフト，リサンプリング（デシメーター），ロー／バンド／ハイパスフィルタ，ディストーションの，計４つのエフェクトが備えられている。これを繋いで値を適当に設定してやるだけで，ゴリゴリと音に歪みが加えられる。 Micron の音にはやや上品なきらいがあるので，この手のエフェクトで音を歪ませてやると，本来の音とは違った雰囲気が得られて面白い。特に，リサンプリングによって生じるツンツンとしたエイリアスノイズには独特の味わいがあって良い。
http://www.radiumsoftware.com/files/micron2.mp3
E-Phonic のサイトでは， "LOFI" の他にも様々な VST プラグインがフリーで配布されている。いずれも非常にクオリティが高く，かつ個性的なプラグインばかりで面白い。
http://www.e-phonic.com/vstplugins/
FL Studio にはアナログモデリングのドラム音源が搭載されていないため（"DumSynth" が付属しているものの，体験版のため保存ができない），バーチャル・ドラムマシンであるところの "Drumatic" などは，非常に実用的だ。ちなみに， Drumatic の最新版である "Drumatic 3" は， FL Studio との組み合わせでは正常に動作しなかった。残念……。
こうして VST プラグインなどに触れていると，本当にバーチャル音源だけで何でも出来るようになってしまったのだなという感慨が湧いてくる。 FL Studio と各種プラグインの組み合わせだけでも，相当に面白いことができそうだ。ストパフォーマンスの良さを考慮すると，なかなかに優れた組み合わせなのではないかと思う。
2004-12-21
先週末に購入した MGS3 を，三晩かけてやっとクリアした。クリアタイムは約 16 時間。これでも結構急いでプレイしたつもりなので，じっくりと遊んでいたらもう少し時間がかかったことだろうと思う。見逃した要素も多く残されているようなので，また年末辺りに２週目をプレイすることになるかもしれないと考えている（予定通りに休みが取れればの話だけれど……）。
MGS3 を最後までプレイした結果，最も印象に強く残っていたのは，映像の美しさと，アイデアの奇抜さだった。
映像に関しては，単純に造形や動きが優れているだけでなく，激しく燃え盛る炎や，辺り一面に広がる花畑などのように，今までに見たことの無いような表現を作り出している点が，非常に秀逸であると感じられた。今作の物語の流れには緩急が激しく存在するのだけれど，その「急」の部分には恐ろしいほどの労力が集中的に注ぎ込まれていると感じる。中には本当に「映画を超えた」と感じさせる瞬間もあり，それが非常に強く印象に残っている。
アイデアの奇抜さに関しては， MGS シリーズでは半ば定番となりつつあるものだ。今回も秀逸なアイデアが数多く盛り込まれており，非常に楽しい。こういった要素は，ぜひ，新鮮なうちに多くの人に楽しんでもらいたいと思う。何気ない会話や雑誌の記事などからネタバレしてしまった後では，せっかくの楽しみも半減してしまうためだ。
こういったアイデアの中には，制作者の側から見た場合に，決して実現が容易でないものも存在する。そのようなアイデアに対して一定の労力を割くというのは，非常に勇気の要ることだと思う。特に，その面白さの裏付けが理論的なものではなく，主として感覚に訴えるようなものである場合，労力を割くことは余程難しくなると考えられる。
しかし， MGS3 やその他のシリーズ作品をプレイしていると，非常に突飛なネタや，「面白いのは分かるけど，ゲームとしてまとめるのは難しい」と感じられるようなネタと出くわすことも，決して珍しくない。今作でも，例えばバイク周辺の進行には度肝を抜かされるものがあった。これを形にする作業には相当の苦労があったのではないだろうかと思われる。また，「ガイ・サベージ」なども驚愕した点として挙げられる。自分らにはまず絶対に真似できないであろうことを実現してしまっているという点に驚きを感じる。
物語的な部分で印象に強く残っているのは，敵ボスキャラであるところの「コブラ部隊」の面々のキャラクターの強さだ。 MGS シリーズには，これまでにも数多くの強烈なキャラクターが登場してきたものの，その中でも今回の「コブラ部隊」は白眉の存在だ。少年マンガやヒーロー特撮のノリを上手く取り込んでいると感じられる。また，若きオセロットの活躍も見逃せない。どこか微妙に憎めない性格の好悪役をよく演じており，カットシーンに登場する度に色々と楽しませてくれる。
相変わらず物語の内容は非常に難解であり，やはり，自分には理解に苦しむ点が少なくなかったと感じられる。スパイものであるということから，どうしても陰謀論的な展開になってしまうのかもしれないけれど，そこはもう少し簡単な構図に直して楽しませて欲しいと思うことがあった。しかし，その歪みっぷりも本シリーズの「味」であると考えるならば，良い意味で期待を裏切らない展開ではあったと思う。
一言で総括すると，今回の MGS は「観て楽しむゲーム」としての進化を一層遂げたものであったと感じられる。前述の要素に加えて，映画を意識したと思われる演出が増やされている点も，そう感じる一因となっているのではないかと思う。これまでの基準からすればＮＧであろう暴力表現や感情表現が取り入れられているのも，そのような「観る楽しみ」の強化に繋がっていると考えられる。
2004-12-23
一般にモーションキャプチャーの技術は，現実世界のアクターの動きを「録画」し，コンピュータ上で「再生」するための仕組みとして用いられている。その技術の内容とは，収録時の誤差を減らすためのものであったり，アクターの動きを制約しないためのものであったり，収録したデータをアプリケーションのために加工するものであったりする。
収録時の技術に関しては，これまでにも様々な改良が行われおり，現在もその改良は続けられている。他方で，収録したデータを加工する技術に関しては，まだ発展の余地が大いに残されており，今後も様々な手法が登場してくるものと予想される。
その一例として挙げられるのが， Lucas Kovar 氏の行っている一連の研究だ。
http://www.cs.wisc.edu/~kovar/projects.html
Kovar 氏は 2002 年頃からモーションキャプチャーデータの加工に関する研究を行っている。それらの中でも，特にモーションの分解と再合成に関する研究は非常に面白く，また実用性を大いに予感させるものとなっている。
まず， 2002 年の SIGGRAPH で発表された "Motion Graphs" は，一連のモーションデータの中から互いに接続可能な「節点」を検出し，そのグラフ構造を自動的に生成するというものだった。
http://www.cs.wisc.edu/graphics/Gallery/Kovar/MoGraphs/
この手法から生成されたグラフ構造を辿ることによって，収録されたデータを忠実かつ連続的に再生しながらも，ある程度の自由度を持つことが可能になる。デモの映像では，ユーザの指定した経路の上を，収録されたリアルなモーションを繋ぎつつ辿るという応用例が紹介されている。
2003 年の Interactive 3D Graphics で発表された "Snap-Together Motion" は， Motion Graphs の手法をもう一歩進めたものだ。
http://www.cs.wisc.edu/graphics/Gallery/Kovar/SnapTogetherMo...
Snap-Together Motion の手法も，基本的にはモーションの接続を表すグラフ構造を生成するものだ。ただしこの手法では，特定のポーズ（「ハブノード」と呼ばれる）に繋がるようなモーション群へと分解が行われる。例えばゲームなどでも，特定のポーズ（待機ポーズ等）をハブとして，始めと終わりをそこに繋げるような形でモーションのバリエーションを作成することが多い。 Snap-Together Motion は，一連のモーションキャプチャーデータを分解することによって，そのバリエーションを自動的に生成するものだと考えることができる。この仕組みが理想的な形で動けば，非常に安いコスト（アクターに同じ動きを数分間繰り返してもらうだけ）で，大量かつリアルなモーションのバリエーションを作り出すことが可能となる。
2004-12-25
最後に，今年の SIGGRAPH で発表されたのは， "Automated Extraction and Parameterization of Motions in Large Data Sets" （大規模データセットからのモーションの自動抽出とパラメータ化）題された論文だった。
http://www.cs.wisc.edu/graphics/Gallery/Kovar/ParamMotion/
前出の二つの論文がモーションの自動分解とグラフ構造の構築を主題としているのに対して，この論文は「モーションの検索」を主題としている。例えば，アクターが延々と蹴りを繰り返しているモーションデータの中から，代表的な蹴りのモーションを切り出しておいて，それをクエリとして検索を行うと，その「代表的な蹴り」に類似したモーションが自動的に抽出される。
ここで重要なのは，従来の手法では数値的に類似した動きしか検出することができなかったのが，この手法では「見た目で似通っているもの」が検出できるようになっているという点だ。例えば上の画像では，ハイキック（上）をクエリとして検索した結果，ジャンプキック（下）が類似モーションとして検出されている。数値的に見れば姿勢もタイミングもかなり異なっているはずであるのに，ちゃんと検出されているのが非常に面白い。他にも，ジャンプをクエリとして検索を行えば，横跳びやバックジャンプも検出されるし，「腰の高さにあるものを手に取るモーション」をクエリとして検索を行えば，「頭の高さにあるものを手に取るモーション」も検出される。
更にこの論文では，摘出された類似モーションを合成する方法に関しても触れられている。例えば，ハイキックとミドルキックを適切に合成すれば，「胸の高さを蹴る」モーションを生成することができるし，ジャンプと横跳びを合成すれば，「斜め前にジャンプする」モーションを生成することができる。論文中ではこれを「関節の位置や姿勢をパラメータとしてモーションの合成を行う手法」として述べられているため，「パラメータ化」 (parameterization) という言葉が用いられている。
ここで，ユーザによってパラメータが指定されたならば，そのパラメータから各モーションの合成比率を算出しなければならない。しかし，合成比率からパラメータを算出することは容易であるものの，パラメータから合成比率を逆算することは一般に容易でない（ＦＫとＩＫの関係に似ている）。これは，モーション合成の分野における技術的課題の一つであり，既に種々の研究が行われている。例えば，論文中でも参考文献として挙げられている Charles Rose 氏らの一連の研究などは，ＩＫの一般的な解決法としても興味深いものだ。
http://research.microsoft.com/~rose/publications.htm
以上のような技術が揃うことによって，大規模なモーションキャプチャーデータを半自動的に分解し，演出上の意図に合わせて合成・再構築を行うことが可能になる。オーサリング作業に必要とされるコストが比較的低く，かつ，抽出したデータを柔軟に扱うことのできる点が大きな魅力だ。また，検索・合成処理が比較的高速である点も見逃せない。当面の応用はオフラインでのモーション合成に限定されるとしても，将来的にはリアルタイムに合成を行うことも可能になると予想される。
2004-12-27
先日， "Games from Within" の Noel Llopis 氏が，先月終わりから今月初めにかけてサンフランシスコにおいて開催されたゲーム技術系イベント "GameTech" のレポートを記していた。
http://www.gamesfromwithin.com/articles/0412/000057.html
http://www.gamesfromwithin.com/articles/0412/000059.html
４日間あったイベントの内，前半の２日間は "Creating Believable Characters Seminar" と題されたセミナーに費やされている。どうやら Lucas Kovar 氏も講師として参加していたようだ。 Llopis 氏が様々な感想を述べている。
この話題の中で個人的に興味を引かれたのは，英 NaturalMotions 社のモーション自動生成技術だった。
http://www.comtec.daikin.co.jp/endorphin/
例えば， NaturalMotions 社の主力製品 "endorphin" は，キャラクターモーションを自動的に生成する技術を応用した製品の一種だ。その技術の詳細に関しては公開された情報が存在しないものの，単純な人体物理モデル（いわゆるラグドール）に生体力学とＡＩの要素を付加したものであることが推測される。
実際に endorphin を利用して生成されたモーションを見てみるには， SIGGRAPH 2003 において公開されたデモ映像を参照してみるのが分かりやすくて良いと思う。
http://www.naturalmotion2.com/files/NM_Siggraph03_Show_Reel....
"Ragdolls are dead!" のキャッチコピーは印象的だ。ウェブサイト上の情報によれば，「鉄拳５」のムービーシーンの制作や，映画「ロード・オブ・ザ・リング 王の帰還」の制作などにおいて導入実績があるとのことだ。
endorphin において用いられているアプローチは，技術的に見れば非常に面白い試みではあると思う。ただし現段階では，受身的な動作しか扱うことができないという点が明らかな制限として指摘される。あくまでも「モーションキャプチャーによる収録が難しいスタント系のモーションを低コストで作成するツール」という位置付けであるようだ。するとやはり，現段階では「高等なラグドール」という認識が妥当であると考えられる。
自律的なモーションの自動生成に関しては， NaturalMotion 社も様々な模索を行っているようだ。同社ウェブサイトの "Technology" のページでは，その技術の一端を垣間見ることが出来る。
http://www.naturalmotion.com/pages/technology.htm
http://www.naturalmotion.com/files/simplewalkevolution.mpg
このページでは，遺伝的アルゴリズムの応用によってリアルな生体力学的モデルの二足歩行を実現する技術のデモが公開されている。この技術に関しては，下記の Discover 誌の記事も参考になる。
http://www.discover.com/issues/aug-03/departments/feattech/
個人的な意見としては，遺伝的アルゴリズム自体が非常に応用の難しい技術であることと，モーションの妥当性を評価する仕組みを遺伝的アルゴリズムに組み込むのが困難であることから，近い将来にこのような技術が実用化するとは考え難いものがある。それでも，人手に頼らないコスト追求型の技術としては，非常に興味深いアプローチではあると思う。
2004-12-28
NaturalMotion 社の自動モーション生成技術に関して調べている間に思い出したのだけれど，自分は遺伝的アルゴリズムに対して良い印象を持っていない。優れた解法の探索を棚上げにして，「遺伝」という仕組みの持つ神秘性に問題の解決を委ねてしまっているような印象があるためだ。
http://ja.wikipedia.org/wiki/%E9%81%BA%E4%BC%9D%E7%9A%84%E3%...
自分は遺伝的アルゴリズムや遺伝そのものに関して詳しく知っているわけではないので，ここから先は全くの素人意見になってしまうのだけれど……まず，遺伝の仕組み自体が，優れたものを生み出すための戦略ではないという点が引っ掛かってしまう。遺伝とは，多様性から環境への適応形質を得るための基本戦略であって，そこから優れた種が生まれるかどうかは，周囲の環境に拠るところが大きいと考えられる。
遺伝を基本メカニズムとした進化論に対を成す考え方として，「創造論」という論説が存在する。
http://ja.wikipedia.org/wiki/%E5%89%B5%E9%80%A0%E8%AB%96
もうひとつ，創造論に近い考え方を持った論説として "Intelligent Design" が存在する。
http://en.wikipedia.org/wiki/Intelligent_design
創造論は宗教的な観点から生み出された「疑似科学」であるけれど， Intelligent Design は，より科学的な思考に基づいた（少なくともそう主張されている）論説だ。人間のように複雑な生命体を進化の過程から生み出すことは不可能であり，その創造の過程には何らかの知性による働きかけが存在したはずであると主張されている。
先月号の Wired 誌では，この "Intelligent Design" に関する特集が組まれていた。日本ならば，単なるオカルトやトンデモとして片付けられそうなこの論説が，アメリカではそれなりに大きな影響力を持っているという点に驚かされた。
http://www.wired.com/wired/archive/12.10/evolution.html
この辺りの論争には，少し複雑な背景が存在するため，自分はあまり立ち入りたくないと思う。どちらの論説を信じるにせよ，ひとつ確実に言えることは，人間はそれほど優れた生物ではないということだ。進化論は完全な生物を生み出す必要が無かったのだろうし，創造を行った知性は自分ほど優れた分身を生み出そうとは思わなかったのだろうと思う。
例えば， Discoverty Institute の Bruce Chapman 氏の意見などは，安直ではあるけれど的を射ていると感じられる。
http://www.wired.com/wired/archive/12.12/rants.html
この辺りの話題に関して考えを巡らせていると，ドーキンスの「利己的な遺伝子」や「ミーム」が連想されてくる。
http://ja.wikipedia.org/wiki/%E5%88%A9%E5%B7%B1%E7%9A%84%E9%...
http://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%BC%E3%83%A0
「利己的な遺伝子」には以前から興味があるのだけれど，自分の中でオカルトとの線引きを行うことができなくなりそうな気がしているために，あまり深く足を踏み入れることができていない。恐らくドーキンスは科学的見地を持っていたものと考えられるものの，その周囲にはやはりオカルトの匂いが感じられる。遺伝的アルゴリズムに対して懐疑を抱いているのも，同じような警戒心によるものなのかもしれないと考えている。