１．担当ＰＭ

　竹内　郁雄 　　（東京大学大学院教授）

２．採択者氏名

３．プロジェクト管理組織

　株式会社オープンテクノロジーズ

　2,455,233円

５．テーマ名

　制約伝播を使った3次元モデルの構成 とストリームを使ったアニメーションの表現

６．関連Webサイト

　なし

７．プロジェクト概要

　以下は，久井君の提 案書の冒頭をかなり忠実にコピーするとともに，公式に発表されているテーマ概要をPMが織り込んだものである．提案書に彼の思いの丈が最もよく語られてい るからである．実際の開発計画ではバーチャルマリオネットの記述は消えているが，それでは本来の狙いがわかりにくくなるので，ここでは敢えてそれを含め た．

　プログラミングの教科書『計算機プログラムの構造と解釈』 (SICP) に載っている「図形言語」のアイディアを空間的・時間的に拡張し，さらに制約伝播のテクニックを導入することで，今までのものに比べ汎用性の高い3次元 CGアニメーションの処理系をつくることができると考えた．
　プリミティブな図形要素をそれぞれSchemeの手続きとして記述し，それらの手続きの合成によって複数の図形要素を結びつける．ここでは，この手続き 合成による図形の記述を図形言語と呼ぶ．3次元グラフィックスの描画ライブラリOpenGLを，Scheme処理系Gaucheから使うためのモジュール Gauche-glを使用して，3次元モデルを表す図形言語をつくる．
　すでにCAD/CAMなどの分野では，制約伝播を使って形状を表現する手法は使われているが，テレビゲームなどで用いられるインタラクティブなCGアニ メーションでは，デザインとシステム制作の分業の関係から，どうしても不正確な表現になりがちである．ゲーム制作の現場では，たとえば「歩く」という動作 を実現するときには，まず，キャラクターがその場で歩いているアニメーションシーケンスをデザイナが作成し，プログラマはそのアニメーションが不自然に見 えないような速さで，フィールド上をキャラクターのモデルが移動するようなプログラムを書く．この方法では，でこぼこの地面を人が正確に足で踏んで歩くな どの動作は実現が非常に難しい．これは，キャラクターが歩くというアニメーションをつくるときに，地面のでこぼこに対応できるような柔軟さがアニメーショ ンシーケンスデータに含められない，あるいは仮にできたとしても，オーサリングが非常に難しいからである．
　人形劇などで使われるマリオネット (糸操り人形) は，いろいろなタイプのものがあるが，通常7〜9本の糸で操作する．つまり，単純に考えれば9個の頂点座標を与えるだけなのであるが，関節のつながり具合 や各パーツに働く重力などの物理的な作用によって，まるで生きているかのような多彩な動きが可能になる．
　したがって，幾何的な関係や物理法則などを用いた「制約」を使って，3次元モデルの各部分の状態を決定することで，スピーディに，操作者の思いをリアル に反映できるアニメーションの制作が可能になると考えられる．
　すなわち，チェコの伝統芸能であるマリオネットをヒントにして，人間による操作に関してはできるだけ自由度を抑えながらも，多様な表現ができる処理系を つくり，ゲームなどインタラクティブなアートに応用できるものを開発する．少ない自由度で多彩な表現＝ヴァーチャル・マリオネットを目指す．
　このために，オブジェクト同士の位置関係などを，できるだけ人間が直感的に理解しやすい形で記述できるように，制約ネットワークを使った記法を導入す る．制約ネットワークを用いることで，数値的な詳細を内部に隠しながら，宣言的にオブジェクト間の関係を記述できると考えている．
　たとえばマリオネットのように，胴体と手先の位置を指定するだけで，ひじの曲げ具合などは自動的に計算できるようにする．図2.2.1 白木のマリオネットでは，点AとDは操作者によって与えられるが，BとCの位置や腕のパーツの角度などは，幾何的な関係や重力などの力学的な制約によって 決定される．
　アニメーションの各コマ (フレーム) を時刻と図形の対で表し，この対のリストとしてアニメーションシーケンスを表現する．このリストはストリームの形で実装する．ストリームは無限に長いリス トとして扱うことができるので，時間的な長さを持った映像の表現にはちょうどよい．ストリーム演算とは，ストリームとストリームをあわせて新しいストリー ムを作り出す操作なので，理論上はいくらでも重ねて複雑な処理を記述することができる．このストリームは，つなぎ合わせたり部分的に合成したり出来るとい う点で，映画のフィルムによく似た性質を持つものである．

　　図 2.2.1 白木のマリオネット（Kaiser作）
　

　ゲームの製作現場では，デザイナとプログラマのそれぞれの仕事がはっきりと 分かれすぎているため，どうしてもキャラクターの動きがぎくしゃくしてしまい，リアリティに欠けるものが多い．この問題を，制約ネットワークによる宣言的 なモデルの記述という形で解決する．こうすることによってデザイナとプログラマの新しい関係性を樹立したい．

８．採択理由

　制約解消エンジンをど うするのか，迂余曲折がありそうだし，久井君にもさらなる勉強が必要だと思われるが，マリオネットというパラメータの少ない3次元可動物体をモデルにした アイデアはとても面白い．これであれば，制約解消エンジンにあまり負担をかけずに独特の雰囲気をもったアニメーションが作成できそうだ．Schemeを ベースにしてすっきりした概念構成をとっているのもよい．これならエレガントでわかりやすい．

９．成果概要

　テーマ概要で述べたよ うな狙いを達成するために，ストリームと制約システムという概念を使って，3次元グラフィクスのアニメーションを表現する方法を考案した．また，それを実 現するために，プログラミング言語Schemeの処理系Gaucheを使って，次の3つのライブラリモジュールを実装した．これらを総称して MEPHISTOと呼ぶ (カリグラフフォントを使って書くべきだがここでは通常の英文フォントで書く)．

(1) 図形言語とストリームを使ったアニメーションモジュール
(2) ストリーム処理モジュール
(3) 制約システムモジュール

これらを組み合わせることで，3次元モデルのアニメーションを実現することができるようになった．また，制約システムとストリーム処理の各モジュールは， 単体でも使用することができる．
　MEPHISTOは今後，PCや特定のハードウェアのために最適化された，既存のフレームワークと共存できるようにするため，具体的な実装よりもデータ やアルゴリズムの最適な表現を見つけることを優先した．また，最終的にはScheme以外の言語でも実装ができるよう，言語に依存した部分はできるだけ隠 蔽できるようにした．さらに実用性を考え，ほかのフレームワークで用意されているようなアプリケーションの性質に依存する機能や，実行効率を低下させる可 能性のあるものは，極力含めないようにした．

(1) 図形言語
　MEPHISTOでは図形言語という図形の記述言語を使って，静的な画面構成を記述する．これは，画面を構成する静的な図形要素をペインタという単一の データ型を使って表現し，複数のペインタを組み合わせて新しいペインタを構成したり，ペインタに対してさまざまな加工を行なったりするペインタ演算を定義 することで，最終的な画面構成を記述できるようにしたものである．ペインタは再帰的な構造であるため，いくらでもペインタ演算を重ね合わせて複雑な要素を 構成することができる．

(2) ストリーム
　時刻nと描画手続きprocの対を使って，次のような形式でフレーム (アニメーションの1コマ) を表現する．
(n ．proc)
　さらに，アニメーションをフレームの無限ストリームで表現する．無限ストリームとは無限の長さを持つリストである．概念的には，次のような構造の無限リ ストとして扱うことができる．
((1 ．p1) (2 ．p2) (3 ．p3) ...)
　ストリームの特徴として，ある要素の値から次の要素の値を決定することができる．つまりこのの形式でいえば，pnはpn-1 の関数であってよい．ストリームはこの性質のため，入力に対してリアルタイムに反応するような，対話的なアニメーションを表現するのに適している．

(3) 制約システム
　人体のような関節を持つ3次元モデルを表現する際，一般的には，木構造を使ってモデルを表現することが多い．木構造は確かに合理的は表現方法ではある が，ノード間の関係が一方向的であるために制限も多い．そこでMEPHISTOでは従来の木構造を捨て，すべてのノードをフラットに扱い，ノード間の関係 は制約システムを使って記述することにした．そのモデルを特徴づける各種の方向ベクトルや，その他のモデル固有のパラメタも含ませることができる．
　木構造による表現と制約システムによる表現の概観を比較すると，図2.2.2 木構造による表現 (左) と本制約システムのグラフ表現 (右) のようになる．
　制約解消系は，図2.2.2のような構造をしており，図の中の矩形で表された制約と，線で表されたワイヤからなる．ワイヤはアプリケーションで使われる 変数に結びつけられ，制約によって値が設定されたり，値が消去されたりする．制約解消系の構成要素のそれぞれは，活性，非活性の2種類の状態をもち，制約 解消のプロセスでは，活性状態の構成要素のみが計算に使われる．一度計算に使われた制約は直ちに非活性状態となり，再び活性状態に戻るまでは計算に使われ ることがない．これにより，計算が無限ループに陥ることを原理的に避けることができ，また，高々制約の個数程度の計算しかしないことが保証される．

　 図 2.2.2 木構造による表現 ( 左 ) と本制約システムのグラフ表現 ( 右 )
　　
　また，モデルの状態を時刻と結びつける制約を設定すれば，簡単で宣言的にアニメーションが表現できる (詳細は省略する)．

　図形言語のペインタはSchemeの手続きを使って実装した．また，ペインタ演算も通常のScheme関数で実装した．Scheme の手続きはファーストクラスのデータ型であるため，特別なライブラリ等を用意する必要はなく，一般的な手続きの構成だけで実装できた．
　実際の画面描画の手続きとアニメーションは，OpenGLの関数を用いて実装した．
　MEPHISTOで使用するストリームライブラリは，Gaucheに付属のストリームライブラリモジュールをベースに，いくつかのユーティリティ関数を 追加して構成した．
　制約システムは，アプリケーションのコードに記述する制約の記述を冗長でなくし，また処理の内容を理解し易くするために，Schemeの健全なマクロを 多用して実装した．また，ワイヤや制約という概念を意識しなくてもアプリケーションの開発ができるような，簡単に利用できるユーティリティ関数群も実装し た．
　3次元モデルデータのフォーマットはWavefront OBJである．
　
　図2.2.3 平地を歩く人形と階段を歩く人形 に本システムを用いて作成した平地を歩く人形と階段を歩く人形のアニメのスナップショットを示す．脚の関節などに関する制約を記述しておいた上で，図で赤 く示されている「次に足を進める場所」をどんどん指示すれば制約システムが自動的に歩行アニメを作成してくれる．
　図2.2.4肩を組んでダンスを踊る人形 は脚だけではなく，2つの人形が肩を組んでダンスのステップを踏むアニメを本システムを用いた作成したスナップショットである．
　

　 図 2.2.3 平地を歩く人形と階段を歩く人形

　　　 図 2.2.4 肩を組んでダンスを踊る人形

１０． ＰＭ評価とコメント

久井君のオーディションでもブースト会議でもユニークであった．本物のマリオ ネットを用いて彼の考えていることを説明したからである (図2.2.5 ブースト会議でマリオネネットを実演．足元でマイクを持っているのはOBの川合秀実君)．紐で吊されたマリオネットが奥の深い世界であることは本物を見る とよくわかる．7〜9本の紐を指などでコントロールするだけで，人形に命が宿る様子は見ていて飽きない．非常に少ないパラメータでマリオネットが制御され ているところに，コンピュータ屋の感受性が働くのはよく理解できる．
久井君が，AbelsonとSussmanの有名な教科書にインスピレーションを受けてこのプロジェクトを発想したというのは，Lisp愛好家のPMに とって喜ばしいかぎりである．これによってゴチャゴチャになりそうなシステムの基底デザインがいきなり非常にすっきりした．それにしても，小さなソフトハ ウスに勤めている人に結構「隠れLisper」がいることに驚かされる．
　　　

　　　 図 2.2.5 ブースト会議でマリオネネットを実演．足元でマイクを持っているのは OB の 川合秀実君

　 この種のシステムで，一番問題になるのが制約解消系の設計と実装であるが，久井君の方針はなかなか現実的である．システム側に過大なことをさせず，ユーザ にある程度の，しかし現実的に許容可能な範囲の負荷をかけて制約を記述させる．また，厳密なエラーチェックはさぼっている．いろいろなアニメを作成する場 合それがどのくらいの問題を生み出すのかPMにはちょっと読めないが，簡単なデモを見るかぎり，うまく制約ライブラリを蓄積していけば，一般ユーザやデザ イナでも使えるレベルになるのではないかと思う．
　もう一つ良かったのは，いささかユニークな組成のシステムの汎用性を高めるために，プラットフォームになるべく依存しない作り方を進めたことである．つ まり，久井君は図形言語とストリームと制約を束ねた一つのCGアニメーション自動生成の，ある意味で抽象的な枠組を開発した．これをいろいろなプラット フォームに移植することはそれほど難しくないと思われる．性能が問題になる家庭用ゲーム機のことを考えるとそのような設計論をとったのは正解である．その うえで，具体的なプラットフォーム上での最適化を久井君は考えているようだが，これも実に正しいと思う．
　しかし，残念ながら，MEPHISTOの上で力学的制約が必要になるバーチャルマリオネットを実装するまでにはいたらなかった．これは開発計画の具体化 の段階で見切りをつけたということである．久井君の簡易な制約システムに真正直に力学を取り込むのは性能のことを考えると容易ではない．また衝突判定も， 単純なモデルでは対処しきれないところがある．いずれも抜本的なアイデアが必要である．しかし，初心はぜひ貫徹してほしい．
　久井君は勤めていた会社をプロジェクト期間中に退職して，次の新天地 (海外) に向けて充電しつつの開発となった．PMの見るところ，彼の力をもってすると，もっと早くいろいろな開発が進んだと思うのだが，そうもいかない事情があっ たのであろう．また，実装よりも設計に時間を要するプロジェクトであったとも言えよう．
　そういえば，久井君のプレゼンはいつもどこかピントが外れたようなところがあった．文章は非常にしっかりしているのに，誰にどのようなことを伝えるべき かのプレゼンのTPOをどこか見誤るような不思議な癖があると見た．このあたりは今後改善してほしい．
　途中で面談したとき，まだちょっとバグの残っている人形の動きを見せてもらった．非常に不思議なステップのダンスを踊っているように見え，バグが思いも かけぬ「創発」を生み出したように見えて，PMには大変面白く，こういうのをもっと突っ込もうよと言ったのであるが，バグのせいなので久井君は気に入らな かったようである．こういった遊び心もあっていいと思うのだが…．
　いずれにせよ，とても面白い成果が出ている．これをどのように世の中に出すのか，久井君にはぜひとももう一踏ん張りしてもらいたい．

。