日本でハリウッドVFXを制作! 「経産省アイディアボックス」 結果:  
●まとめエントリはこちら ●FAQ ●お問い合わせは左のメールフォームから

2009年12月30日水曜日

カール・セーガン

<2009/12/30 追記:ニコニコ動画に日本語字幕付をアップされている方がいましたので、情報元のブログリンク、大元のサイト「The Symphony of Science」の情報と共に追加しました。>

GIZMODO JAPANで「ハッブル超深宇宙の最新画像で啓蒙タイム(動画)」というエントリに
Symphony of Science-'We Are All Connected' 」という動画が紹介されています。
音楽に乗せて、いろいろな科学者の話をラップ風につなげているのですが、これがまた良くできてます。



この動画は、ジョン・ボスウエル(John Boswell)というプロ・ミュージシャンが「科学的な知識と音楽的形態の中にある哲学を伝えるため」に企画したと「The Symphony of Science」のホームページに書かれています。
上記の「We Are All Connected(我々はすべてつながっている)」は実は企画第二作目で、いまは第三作目まで公開されています。
すべて上記ホームページから見ることが出きるだけでなく、MP3,FLAC、その他のフォーマット、音楽のみ、アルバム画像までダウンロードでき、一作目はiTune版もあるようです。

第一作「A Glorious Dawn(輝かしい夜明け)」(YouTube)(ニコニコ動画
第三作「Our Place in the Cosmos(宇宙の中の居場所)」(YouTubeのみ)

またニコニコ動画に日本語字幕付がありました。
情報元の以下のブログにはカールセーガン以外の科学者の事や、この音楽プロジェクトの説明も書かれています。
Blog:里親から里子への児童虐待・・etc :該当エントリ「今年も残りわずかです」




カール・セーガンの話している一部を翻訳したものが以下のページにありました。
リンク:Remembrance Session Room

生物の美しさは、それを構成している原子にあるのではありません。
それらの原子の組み合わせ方なのです。
宇宙は私たちの内にもあります。
私たちは星と同じ物質でできています。
宇宙がみずからを知る一つの方法。それが私たちなのです。

「原子」と「原子の組み合わせ」の話は、一つ前のエントリ「勉強のやり方について」で書いた教育の話「知識」と「考える」ということにもつながってくるように思えます。


知らない人のために補足しておきますと「カール・セーガン(Wikipedia)」は天文学者でもあり作家でもあります。

NASAではアポロ計画において、月に飛び立つ前の宇宙飛行士の指導者であり、数多くの惑星探査計画に関わりました。
地球から、宇宙人へ向けたメッセージを探査機に積むこと(Wikipedia)を考案し、パイオニア計画では金属板、ボイジャー計画ではレコード盤が搭載されました。

また、1980年には、社会現象ともなったTVドキュメンタリー「COSMOS」を監修。
SFファンに知られるところでは1997年のジョディー・フォスター主演「コンタクト(Wikipedia)(YouTube)」の原作が彼です。


くわしくはわかりませんが、おそらくこの人のおかげで地球外生命体に対して、科学的な考えが普及し始めたのではないでしょうか。

またこのようなシンポジウムにも参加していたようです。
リンク:米下院UFOシンポジウム


----------------------------------------
さて、彼に関する映像をもっと、見たくなり、いくつか探してみました。

Youtube:Pale Blue Dot - Japanese sub (カール・セーガン、日本語字幕)
「想像力なくしては、私たちはどこへも行けない。」

物質におぼれることは、人の心を貧しくすると言われるが、このビデオを見ていて、より大きな物質「宇宙」や「星」を考えるとき、それは人の心を豊かにしてくれていると感じた。
なぜだろうと考えたとき、人の心を貧しくする「物」は所有することができる、もしくは可能性を感じさせる物だ。そして手元にないときそれがほしいと感じるとき心から何かを失うのかもしれない。
全ての所有が悪いわけではないが、本当に必要な物以外、たとえば娯楽や、嗜好品、もしくはちょっとした贅沢に関連する物では特にこういうことが生じるように思う。
ある「星」を所有できると感じるようになったとき、やはり心は貧しくなるのだろう。
物質の大きさではない。


----------------------------------------
YouTube:カール・セーガン(ボイジャーに乗せてある黄金のレコードに関するコメント)

あと160年したら、進化して地球に帰ってくるのでしょうか(wikipedia)。w
(参考リンク:ロボット・マニア「スタートレック」YouTube映像あり)
それにしても同時通訳の「宇宙はあんまりにも、がらーんとしてるので・・・」には笑えます。
知的なカールセーガンが普通のおじさんに見えてきましたw


----------------------------------------
カールセーガンと言えばTV番組「コスモス」
私たち人類は、宇宙が宇宙自身を知るための手段なのだ」(Wikipedia)の信念の元に作られたという「COSMOS」。これもYoutubeにありました。
ただし、1980年のオリジナル「コスモス」ではなく、1986年に再編された「コスモス・スペシャル」の映像です。

1)宇宙の地平線から
コスモス・スペシャル第1 1/11
コスモス・スペシャル第1 2a/11
コスモス・スペシャル第1 2b/11
コスモス・スペシャル第1 3/11
コスモス・スペシャル第1 4/11
コスモス・スペシャル第1 5/11
コスモス・スペシャル第1 6/11
コスモス・スペシャル第1 7/11
コスモス・スペシャル第1 8/11
コスモス・スペシャル第1 9/11
コスモス・スペシャル第1 10/11
コスモス・スペシャル第1 11/11

2)星の子供たち①
コスモス・スペシャル第2 1/6
コスモス・スペシャル第2 2/6
コスモス・スペシャル第2 3/6
コスモス・スペシャル第2 4/6
コスモス・スペシャル第2 5/6
コスモス・スペシャル第2 6/6

3)星の子供たち②
コスモス・スペシャル第3 1/7
コスモス・スペシャル第3 2/7
コスモス・スペシャル第3 3/7
コスモス・スペシャル第3 4/7
コスモス・スペシャル第3 5/7
コスモス・スペシャル第3 6/7
コスモス・スペシャル第3 7/7

4)宇宙からのメッセージ①
コスモス・スペシャル第4 1/7
コスモス・スペシャル第4 2/7
コスモス・スペシャル第4 3/7
コスモス・スペシャル第4 4/7
コスモス・スペシャル第4 5/7
コスモス・スペシャル第4 6/7
コスモス・スペシャル第4 7/7

5)宇宙からのメッセージ②
コスモス・スペシャル第5 1/6
コスモス・スペシャル第5 2/6
コスモス・スペシャル第5 3/6
コスモス・スペシャル第5 4/6
コスモス・スペシャル第5 5/6 
コスモス・スペシャル第5 6/6 


宇宙に思いをはせ、2010年の抱負をより大きな物に、そしてそれを達成出来る確固たる信念をもてるようになるといいですね。

皆様良いお年を !



<以下はおまけ>
コスモス最前線~ETからの電話 1/8
コスモス最前線~ETからの電話 2/8
コスモス最前線~ETからの電話 3/8
コスモス最前線~ETからの電話 4/8
コスモス最前線~ETからの電話 5/8
コスモス最前線~ETからの電話 6/8
コスモス最前線~ETからの電話 7/8
コスモス最前線~ETからの電話 8/8

懐かしいCMいろいろ

Japanese CFs 198X-1A 昭和六十年代の懐かしいCM

 

勉強のやり方について

プログラミング言語が開発され発展し、さらにMelスクリプトがうまれるまでには長い歴史があります。

その背後には数多くの天才科学者が考え出したり、見つけてきた理論や法則があります。
そしてそれらを応用し、その領域で働く人達の中で一般化し、忘れられたり棄てられた理論も数多く存在する。
そしてまた新しい理論や法則が発見され、過去のルールを改善したり発展させてきました。


この連鎖は過去(チューリングマシンをそのはじまりとするなら、1936年)から綿々と続き、その過程で、詳しい説明が省かれ、ただの記号や単語のみが残っているようなものさえあります。


それゆえ、現在においてその知識を勉強するには、その記号や単語をそのまま丸暗記するか、唯一残された要点をそのまま理解することを求められます。

記憶する勉強、知識を詰め込む勉強、速いスピードで動く社会についていくための勉強、これらになれた社会では、それらが当然の勉強方法として容認され、それに適用できない学習法は忘れ去られていくように思えます。

教育機関とそのシステムの発達は「記憶」に焦点を置いた勉強法が主流となり、そうでないシステムは細々とやっていくことができるに過ぎません。
現代では、沢山の人がそれだけが重要ではないと気がついていながら、何が重要かが見えてこず、その呪縛から逃れる方法もわからず、迷える子羊となっているような感じがします。

もちろん、すべての人や組織、そしてシステムがそうではないですが、それらはほんの一部のように思います。


たしかに「勉強」や「学習」の要素をつきつめれば「知識の記憶」があればどうにかなるような気もします。
百科事典のような知識があれば、なんでもできるような気がします。

でも、いくら沢山のブロックや木材があっても家はできあがりません。
多種多様な金属やプラスチック、化学物質と言った材料があっても自動車は生まれてきません。

それらを組み合わせるやり方や、裏付けとなる理論があるから、できあがります。
失敗を経験し、そこから「考える」ことで生まれてきました。
そして、そこには数多くの有名無名の人のアイデアが息づいています。

しかしながら失敗や経験、どうしてそれが考えられたかということは、現代のシステムでは要点のみが生き残るか、結果だけが生き残るかです。
それがどうして生み出されたかと言ったことは、闇に葬られます。


それが悪いといいたいのではなく、そのようになっているということです。
それは「勉強のスピード」を早め、情報の伝達を簡潔にするには仕方がないことです。
貴重な時間をすぐに役に立たないことに費やしていていては、本当に必要な事を学ぶチャンスを失うことも考えられます。

どちらが良いか、何が悪いかという議論は、人や状況によって違うので、おそらく際限なく続くでしょう。

ここで言いたいことは、そういった棄てられた知識、表に出てこない知識が、今勉強している重要なことをより生きた知識にしてくれることがあるということです。


プログラミング言語の勉強においては、学ぶべき重要な知識が膨大です。

その裏には棄てられ表に出てこない知識が、その数倍存在しているということをどこかで考えておいたほうが、良いのではないかと思います。
特に基本事項においてはそれらのことは重要な作用をしているように思います。


自分は記憶力が悪いのですが、体で覚えていくのはうまいです。
「経験にまさるものはない」という言葉を聞いたことがありますが、その通りかもしれません。
体で覚えた物は、考えるまでもなくスッとでてきます。



お気づきだと思いますが、私はある知識のバックグラウンドをやり過ぎと思われるまで細かに調べます。
そうすることで、その知識が生まれた背景、そこに関わった人々の心理を追体験しようとしているのかもしれません。

それにより、ただ記憶するのではなくその進化を疑似体験しようとしています。
そしてその過程で、そこに関わった人と同じように考え、また自分なりに考える時間的な余裕もできます。
それにより知識は生きた知識になり、自分で考える力も身についてきます。

すべてをこのような勉強の仕方にしていては、短い一生で何も出来なくなるかもしれません。

しかし時によってこのやり方が、後の勉強を加速してくれることもあります。
そういった裏の知識が、いろいろなところでつながりを持ち始め、無駄なところがなくなります。

これも20代前半に経験したことですが、一見関係ないような知識でも、いつかどこかで全てが結びついてきます。

たとえ、そのとき、無駄に思えたことでも。

本:「七つの習慣」

Biz.ID「習慣に必要なエネルギー

古い習慣を抜け出して新しい習慣を築くのにどれほどの力が必要か、
この月探査は比喩として多くを教えてくれる。

地球の引力は
深く根づいた習慣、
つまり遺伝や環境、両親、その他の影響力ある人物によってプログラムされた性向に例えられる。

地球の大気の抵抗は、
私たちを包む、より広い社会的、組織的な文化に例えられる。

この2つの力は強く、その力の影響から脱するには
その両方の力よりも強い内的な意志を持たなくてはならない。



これは「七つの習慣 セルフスタディーブック」という本から抜粋された文章らしいのですが、映像業界で小なり大なりの差はあれど、フロンティアを開拓していくことに関わるなら参考になるのではないかと思いました。

そしてこれが上杉祐世氏の言葉「夢を実現するには目標を高く持ち・・・」につながると思います。
上杉氏の言葉には、「強い意志」が不可欠であることが前提となっていると思います。
彼の言葉は「一つ一つのステップをおろそかにしない。」と続きます。

強い意志があるからこそ、そして現実的にそれをそすめようとすればこそ一つ一つのステップをおろそかにしないという考えが生まれるのではないかと思いました。
 

子供の教育のこと

プレススクールへ通う子供が、学校で先生の言うことに反抗したり聞かなくなることがあった。
いまも時々起こるのだが、ずいぶんマシにはなった。

学校は英語の環境なのだが、先生の話によると英語の理解力が足りないせいで、言いたいことが言えずに癇癪を起こすのだろうと言うことだった。

こちらに居ると、英語の環境では子供はすぐに英語がメインになってしまう。
そのため日本語の能力を維持するためには、自宅では日本語のみという環境が必要。
そうすれば、将来大きくなって英語も日本語もできるようになるというのがバイリンガルを育てる上で、重要なことと、こちらで実際に子育てをした体験談として数多く語られているのでそれにならっていた。

英語は、子供が友達と仲良くしたり学校へ行くために必要だが、日本語は日本の文化を正しく理解し、日本には良書も多いのでそれらを読めるように育って欲しいとおもっている。
そのため自分もその方法に習ったわけだが、言葉を覚えはじめの年齢では、それが逆に悪影響を与えることもあるようだとわかった。


解決策としては、そういった先生とぶつかるときがあれば、先生ができるだけ理解をできるように、そして言いたいことが言えるようにするということになった。

そして、自宅での対応として英語を使う機会を増やし、自分の言いたいことが言えるようにする手助けをするようにいわれた。
まぁもともと英語がそれほど出来るわけではないので、英語で相手をしてやれるのも限界があるが。

ただ、そのときに学校の先生に言われたことが頭の片隅に残っている。
「自宅で親が英語を使わないと、こどもは英語を使ってはいけないと思い、使おうとしなくなる」
とういことだった。

「使ってはいけない」というのが本当なのかそれとも比喩的な表現なのかはわからない。
しかしこの学校には様々な国の出身者を親に持つ子供がおり、バイリンガルが多い。
その子供の世話をしてきた先生のアドバイスなので経験からきたものだろうと思う。


そして、それからは、自宅で英語の絵本を読んでやったり、遊ぶときに英語を使ったりしてやると、どんどん話すようになってきた。
そして先生の対応もあり、あっという間に子供の態度がかわった。
学校では問題を起こさず、それまでいやがっていたのに、自分から学校へ行きたいと言い出した。


もちろん、ボキャブラリが増えたのも一つの原因とは、言える。
しかしそれまで幼稚園では英語を使って話していたにも関わらず、自宅では話さなかったり話すのをいやがったりしていたのが、どんどん自分から英語を使うようになってきた。



最近、これはもしかすると英語にかぎらず何でもそうなのかもしれない。
芸能人に限らず、親と同じ職業や趣味をもつようになる子供は多い。

子供は、奔放に興味がある物や好きな物を次々と探し、自分からそこへ入り込んでいくように見える。
しかし心の奥底では、やはり親や近くの人が慣れ親しんでいる物、常習的に目にし体験できることのほうが容認される=自分が受け入れられると感じているのかもしれない。

もしかしたらそこにある親の(子供へではなく)環境への愛着(愛情)を敏感に感じ取り、その世界に安心感を得て、その世界にいたいと思うのかもしれない。


反抗期になり、親のして欲しくないことをするような子供や、大人になって親とは正反対のことをするために家をでた子供が大きくなり、家の家業を受け継いだり、親と同じ趣味を持ったりする話も聞く。

そこには、この心の奥底での愛情ある環境の記憶があるのかもしれないと思った。


拒否や無視がある対象よりも、肯定や理解がある対象に人は親しみや愛着を感じる。
親の下に管理されている子供は、親の環境からそういったことを敏感に感じ取っているのだろう。

そして幼児期に、親しんだそういったことは、大きくなる過程で、いつもどこかに残っているのだろう。

 

2009年12月29日火曜日

命令構文と関数構文(4):まとめ

「命令構文と関数構文」に関するエントリのまとめです。
それにしても今回はかなり集中したので、疲れました。
でも自分なりに結論が出せて理解が深まったので調べて良かったです。

命令構文と関数構文(1): 「文法」と「構文」の違い

命令構文と関数構文(2): 「命令構文」
命令構文と関数構文(3): 「関数構文」


----------------------------------------
内容のまとめ
----------------------------------------

●「構文」とはプログラミング言語において、具体的な文字や記号の配列の仕方に関する決まりのこと。

●「命令構文」とはコマンド(関数)名の後に任意のフラグや引数を並べる表記方法
(例)コマンド名 フラグ 引数 ;

●「関数構文」とは、関数(コマンド)名の後に引数を( )にいれる表記方法
(例)関数名( 引数 )

●Melでは「関数」を命令構文で書くことも可能
(「コマンド」と「関数」の構文に柔軟性がある。

●「命令構文」はコマンドのみに使用。「関数構文」は関数のみに使用。というわけではない。
(Melコマンドの一覧に関数が入っていたりする。Melコマンドと関数の区分が明言されていないように見える)
 

追記:知識は守るべきか広げるべきか

昨日エントリ:「知識は守るべきか広げるべきか」
に匿名さんからコメントをいただきました。
そしてそれに関して、本文に追記をしました。

色んな人の考えに触れることが出来るのはいいですね。
コメントありがとうございました。
 
 
 

更新:命令構文と関数構文(3): 「関数構文」

エントリ:命令構文と関数構文(3): 「関数構文」
が書きかけでしたが、本日書き終わりました。
 

A.A.?

まだ見に行っていないのですがAVATORはかなり評判良いですね。
映画のストーリーや世界観自体の評価以外に3Dであることはどのぐらい評価されているのでしょうか?

Avator制作中に言われていたように、これからは3D映画の時代の幕開けとなるのでしょうか?
(少なくともジェームス・キャメロンはもう2Dに戻る気はないというようなことをどこかのインタビューで言っていましたが)

もし、本当に3D映画が大衆に受け入れられるきっかけとなり、これから爆発的に3Dを求める声がたかまるとか、これからの映像業界の一スタンダードとして定着するのであれば、それは歴史を作ったとも言えると思います。

まぁそこでばからしいことなんですが、
Avatorがそのきっかけになったと言うことで「B.C.(紀元前)、A.D.(西暦)」の表記にちなんで

B.A.  :(Before Avator);アバター以前
A.A.  :(After Avator);アバター以後(アバター歴?)

というような表現も使われるようになるのかなと、ふと思いました。

(ちなみに「After Christ(西暦)」がA.C.でなくA.D.となるのはラテン語の「Anno Domini」から来てるんですね。wikipedia


「A.A.」って...「アスキー・アート」と混同しそう...。

 

2009年12月28日月曜日

坂口亮氏のブログ「「Articulation skill」の重要性」を読んで

「Articulation skill」の重要性 --- Part.2

読んでてハッとさせられました。
これって自分がいままでLAのアメリカ人の嫌なところとおもっていたところかもしれません。
(以下の事は、自分の狭い範囲での経験でしかないので、どこまで一般的か保証はありません)

まぁ「LAの」ってのは何の根拠もなく、以前働いてたところで、そこの偉い人が「典型的なLAのタイプだ。」「口先だけで何もしない」「いいわけばかり」と言っていたのを真に受けていただけなんですが。

ただ自分の経験から見ても、
「計画性がない(プランに潜む落とし穴を検証しないで考えた理想プランのみを話す)」
「自分の推測が足りなくて起きたミスを、自分が原因とはまったく考えていない」
「そのため、その理由をとにかく並べ立てる。=>言い訳にしか聞こえない」
という感じる事がよくありました。

日本の会社でこんな事してたら一喝されるか、だれもまともに話を聞いてくれなくなります。

ただ、よく見ていると利点もある。
テクニカルな面をよく知らないプロデューサーや社長などに説明するとき、細々とした予測できる問題点をあげて説明しているとあっちも不安になり、「それで結局どうなの?」となります。

それよりも簡潔に述べたほうが相手にもわかりやすい。
そして自分でなんとかできるような予測できる問題で、それが100%出てくる問題でもないなら、最初から話さないほうが、相手が安心する。


そう、今書いてて思ったが、安心したり不安になったりするのは、すべて話し方による。
そしてそれがかなり強く影響する。
簡単に言えば、今その場で話していることが全てでその人の経歴などは問題なくなってしまう。



そういったスキルに長けている人は自己PRもうまい。
「I'm very good for modeling」など平気で言います。
あれやってこれやって、こんなこともできてあんなこともできてとPRしまくりです。
そういう人に限って、技術的なスキルはまぁまぁなのに、たちまち会社の上層部の信頼を得てしまう。

ただし、それがうまく作用するには条件もある。当然と言えば当然ですが
「問題が起きたときに処理できること」
「結果が出せること」

これがない、新卒者などは、口が達者なだけに逆に信頼を失うこともあります。
そしてこれが完全には伴わない人をみてきたので「口だけ達者だ」という印象が自分に残ったのだと思います。
切り抜けるのがうまい人は問題を部下に処理させて自分は何もしない人をみてきました。
それでも口がうまくて、社長から親近感をもたれていたので、疑いもされませんでしたが。

個人的には「うだうだ言ってないで、結果出せば良いんだよ」とは思っています。w
しかし、結果が全てと考えてコミュニケーションを怠り黙々とやっていては、「こいつは自信ないのか?それとも変わり者か?」と思われます。
実際、そうしてきて、信頼を得るまでには時間がかかりました。


まぁよく考えればそうしてくれるなら、まぁ結果OKということにはなります。
実際、問題が起きても日本人社会よりは簡単に許してもらえるケースが多いように思います。

日本だと問題が起きたら「なぜ、それを見抜けなかったのか?」とか、
「もっと良いプランはなかったのか?」となりかねませんが、(今はそうでもない??)
こちらだと、「どう解決するのか?」がまず来ますね。


それにしても、これはアメリカ人の仕事の仕方がよく表れているなぁと思います。
まぁ自分も本で読んだだけです。
約20年前に読んだ東京ディズニーランド建設時の話をまとめた本でした。
(タイトル覚えていないので確証はないですが、おそらく「東京ディズニーランドを作った男たち」だったと思います。)

この本で興味深かったのは、日本とアメリカの仕事の仕方の違いでした。
日本:前もって綿密な計画を立ててから建築を始める。
アメリカ:とりあえずはじめて、不足していることや変更が必要な事はその都度行う。
TDLの建築には、アメリカから沢山の技師を呼んだそうです。
しかし、このあたりの習慣の違いからアメリカ人サイドは、
「日本人はミーティングばかりして何も進まない」
「細かなことまで、ミーティングして決めないと動かない」
とイライラしたそうです。
そしていざ建設が始まると
「日本人はあっという間に、次々と建設していった」と驚いていたそうです。


前にもこの話はしたことがありますが、こちらで仕事上の問題に出くわすと、よく思い出す逸話です。

「問題は最初から、すべて予想できる物ではない。」という考えは双方にあるようですが
日本人:それなら推測して、できるだけ問題を洗い出してあらかじめ解決策を決めよう。
アメリカ人:今わからない問題を議論しても仕方がない、問題が起きたら解決しよう
となるようです。

最初から予測できない問題がおきることはすでにプランの内なんでしょうね。
だから、問題が起きたときに解決できることが重要です。

まぁ「問題が起きるのは人間だから当然」と考えているのか、「まぁいつもあとで問題が起きることはあるから」と習慣になっているのかはわかりません。どちらにしても文化です。


そうすると、ミーティングや人との出会いで、最初の話し合いの時に、いかに自信を持って主張できるかということにかかってくるのもなんとなく理解できます。
聞く側からすれば自信たっぷりに、しっかりとした話をしてくれれば安心できますからね。
特に分野の詳しい話がわからない人には、細かな専門的問題はどうでもいいようです。


これが適切な言葉かどうかはわかりませんが、KISS(Keep It Simple, Stupid)。

相手に不安を与えるような余計なことは言わずに必要な事だけを話せ。
相手にポジティブな考えや印象を残せるほうがいいような気がします。
まぁそう考えればこういう習慣も悪くはないかとは思いますが。


最近は、
「ポジティブなことをあいまいではなく、明確に話せるようにする」
「修飾語はややおおげさに、しかし嘘はつかずに」
を心がけています。


それから、アメリカン人の文化だと言ってもやはり、それは人によって程度の違いはあるでしょう。Lifehackなどの優れた人や、MITの教授などで、そうではない人もいます。

SonyやDDといった大手のエフェクトハウスでは、そのプロジェクトに動くお金も大きいし、人間の数も多いので、無駄なことは出来ないので、私の居るような小さなプロダクションに較べれば、もっと「問題予測」「綿密な計画」に力を入れているとは思います。


しかし、それでも上記の文化的背景は以前存在し影響するでしょう。



実力が100%の人と、実力が70%の人がいれば坂口氏の言う「Articulation skill」がある実力70%の人のほうが信頼を得ることがほとんどでしょう。 
経歴よりもそちらのほうが重視される。
「重視される」というと意図的にやっているような印象をあたえますが、習慣的にそちらのほうが信頼できると「感じる」みたいです。

そしてプロジェクトリーダーやプロデューサーがそういう人を簡単に信頼するタイプだと、もうその人のプランで話を進めて、他のことは聞こうとしなくなることも十分起こりえます。

まぁそういう人の所には、口先だけの金や名誉を求める亡者が集まりやすくもなるような気がします。




坂口氏が言うように、日本人としてこういったスキルを身につけていく必要正は感じます。

特に坂口氏のようにリーダー的な立場をとるにはそれは避けるわけにはいかない。
かといって対立するわけにはいかない。

実力が伴わない口先だけにならないよう、嘘をついたりしなければ、いい。
責任を持って、相手の気持ちを寄りポジティブな方へ持って行けるならその方が良いだろう。


最後に、坂口さんへこの言葉を贈りたい思います。

「大いなる力には、大いなる責任が伴う」
(With great power comes great responsibility. by Ben Parker)
坂口さん、がんばってください!!

 

知識は守るべきか広げるべきか

このブログを書いていてふと思うのが、苦労して得た知識は他に知られないように守るべきか?ということだ。

特にこの業界の進歩は著しく、5~6年前は知っている人が凄い人に見えたようなことが、今は新卒者でも知っていたりする。

そうなると、そういった知識をもっていても、給料の安い新卒者に取って代われてしまう。
要は同じ事をやっていては、高給取りは、首になる。
そうならないためにもさらなる知識と知恵を持って、より高度な結果を生み出し続ける必要がある。

また、そうならないために、自分たちの知識や知恵を出し惜しみする人もいる。

これは他と差別化を図り生き残るためにも、高度な戦略では必要な事になる。
例えば大企業同士の場合はそうだ。

しかし、それは個人にも当てはまるのか?

苦労して得た知識なら、後から来る人が苦労が少なくてもすむように手助けしてあげたほうがいいのではないかと思う。

良き先輩方はそうしてくれたはずだ。

それは、自分が仕事を失うことにつながるのだろうか?
もし、そうならそれは自分がより一層努力しなくてはいけないことを怠っただけなのではないか?

この仕事はたえず上を見続け、より高度な物をもとめていく必要がある。
たえず歩き続ける必要がある、息の抜けない仕事なのかもしれない。

良いことか悪いことかといえば良いことだと思うので、いままで自分が得た知識を公開している。

そして良い流れは、また別の良い流れを産み、めぐりめぐっていつかは自分のところに戻ってくると思う。
自分の所に返ってくるなら、その流れを止める理由があるのだろうか?

皆が向上し、その向上によって自分も助けられる。
なら、何も損になることはない。

知識を一般化し、より簡単に得られるようにすることで、全体が向上してきたことは歴史が証明している。
知識を広めないようにし、ひとところにとどめることで、独裁がうまれ、差別がうまれ、進歩が止まったのではないか?

まぁそれほど大げさに考える必要もないのかもしれない。

この仕事の知識の大きさはどうだろう?
広げる価値がある物なのか?それとも自分の利益を守るために死守すべきなのか?

死守したところで、いつか誰かが広める。
守りに入った人生は、退屈でもあるし、苦しくもある。
もし仕事がとられてしまうなら、自分はもっと高度な仕事につけばいい。
高度な仕事が存在しないなら、その仕事でできることはもうない。
違う仕事につけばいい。

けちけちするぐらいなら、そのほうがいいと思う。

それとも、これは頭の悪いやり方なのだろうか?



 
<2009/12/28 追記>
是非、このエントリに対するコメントも読んでください。 

私は上で、偉そうに理想論を述べていますが、よくよく考えてみると自分もすべてを公開しているわけではありませんし(時間的にもまとめきれませんw)。実際この業界の細かなスキルまですべて書き切れるものではないとは思います。

もしみんながそうすれば可能かもしれませんが、違う考えを持っている人に押しつけるつもりもありません。
やや批判的な書き方があったことは、反省しています。(まぁ以前、そうでなひとがいてあまり良い印象を持たなかったのが尾を引いていますね。)

まぁ、もともとそれほどすごいことをやっているわけでもないので、Melスクリプトに関してこのブログでやってきた方針を変えるつもりは、ありません。
この点に関しては、上記のことを貫いていこうと考えています。

ただ、これからの自分の考えをもう少し柔軟にしてもいいかなとは、思いました。
時と場合、おかれた環境、情報の内容など、臨機応変な対応も考えよる必要があるかもと思いました。

 

最近の勉強とこの1年のこと、これからのこと

ここのところ、仕事が無いので、一気にウインドウ関係のMelを習得してやろうと思い勉強し始めたのだが、最初簡単に考えていたが思ったよりいろいろな多岐にわたる知識が必要だった。

また、それらを勉強する間に、でてきた枝葉の部分を以前より腰をすえて明確にしようとしたところ、思いがけずこれまでたまっていた疑問を少しづつ解きほぐすことに役立った。

まだMelが使いこなせるようになるには時間がかかると思うが、ここ一年である程度は、成長したと思う。
当初の予定では、1年でかなり使えることろまで行きたかったが、生来の怠け心が邪魔をして半分ほどしか成し遂げられなかった。

しかし、このブログを書くことは、その怠け心を押さえ込むことに役に立った。
このペースで行けば来年には、自信をもってMelを作る事が出来るようになりそうだ。
(それじゃ遅いのだがw)

まぁ、昨年は、それを考えつつも何も出来ずに終ったことを考えると、今年は半分程度は進んだのでこれでも良しとすべきか?
人の歩みというか成長というのは期待するよりは遅い物だ。

確実に日々の勉学を続けることが以下に大切かを改めて感じさせられる。

このブログの左端上にILM 上杉 裕世氏の言葉をのせている。
「夢を実現するには目標を高く持ち、そこに至るまでの1つ1つのステップをおろそかにしないこと。」 

Melの勉強をやっている時には、できるだけ全力を尽くしてきたつもりだ。
しかし「1つ1つのステップをおろそかにしない」ということが出来たのかどうかはわからない。
なにかがおろそかになっていたような気もする。
(もしかして就職活動か?! そうだそれだ....。visa関係に気を取られてそちらをおろそかにしてしまったように思う。)

目標は揺れこともあるが、この言葉を見直したりいろいろな人と接することで、高い目標を何度も見直すことができた。

これからは、今自分がなにをおろそかにしているのか、それをより明確にしステップをより確実に踏んでいきたいと思う。

 
とりあえずMelに関してのこれからの学習予定は、
1)コントロール(スライダ、ラジオボタン、チェックボックス)、レイアウトについて
2)ランプシェーダーを使った、コントロール
3)GUIと連携したMelスクリプト
4)while文をはじめ、switch...case、for-in、breakと言った制御コマンドの習得
5)いま習得しておかなくては致命的なことになるParticleExpressionを洗いだし習得する。
6)関数の習得
7)ベクトルの値のやりとりでまだ明確でない部分をすっきりさせ、自信を持って使えるようにする。
8)配列に関して同上
9)行列の習得

これらにももっとあると思うが、こういった学習を進めていき、その過程で今現在、あいまいにしか理解していないために引き起こる問題(エラーが解決できない。エラーを解決するために処理が複雑になる)を解決していきたいと思っている。

またMel以外ではHoudiniの学習、Pythonの学習、Nukeの学習、トラディッショナルアートについても考えている。
 
まぁ、一番しなくちゃ行けないのは、今すぐ出来る仕事を見つけることなんだけど.....。
 
 

命令構文と関数構文(3): 「関数構文」

今回は最後に残った「関数構文」について調べていきます。

オンラインヘルプの「関数構文」の説明をよんでみましたが、(自分には)わかりにくいことこの上ない。
「関数構文はコンピュータ言語の標準的な関数コールに似ています。」

いくら何でも省略しすぎw
「Melはプログラミングの知識が無くても使えます」と言っておきながら、これでは「関数コール」というものがわかっていなければ理解することができない。

しかたないので、まず「関数」から調べていきます。


----------------------------------------
(1)数学用語の「関数」
関数」は英語で言うと「Function」、これは数学用語の「関数」も同じです。
どちらの「関数」も基本的概念は同じだからと思います。
(きっと、数学の「関数」からきているのだと思います)

これについてはKIT数学ナビゲーションにある「関数」の説明がわかりやすい。

特に図に書いてある
「ある入力に対して一つの出力に変換する機能を持つ箱」
という考えは、プログラミング用語の「関数」にも当てはまると思います。


----------------------------------------
(2)プログラミング用語の「関数」

ではプログラミング用語の関数の定義を見ていきます。

IT用語辞典BINARY
関数とは、入力された値に対してある決まった内容の計算を行い、入力された値に応じた処理結果を返す、数式、あるいは命令の集まりのことである。


IT用語辞典e-Words
関数とは、引数と呼ばれるデータを受け取り、定められた通りの処理を実行して結果を返す一連の命令群。

例えば「二つの数を受け取って、それらを合計した結果を返す」という命令は関数である。
この関数をfと呼ぶとすると、「関数fに引数1と2を与えると3という結果が返ってくる」ということになる。
必ずしも数字を扱うものだけを指すのではなく、「入力された文字を画面に表示する関数」なども存在する。
言語によっては引数を取らない関数や結果を返さない関数を作成できるものもあるが、通常はそうしたものは関数とは呼ばないことが多い。


wikipedia(サブルーチン)
サブルーチンを、
●結果として値を返すものと
●処理だけを行い値を返さないもの
に分類することがある。
その場合、前者を関数(かんすう)、後者を手続き(てつづき)と呼んで区別する。



以上の定義から考えてみた。

関数とは、
1)名前を持つ :「関数名」
2)入力値を持つ :「引数」
3)それに対して処理を行う。:「処理」
4)処理を実行して結果(値)を返す。:「戻り値」
以上を行うために必要な命令を書き並べたものが関数と言うことになる。
(参照:「Programing Place」の「C言語編 第8章 関数とは」)

※ここでいう「命令」とはMayaでは、MelのコマンドのことではなくC言語やAPIレベルの命令である。
(プロシージャを関数と考えればMelコマンドも上記の命令に該当すると考えることは可能)


----------------------------------------
(2)Mayaの関数

C言語では、あらかじめ用意されている関数を「ライブラリ関数」と呼ぶ。
また、プログラマが独自の関数を作る事もでき、それらは「ユーザー関数」と呼ばれる。
そしてどちらの関数も基本的には、上記の特徴(引数、処理、戻り値)をもっている。

Melではそれぞれ以下のように対応していると考えて良いだろう。
●ライブラリ関数(C言語): 関数(Mel)
●ユーザー関数(C言語): プロシージャ(Mel)


以下はMelにある関数の例である
例:sin, cos, log, mag, size, rand, linstep, eval

※関数には戻り値を持たない物もあると書かれている定義もありますが、Melでそれに該当するものがあるのかどうかは私にはわかりません。

「コマンド」との違いで思いつくのは、、
●フラグを持たない
●引数の入力
●戻り値がある。

「エクスプレッション」とも違います。見た目の違いは。
●左辺、右辺がない。


----------------------------------------
(3)「命令構文」と「関数構文」の違い

オンラインヘルプの「関数構文」のところをもう一度見てみます。
ここに表があり、例としてabs関数があげられています。

abs関数とは以下のような物です。
abs:数値の絶対値を返す、制限関数の一つ。

(例)
abs(-1):値 1 を返します。
abs(1):値1を返します。
abs(-2.43):値2.43を返します。

「関数構文」の説明にある表には命令構文と関数構文の表記の違いがならべて書いてあります。
●命令構文: abs -50
●関数構文: abs(-50)

両者をスクリプトエディタ上で実行するとどちらも、

// Result: 50 //
と返してきてスクリプトエディタでは、違いがわかりません。


しかしながらこれを代入演算子を使ったエクスプレッション「$a=*****」で使うと違いが見えてきます。


①まず、「命令構文」で記述したもの。
{
int $a;
$a = abs -50;
print $a;
}

// Error: $a = abs -50; //
// Error: Invalid use of Maya object "abs". //
エラーになりました。
これは「命令構文」では、戻り値をスクリプトエディタにしか出力しないためです。
その戻り値をコマンド(エクスプレッション)内で使う事ができません。


②次に、「関数構文」で記述したもの。
{
int $a;
$a = abs(-50);
print $a;
}

50
値「50」がきちんと出力されました。
これは「関数構文」で表記されていれば戻り値をコマンド(エクスプレッション)内で使う事ができることを示してるといえるでしょう。


③次に「命令構文」を「` `」で囲んだもの
{
int $a;
$a = `abs -50`;
print $a;
}

50
値「50」がきちんと出力されました。
これは「命令構文」表記であっても「` `」でその戻り値をコマンド(エクスプレション)内で使う事が出来るようになることを示しています。
いわば「`コマンド構文`」で関数のような利用ができると考えて良いかもしれません。


何となく「関数構文」と、「命令構文」のはたらきの違いがわかってきたように思います。


前にも調べたように、構文とはただの表記上の違いです。
難しく感じるのは、それにより期待できる動作が異なってくることです。

●命令構文: ( )を使わない: 戻り値を使えない
●関数構文: ( )を使う:    戻り値を利用できる


----------------------------------------
(4)関数コール

オンラインヘルプ「関数構文」には
「関数構文はコンピュータ言語の標準的な関数コールに似ています。」
と書いてありました。

「関数コール」とは何でしょう。それについて調べてみます。


●関数呼び出し(function call)

IT用語辞典BINARY
関数呼び出しとは、プログラムから関数サブプログラムや関数ライブラリを呼び出すことである。

GNU Octave 2.1.x 日本語マニュアル 「10.2 関数の呼び出し
関数を使用するための方法は,関数呼び出し式を使うことです。この式は,関数名と,それに続くかっこでくくられた引数のリストから構成されます。
その引数は,関数が実行する計算に用いる生の対象物を与える式です。
1つ以上の引数があるとき,それらはカンマで区切ります。
もし引数がなければ,カッコを省略することができます。
sqrt (x^2 + y^2) # 1個の引数
ones (n, m) # 2個の引数
rand () # 引数なし

AjaxTower 「関数の定義と呼び出し
関数を呼び出すには次の書式を使います。
関数名(引数1, 引数2, ...);
関数を呼び出す時には関数名の後の「(」と「)」の間に引数を指定して呼び出します。


C言語講座 & ライブラリ関数 - 呼び出しと引数
関数を呼び出す時は、
関数名( 引数 );
です。


これは、簡単ですね。
関数呼び出しとは、決められた手順にしたがって関数を使う事。

そしてその決められた手順とは
関数名の後に( )を使用し、その中に引数を入れるということ。

関数名(引数)

これがC言語などのプログラミング言語での関数コール(呼び出し)の方法です。

Melの「関数構文」もこれと同じだと言うことです。
ようするに関数構文とは、
●関数名
●(
●引数(複数の場合は、「,」で区切る)
●)
●;
という順番で並べた物です。


ここで、オンラインヘルプにある「attributeExists」の例をみてみます。
このコマンドは、「指定したアトリビュートが特定のノードに存在するかどうかを確認する」ものです。

先ほどのabs関数もこの「attributeExists」もコマンド自体のヘルプページには( )付で「関数構文」の表記で説明されています。
このあたり関数なのかコマンドなのか境目が曖昧ですね。

「関数構文」のところでは、例として「命令構文」での表記と「関数構文」での表記を並べてあります。
attributeExists visibility mySphere;(命令構文)
attributeExists("visibility","mySphere");(関数構文)


このような説明では、本来「関数構文」であるものを、わざわざ「命令構文」で使うメリットは何か?
また、逆に「命令構文」表記のコマンドを「関数構文」の表記に入れ替えることができるのか?
という疑問は残ります。
それともこれはヘルプ上で、違いをわかりやすくするための便宜的な物なのでしょうか?

----------------------------------------
まとめ
----------------------------------------
●関数とは「関数名」「引数」「処理」「戻り値」をもつ

●関数構文とは関数名の後に引数を( )で囲む表記方法。
関数名( 引数 );

●引数には数字、文字列、変数が利用できる。

●その引数が文字列である場合は、" "で囲む。

●「関数構文」では戻り値をコマンド/エクスプレション内で利用できる。

●「命令構文」では戻り値はスクリプトエディタ上にしか出力されない。

●「命令構文」を「` `」で囲めばその戻り値を利用できる。
 

命令構文と関数構文(2): 「命令構文」

さて「構文」の意味がわかったので、「命令構文と関数構文の違い」についてさらに調べていきたい。
「構文」の定義から推測すると、どちらも「具体的な記号や文字の使用方法と、配置」について説明しているはずである。

まずは「命令構文」について見ていきたい。


----------------------------------------
(1)「命令」の種類

オンラインヘルプ「命令構文」の説明として「命令コマンドの構文・・・・」と書かれている。
これは英語表記では「The imperative command syntax」となっている。

「命令」と「コマンド」という日本語ではどちらも「命令」と訳すことが出来るがここではあえて区別され使われているのでその理由を考えてみた。

調べるとコンピュータ用語で「命令」と訳すことができるのは「imperative」以外に
Instruction
command
のふたつがある。

まず、この二つの意味的な違いを明確にしておきたい。


●「命令(Instruction)」

Wikipedia
命令(めいれい)とはCPUが処理する操作のこと。
英語版Wikiをみると「単一の操作」となっている)
通常、命令操作部と複数のオペランドからなる。
あるいは操作者がコンピュータに入力する簡易な書式による指示の総称として用いられることもある。
通常、加算・減算・乗算・除算の四則演算、ロード・ストア命令、条件分岐命令などからなる。


IT用語辞典BINARY
この命令によって、CPUの動作を直接操作し演算処理やデータの入出力を行わせることが可能となる。



●「コマンド (command)」
Wikipedia
特定のタスクをコンピュータに実行させるための指示の一種であり、プログラムが一種のインタプリタとして解釈し実行する。
シェルなどのコマンド行インタフェースへの指示をコマンドと呼ぶことが多い。
(例:Unix系シェルなどで、ディレクトリを変更するための cd /home/peteといったコマンド)

IT用語辞典
コマンドとは、ユーザがキーボードなどで特定の文字列を入力してコンピュータに与える「命令」のこと。
DOSプロンプトやUNIXコンソールでの作業は基本的にコマンドを用いて行われる。
Windowsの「ファイル名を指定して実行」も、ファイル名をキーボード入力して起動するという意味で、コマンドの入力に近い特徴をもつ。


IT用語辞典BINARY
ソフトウェアの機能を指定し、実行させること。キャラクターベースのOS(CUI)やプログラミング言語で用いられる。


●違い
以上から考えると通常は以下のような意味らしい。
Instruction:CPUを直接的に操作するような命令のこと。
Command:インタプリタ的で、プログラム(ソフトウエア)が解釈し、機能を指定し実行するために使われる。

Melはインタプリタの性質を持っており、ソフトの機能を指定し実行しているので、「Command」ということになるだろう。
(実際ヘルプにはMelコマンドとなっているし)



オンラインヘルプで「命令構文」の説明では「命令コマンドの構文」とあるが、
「命令(Imperative)」は「構文(Syntax)」にかかっているのか、「コマンド(command)」にかかっているのかは、現時点の自分の知識では明確に出来なかった。
ここでのねらいは「関数構文」との違いを明確にすることなので、そのあたりは将来の課題としておき、先へ進みたい。


----------------------------------------
(2)命令構文

オンラインヘルプの「命令構文」をもう一度、読み直してみる。
命令コマンドの構文は、UNIX や DOS シェルのコマンドに似ており、コマンド名の後に任意のフラグや引数を使用します。
sphere -name "martha" -radius 10;
命令形は完結した文で、末尾には必ずセミコロンを付けます。


この部分の記述は以前ははっきりとわからなかったが、「Command」の意味を調べたことから、Melのコマンドがシェルのコマンドと類似していることがすんなりと理解できるようになった。
これは「Command」の意味を調べなければ、UNIXやDOSのことが述べてある理由はわからないままだった。

こういう予備知識がないとすんなりとは理解しずらいことが、平気で、しかも突然でてくるので、コンピュータ系の勉強は混乱させられることが多い。
しかも「知ってて当然」みたいなので、初心者向けの説明のはずなのに「知らないの?」とイヤミをいわれているような気持ちにさえなる。
知らないのに一生懸命勉強している側からすれば、イヤミか、もしくはいじめか、それとも教える側が高飛車なのか、知識をひけらかそうとしているのか?と邪推してしまう。
これがコンピュータの学習の嫌なところだ。w


さて、オンラインヘルプの続きを見ると、以下のように書いてある。
エクスプレッションの一部としてコマンドの命令構文を使用する場合には、コマンドをバッククォーテーションで囲む必要があります。


●エクスプレション

ここで「エクスプレッション」とはどういうものか、もう一度、おさらいしてみたい。
以前のエントリ「構文 (1)」でもふれたことがあるが、オンラインヘルプ「エクスプレッション、演算子および文」には以下のように書かれている。
エクスプレッションとは、新しい値を導く一連の値と演算子です。
MEL のコマンド構文でエクスプレッションを使用する場合、エクスプレッションをカッコで囲む必要があります。

「演算子」とは「+」「-」「*」「/」といった算術演算子、「==」 「<」といった比較演算子、「!」「&&」といった論理演算子のことである。また変数の代入に使う「=」は代入演算子である。 「新しい値を導く一連の値と演算子」の具体例としては、「5 == 10」というような表記がそうだ。

2行目で述べているのは、エクスプレッションをMelコマンド構文内で使うことについて述べている。
「コマンド構文」には「命令構文」も「関数構文」も含まれることは前回調べたとおり。
それらの文の中でエクスプレッションを使うときはエクスプレッションを「( )」で囲むことが必要と言っている。

これについては例をあげて検証していきたい。

(例1)
if文の条件部分を書くとき、
if($a=1);

などと記載するが
if $a=1;

とは書かない。

これは「$a=1」がエクスプレッションだから「コマンド構文の中で使用するときには( )で囲む」という決まりに沿っているからだと思われる。


(例2)
printコマンドでエクスプレッションを使った例
print (Cone.scaleY + "\n");

(例3)
setAttrコマンドでエクスプレッションを使った例
setAttr ($object + ".tx") 2;


●エクスプレッションの一部として命令構文を使用する

話がエクスプレッションの説明にそれたので、再びオンラインヘルプ「命令構文」の説明文に戻ることにする。
エクスプレッションの一部として命令構文を使用する場合には、コマンドをバッククォーテーションで囲む必要があります。」と続いている。


(例1)代入演算子「=」を使った例
まず以下を実行するとエラーになる。
{
string $a[] = sphere -r 10;
print $a[0];
}
// Error: string $a[] = sphere -r 10; //
// Error: Invalid use of Maya object "r". //

代入演算子「=」を用いる場合それは、エクスプレッションである。
エクスプレッションの定義は「新しい値を導く一連の値と演算子」であり、代入演算子は右辺の値を左辺へ代入するエクスプレションである。

しかし、この例では、左辺は「変数」であり、右辺は「命令構文」となっている。
「変数」は「一連の値」の一つとみなすことができるが「命令構文」は「値」ではない
よってこれがエラーとなるのは理解できる。

「命令構文」のルール「エクスプレッションの一部として命令構文を使用する場合には、コマンドをバッククォーテーションで囲む」に従い、「sphere」コマンド部分をバッククォーテーションで囲めば、エクスプレッションの一部として正常に動作し、$a[0]に「nurbsSphere1」の名前が収まる。

{
string $a[] = `sphere -r 10`;
print $a[0];
}

nurbsSphere1 (スクリプトエディター内の出力)

これは「sphere」コマンド(命令構文)を実行した結果の戻り値と一致している。
sphere;
// Result: nurbsSphere1 makeNurbSphere1 //

ちなみにこの戻り値には「makeNurbSphere1」があるが上記のスクリプトの$a[0]を$a[1]に変更すればその戻り値がきちんと格納されていることが確認できる。


ここでふと疑問に思うのが「sphere」コマンド自体に戻り値はある。
ちゃんとスクリプトエディターには出力されている。
それなのになぜ機能しなかったのか?

実は、このことはオンライヘルプ「コマンド構文」の最後に明記してある。
戻り値を使用する: 関数構文とバッククォーテーション
命令構文を使用すると、コマンドはスクリプト エディタ(Script Editor)に戻り値を出力するだけで、使用できる戻り値は提供されません。


(例2)比較演算子を使用するエクスプレッションの例
まず、
sphere -r 5;
で半径5のNurbsスフィアを作成。

そのスフィアが選択された状態で、以下のスクリプトを実行。

if(`sphere -query -r` == 5)
print "radius is 5";
}

これで「radius is 5」と表示される。

if文はコマンド構文であり、比較演算子を使う部分は左辺、右辺を含めてエクスプレッションである
コマンド構文内でエクスプレッションを使用するので、エクスプレッションをカッコ「( )」で囲む必要がある。
(***** == 5)

またエクスプレッションの一部として命令構文「sphere -query -r」を使っている
よって、それをバッククォーテーションで囲む必要がある。
`sphere -query -r`

上記二つのルールが組み合わさったことにより、
(`sphere -query -r` == 5)
という表記ができあがっている。



上記のことから「`(命令構文)`」=「戻り値」=「値」であることがわかる。


これと似たような機能をするのが「eval」である。

evalの場合は、「( )」の中身をstringとして扱うので「" "」で囲む。
{
string $a[] = eval("sphere -r 10");
print $a[0];
}

しかし、evalの場合、ヘルプにあるとおり、「戻り値は、コマンドを実行した結果を表す文字列」である。
 

----------------------------------------
まとめ
----------------------------------------
●「Command」とは特定のタスクをコンピュータに実行させるための指示
 ソフトウエアが一種のインタプリタとして解釈、実行する。
 Melコマンドという名前が示すとおりである。

●命令構文:コマンド名の後に任意のフラグや引数を使用する。
命令形は完結した文で、末尾には必ずセミコロンを付けます。

●「命令構文」は戻り値をスクリプトエディタ上にしか出力できない。

●エクスプレッションとは、新しい値を導く一連の値と演算子。
(例)代入演算子、比較演算子などを用いる場合その左辺と右辺を含めてエクスプレッションである。

●「`(命令構文)`」=「戻り値」=「値」=「変数」と相互に入れ替えることが出来る。

●コマンド構文の中でエクスプレッションを使用する場合、エクスプレッションをカッコで囲む。
(例1)コマンド構文########(エクスプレッション)########
(例2)if($a=1);
(例3)setAttr ($object + ".tx") 2;

●エクスプレッションの一部として命令構文を使用する場合には、コマンドをバッククォーテーションで囲む。
(例1)エクスプレッション*********`コマンド(命令構文)`*********
(例2)string $a[] = `sphere -r 10`;
(例3)if(`sphere -query -r` == 5)

●コマンド構文の中で、エクスプレッションを使用し、かつエクスプレッションの一部として命令構文を使っている場合。
(例1)コマンド構文####(エクスプレッション****`コマンド(命令構文)`****)####
(例2)if(`sphere -query -r` == 5)

<例によって、知識不足から来る間違いがあるかもしれませんので、使用に当たっては自分で確認をしてください。>

「命令構文」の定義については、調べ切れていないと思っているので、わかり次第、追加したいと思っています。
 
  

2009年12月27日日曜日

命令構文と関数構文(1): 「文法」と「構文」の違い

先日のエントリ「Fieldコントロール(3):floatField(2)」の「(2)値を変数へ代入」のところで、オンラインヘルプの「戻り値を使用する: 関数構文とバッククォーテーション」にある以下の内容を転載している。

コマンドの関数構文を使用すると、コマンドは値を返します。
命令構文を使用すると、コマンドはスクリプト エディタ(Script Editor)に戻り値を出力するだけで、使用できる戻り値は提供されません。
エクスプレッションで命令構文を使用すると構文エラーの原因となります。


実は、この内容はよく理解出来なかった。
そこで今回、そこにある疑問を解決し、明確に理解できるようにしようと思う。


----------------------------------------
この文章で、まず分からなかったのが
「命令構文」「関数構文」の違い。

同じページの上方に、それぞれの説明が具体例もふくめて書いてあるのだが、今ひとつ頭の中で結びつかない。とくに、「関数構文」の説明は、よくわからなかった。

このオンラインヘルプのページ見出しは「コマンド構文」となっている。
そしてその中の小見出しに「命令構文」とある。

最初に疑問に思ったのは、この二つは同じことではないのか?
ただ日本語の訳で変えているだけではないのか?という疑問だった。
というのが「命令」って英語でいうと「コマンド」でもあるからだ。

そこで、まず、それぞれの表記を英語のオンラインヘルプで確認してみた。
コマンド構文=Command syntax
命令構文=Imperative syntax
関数構文=Function syntax
(ちなみに「フラグ」はflags、「引数」はargumentsである。)

日本語の「命令」は「Command」と訳すことも出来る(goo辞書)が、あえて「Imperative」となっているのは、この言葉が文法的な性質を持っていることを示しているからで、通常は「命令に使われる動詞の形」を示す言葉である。(ワードパワー英英和辞典)

ようするに「Imperative syntax」とは、後に続く単語「Syntax(構文)」が命令文の性質を持っていることを示唆している。
意味的には日本語の「命令」でも良いと思われるが文法的な物につかわれる用語ということだ。
それにしても英語には「命令」を意味する単語が多い、これは命令というものに対してのいろいろなニュアンスをわけて考えるような習慣があるのだろうか?

さて、これで、英語表記では明確に異なっていることがわかった。
「コマンド構文」と「命令構文」は違う単語なのである。


----------------------------------------
(1)構文

実は、ここでもう一つ疑問がでてきた。
それは、「Syntax」という単語だ。
英語で見るまで自分は文法を勉強しているのだと思っていたがSyntaxが「構文」と訳されている。

これは、日本語で「文法」ではなかったか?
なぜわざわざ「構文」となっているのか?
「文法」と「構文」の意味は同じなのか違うのか?

というのも命令構文と関数構文の違いを理解する上で、この言葉「構文」が理解を妨げ、混乱の一因となっているような気がするからだ。

こういった頭の中での些細な混乱が、バタフライエフェクトのようにより大きな問題となり、何か別のことやより高度なことを理解しようとするとき、それをさまたげたり、いっそう混乱をひきおこすことがよくある。
このあたりの些細な疑問というのは人によって違うケースもあるので、明確に理解できている人からすると、何を馬鹿なことにこだわっているのかと思えることもあるだろう。
しかしこのブログは個人的な物、遠慮無く調べていきたい。w

そもそも「Syntax=文法」という考えは、ずっと以前にBasicを勉強していたときに身についた。

昔、Basicでは、入力間違いをすると「文法エラー」と表示されることがあった。
Basicはそのパソコンメーカーによって異なり、「Syntax Error」と表示される機種もあったため、どちらも同じ意味を示していたことから、Syntax=文法と解釈していた。


では、なぜMayaのオンラインヘルプでは「構文」となっているのか?
また「構文」とはどんな意味があるのか?
まずは辞書で「Syntax」の定義を調べてみた。

@IT XML用語辞典
シンタックスとは、構文を意味する。具体的な文字がどのように配列されているかに着目した概念を示す言葉である。

IT用語辞典BINARY
シンタックスとは、もともと「構文」や「統語論」を意味する英語である。
(このページは「シンタックス・エラー」の解説であるが上記のように「シンタックス」の説明が書かれている。また「別名」として「文法エラー」と「構文エラー」の二つがあり、「シンタックス」が両方の意味で使われていることがわかる。)


以上の定義からは、「シンタックス」=「構文」で間違いないことがわかる。

おそらく昔のBasicユーザーには、小中学生も含まれており、英語に親しみのない人にもわかりやすくするためにエラー表記を日本語にしていたのだと思う。
そのときに、翻訳のミスか、ユーザーがプログラミングが初めての人が多いとういことに配慮して一般的にもわかりやすい「文法」という言葉を選んだのかは定かではない。
どちらにしても、これが混乱の源だった。
まぁよくよく考えてみれば、確かに「文法」を英語でいうと「Grammar」であり、「Syntax」ではないので正確な訳ではないことは注意深く調べればわかったかもしれない。



----------------------------------------
2)文法

では「文法」の定義は何か?

wikipedia
文法(ぶんぽう)とは、ある言語において、その言語のより小さな単位を連結してより大きな構造を作る際の規則である。


以上の定義で、なんとなくわかってきたが、もう少し「文法」と「構文」の違いを明確にしておきたいと思う。

面白い物で英語の学習においても同じような疑問を持った人がいて、Yahoo知恵袋で質問していた。
Yahoo知恵袋;「英語の「構文」と「文法」とは何処が、違うのでしょうか?教えて下さい。」
回答:文法とは、語学を分析して、どういうルールで解釈していくのかをまとめたものです。例えばDVDプレーヤー本体が英語とすると、文法は取扱説明書だと思ってください。
構文というのは、その中で具体的に、文法で分析した内容を文章にしてわかりやすく示したものです。

DVDプレーヤーを使ってどうやってDVDを見ればいいのかわかったあなたは、再生ボタンを押してスタートさせますよね。その再生ボタンそのものが構文だと思ってください。
説明書を読んで使い方がわからなくても、ボタンを押したらスタートして見ることができる、というわけです。

個人的には、わかったような今ひとつのような感じだが、
「文法」はそれぞれの単語同志の関係やつながり、機能などを説明した物。
「構文」は、具体的な表記(記号やアルファベット)とその位置などを明確に定めた物
したがって「文法」をしらずとも「構文」がわかっていればとりあえず、プログラムは書ける。
しかしその逆はできない。
ということでよいだろうか。


もうひとつ、信州大学海尻賢二教授による「プログラミング言語論(2009年度)」のシラバスにある「構文と意味」というページが参考になる。
以下に、そのページから一部を引用した。

次の様な表現を考えよう
i = i + 1
この表現が正しいとは何を意味しているか?
例えばi=i+1+は正しくない。この形としての正しさを定める規則が構文規則である

# 文法は正しい文(プログラム)を定義する
# 文法によるプログラムの定義には、語彙、構文、意味という階層がある

余談だがこの言語論、なかなかおもしろそう。まだすべて読んだわけではないので言い切れないですが、先日のエントリ「プログラミングの勉強方に関して(メモ)」で述べた考えをさらにまとめるための助けとなりそうです。


----------------------------------------
まとめ
----------------------------------------
さて「文法」と「構文」の違いについての自分の解釈をまとめてみます。

「文法」は「構文」より広い意味を持ち、「構文」は「文法」に含まれる

「文法」を知らずとも「構文」がわかっていれば、プログラムは書ける。しかしその逆は否。

「構文の間違い」という意味で「文法の間違い」と表記されることがある。

●「文法」はそれぞれの単語(コマンドなど)を使うときに、どういった時に、どういうふうに、どういったことに使い、どういった動作をするのかといったことの決まりである。
「if文は条件式を使って判断し、判定がTrueの場合は、実行文に書かれた内容を実行する、Falseの場合は実行しない」といった内容。

「構文」とは具体的な文字または記号の配列についての決まりである。
「If文において、条件文は「( )」内に表記、実行文は条件文に続けて「{ }」を使って書く、実行文の各行は「;」で区切る。」といった具体的な記述における決まりが「構文」ということだろう。

「構文」は厳格に、正確に理解する必要がある。
「具体的」ということは曖昧さはみとめられないということでもある。


「文法」の定義は上記wikipediaが、自分にとって一番わかりやすかった
その言語のより小さな単位を連結してより大きな構造を作る際の規則である。

「構文」については@IT XML用語辞典が簡潔で分かりやすかった
具体的な文字がどのように配列されているかに着目した概念を示す。

  

2009年12月26日土曜日

Youtube 「20年の空飛ぶ交流 ピクサーとジブリ」

「20年の空飛ぶ交流 ピクサーとジブリ」というタイトルでピクサーとジブリの取材をした映像がYoutubeにありました。



おそらく12月3日のめざましテレビ」だと思われます。


ジョン・ラセターも宮崎駿も同じストーリーは二度とやらないという同じ考えを持っているのは、ストーリーテラーとしての社会に対する自分の役割を強く認識しているからでしょうね。

また、スタジオジブリのプロデューサー鈴木敏夫氏がカールじいさんの空飛ぶ家の冒頭10分間のことをべた褒めでしたね。

自分も、あの10分間はアニメーションという技法を最大に生かした、すばらしいショットだと思いました。
個人的には、白い犬ダグ、怪鳥ケヴィンとの出会うあたりも好きです。
犬好きなので、細かな犬の癖など、よく観察してるなと思いました。まぁ観察だけではなくそれを演出にまで押し上げていることがすごいところですが。

 

Fieldコントロール(4):floatField(3)


「フィールド入力値をスクリプトで利用する」
という目的を達成出来る方法は二つあると前回書きました。それは以下の二つです。
1)フィールド入力値を変数へ代入
2)または、フィールドをアトリビュートに接続


今回は「2」の方です。

この接続は「-attribute」フラグを持つ以下のコマンドであれば簡単にできます。
「attrFieldGrp」, 「attrFieldSliderGrp」, 「attrColorSliderGrp」
しかしながら、
●「attrFieldGrp」は、「Vectorアトリビュート」との接続のみ。
●「attrFieldSliderGrp」は単独のアトリビュートに使えるが、スライダーが附属。
という感じでしっくりきません。
(ちなみに「attrFieldSliderGrp」についてはDigitalMatrixで説明されています。)



また今回使用したい「floatFiled」コントロールには「-attribute」フラグがありません。
したがって、アトリビュートへの接続はできません。

こういった「-attribute」フラグを持たないコントロールをアトリビュートへ接続するには、「connectControl」が使えます。

「connectControl」を使うと以下の事が可能になります。
●「-attribute」フラグを持たないコントロールとアトリビュートを双方向コネクションする

これにより、値の変更はリアルタイムに反映されます。
実際の動作を、説明すると以下の通りです。
1)コントロールで数値を変えれば、接続されたアトリビュートの値が連動して変わる。
2)アトリビュートの数値をチャンネルボックスなどから変更すれば、接続されたコントロールの数値も変わる。

よって、
●ビュー内で対象の変化を確認しながら使いたい場合には便利です。

ヘルプによると、フィールド、スクロールバー、スライダー、チェックボックス、ラジオボタン(コレクション)などのコマンドに使用できます。
ヘルプに掲載されている使用可能なコマンド例は、以下の通り
floatField, floatScrollBar, floatSlider, intField, intScrollBar, intSlider, floatFieldGrp, intFieldGrp, checkBox, radioCollection, optionMenu



話が少しそれますが、「connectControl」については、検索してたときに偶然みつけたページ「オレコンのすすめ2(ちょっと前進編)」で知りました。

NHK人体2の製作や、CG映画のファイナルファンタジーでキャラクター製作に関わり現在はフリーでご活躍のKonKonさんという方が作られたページらしく、「ウインドウ作成」と「コントロール」に関して、とても簡潔かつ要点をおさえて書かれています。

なお、現在、KonKonさんのホームページ「特殊映像研究会」からは上記のページへたどり着くリンクを見つけることは出来ませんでした。意図的なものかもしれないので、上記のページへのリンクは当ブログには掲載しませんでした。どうしてもみたい方はGoogle検索してみてください。


----------------------------------------
(1)「connectControl」

実際の使用例としては、オレコンのすすめ2(ちょっと前進編)」にも、いくつかの例が載っています。
今回は、それを参考にして、自分なりのスクリプトを作りました。
{
sphere;
window name;

columnLayout;
floatField testField;

connectControl
testField "nurbsSphere1.sx";


showWindow;
}

Nurbsスフィアが一つ作成され、フィールドの数値を変えるとX方向へスケールされます。

スクリプトエディターのヒストリ欄を見ると、
setAttr "nurbsSphere1.scaleX" 1.115;
と言った表記が見つかります。

要するにsetAttrを実行してアトリビュートをリアルタイムに反映しているということです。

実はこれは、通常オブジェクトのアトリビュート値を「チャンネルボックス」や「アトリビュート・エディター」で値を変更したときの動作で特別な物ではありません。
「チャンネルボックス」や「アトリビュート・エディター」から値を入力するのと同じ事がおきているということです。

逆に「チャンネル・ボックス」から値を変更した場合も通常通り「setAttr」が実行されますが、同時にウインドウ内のフィールドの値も変更されます。
(図:アトリビュートの相互関係)


ここでちょっと気になったのが、
チャンネルボックスで見るとエクスプレッションやキーフレームのようにアトリビュートに接続を示す色はありません。
Hypergraphで見ても、接続を示す→などは見あたりません。

では、この「connectControl」で接続されているアトリビュートにエクスプレッションを使うとどうなるか試してみました。

ポリゴン・キューブを一つ作成し、
nurbsSphere1.scaleX = pCube1.translateX;
というエクスプレッションを作成しました。

キューブをX方向へ移動するとスフィアはその位置に応じてスケールされます。
そしてフィールド内の値も変更されます。
この場合「setAttr」は使われません。

次にフィールド内の数値を変えると、「setAttr」は実行されますが、その数値は反映されません。
これはエクスプレッションが存在するアトリビュートに値を入力しても反映されないのと同じです。
またエクスプレッションを削除すれば、元通り連係動作をします。

要は、このフィールドは完全にチャンネルボックスやアトリビュート・エディター内の該当アトリビュートのフィールドと同じということです。

それらのフィールドを、どこに表示しているかの違いだけです。
(もちろん、アイデア次第で異なる使い方もできるとは思います。)

また、すでに存在する対象のアトリビュートを操作するためのMelには向いていますが、 アトリビュートが存在しない状態で、数値を設定する必要があるクリエイト系のスクリプトには向いてないと思われます。(使えなくはないでしょうが、より複雑になりそうです)



----------------------------------------
(2)簡単便利な「attrControlGrp」

オンラインヘルプで調べて居るときに偶然見つけたのですが、これはひょっとしたら上記のコマンドより簡単で便利な気がします。
ひょっとすると初心者はこれ一つですべて間に合うかもしれません。

それが「attrControlGrp」です。

オンラインヘルプには以下のように説明されています。
「このコマンドは、指定したアトリビュートに最適なタイプのコントロールを作成し、そのコントロールをアトリビュートと関連付けます」

これを使えば
●他のコントロール・コマンドを覚える必要がない。(例外はあります)
●「-attribute」フラグで、特定のアトリビュートへの接続ができます。

早速使ってみます。
{
window name;
columnLayout;

attrControlGrp -attribute "nurbsSphere1.tx";

showWindow;

}

これを実行するだけで、以下の事が自動的に行われます。
●「Translate X」というラベル名の作成
●「floatField」をウインドウ内に作成
●「nurbsSphere1のTranslateXアトリビュート」への接続

(図:attrControlGrpをTranslateXへ使った結果)



floatFieldは簡単なので、やや複雑な例をみてみましょう。
ここでは、ランバート・シェーダーのカラー・アトリビュートのコントロールを作ってみます。
{
window name;
columnLayout;
attrControlGrp -attribute "lambert1.color";
showWindow;
}

●ラベル
●カラー キャンバス
●スライダ
●ボタン
が自動的に作成されます。
(図:attrControlGrpをカラー・アトリビュートへ使った結果)

これは「attrColorSliderGrp」を使用した場合と同じ結果です。
上記のフィールドを作成したのと同じコマンドで達成できています。


このように「attrControlGrp」は個々コントロールの知識が無くても簡単に作成できます。
ただしヘルプにも書いてあるように、万能ではありません。
「すべてのアトリビュート タイプがサポートされているわけではありません。」


----------------------------------------
さて上記の方法を使った場合、入力値を対象アトリビュート以外でスクリプト内で使うには、もう一工夫必要です。(変数への代入など)
しかしながら、現在の自分の計画にはそういった用途がないので、今回は掘り下げることはしません。



----------------------------------------
まとめ
----------------------------------------
アトリビュートとコントロールを結びつけるには

(1)「-attribute」フラグのあるコントロールを使う。
(例)attrFieldGrp、attrFieldSliderGrp、attrColorSliderGrpなど

(2)「connectControl」を「-attribute」フラグのないコントロールと組み合わせて使用。

(3)「attrControlGrp」を使えば、最適なコントロールを知らなくても自動的に作ってくれる。

(4)アトリビュートとの接続なので、該当アトリビュートがすでに存在している必要がある。

(5)接続するアトリビュートが存在しない、クリエイト系のスクリプトには向かない。(?)

(6)これは、チャンネルボックスやアトリビュート・エディターから該当アトリビュートの値を変更するのと同じこと。

(7)リアルタイムに処理が反映される

(8)入力値をスクリプト内で使うには「getAttr」を使うなどもう一工夫必要。

 

Fieldコントロール(3):floatField(2)

前回のフラグの検証では、目的の結果はえられなかった。

混乱したときや、道を見失いそうなときは目的を思い出すのが重要w
ここでもう一度、目的を明確にしてみました。

「フィールド入力値をスクリプトで利用する」 これが目的です。

具体的に、求めているのは

1)フィールド入力値を変数へ代入
2)または、フィールドをアトリビュートに接続

のどちらかが、起きれば良いと言うことになる。

その答えは意外と早く見つかりました。

----------------------------------------
変数へ値を代入する方法の段階的アプローチ
----------------------------------------
(1)-queryモード

まず「1)入力値を変数へ代入する」手順について
これのヒントはDigital Matrixの「スライダ」のページにヒントがありました。

スライダ」ページ→「スライダの使い方」→「2.スライダの値を取得
に書かれている「-query」フラグを使う方法がそのままフィールド・コントロールに使えます。

「-query」フラグについては、オンラインヘルプの「コマンド構文」→「作成、編集および照会モード 」にもう少し詳しく、書かれています。
「-query フラグを付記してコマンドを使用する場合、コマンドは指定されたオブジェクトのプロパティの値(他のフラグによって決まる)を返します。 」

結論から言えば「floatField」は、「-value」フラグを持っているので、「-query」フラグを使えば、その値を取得できます。


具体的には以下のようになります。

flatField -q -value フィールド名;


さて実際にこれが機能するかどうかをまずテストします。

まず以下のスクリプトで「testField」という名前のfloatFieldを作ります。

{
window name;
columnLayout;

floatField testField;
showWindow;
}


そして任意の値(例:0.8730)に変更し、以下のコマンドを実行。
floatField -q -value testField;
// Result: 0.873 //

ちゃんと値が返ってきました。


----------------------------------------
(2)値を変数へ代入

次のステップは、この値をどのように変数へ代入するかという話になります。

これも先ほどのオンラインヘルプの一番下にヒントがあります。
「戻り値を使用する: 関数構文とバッククォーテーション 」
命令構文を使用すると、コマンドはスクリプト エディタ(Script Editor)に戻り値を出力するだけで、使用できる戻り値は提供されません。
エクスプレッションの照会モードでコマンドの戻り値を使用する場合には、よくバッククォーテーションが使用されます。
if (`sphere -query -radius "mySphere"` == 5)
print("This sphere has a radius of 5!";


この例のif文の条件式だけをみると以下のようにクエリーモードでスフィアの半径を照会している。
`クエリーモードのsphereコマンド` == 5)

もっと短くすると以下のようになる。
(半径の値==5)

ここから解釈すると、いかが成り立つ
「半径の値」=(イコール)「`sphere -query -radius "mySphere"`」


これを応用して、「半径の値」を変数「$a」へ代入する式は以下のようになる。
$a=半径の値

この右辺を上記のコマンドと置き換えると、以下のようになる。
$a=`sphere -query -radius "mySphere"`;


Digital Matrixの同ページ「スライダの使用例」でも同じ方法が使われている。


-------------
ではこれを早速使ってみます。
{
window name;
columnLayout;

floatField -value 0.8555 testField;
showWindow;

float $a;
$a =`floatField -q -value testField`;
print $a;
}

これできちんと
0.8555
と表示されました。


----------------------------------------
(3)値を取得するタイミングを設定する。

変数へ代入することはできましたが、このままではスクリプトを実行した最初に値を取得するだけで、後の変更については反映されません。

反映させるためには以下のステップを踏む必要があります。
A)フィールドを持ったウインドウが表示される。
B)フィールドの値をユーザーが変更する。
C)値を取得する。

ステップBは、ユーザーの行う操作なので、コンピュータの自動的な処理はいったん停止している必要があります。
そしてステップCでは再びコンピュータの自動的な処理を開始します。
ようするに、ユーザーが自分の入力作業が終了した段階で、コンピュータに続きの処理を開始させる必要があります。


上記のスクリプトでは、それがありません。

もう少しわかりやすくステップを書き直すと
A)フィールドを持ったウインドウが表示される。
B)スクリプトの処理を停止
C)フィールドの値をユーザーが変更する。
D)スクリプトの処理を再開
E)値を取得する。


これを行うには、ステップD以降の処理を「別のスクリプト」すなわち、「プロシージャ」としてまとめておけば、明確に処理を分けることが出来、考えるのも簡単になります。

そのプロシージャに含めるべき物は以下のものです。
●-queryフラグで値を取得するステップ
●その値を利用したアクション


そのプロシージャを実行するタイミングですが
二つの方法が有効だと思われます。
●ボタン・コントロールを使いボタンを押したときに-commandフラグでプロシージャを実行。
●floatfiledコマンドの-enterCommandフラグを使い、Enterを押した時、プロシージャーを自動実行


まず両方に共通している要素、「プロシージャ」部分を作成します。
ポリゴン・プレーンをスケールを変えて作成するプロシージャです。

global proc testPlane()
{
float $a;
$a = `floatField -query -value testField`;
polyPlane;
scale $a $a $a;
}



次にボタンとフィールドをもつウインドウを作成。

window name;
columnLayout;

floatField testField;

button -label Create -command "testPlane()";

showWindow;

}


--------
これを一つにまとめます。
{
global proc testPlane()
{
float $a;
$a = `floatField -query -value testField`;
polyPlane;
scale $a $a $a;
}

window name;
columnLayout;

floatField testField;

button -label Create -command "testPlane()";

showWindow;
}


これで、スケールの異なる、プレーンを作成するウインドウができました。



----------------------------------------
(おまけ)-enterCommandフラグを使った方法。

いちいちボタンをおさなくても良いのでボタン・コマンドを使う必要はありません。
しかし、ミスも起きやすいかと思いますので、オブジェクトの作成に使うには向いてない方法かもしれません。


{
global proc testPlane()
{
float $a;
$a = `floatField -q -value testField`;
polyPlane;
scale $a $a $a;
}

window name;
columnLayout;

floatField -enterCommand "testPlane()" testField;

showWindow;
}


----------------------------------------
まとめ
----------------------------------------
フィールドに値を入力し、それをスクリプトで活用するには、

(1)-queryフラグをフィールド・コマンドに使い値を取得する。
(例)floatField -q -value testField

(2)``を使ってそのクエリーコマンドから変数へ値を代入する。
(例)$a = `floatField -q -value testField`;

(3)値の取得と、その後の処理はプロシージャにまとめる。
   「プロシージャ」+「ウインドウ作成」とブロック分けして考える。

(4)値を入力後に、プロシージャを実行する。(buttonコマンドを使うと良い)

Fieldコントロール(2):floatField(1)

今回は実際にフィールドを使ってみます。

時間の無駄にならないように前もって言っておきますが、今回のエントリは、あまり役に立たないと思います。

このエントリでは、floatFieldコマンドと以下のフラグをテストしました。
結論から言うと、目的である「フィールドへの入力値をスクリプトで利用する」ことはこれらのフラグではできません。(少なくとも現在の私の知識では)

(このエントリで試したフラグ一覧)
-changeCommand
-enterCommand
-dragCommand
-receiveFocusCommand
-annotation


----------------------------------------
では以前、一番必要性を感じた「floatField」から検証していきたいと思います。。

使用する基本的フォーマットは以下の通りです。
なお行数が増えて見づらくなるので、同じ名前のウインドウが存在する場合に削除するif文+deleteUIの行は含めていません。

{
window name;
columnLayout;

<コントロール・コマンド>

showWindow;
}


----------------------------------------
まずは「floatField」コマンドをフラグ無しで使った場合。
ウインドウ内にフィールドが作成されます。
値を変えてもなにも起こりません。

{
window name;
columnLayout;

floatField;
showWindow;
}



とりあえず何か値を変更した時に、反応することで、フィールドがちゃんと生きていることを確認してみようと思います。
オンラインヘルプで、それらしいフラグを探してみたところ以下のような物がありました。


-changeCommand(-cc):フィールドが変更されたときに実行されるコマンドです。値が -v/value フラグによって変更されたときはこのコマンドは起動されません。

-enterCommand(-ec):キーパッドの「Enter」キーが押されたときに実行されるコマンドです。

-dragCommand(-dc):フィールドでドラッグしたときに実行されるコマンドです。

-receiveFocusCommand(-rfc):フィールドにフォーカスが移ったときに実行されるコマンドです。


それぞれ検証してみます。

----------------------------------------
<-changeCommand>
値が変更されるとNurbsスフィアが作られます。
値を変更するには以下のような方法があります。
フィールドでCtrl+LMBドラッグする。
値をキー入力してEnterを押す。
値が変わってないばあいはEnterキーを押しても何も起きません。

{
window name;
columnLayout;

floatField -changeCommand sphere;
showWindow;
}



----------------------------------------
<-enterCommand>
フィールドに値を入力し、(テンキー側の)Enterが押された瞬間にNurbsスフィアが作成されます。
値が同じでもEnterキーが押されれば実行されます。

{
window name;
columnLayout;

floatField -enterCommand sphere;
showWindow;
}


----------------------------------------
<-dragCommand>
フィールドにマウスポインターを移動し、左(または右)マウスボタンをドラッグすると次々とスフィアが作成されます。ちょっとやっただけで60個のスフィアが作成されました。
私のマシンでは、タブレットしかないためマウスでの正確な動作はわかりませんが、タブレットではクリックした時点でひとつのスフィアが作成されました。(微細な手ぶれをドラッグとして認識しているのかもしれません)
また中ボタンには反応しません。

{
window name;
columnLayout;

floatField -dragCommand sphere;
showWindow;
}


----------------------------------------
<-receiveFocusCommand>
この例では動作をわかりやすくするためにfloatFieldコマンドを二度つかっています。
それぞれ、マウスでフィールドをクリックしてフォーカスされた場合にNurbsオブジェクトを作成します。
上のフィールドがフォーカスされたらNurbsスフィア。
下のフィールドがフォーカスされたらNrubsシリンダが作成されます。

{
window name;
columnLayout;

floatField -receiveFocusCommand sphere;
floatField -receiveFocusCommand cylinder;

showWindow;
}



結論から言うと、それぞれフラグの名前通りの動作をするだけ。
これらのフラグはただ単にボタンの「-command」フラグと同じ働きをするだけだ。
目的とする「入力された値を利用する」ためのフラグではなかった。 


----------------------------------------
ついでなので、気になった「-annotation」フラグの働きも確認してみた。

-annotation(-ann): コントロールに文字列値で注釈を付ける。
フィールド上にマウス・ポインターをあわせたとき、ヘルプ・ラインへ注釈が表示される。
例1:floatField -annotation test;


注釈がスペースを含む場合は、「" "(ダブルクォーテーション)」で囲む
例2:floatField -annotation "test 1";

 

プログラミングの勉強方に関して(メモ)

初心者がプログラミングを勉強するときにネックとなるのは、

1)プログラミング言語の文法
2)プログラミング言語の語彙
3)プログラミングの考え方

この三つを同時に、勉強して行く必要があると言うことではないかと思っている。


自然言語の学習との違いとして、3番目の「考え方」があるように思う。

ある外国語たとえば、フランス語を習得しようとする人は、大抵1と2に集中する。
まぁその国の事細かな生活習慣まで習得しようとする意気込みはなくともある程度の会話はできるようになる。

しかしながら、プログラミング言語においては、人間の文化とはまったく異質であるので、容易には理解できない習慣や、きまりがある。
これは文法と語彙とは別に親しんでいく必要がある。

しかし、現状では、それを達成するには、文法と語彙を少しづつ増やしながら、プログラミングを作る事を繰り返して、そういった「プログラマー脳」とでも言える考え方を身につけていくしかない。

視点を変えれば、1~3が密接に関係しているとも言えるので、どれか一つをのばすことで、それらすべてをのばしていくことにつながっているのかもしれない。

しかしながら初心者にはやるべきことが多すぎるし、慣れない考え方にストレスを感じる。


この「3」のあたりを、もっと切り離して個別に身につけられるようにできるテキストに出会ったことがないので自分にそれを作る事ができないか、ずっと考えている。

「出会ったことがない」と偉そうに言っているが、プログラミング言語の入門書を数冊読みかじった程度なので、(しかも、どれも完読はしていない)ただ単に自分のリサーチ不足かもしれない。

もしかしたらゲームにしたり、マンガにするといいのかもしれないし、そういったものはすでに存在しているのかもしれない。


プランと言うにはあまりにもおおざっぱだが、文章にして5行程度のアイデアは出来てきた。
ただし概念の段階であり、具体性は全くない。
「3」の考え方という物を、容易に、しかもあまり頭を使うことなく、段階的に習得するというのはその基本方針であることは明確だ。
できるなら、プログラミング言語の文法と語彙にたよらず達成できるほうがいい。


しかし、具体性を持たせるには、経験も少なすぎるし、あまりにもプログラミングのことを知らなさすぎる。
どのような思考法から身につけていくべきか、どういった段階をふむべきか、そういったこともほとんどわからない。
現段階でわかっているのは、いかに初心者が苦労し、ストレスを感じるか、そしてそれに対して根本的な解決策がなく、昔ながらの「やってなれろ」方式しか解決策がないということだ。
(最近は、まぁそれで解決してくるのだからそれでいいのかとも思う気持ちもあるが)

そもそもこういう考えを抱くのは、間違っているのかもしれない。
でも何か考えずには居られない。