GLP：言語圏総生産！？

ふと、GLPという言葉を思いついた。Gross Linguistic Product。言語圏総生産。

日本語圏とか英語圏とか、言語で作られる経済圏の規模は測れないのかなー、などと思ったので。厳密な定義は？と聞かれたら・・・、知らん(^^;

もしかして、似たような統計値って調べられているのかな？いるのかも？

社内の公用語を英語に、の話題で盛り上がってるのを眺めてて、GLPみたいな統計値があればもっと具体的な議論ができそうなのになーと思ってみたり。日本語のGLPは縮小しているのかとか、英語のGLPはどのくらいの成長率なのかとか、一人当たりのGLPはどうなのかとか、数字があったら面白いなー、と。

んー、でもあれだ、やっぱりGLPみたいな指標はこの論争の解決には役に立たないか。片や「英語を根付かせないと優秀な人が日本から出ていってしまう」という意見に対して、「どーぞご勝手に、日本が嫌いなら出てって結構」という意見があるわけで、後者の意見の人はそもそもGDPみたいな経済的な指標で豊かさとか幸せを測ることに否定的なんだと思う。そういう方にGLPとか言っても意味ないもんなあ。

それにそもそも英語が別格なのは分かりきってるし、日本語のGLPと日本のGDPは大差なさそうだから、あんまり面白くないかも。それよりも、ロシア語とか韓国語とかアラビア語とか中国語のGLPが分かったらそのほうが面白いのかも。

・・・すいません、グダグダで。まあ、与太話です(^^;

実は、最近思い立って経済学の本を読んでみようなどと思いまして、まずは基礎の教科書からということで、マンキューさんを読んでいるわけで。

マンキュー入門経済学

関係ないけど、マンキューさんって若いんですねー。1958年生まれと書かれているので現在52歳。マンキューって10年以上前から教科書として使われてません？40歳前後、もしかして30代で既に世界で使われる教科書を書いたってこと？凄い！

「帰納と演繹」の補足のような訂正のような反省のようなもの

我が目を疑いました。僕のライフはもうゼロです＞＜

ホッテントリの経験はあるとはいえまぐれ当たりが数回あっただけだし、最近はすっかり過疎ってたので急にブクマされてビビりまくり。居酒屋で適当なことを喋ってたら突然店中の客が立ち上がって「面白い」とか「それは違う」とか言い出した感じ。ひえ〜、ここは居酒屋じゃなかったインターネットでした、ごめんなさい。

でも色々とフィードバックいただけて勉強になりました。恥ずかしながら「アブダクション」って知らなかったし。この場を借りて御礼申し上げます。それと共に、コメント欄に一つ一つは答えきれなくなってきたので、ここにまとめて返答ということでお赦しください。

帰納と演繹という言葉の使い方が間違ってたようです

頂いたコメントをまとめると、概ね「言わんとすることは分からんでもないけどそれって帰納とか演繹じゃなくね？」といったものが多い印象。そこで慌てて今さらのようにネットで帰納と演繹を検索したりして考えなおしてみた。

うーん、これは確かに僕が間違ってますね・・・、申し訳ありません。

じゃあ帰納と演繹とは何かをちゃんと理解したの？と問い詰められると、正直なところ考えれば考えるほど分からなくなって来たのだけれど・・・orz。そもそも帰納と演繹って思考法ではないのかな。思考法ではなくて論法、つまり論じる方法。

人の思考は急に飛んだり分散したり蛇行したりしながら進むものであって、直線的に思考するわけじゃない。だから思考の流れ自体を帰納とか演繹で説明すること自体が間違っていたような気がする。そうではなくて、思考の結果を何らかの資料として説得力のある形にまとめ上げる時に、帰納とか演繹といった論法が役に立つ。ということではないかしら。

帰納と演繹が逆？

コメント欄で立て続けに「帰納と演繹が逆では？」との指摘を受けた。そもそも帰納と演繹の言葉の使い方に間違いがあったので、この時点で逆かどうかなんてナンセンスな問いかもしれないけれど、考えてみた。

まず僕の帰納と演繹に対する理解を書くと

• 帰納： 複数の事実から背後の一般則を推論すること
• 演繹： 一般則を組み合わせて別の事実を推論すること

ここから想起していたイメージは、

• 帰納法で推論するとき： 複数の事実から一つの原則へ集約するように推論するイメージ
• 演繹法で推論するとき： 一つの（少数の）原則から多くの事実を導き出すイメージ

ところが、下記のエントリに描かれている図は僕のイメージと向きが逆！
http://blog.goo.ne.jp/globalsciencejournalist/e/f5b40dffa3de9b0c8a5d625922a6169a
最初は大混乱したのだけれど、やっと分かった。推論する時と違って、何かを主張したい時には次の順序になるのではないか。

• 帰納法で主張するとき： 主張したい一つの原則（目的）が複数の事実（手段）に当てはまっていることを示す
• 演繹法で主張するとき： 複数の原則（手段）がことごとく主張したい一つの事実（目的）を指し示していることを示す

つまり、何かを推論する時と、その推論が正しいことを主張するときでは、論理の流れが逆になるのではないだろうか。コメントを書いていただいた方と僕との間でここにズレがあったために、「逆ではないか」という指摘を受けたんじゃないかと思う。

帰納/演繹じゃないなら何が言いたかったの？

まず直観として、思考の「向き」が違う人がいる気がするなーと感じていた。これはつまり、因果関係のツリー構造を探索する際に、原因から結果に向かって論理を展開するのが得意な人と、結果を見て原因を推定するのが得意な人がいる、ということではないかと考えた。

（エントリを書いた時点での僕の理解では）演繹法は原因から結果を推論していく手法であり、帰納法は結果から原因を推定する手法と理解していた。従って、思考の向きが演繹的な人と帰納的な人がいるのかなー、と考えた。そう、ここで僕は一つ間違いを犯している。「結果から原因を推定する」のと「結果から原因となる原則を推定する」のは似ているようで違う。帰納法は後者だが、前者は帰納法とは言えないのだと思う。

ここからが決定的に不味かった気がするのだが・・・。さらに「結果から原因を推定するのが得意な人などうして得意なんだろう」と考えて、そこから「経験を蓄積されたことで原因を探る推論エンジンが優秀になったから」だろうと予測した。これを帰納的な人と書いてしまったのが決定的に間違っていたと思う。ここまで来ると帰納法とは何の関係もないよね・・・orz。

でも書きたかったのはそういうこと。自分とあの人は何か思考の「向き」が違うなーって感じたことないですか、という問いかけがしたかった。

なんで急にこんなブクマされたんだろ？

ブクマコメントを見ると

• 面白いと感じてくれた人
• 間違っているところにツッコミを入れてくれた人

の2種類がいるように見える。ここから、

• 頷けるところはあるもののツッコミどころもあるエントリはブクマが伸びる

という原則が推論できる。この原則を主張するためには

• 多くの事例を集めてこの原則で説明できることを示す

必要がある。
これが帰納法である。（合ってる？

「理系と文系」より「帰納と演繹」

ネットでは定期的に「理系と文系」ネタが盛り上がるようだ。「理系はコミュニケーションができん」「文系は論理的な思考ができない」「それはレッテル貼りだ」の3行が毎回無限ループする。もちろん文系の学問に論理的思考が不要であるとは到底思えないわけで、むしろ着眼点として面白そうなのは、論理的思考に対するアプローチの違いだと思う。思考法には演繹法と帰納法があって、この思考法で分類してみるほうが理系/文系の分類よりも面白そうに僕には思える。そして「文化」の衝突も理系/文系と同じくらい、帰納派と演繹派の間で起こっているような気がする。

ここで急に話は飛ぶのだけれど。

前職の後輩で、保険会社から転職してきた人がいた。社内では変わった経歴の持ち主だった。その彼に「保険会社ではどんな仕事をしてたの？」と聞いたことがある。

なにやら彼は保険商品のリスク計算のようなことをしていたようだ。と云われても僕には具体的なイメージは湧かないのだけれど、とにかくデータを集め、エクセルか何かに入力して色々と計算して、それを上司に提出するというようなサイクルだったらしい。その上司といえば、会社に来てのんびりと新聞を読み、ときどき居眠りをし、到底仕事をしているように見えない。関西出身の彼は「なんや、なんであんな居眠りばっかりしよるオッサンに報告せなあかんねん」と心の中で毒づきながら報告書を提出していたそうだ。

ところがいさ報告書を提出すると、上司はメンドくさそうにパラパラとページをめくったかと思うといきなり「ここの計算結果おかしいぞ」と言う。「し、失礼な。何言うてンのオッサン、俺がどんだけチェックしたと思ってんねん？」と思いつつその計算を調べると、指摘されたとおり確かに間違っていた。そんな悔しい経験が何度かあったらしい。

さもありなん、と思う。ここからは僕の予測だけれど、彼の思考法は演繹的であり、オッサンの思考法は帰納的であったのではないか。後輩はたぶん、入力したデータから計算を一つ一つ順番に確かめ、論理を積み上げていって結果を出したのだろう。一方オッサンには、たとえ今は居眠りをしていようとも、今までの仕事経験で積み上げられた膨大な経験が身体知として獲得されている。そういった経験に照らして、どうもこの計算結果は間違っていそうだという「匂い」を嗅ぎとるのだ。いわば、蓄積された経験がベイジアンフィルタとして作用しているのだと思う。

思うに、若いうちは演繹的な思考力が強く、経験を積むにつれて帰納的な思考が得意になる。

実は僕自身、思い当たるふしがある。昔と比べてデバッグの効率は明らかに上がったと思う。「あの辺に原因がありそうだな」という嗅覚が以前よりも働くようになった。後輩が「くそっ、原因が分からん！」とハマっている様子を横から眺めて、「この辺が怪しいんじゃない？」と適当なことを言うだけで当たってしまうこともある。そんな時はきっとドヤ顔（恥ずかしい・・・。

しかし、プログラマという職業は絶対「演繹派」が向いていると思うんだよね。帰納派プログラマはどうも頂けない。例を挙げると、ある関数の動きを知りたい時に演繹派プログラマはソースを読むのだが、帰納派プログラマは「実験」するのだ。ソースは読まずにブラックボックスのまま、とりあえず引数を色々変えながら呼んで実験をして、その実験結果から関数の仕様を類推するのである。

一見、帰納派プログラマの方が要領の良いアプローチに思える。実際、瞬発力的な比較で言えば帰納派の方が仕事が早い。しかしそのアプローチではプロジェクトが早晩破綻する。効率よくバグのないソフトウェアを開発するためにはコードをキレイに保つ必要があり、コードがキレイであるということの評価軸の一つは、演繹的な論理の流れが端的にすっきりと表現されているかどうかである。そういう視点を持たない（あるいは希薄な）帰納派プログラマは、デバッグや緊急対応のような瞬発力が要求される場面では活躍するかもしれないが、長期的に見ればプロジェクトにダメージを与えてしまうと思う。

視点を変えて、大学の学科や研究室による思考法の違いを見てみよう。数学科は間違いなく演繹的だ（追記：間違いのようですトホホ。コメ欄参照m(_ _)m）。数学的帰納法はあまり帰納的なアプローチには思えないし。そして数学者が輝かしい実績を残すのも若い時が多い。つまり数学者は演繹的な思考力がピークとなる若い頃に最大の成績を残すのではないか。一方、いわゆる実験系の研究室は帰納派だ。膨大な実験データを元に背後の数理モデルを組み立てていく。こういう実験系の研究室では、実験データを読み解く能力は年長者の方が得意だという印象が強い。徹夜で整理した実験データを教授に一瞥でダメ出しされて泣いた経験がある人も多いんじゃないかな。お医者さんも、経験豊富な年長の先生のほうが診断が的確なんじゃないかというイメージがあるね。

思うに、「論理的思考」という言葉は主に「演繹的思考」を指していることが多い。そして帰納派の人、つまり蓄積された経験に基づいたベイジアンフィルタを備えた人、の言うことは一見、論理を欠いているように見える。これは当然のことで、GMail のスパムフィルタの判定を見てもそこに論理を見つけることは難しい。オッサンが「俺のカンだ」と言うのと、GMail が「データから学習した結果の判定です」というのはあまり差がない。困るのは、大した学習データもインプットしてないくせに「俺のカン」を押し付けてくる御仁が時々いらっしゃることなんだろうと思う。

あなたは帰納派？演繹派？周りにいる人はどう？そう考えてみるとちょっと面白いと思うのだけれど、どうかな。

追記

「数学は演繹的」と書いたらツイッターで、数学にも帰納的な発想が必要との指摘を受けた。「帰納的な発想から予想が生まれて、それを演繹的に証明して定理になる」との意見も。なるほど！と思ったのでここに追記。
前から僕が思ってたのは、理系と一口にいっても学部学科に依って思考法のクセは結構違うよなーということ。そしてもうひとつは、非論理的に見える人、つまりカンで言っているようにしか見えない人をホントに単に「非論理的」と切って捨てていいのかな、という問題意識。さらに「勘」って実は肉体化されたベイズフィルタなんじゃね？という思いつき。この3つを絡めて書いてみたけど、うーん、読み返してみるとあまりうまく書けてないですね。考察が浅かったかな・・・。

顔をスキャンしてもらった！

どど〜ん！


こちらのスタジオでスキャンして頂きました！
http://www.ga-cg.com/studio/
ダメモトで「見学に伺ってもよいですか」と聞いてみたのですが、不躾なお願いを快く受けて下さいました。まさか実際にスキャンしてくれるとは思っていなかったのですが、「どうぞどうぞ〜」と快くスキャンまでしてくれました。ありがとうございました！

いやー、このスタジオは凄いですね。
全身をスキャン出来る大型の機械と顔をスキャンするための小型の機械の2つが置いてありました。全身をスキャンするなんて、ピクリともズレ無いようにポーズを決めて待つのはさぞかし大変だろうと思ったのですが、計測時間はわずか十数秒。これなら姿勢を維持していられますね。

影になって撮影出来ない部分がかなり出るのではないかとも思っていましたが、データの穴が開く部分は意外に少なく驚きました。股の部分や脇の部分などごく一部だけでした。あ、ただ、上の画像でも髪の毛は撮れていないのですが、黒くてツヤのある素材は撮影できないそうです。

この計測器は、なんと日本には3台しかないとのこと。しかも他の2台は大学だそうなので、民間企業で持っているのはゼネラルアサヒさんのみだそうです。そういうわけで、国内でCGが必要となる映画作品やゲーム作品は結構こちらのスタジオを利用されているようでした。少し伺っただけでも、ヤッターマン、ゼブラーマン、龍が如く、などなど聞いたことがあるタイトルがたくさんありました。スタッフの方もいろんな芸能人の方にお会いできるので役得ですね、などと話していました。華やかそうでちょっと羨ましい・・・。

話してくれるちょっとした裏話もいちいち面白いのです。例えば、先ほど髪の毛はうまくスキャン出来ないと書いたのですが、「龍が如く」の撮影でキャバ嬢の方をスキャンしたときはまつ毛のエクステが撮影出来ず目の周りの形状がごっそり落ちしたと言ってました。

以上のようにとても素晴らしいスタジオなのですが、計測器の稼働率を上げるために映画/ゲーム以外の応用方法がないか探しているようです。何か良いアイデアが出せれば良かったのですが、ビジネスに繋げられそうな良い提案は残念ながらできませんでした。せっかくお招きいただいたのに申し訳なかったですが、今後とも宜しくお願いします ＞ Iさん。

以上、今回はですます調でお送りしました。

P.S.
それにしても、自分の顔を3Dで見るのは実に妙な気分。いろんな角度から自分の顔を眺めて「うあ、自分の顔ってこんな形してるんだ・・・ブサイクだな・・・orz」という気分に浸りました・・・。モデリングソフトで変形してイケメンに変えてみようかな。いや、そんなことしたらますます凹みそうだ。

C#とCGアプリの相性について

etopirika5 さんが下記のように書かれているので、http://www.quatouch.com/products/hisui/index.html を作っている者として、ちょっと反応してみるよ。

C#は業務用の小さなアプリケーションをちょこっと作るには最適だと思うのですが，一年間かなり使ってみた結果CGアプリや数値計算アプリを作るには全く適していないことがはっきり分かりました．

http://d.hatena.ne.jp/etopirika5/20100612/1276299740

僕としては「全く適していない」とは思ってないのだけれど、でも etopirika5 さんがそう思われるのもよく理解できる。

氏は研究者。研究者というのはとても厳しい職業だなあと以前から畏敬の念をもって見上げているのだけれど、彼らは「世界一じゃないと存在意義が示せない」人達なのだ。たとえ狭い分野であろうとも、その分野では一番の結果を出さないと論文が書けない。これはホント僕には無理。論文を読むといつも「すごいなー、こんなアルゴリズム僕には絶対思いつかないなー」と感心することしかできない。その論文の弱点を見つけてそれを上回るアルゴリズムを研究しようなんていう能力は到底僕にはない。そういう厳しい世界で etopirika5 さんは戦っているのだろうと思う。

そういう研究者が使うべき言語は、そりゃあ C# じゃないでしょう、C/C++でしょう、と思う。数値計算で論文書くなら計算時間などの実測値を掲載する必要があるだろうし、特にCGならば論文発表の際にインパクトのあるデモも必要になるだろうと思う。そういう戦いの場でC#使った眠たいデモはアウトなんだろうと思う。

つまり、CGとか数値計算の分野で真正面からの横綱相撲が必要とされている方はやっぱりC/C++。そこに異論は全くない。だけれど僕は、はなっから横綱は狙ってない感じ。一昔前の舞の海みたいな相撲を狙っているといえばいいのかな。小兵には小兵なりの戦い方があるさ、という感じ。

僕が狙っているビジネスの一つは例えば「業務用の小さな *CG* アプリケーションをちょこっと作る」というニーズ。あるいはトップレベルのパフォーマンスがそこまで要求されないアプリ。こういうニーズにはC#はとても適していると思う。

C# と OpenGL

やっぱり生の OpenGL API を直接ガンガン叩こうと思ったら、C# からはやりにくい。ラッパーを丁寧に作りこんで使い易い環境を作り上げていく必要があるだろう。
拙作の ヒスイ では、Hisui.OpenGL.dll というDLLがあって、コイツがOpenGLの薄いラッパーの役割を果たしている。また、Hisui.Geom.dll という幾何ベクトルなどのライブラリもあり、これら2つが連動するように作ってある。このおかげで OpenGL の呼び出しはとても快適になった。まー、ここまでライブラリを育てるのはかなり時間がかかったけれど。

C# と C++ の接続が難しい

これは同意！
C# と C の接続は別に難しくない。でも C# と C++ はとても面倒だ。C++ を呼び出そうとしたら C++/CLI でラップしないといけなくなって、やり始めるとあらゆるクラスを全部ラップしないといけなくなって、delete のタイミングとか考え始めると気が狂いそうになったりする。
どちらかというと、C++ を C 形式の API でくるんで、それを C# から呼び出す方がいいんじゃないか、と僕は思っている。そういう時は、オブジェクト指向脳は意図的にOFFにしてC言語脳に切り替えてAPIを設計する必要あり。
あと、C# から C/C++ を呼び出すときのパフォーマンスってどーなんだろ？やっぱり .NET 内のメソッド呼び出しよりコストがかかるんじゃないかしらん？あまり頻繁にネイティブコードの呼び出しが発生するのはパフォーマンスに悪影響しそうな気がする。（この辺は知識ないので単なる予想です、すいません）

追記

調べてみたら、DllImport する際は SuppressUnmanagedCodeSecurity 属性も付ければ速くなるらしい。セキュリティチェックが省略されるので呼び出し先が信頼できる場合しか使えないようだけど。し、知らなかった・・・。知識不足露呈（恥。

C# は遅いか

分かりません＞＜ 知りません＞＜ ごめんなさい m(_ _)m

ただ使っている身としては、そんなに使いものにならないほど遅いという感覚は持っていない。かなーり昔に Java の実行速度は C/C++ と比べてもそんなに遜色ないというベンチマークをみた記憶もあって、それならば C# だって結構イケルだろうと予想して僕は C# を選択した。もし仮に今は遅かったとしても、将来的には同等な速度までJITコンパイラが進化するだろう、と。

まあ、メモリは・・・、喰ってると思いますが・・・。

はっきりとC/C++と違いを感じるのは以下の部分。

• 配列へのアクセスは圧倒的に遅い！　→　unsafe コード使わないと話にならん！逆にいうと、unsafe 使えば結構イケる。
• C++ の STL >>> C#(.NET Framework) の System.Collections.Generics。STL が恋しい・・・。

あと、C# は GetHashCode() の実装でアホをやらかすとメッチャ遅くなるので注意。一度ハマった・・・orz。

追記

Java のパフォーマンスがどこまで参考になるのか分からないけど・・・。

• 32/64 ビットの数値演算 ファイル入出力 例外処理 では C と同等の性能を示す。
• コレクション、オブジェクトの生成、解放、メソッド呼び出しの性能 では、Java の方が C++ より性能が高い。
• 配列の操作は C の方が高速である。
• 三角関数 の性能は C の方が高い[41]。

Javaの性能 - Wikipedia

C# も動作原理は似ているはずなので似たような傾向になるのではないかしら。コレクション系がJavaの方がC++より高速というのは意外だったけど。C++ の STL はクールと思ってたけど、必ずしも速いわけではない？

メモリアロケータ

これがパフォーマンスに影響しているかどうかはハッキリと分からないけれど、僕はアロケータのようなものを自作して工夫しているのでちょっと紹介してみよう。これは C/C++ でも使えるテクニックで、結構有名なものだと思う。

ヒスイ には Hisui.Core.Storage というコンテナクラスが定義してある（ここにちょっと説明あり）。簡単に言うと int 型の整数をキーとして値を格納出来るコレクションクラスだ。この中で簡単なアロケータを実装している。

CGアプリでは例えば次のような座標値を大量に扱う。これは絶対 struct でしょう。絶対 class にしてはいけない。

public struct Point3d
{
  public double X, Y, Z;
}

これを Hisui.Core.Storage に対して次のように格納できる。

var points = new Hisui.Core.Storage<Point3d>();
int id = points.Put( new Point3d { X = 1, Y = 2, Z = 3 } );  // (1, 2, 3)が格納されて、空いている ID が割り当てられる
var p = points[id];  // id をキーとして (1, 2, 3) が取得出来る
points.Remove( id ); // id をキーとして (1, 2, 3) が削除される

ここで重要なのは、Put() も Remove() も points[id] も O(1) の計算量で実現出来ていること。通常、配列を使ったら Remove() は O(n) の計算量が必要となってしまうのだけれど、Storage ではそれが必要ない。
このカラクリを説明するために、簡単のために Storage には最大で 256 個までしか要素を格納出来ないことにしよう。その場合 Storage は、まずいきなり 256 個分の連続したメモリ領域を確保してしまう。その 256 個分の領域のうちどこが使われていてどこが空いているのかを Storage が自分で管理するのだ。Put() 関数がキーとして返す ID は 0 〜 255 のインデックス値（実はヒスイでは 0 は null 扱いなので 1 〜 256 までの値）となる。
その最初に確保される 256 個分のメモリ領域は、ただの何も書かれていない空の配列ではない。次の図のようなチェイン構造が埋め込まれている。

このチェインは空き領域をリスト状につないだ空き領域チェインだ。図中の「空き位置」というのはこの空き領域チェインの先頭を指すポインタだ。
Put() が呼ばれると、「空き位置」ポインタが指している先に値が格納され、そのインデックス値がIDとして返る。このとき「空き位置」ポインタはチェインを辿ったもう一つ先の領域を指すように更新される。
Remove() が呼ばれると、id が指す領域が空き領域チェインに挿入され、「空き位置」ポインタはたった今 Remove された領域を指すように更新される。
つまりなんのことはない、連続したメモリ領域上にリンクリスト構造を展開して、配列とリンクリストのいいとこ取りをしたような設計といえる。これはたぶん古典的で有名な方法なので、絶対ネット上にもっと丁寧な解説があると思うのだけれど、すぐには見つからなかった。なんかこの手法には名前がついているのかな？（追記：「メモリプール」ではないかとコメ欄でご指摘頂きました）

まあとにかく、僕はこんな実装をやっている。ベンチマークをしたわけじゃないのでこの実装がパフォーマンスに寄与しているのかどうか分からないし、計測しないでパフォーマンスに言及するのはとても危険なことなんだけど、もしかしたら、本当にもしかしたらだけど、こういった工夫がそれなりの効果を上げているおかげで僕は C# でもなんとか CG アプリが組めているのかもしれない。

もうひとつのアバター

今さらながら「アバター」をDVDでレンタルして観た。3Dを生業にしてるくせに、恥ずかしながら映画館での立体視は体験していない。

アバター [初回生産限定] [DVD]

受けた印象は、事前に見聞きしていた巷の感想と同じものだ。映像は圧巻だったが、ストーリーは手垢にまみれたものだった。

もし本当にパンドラという星があったらどうなるだろう。もし本当にナヴィという種族が生活していて、そこに人間が入り込んだとしたらどうなるだろう。ああいうストーリーにはなるまい。

ここでは思考実験として「もうひとつのアバター」のストーリーを妄想してみる。映画にしても絶対に面白くならないストーリーだ。

まず、人類はそんなに攻撃的ではないはずだ。主人公ジェイクは、軍からの情報収集の命令など受けることなく、全面的に支援を受けて親善大使としてナヴィのもとへ向かうだろう。想像して欲しい。仮にNASAが宇宙人とコンタクトしたとして、いきなり軍が攻撃的な行動を起こすだろうか。現代の国際社会ではそれはありえない行動だと思う。

では逆に、ナヴィ側が極端な拒否反応を示して人類を攻撃するだろうか。その可能性はある。でも、ゲーム理論の見地から見ても、ただ外部の存在を攻撃するだけの凶暴な種は進化の過程で淘汰されてしまうはずだ。他者と協力するという遺伝子を持った種でないと存続することはないだろう。これは地球上の生物に限った話ではない。だからナヴィも友好的な他者とは親交を結ぼうとする可能性は十分にある。ここでは、ナヴィはジェイクの勇気と誠意に応え、人類との親交に向かって一歩踏み出したとしよう。

さて、人類とナヴィの間には文明に差がある。人類の方が遥かに高度な文明と軍事力を持っている。一方でパンドラ星には貴重な地下資源がある。人類は欲望にかられてこの地下資源を力ずくで奪おうとするだろうか。

ここで経済学者が登場する。経済学者は政治家に交易を勧めるだろう。彼らは云う。「確かに文明は我々の方が優れています。ナヴィと比べて人類の文明は絶対優位であるといえるでしょう。しかし比較優位の原理に従えば、交易は我々人類にも彼らナヴィにも大きな益をもたらすはずです。交易するべきです。」

交易となれば民間企業の登場だ。商売の基本は Win-Win の関係である。勝間勝代女史ならきっとナヴィとうまく Win-Win の関係を築くだろう（見た目もちょっとナヴィと似ているし）。つまり、ただ奪うのではなく、Give and Take の関係を築くだろう。ジェイクが気づいた信頼を元に、徐々に信頼関係を広げていき、契約を結ぶようになるだろう。

するとどうなるか。ナヴィの社会に貨幣経済が導入されるだろう。ナヴィはその強靭な身体の優位性を活かした職につくだろう。そしてナヴィは、安定した生活と、娯楽と、酒を得るだろう。

かくしてパンドラ星にはマクドナルドとセブンイレブンが立ち並び、トヨタ車が走り、ナヴィたちはiPhoneで電話をしたりメールをしたりするようになるはずだ。地球からは観光客が押し寄せ、ナヴィたちと一緒に写真を撮って大はしゃぎして帰っていくはずだ。ナヴィたちはいつしか狩りを忘れ、自然への畏怖を忘れ、エイワを忘れてしまうだろう。そして自ら森林を伐採しゴルフ場を建設するようになるだろう。

さて、果たしてこのストーリーに悪人は登場しただろうか。

これが今、世界で起きていることではないのか、と思う。以前オーストラリアに旅行した際、現地で聞いたアボリジニの状況も似たようなものであった。僕は文明社会の恩恵を教授してジェット機でオーストラリアに渡り、そういった悲しい現実のお話を、さも分かったふうな顔をしてしたり顔で聞いてきたのだ。そういった悲しいお話を、ただ「消費」しただけで帰ってきた単なる観光客であった。自分も蹂躙する側に加担したということなのだろう。

もう植民地時代は終わった。奴隷制度も終わった。人類は曲がりなりにも一歩進んで、ただ奪うだけの時代は超えたようにも思える。略奪を反省した映画も既にたくさん作られている。今この時代にアバターのような二番煎じの映画を作ることは、安全なところから過去の人達が犯した過ちを笑っているに過ぎないのではないか。自然破壊や人種差別問題を扱った作品と云われているが、本当に今、現在進行形で起こっている問題を真正面から扱った作品と云えるのだろうか。

・・・もちろん、そんなことはどーでもいいと思えるくらい映像は素晴らしかったのだが。やはり映画館で3D映像を体験しておくべきだった、残念。

スカルプトリス凄い

いやー、Scuptris 凄いですねー。
【無料】粘土感覚で3Dモデリング！高性能フリーソフト「Sculptris 1.0」のデモ動画 | ふらぶろ

試しにダウンロードしてみて遊んでみた。・・・なんつーか、センスとスキルの無さがバレますな。なんだこの気持ち悪い顔は。

まー僕のセンスはともかく、ズブの素人でも遊びでいじっているだけでこういう形が作れてしまうんだから面白い。このツールは「お勉強」が要らないから素晴らしいよね。大抵の3D CADって一生懸命使い方を勉強しないとさっぱり操作が出来ないんだけれど、こういうツールはテキトーに触っているだけで使い方が掴めてしまう。だから「知識勝負」じゃなくて、センスとかスキルとかテクニックが重要になる。うん、やっぱりこれからの時代はテクノロジーじゃなくてテクニックだね。（参考：d:id:u_1roh:20100220:1266657712）

・・・って呑気なことばかり言ってられない。こういうのをフリーで出されちゃうと、ユーザー目線としては面白くて嬉しいけれど、プログラマとしてはチト辛い。なんつーかね、こういうスゴイものをポンっとフリーで出されると打ちのめされる感じが。一体どうやって実装されてるんだ、これはオレにもある程度は作れるものなのか、それとも到底手の届かない先にある高度な技術なのかどうなのか。
というわけで、ちょっと http://www.quatouch.com/products/hisui/index.html でスカルプト変形を試作してみた。

思ったことメモ：

• ちょっと作りが雑なので、盛り上がるスピードが一定じゃない。突然モコっと盛り上がっちゃったりするからダメダメ。
• Sculptris は変形に応じてアダプティブにメッシュが再構成される。それがないと大きく変形するに従ってメッシュがどんどん荒く歪（いびつ）になってしまうのでダメダメ。
• アダプティブにメッシュを再構成していても、Sculptris の描画は実に滑らか。メッシュを再構成したら頂点配列なども作り直しのはずだが、それであの速度が出るのか。変形箇所のみを別の枠組みで描画するなどの工夫をしているのか。この辺は試してみないと分からない。
• あの全くWindowsっぽくないGUIってどうやって作ってるんだろ。やっぱ全部自前で描画して作りこんでるんだろうなー。凄いけれど、今のところアレを真似しようという情熱はないな・・・。