2001年5月

[前月][次月][一覧]:[表紙][映画][King][BBS]


5/28 (Mon) メモリアルデー/Shrek

メモリアルデー。日本での終戦記念日と同様に、こちらでも戦争回顧気分が盛り上がる日だ。 日系人が多かったハワイでは、第2次世界大戦は決して「勝った戦争」ではない。 もうひとつの「二つの祖国」→ Nisei who served on Okinawa push for recognition


PDI/DreamworksのフルCGアニメーション "Shrek" を観てきた。 面白い。よく出来てる。映像だけでなく、脚本と演出が家族連れの観客向けに良く練ってある。 英語が苦手な妻でもストーリーが追えて楽しめたのだから。 スタッフが楽しんで作っている感じが伝わってくるのも良い。

CGでは困難とされていた人物の表現だが、世界感に融け込むようなスタイルを作っていて、 これはこれで(セル、クレイ、パペットなんかと並ぶ)別の表現方法として確立したな、という感じだ。 メインキャラクタの表情は相当作り込んであって、フォトリアリスティックでなくても 存在感のリアルさは表現できるんだ、という意地さえ感じる。 最初の方のシーケンスや、その他大勢的キャラクタのアニメーションにはぎこちないものがあったが、 それはリソースの問題だろうなあ (逆に言えば、例えフォトリアリスティックでない映像でも、 不自然なアニメーションは浮いてしまうということだ)。

5/23 (Tue) 忘忙/「一人屋台」方式

日記を書かないとなんか落ち着かない。かと言って、 自宅でPCに向かっている時間は全て開発に費してしまう。 やっぱりWebから更新できるようにして、ネタのメモ的にしてゆくしかないのだろうか。


妻に、「あんたは酉年だからね、三歩歩いたら忘れるのよ」と言われるほど、 よく物を忘れる。朝出る時に妻に頼まれたことは、会社で席に着くころにはどこかに行っている。 すっかり忘れてしまうのではなく、他のいろいろな考えが手前に来て、それに隠れてしまうのだ。 帰宅してドアを開けた瞬間に思い出すのだから、そうとしか考えられない。

頭の中では、いつもいくつかの思考が並行して走っていて、 それぞれが必要とする情報が活性化しているんだろうけど、その容量に限りがあるのだろう。 いわゆる短期記憶がキャッシュに載ってる情報だとすれば、その後ろにもう一段、 メインメモリにあたる領域があるかのごとく。バックグラウンドに回った思考のスレッドは 他のスレッドが容量を必要とするにつれ、スワップアウトされてしまう。 一度そうなると、何かのきっかけでスレッドが起こされない限り、情報は埋もれたままだ。

工学的な問題の解決は、唯一の解を求めるというより、 いくつもある可能な解の中からゴールにどれだけ適するかを評価して、 最適と考えられるものを見つけることにある。システムがいくつもの構成要素から成り、 各々の構成要素にいくつもの可能な実現方法があるとする。 それぞれの構成要素内での実現方法の適性が独立して評価できれば話は簡単なのだが、 ある部分での選択は他の部分での評価の尺度に大きな影響を与えてしまう場合がある。 そうなると、問題を小問題に分割してひとつづつ解決してゆく、という方法では全体の最適解が得られない。 (こういうのは、評価の尺度自体が数値化出来ないものである場合が多い。 よくあるのは、デザインのシンプルさと機能とのトレードオフとか、 ツールのインタフェースを充実させる方が速いかユーザを教育する方が速いか、とか)。

そうなると、基礎データをそろえた上で、頭の中に入るだけの要素を詰め込んで、 いろいろシミュレートしてみる必要がある。 これをやると、頭の中のメインメモリが溢れる感覚がある。 その問題以外の情報がどんどんスワップアウトされる。


関係ないが、「忙」と「忘」はどちらも「心」と「亡」から出来てるんだな。


「一人屋台方式」の効率とやりがい (ちはるの多次元尺度構成法(5/22)じぶん更新日記(5/23))。 製造業に限らず、プログラミングやデジタルコンテンツ制作にも通じるところがある。

CGアニメーション制作も大規模になると、どこかで分業しなければならない。 3Dのモデルを作る人、外見を決めるテクスチャを描く人、アニメーションをつける人、 ライティングを決める人、等々。どれも特有のセンスを必要とするから、 分業してそれぞれの技能に特化する方が良さそうに思える。

でもそれがうまく行くのは、作業行程をきちんと定義して、 作業行程間のデータの受け渡し方法が明確にマニュアル化されていなければならない。 3Dのモデルを作るんでも、とにかく静止画で綺麗に見えれば良い場合と アニメーションを綺麗につけなければならない場合で自ずと作り方が変わって来るから、 それぞれのパートが好きなようにデータを作っていると収拾がつかなくなる。

一方で、デジタルデータを作ることのメリットは、さまざまに加工できる柔軟性にある。 思い付いたことを試せるチャンスが、物理的な「もの」を扱う場合より遥かに多いのだ。 せっかくそういう性質があるのに、工程をがちがちに固めてしまったら、 創造の余地をどんどん狭めてしまうことになる。 それは、コンテンツ制作の本来の目的とは相反する。

これも、上に書いた、部分の最適化で全体の最適解が求められない例だ。 まだ計算機システムなら、要求仕様を明確化すればそれがゴールになり、 多少は定量的な評価のしようもあるというものだが、 CGアニメーションの要求仕様なんて監督の頭の中にしかないからなあ。 それに、制作過程で投入される創造性ってのが最初の要求仕様よりも重要だったりするし。

5/8 (Tue) またCG俳優の議論/言語処理系を書くことの副作用

公開まであと2ヵ月ばかりとなって、ぼちぼちメディア露出が多くなって来た。 LA Timesの"Synthetic Actors Guild"は例によって「CGアクターは俳優を置き換えるか」の論調。 皆やっぱりそういう視点になるのかね。 つくる立場からはこんな疑問は出てこないということは過去の日記で論じた (2000/7/30) ので繰り返さないが、こういう議論が常にでてくるってことは、 「演技する」という表現形態は、例えば音楽を演奏するって表現形態なんかにくらべて 一般にはあんまり理解されていないのだろうか?

Andrew Niccolの "Simone" がどうなるかは楽しみである。


Gaucheで、算術関数を複素数の範囲まで規格通りに実装しようとしているのだが、 三角関数の加法定理を忘れていることに気付いた。とほほ。 そりゃ、exp(ix) = cos(x) + isin(x) さえ覚えてれば導けるわけだけど。複素数の範囲でarcsinを求めるあたりから だんだん怪しくなってきたので、高木貞次の解析概論を引っ張り出して復習。 大学で使った教科書類はもうほとんど持っていないだが、どういうわけかこれだけは持って来ていたのだ。 あああちこちに書き込みが。熱心に勉強したんだなあ(感慨)。

自分で言語処理系をちゃんと実装することの意外な副作用は、 基礎的なことをきちんと復習する機会に恵まれることだ。 本棚の飾りになっていたKnuthの "The Art of Programming" も、 部分的にだけど読み込む機会を得たし。

5/3 (Thu) LISP

同僚がPaul Grahamの Beating the Averagesを「面白いよ」とメイルで紹介してくれた。 Lispの実業への応用の成功事例なんだが、 プログラミング言語の「力」とそれに対する人々の認識の分析があまりに見事なもので、 つい興奮して一気に翻訳してしまった。Paulの許可が取れたので公開: 「普通のやつらの上を行け」。 題名はいまいちかなあ。


[前月][次月][一覧]:[表紙][映画][King][BBS]

Shiro Kawai
shiro@lava.net