３D（立体）映画に関するメモ （２）

AVwatchでパナソニックの立体映像に関わる人たちへのインタビューが掲載されていた。
パナソニックはいちはやく、民生用の立体映像システムに取り組んでおり、今から1年後の販売を予定している。
リンク：パナソニック/PHL関係者が語る「3Dに行く理由」

ハリウッドに研究所があるため、最新の情報を取り入れ、ジェームス・キャメロンも開発に協力しているらしい。
(そういえば、Avatorの予告編公開まで、あと3時間30分、今朝の7時に公開予定）

このインタビューでは、劇場映画と家庭用ビデオの違い、ブルーレイの利点といった試聴システムの開発者ならではの話がメインだが、以前にも少し話したカメラ間の視差の話も出ている。
友人が2台のRED ONEを使用して立体画像の撮影を試みていたが、やはり視差の設定は重要で、それを間違うと最近はやりの箱庭写真、すなわちミニチュアのようにみえてしまうそうだ。

以前の立体映画とはここが違うのだなと思った。
インタビューを読んでいて、今回の立体映画の復興では、驚きよりも臨場感が重視されていて、映像の体験を新しい次元へあげることなのだということを再認識した。

--------------------
また、うるまでるび氏がFinePix REAL 3D W1のリビューを書いていたのを少し前に読んだことがあるがそこに、興味深いことが書かれていた。

実は3D写真の世界では「手間に出すより奧に引っ込めろ」というのが常識です。

これはそのほうが、「見やすい立体画像になる」と言うことを意味しているのか、「立体画像を破綻しないでみれるようにするにはそうしたほうがよい」という意味なのか、「撮影した立体画像はそのように見える」と言うことを意味しているのかは文面からはいまひとつ読み取れなかった。

しかしながら自分の作業経験とこのパナソニックのインタビューに述べられていることからすると、立体画像はスクリーンに近い状況で見る必要があるということだ。
スクリーンに近い位置でみると、スクリーンのフレームが気にならなくなる。
そうすると立体世界により没入できることになる。

どちらにしてもこのあたりのノウハウが、これから立体画像を作る上でのカギとなるような気がする。
ただ二つの画像を左右のカメラで撮影して立体視できますよというだけでは、映画やTVの世界ではもう通用しなくなる。
そのノウハウが述べられた本などがあると読んでみたい。

他に、おもしろいなと思ったのが
最初は興味を持っていない人も、その立体映像を見ると意見がころっと変わる。
画質の向上よりも立体画像のほうが衝撃がある。
の2点。

今回の立体映像は様々なメディアで「ブーム」と記載されていたので、当初は「あぁまたか」という印象しかなかったが、実際に作業して新しいシステムでの立体画像をみるとその気持ちは吹き飛んだ。
たしかにころっと考えが変わるのを身をもって経験した。


--------------------
実は、ここ1年ほど、もう一つカメラを買いたいと思いつづけて、いろいろと物色してきた。

目的の一つはHDビデオだ。
用途は子供と家族の撮影のため、720pでも良いとは思っており、コンパクトカメラを考えていた。

VFX用途に使うのでなく、子供の記録や日常の利用であれば、それほど高画質の動画は必要無い。おそらく720pで90%の満足感は得られるだろう。


しかしながらコンパクトカメラでは、センサーが小さいせいか画質が今ひとつ。
720pとは言うものの画質の感じはSDとさほど変わりないという印象さえ受けた。
（実際には少しながら高画質だが）

最近になってマイクロフォーサーズのPenなどが発売され、画質も改善されてきた。
そろそろ買いかなとおもったが、やはり良い物は高い。
画質向上のために底までの金額を払うのも実は気が引けていた。

スローモーションも撮れるカメラが発売されたときには、これだ！と思ったが画質の点で満足度は今ひとつ。スローモーションを生かすには300fps以上で撮影する必要があると思っているのだが、それだと画質が640x480よりもかなり小さな物になってしまう。

実生活で、スローモーションを使う機会を考えてみると実は、それほど多くない。
使うとすれば、運動などでフォームを調べたり、アニメーションの勉強のためぐらいだろうか。
普通に日常を撮影しても、いろいろな発見はあるだろうし、科学的な実験などにも学習効果を高めてくれる働きはある。
しかしながら、日常の撮影で、いつもいつもスローモーションが入っていてはすぐに飽きるし、どちらかというとうざい感じもある。
要するに日常の利用ではなく、限定された用途になってしまうので、それに対して出費する余裕はない。

もし300fpsのスローモーションが最低640x480で撮影でき、通常モードでは720pのHD撮影が可能というカメラがでれば買おうかなとおもい待ち続けていた。

しかし、一向にその気配はなかった。

そして、先月、立体画像が撮影できるカメラがFujifilmから発売された。
丁度、仕事で立体画像のすばらしさを実感しただけに、これには食指が動いた。

それまでならどうしても、二つのカメラを使うか、プリズムで、二つの画像にわけるしかなかった。
そのため、動画撮影が手軽に出来る物はほとんど皆無。
たとえ静止画像でもあとでみれるようにPC内で処理を施す必要があった。

しかも今回のカメラは、静止画に限らず動画も立体画像として撮影できるし、撮影直後にカメラの液晶で確認できる。

おそらく現時点で手軽に立体動画が撮影でき、何も処理せずにすぐに、みることが出来るのはこのカメラだけだろう。
これは立体画像における革命とも言える。
静止画はいままでもなんとか工夫して立体画像を撮影する人がいたが、立体画像というとほとんど皆無だった。
しかもいかにも立体を意識した画像ではなく、手軽に日常が立体で撮影されたものなど見たことがない。

現時点では、このカメラの静止画像をフルサイズで裸眼立体視することはできないし、動画もHDではない。

しかし動画の画質もそこそこ行けているのではないかと思われるし、たとえSDの画質でも立体になることで情報量はアップする。

このパナソニックのインタビューでも言われているように高画質への（自分の場合はSDからHDへの）変更よりも、２Dから３Dへのほうが、衝撃的なのだ。


実際の撮影画像を見てみないとわからないが、未だに購買意欲は、さがっていない。

自分独自の仮説だが、自分の子供が成人になるころには、動画の分野は、立体画像が少なくとも20-30％のシェアを獲得するのではないかと思う。

それは日常生活の様々なところで、見ることができることを意味し、その時代に成長した人にとっては当たり前のような事になる。
丁度、昭和の時代に青春を過ごした人たちが、白黒画像からカラー画像への変化を経験したように。

そのときに、自身の幼少期の映像を立体で見せてあげられたらと思うと、今買うしかないかなという気持ちにさせられる。

今、購入するだけの余裕はないので、新らしい仕事をがんばって見つけるか。
月払いで買うか。
買わなくても良い理由が見つかるのを待つか。

そろそろサンプル画像が上がってきているが、購入を決定する前に、もっとリビューを見て、良い点と悪い点を把握しておきたい。

こちらでの発売は9月だが、どちらにしても嫁さんを説得するのがまず先か．．．。

　

MELの使われる領域

英語のWikipediaにMELの項目があった。
簡単に述べられているだけだが、MELがどのような領域で使われるのかがまとめられていた。
勉強の際の方向性を決める助けになりそうなので、日本語に訳してメモ。

--------------------
リンク：Maya Embedded Language（wikipedia）

MELは、Mayaでの作業を簡単にするために使われます。
MayaのGUIで達成されることのほとんどが、さらにGUIではできない特定の作業でさえMELで達成できます。
MELは「複雑」もしくは「繰り返し」の作業を加速する方法を提供します。
また、他のユーザーにとってもおそらく有用な特定のコマンドの組み合わせを再配布する事が出来ます。

MELの構文はTCLやPerlに似ています。
Melは、いくらかのメモリ管理やダイナミック配列をもち、Maya特有の関数への直接アクセスを用意しています。


MELの応用：
MELスクリプトを使って作られるツールは、通常以下のような範疇に属しています。

* データ 入出力
* モーション・キャプチャー・データ の インポート
* プロプライエタリ・ゲーム・データのエクスポート　(コンソール専用データの事と思われる)
* トラッキングを生成するためのシーンのメタ-データ　(？何のことか？)
* ジオメトリの生成/修正
* カスタム・プリミティブ
* サードパーティーのレンダラー向け特定のデータタイプ
　　　(例: レンダーマン サブディビジョン サーフェイス)
* 基本パッケージに含まれていないモデリング用ツール
* アニメーション・ツール
* マッスル・シミュレーター
* リギング/セットアップ コントロール
* 群衆、AIの振る舞い
* ライティング/レンダリング・ツール
* 共通する(common)複雑なシェーダー・セットアップの自動生成
* 事前の(Pre-)もしくは、事後の(post-) レンダー エフェクト
* サードパーティーのレンダラーの呼び出し
* ダイナミックス
* パーティクルの振る舞いをカスタム化
* クロス・シミュレーション
* ユーザー・インターフェイスのカスタム化
* キャラクター・コントロール のカスタム化
* 無効なMayaコマンドの除去
* ツールのためのユーザー・インターフェイス

Mayaは、デペンデンシー・グラフの部分として、実行されるノードに帰結する特殊なMELの組み合わせであるエクスプレッション言語も提供します。
エクスプレッションは、複雑な振る舞いをシミュレートしたり、そのほかの便利なタスクを実行するために、Mayaのエクスプレッション・エディターで開発され、Mayaがシーンファイルを評価しているときにスクリプトが実行されます。

Melは主要なスクリプト言語に較べてとても制限されています。
オブジェクト指向ではなく、連想配列のような進んだ機能を持っていません。

ここ数年、Maya8.5において、わずかですが進歩がありました。Melの代わりにPythonが使えるようになりました。


--------------------

説明では、スクリプトがどのような領域でつかわれるのかという分類が行われているが、どれか一つにしか属さないというわけではなく、用途によっては複数の範疇に属するスクリプトを同時に使うこともある。

また冒頭で、tclやPerlに似ているという記述は目新しかった。
いままでC言語に似ているというのは見たことがあったが．．．。
これからは、情報収集のときにtclやPerlについて記述してあるスクリプト例を見つけたら、ざっと目を通してみることにしよう。

　

小飼弾氏へのインタビュー

引き続きITmediaネタ。

小飼弾というプログラマーへのインタビュー。
氏はプログラマーという仕事に関して、より視野を広げる事が出来るいろいろな考えを述べられている。

特に、自分の立場にも関係していると思われる部分をITmediaから引用したい。


Q33　プログラマーの能力は生まれ持ったセンスによる部分が大きいと思いますか？

ほとんど経験でしょ。


Q34　プログラマーに向いている素質は何だと思いますか？

とりあえずプログラムをはじめてみて、それが続くかどうかかな。いい考えがひらめいたときに、ひらめいたことに安心してそこで止まってしまう人はプログラマーに向いていないといえるかも。実際に手を動かしてプログラムを書いて、それが思い通りに動作するかというところまで確認しないと。意外かもしれないけど、頭のことではなく手のことなんですよ。


Q82　よいプログラマーの条件を3つ挙げてください。

必要なプログラムを必要なときに書き、必要に応じて直せるなら十分。


Q83　悪い／使えないプログラマーの条件を3つ挙げてください。

読まない、書かない、直さない。


Q84　プログラマーの35歳定年説をどう思いますか？

35歳からが楽しいんだけどなあ。僕自身をかんがみても、本当にプログラムを楽しめるようになったのは最近で、それ以前は今思えば気負いなどもあった。35歳定年説を真と感じてしまう人はそもそもプログラマーになるべきではなかったのかもね。



自分が勉強しているのはプログラムというよりもスクリプトなのだが上記で述べられていることの多くは当てはまると思う。

それに「プログラマー」という言葉を「VFXアーティスト」と置き換えてもあまり違和感が感じないものもある。

それにしても、「もっと行動せねば．．．。」と反省させられる。
　

すべての開発は感動から生まれる-池田敏雄

IT media で井上恭輔氏へのインタビューがあり、座右の銘は何かと聞かれて氏が答えていたのが、

富士通の池田敏雄氏の言葉「すべての開発は感動から生まれる」

これは、今自分が関わっている仕事（VFX)や勉強にも当てはまると思う。
そして、幼児教育についての本をいくつか読んでいるときにも同じようなことが書かれていた。
自ら勉強していろいろな事を知ろうという姿勢は、幼児から小中学生にいたるまでの大切な時期に、いろいろなことに感動できることから、始まる。
その時期はいろいろな情報を詰め込むのではなく、いろいろな経験をすべき時期であるということで、その本は現在の早期教育に警鐘を鳴らしていた。

今回、この言葉を見て、隠しブログを始めた理由をもう一度考えてみた。
隠しブログは、自分が過去に見聞きしたいろいろな物事。そしてその瞬間にもっていた感情や考えを思い出して書き出していくことが目的だった。
いつもそうなのだが、自分がなぜそうしようと思ったのかは、行動を起こしている時点では明確でないことが多い。
ただ、そうすべきで、それが正しい方法だと思ったから始めた。

今思えば、この隠しブログを始めたときは、将来の仕事に関しての方向性がどうしても定まらないので、それを打開することも一つの目的だったが、それはいいかえれば自分の未来を開発していくこと。

自分がなにに感動したのかを明確にしておくことで、方向性が見いだしやすくなると感じていたのだと思う。



もしかしたら「開発」という言葉を他の言葉に置き換える事ができるかもしれない。
そしてその応用範囲は思ったより広いように思う。
「感動」というのは「開発」に限らず、未来を創り出していくカギであり、きっかけになる物だと思う。


さて、池田敏雄とはどんな人間なのか、なぜ富士通という会社名がでてくるのかよくわからなかったので少しそちらも調べてみた。


池田敏雄物語
天馬空を行くがごとく生きた男（リンク）


池田氏はかなり型破りな人間で、富士通が日本で初めてのコンピュータを創ることに貢献していたことがわかった。
また「Indexレジスタ」も池田氏の発明だそうだ。
意外と日本は、初期のころからすばらしい人材がいたようだ。

池田氏は、自分の興味を持ったことはとことんやったそうだ。
性格と言うこともあるだろうが、おそらく小さいころから興味を持ったことに関しては、親も邪魔をしないように気を遣ってあげていたのだと思う。
そして、感動することの大切さ、興味を持ったことを続けて目的を達成するまで挫けないように導いてあげたのではないかと思う。
子供に対してそのような教育方法が採れる親は、そうそういない。
大体は子供が何をしていても、その集中している時間を遮ることが多いのではないかと思う。

ちょっと子育ての話になってきたので、この話はそろそろ終わりにします。ｗ

この池田氏のエピソードは、プロジェクトX「命輝け ゼロからの出発 国産コンピューター」で詳しく紹介されているようです。

最後にプロジェクトXの名言集（Youtube）からもうひとつの池田氏の言葉

「挑戦者に無理という言葉はない 」

がんばりたいですね。

コンピュータ専門用語の理解

webサーフィンをしているときに以下のエントリを見つけた。

今日は私のAPI記念日（ギークなお姉さんは好きですか）


タイトルからわかるようにめずらしく女性プログラマのブログです。
実は、以前から、いろいろと調べているときに、時々検索にひっかかるブログだったので気になっていたブログの一つです。

その理由は、めずらしく初心者（非プログラマー）からプログラマーになるときのぶつかる問題や、初心者の気持ちにたった内容になっているからで、その内容には、なるほどなと思うことが多かったからです。

上記のエントリを読んで、自分でも大きく同意できることが書いてあったので取り上げることにしました。

--------------------
じつは、上記のエントリにある「API」という言葉、同じように気になり調べたことがある。

そのときに、やはり他のサイトや辞書を読んだだけでは理解できず、じぶんなりの答えを見つけるのに苦労した覚えがある。

そしてエントリを読んでいて、他の人もやはり同じなのだなと思うと同時に、その理由が書かれていたのを見て、なるほどなと思った。



分かってる人からしたら「他のサイトにも同じようなこと書いてあるじゃん」って思うかもしれないけど、全く分からない側からすると、ちょっと表現が違うだけで理解に至らないことがある。
なんだろね、きっと頭の中にインデックスされてる知識や語彙が違うからだろね。
だから私に理解できる説明を探す必要があるのです。
（今日は私のAPI記念日より）



「人によって、知識や語彙が違う。」

ここにこそ、プログラミングの入門書を万人向けの物とできない理由だと思う。

大学の教授や会社が何年も研究してきて、その過程で生まれた「専門用語」。

プログラミング用語は特に、数多くの専門知識や経験に裏打ちされている。
そのため、初心者が、とまどうのは、その専門用語を理解する為に、複雑、多用な知識が必要となることである。


以前、坂村 健氏の「痛快!コンピュータ学」がコンピュータの基礎知識を理解する上で非常に役に立ったと言うことを書いたが、それはコンピュータを説明するのに、専門用語や専門知識を分野外の人にも、なじみのある言葉と知識から始め、段階をおって理解を深める形になっていたからだと思う。


通常の入門書はそこがうまくできていない。
いきなり専門用語を使ったり、言葉は平易でも説明している内容はけっこう専門的（説明している側からすると、単純化しているらしいが）だったりして、ついていけないことが多い。

ある程度の知識を持った人からすると、上記のように、「同じようなことが書いてあるのになんでこの人は理解できないの？」となってしまう。
それだけならいいが、「やる気が無いんじゃないの？」と思われることさえあるかもしれない。

しかも、同じ説明でも理解できる人もいるので、話がややこしい。

そのような状況では、「他の人が理解できる入門書でも、自分には理解できない。きっと自分はプログラミングには向いていないんだ。」という気持ちにさえ、なってしまう。

特に、「入門」とついた記事や本だとそのような気持ちになりやすい。
そういう文章に限って、最初は非常にわかりやすく書かれている（またはそのように見える）ことが多いのも落とし穴だと思う。



そしてそれは、このブログで書かれているように、「知識や語彙が違う」ということで理解できる。

人によって知識や語彙の「種類」も「量」も大きく異なる、特にコンピュータが普及するにつれて異なる分野の人も増え、ますますそのバリエーションは増加しているのではないかと思う。
また、同じ言葉でもその意味する範囲が異なったりもする。
そういった諸々の理由で、入門書などに説明されている言葉、専門用語を解説した辞書やサイトを理解できなくても何ら不思議ではない。
リアリティーが異なる次元で説明されているので仕方がない。
むしろ初心者はそのようなことの方が多いのだと思う。

自分の理解力の無さをなげくことも、「自分に納得できる理由付けとする」という意味では、まったくの無駄ではないかもしれないが、大半の場合は「あきらめ」にたどり着くだけだろう。

--------------------
ではどうすればいいのか？

コンピュータの専門用語を理解すると言うことに絞って言えば「検索して情報を集めること」に限る。
ただ「検索」は広い意味での「検索」で、印刷された文献を自分で探すことも含める。
以下に自分が主として使う方法をまとめてみた。番号は振ってあるが整理のためで、順番ではない。


１）その用語が元々普通の言葉からきたものであれば、語源を含めて、その意味を先に理解する。
通常は英語から派生していることが多い。

Interfaceを調べてみると、

Interface（gooディクショナリー）
━━ n. （異なる物の）境界面, 中間共通面; 共有領域;

そして、そもそもinter-とは以下の意味があり、
━━ pref. 「の間の；相互の［に］」の意.

faceとは、表面とか外観といった意味を持つ。

そして専門用語の意味では以下のような意味が生じてくる。
Interface（e-words）
インターフェースとは、二つのものの間に立って、情報のやり取りを仲介するもの。また、その規格。


２）その用語を解説したいろいろなサイトを検索してみる。
使えるキーワード例：「＊＊＊＊＊（調べたい専門用語）」、「とは」、「意味」、「初心者」、「わかりやすい」、「難しい」「説明」など。
他にも、調べている途中で、含めたい単語はどんどん入れていけばよい。
Googleなら「初心者にわかりやすい説明をしている」などの文章で入力してもOKだったりする。


３）その用語が生まれた背景（歴史）を読んでみる。
Interfaceの意味を調べているとして、たとえばマウスの開発の歴史を紹介したサイトなどを呼んでいくと
「マン・マシン・インターフェイス」の意味が辞書で紹介されている以上に生き生きとした形で、理解することができる。
マウスを開発していたときに研究者が「インターフェイス」と言う言葉を選んだ理由、そしてその言葉を使うときの彼らの感情や感覚さえ、わかるかもしれない。

暇なときに、今やっていることに関係ない事でも歴史を読むようにしていると、意外なところでその知識に助けられることがある。
そして、それは生き生きとした血の通った知識となることが多い。


４）その用語を分解して、普通の用語として、各単語を調べる。
その専門用語が合成されて生まれたギークな用語だったりすると、辞書にもでてこない事がある。
しかも、それがあまり説明されていなければ各単語を調べていくことでわかることもある。



５）英語のサイト検索で調べる。
通常google.co.jpで検索しているなら、google.comで、キーワードを英語で入力してみると、異なる検索結果が見つかったりする。
google.co.jpの検索結果にも「Web全体から検索」という選択肢があるが、ここから検索される結果と「google.com」で見つかる結果は異なることがある。

またオンラインで使える英英辞書などを使ってみるのも良いだろう。

Oxford Dictionaries Online

そのほか英英辞書へのリンク集


６）推測する。
どうしてもわからなければ、集めた情報から推測していくことも可能だ。
ただ正確では無い可能性もあるので、将来それを明確にする必要があるかもしれない。
時として保留にしておくことが時間の節約になることがある。
あまり枝葉のことを追求していくと、きりがなくなる。

その場合は、おそらく心の片隅で疑問が残り続けるので、後になって思い出しときにでも調べなおせば、もしかしたらもっといい説明が見つかるかもしれない。（インターネットの情報は日々、更新されている）



--------------------
べにじょさんのブログで強調されている点をもう一つ。

「つまりAPIは「特定の機能を持つプログラム部品」なのです。（元ネタへのリンク）」


このAPIに関しては、自分の理解は少し異なった。
APIの説明を読んでいる時点で、
「Interface」「関数」といった概念を理解していたので、「Application Programming Interface」という言葉から容易に理解することができた。

あえてこのことを書いたのは、やはり人によって持っている知識と語彙が異なる。
そしてそれは同じ用語でもことなる理解に導くことがあると言うことの例を示したかったからだ。
本筋において、言葉は違えど、同じ物を示している。


自分では、APIとは、プログラムの部品というよりも、あるソフトウエアやOSの機能を使うためのインターフェイス。すなわち歯車や配線を使った機械装置でいえば「スイッチや、レバー、ダイヤル」にあたるものとして、とらえている。

この理解は100%では無いかもしれないが、本筋においては間違っていないだろう。


APIを「プログラム部品」と理解したとしたら、自分の性格上、APIを使うときに、それぞれの部品の機能をくわしく調べないと気が済まなくなる。

それに、そもそもプログラムの部品ととらえると、他のプログラムの部品とどう違うのかという疑問が生じるてしまう。

しかし、文字通り「インターフェイス」として理解すれば内部構造は理解しなくても、「インプットするためのインターフェイス（コマンド）」、「それにより引き起こされる働き（アウトプットなど）」さえ理解すれば良いという安心感を与えてくれるので自分にとってはこの理解で良いと思っている。

この「ブラックボックス」は「ブラックボックス」のまま使うという考えは「関数」という言葉を「リレースイッチ」と関連づけて理解したときから始まる。

（関連エントリ）
スイッチ＝関数＝ノード＝CPU
初心者プログラミング教育のブレイクスルーになるか？


そして、「ブラックボックス＝関数＝リレー・スイッチ」考え方はプログラミングに深くコミットしたくない自分には便利な考え方で、いろいろなものをシンプルにして理解することが出来る。
また、何より覚えることが少なくて済む。
これは、Melスクリプトのノードを理解するときにも役に立った。

　

スクリプティング学習における第二の壁 （その２）

ここ2ヶ月ほど、あまりスクリプトの勉強をやる気力がない。
家庭でも仕事でも忙しく、時として明け方近くまで仕事が続いたりしたのでやる時間がなかったというのもあるが、もし本当にやる気があればたとえ一日10分でも時間を作ってやっていたはずなので、単なるいいわけにしかならない。

まったくサボっていたわけではなく、十分に時間があるときには、チュートリアルを見たりしていた。

しかしながら、なにか漠然とした壁を感じ、気力を高めることができない。

何を感じているのか、明確にしたいと思い、以前のエントリ「スクリプティング学習における第二の壁」を読み直して、考えてみた。

第一の壁は、自分的には突破したと思っている。
しかしながら、現時点では第二の壁が立ちはだかっていると感じる。
第一の壁ほど大きくはないのだが、第一の壁と違って漠然としていてつかみ所がない感じがする。

シニアに課題をもらっている間は、かなりやる気がでたのだが、新たな課題も用意されておらずｗ
自分で道を見つけるしかない状態だ。

その道を見つけるために、チュートリアルを読んだり、他の人の書いたスクリプトを解析しようとしたが、いずれも目的のずれ、現時点の段階の低さから来る理解力不足を感じてパットした解決策にはなっていなかった。


第一の壁、以前は、このようなときに、いろいろなコマンドを試しながら最低限必要なものを見つけて壁を崩すことができた。

現段階では、アルゴリズムで遊ぶ必要があるのではないかと思う。
数学で言えば、足し算、引き算を終え、かけ算、割り算をする段階で、方程式は早すぎる。

しかし最低限必要なものが、経験のない初心者でしかも自習となれば全く見えてこない。

もしかしたら、自分の専門分野（エフェクト）に関連するスクリプトに絞ってやればいいのかもと思ったが、それも的を得ない。
部分的に自分の段階よりもはるかに高度なことをしらなくていはいけない部分が出てくる。
また覚えなくてはいけないこと（ノード・アトリビュート、コマンド）が非常に多い。

また、ここ二ヶ月ほどは、いろいろなチュートリアルを見たり、人の書いたスクリプトを読み解こうとしたが、やはり目的が明確でなくては、ただ漠然とやることになり、集中力に欠ける。

これでは、スパルタ教育的にスキルをアップしようとする、既存のやり方と変わりない。



もっと基本的な部分のアルゴリズム。
たとえば、パーティクルをならべる。そこへオブジェクトを配置するといった一つの手順。

こういった応用がきく基本のスクリプトを現時点ではたくさん練習した方がいいように思う。
しかしながら、それらがどんなものであるのか、見えてこない。

ある程度、スクリプトの経験がある人でないと、幅広く使える基本且つ普遍的なアルゴリズムを抽出して課題とするのはむずかしい。


しかし、この段階を、スムースに通り抜けるにはこの基本となるアルゴリズムをいくつか練習し習得する必要があるのも事実。
独学で、しかも初心者がその課題を自分でみつける手段をみつける必要がある。


--------------------
どうすればよいのか？！

いろいろなスクリプトの構造を解析、想像して、そこにある共通項を見つけ出し、それを異なる方法で同じような結果を出す物をためしてみるのがよいのか？

共通する普遍的アルゴリズムが、どういった機能や目的を持った物かを見つけ、他のアルゴリズムに置き換えることができるのかといったことを検討することは有効な気がする。

この段階では、自習よりも本当に経験者のアドバイス、もしくは同レベルで同じような勉強をしている人が必要だなと特に感じる。

これを超えれば、自分でいろいろと目的に合わせたスクリプトを苦労しながらでも楽しみながら、作れるようになるのだろう。
--------------------

こうして考えを書き出してみると、なんとも子供の言語教育ににている。
ボキャブラリが先か文法が先か？悩むところだが。
あらゆる事が同時に起きてくる。

これはすべての言語学習に共通することなのだろう。
プログラミング言語という人工言語でもそれは例外ではない。

ボキャブラリを増やす必要はある。
単語を理解するときは、その概念をしっかりと把握する必要がある。

そして、文法に関しても簡単な絵本からはじめて文章をならっていく。
当然わからない単語が含まれていることもある。
しかし単語単体の学習と併せて、文章を学習するときに出てきた単語も明確にしていくことでボキャブラリを増加させつつ、それを文章と関連づけ、かつどのような状況で使うべきかを理解することができる。

よくある大人の学習では、文章や単語がどのような状況でどのように使われるのかをあまり重視せず、単語と文章の学習を別々にしているような気がする。
（自分だけかもしれないが。。。。）















--------------------
たとえば、
パーティクルとオブジェクトの位置、回転情報の関連づけ。
オブジェクトの配置。
サーフェイス上にオブジェクトを配置し、サーフェイスにくっついたままになる。

時間の経過に従った変化。
距離にしたがった変化

人生の目標を見つける

人生の目標を20分で見つけ出す方法(LifeHacker)という記事を見つけた。

まだ実践していないが、手順も簡単だし、是非やってみたいと思う。

今、CGとかVFXなどと書いてみても涙が出てこなかったとしたら、それは違うということかｗ

実際、何らかの答えに出会ったとしても、涙が出るとは限らないような気もするが、その答えに出会ったときには、ピンと来るとは、思う。

バケツの底で、ころころころがる石ころが、居場所を見つけピタッとゆれなくなるような感覚がする。

ここで見つかる答えが本当の答え、最終的な答えとなるかどうかはわからない。
もしかしたら年齢を得るにつれて、その答えも変わってくる可能性がある。

しかし「お金のため」「地位のため」「名誉のため」「これしかないから」といった感情を捨て、本来の「自分」が求めている物を見定めることはすべてにおいてパワーを生み出す源となる。

何か迷いが出てきたら方向性を定めるためにも、これをやってみるのがいいかもしれない。
パイレーツオブカリビアンに出てくるジャックのコンパスのようなもの。
今望んでいる物を手に入れるために進むべき方向をみつけることができるだろう。

　

隠しブログリンクの公開終了

隠しブログのリンク公開を終了いたしました。
今後は、このブログのメールフォームにてご連絡下さい。
全ての方にご返事できるかどうかはわかりませんが、できるだけご期待に添えられるようにいたします。