お休み中である

月曜日に一仕事終わって、今週はお休み中なのである。
お休みの間は今後何をするかのんびり考える期間にしようと思う。

とりあえず昨日今日は英気を養うために寝て過ごした。
ずいぶん寝たのでずいぶん回復した。

なので明日からは地味に活動します(・・)ノシ
髪切ったり歯医者行ったり靴買ったりいろいろとやらねばあかんのです。

ここの情報も散らばっちゃったので、せめてリンクまとめるぐらいはやらないとなと思うのです。

時間ない時はあれこれやりたいなーと思っていたのに、時間出来た途端全部忘れちゃった。
まぁ疲れてたし、今週は何もやらないことにします。

でもレンダリングパワーアップセミナーだけは行ってきますよー(・・)ノシ

DSL?

Schemeの本を読み始めてから、マクロという考え方に感化されています。
LispやSchemeはマクロという機能を使い、自分自身を書き直してしまうことが可能な言語です。
たとえば足し算を全く別の計算に置き換えたりとか、そういう感じです。
や、これはあくまでも一例で。これ自身に意味はないですwww
超パワフルなイメージだけ伝わればOKですwww

マクロを使用する際の目的として多いのが、DSL(Domain Specific Language)の作成などだそうです。
DSLというのは、用途を特定した言語です。
AwkやMakeなどは一種のDSLと考えて良いと思われます。

こういう処理をするならこういう書き方できた方がいいよなー、でもそれって言語仕様にかかわるから無理だよなー、なんて思うことが度々あります。
それはもしかしたらアルゴリズムの改善だけで実現することかもしれないですし、DSLの利用領域としいて適切なものではないかも知れないのでアレですが、まぁそう思うことがあるのです。

たとえばレンダリング用のバッチファイルを書くときに、ここでforループを書きたいとか、これ変数に入れたい、とか、連番リネームしたいけどいちいちPython書くの面倒、、とか、そういうところです。
まぁそれぞれ簡単なユーティリティツールがあればいいのですが、やりたいことはちょくちょく違っていて、あぁこれじゃ使えねぇ!!ってなることもしばしばあるので、ある程度広い局面に対応できるようなものがいいなと思うと、やはりDSL欲しいな、なんて思ってしまうのです。
全部突っ込んだらツールが巨大になってあれこれ覚えないといけないとかだと最悪すぎるので。。

そんなところからDSLには強い興味を持っていました。

ということでちょっくら調べていたのですが、Rubyはマクロを採用しているので、Rubyネタはちょくちょくあるようですが、Pythonにはマクロがないので出来ないものなのだと思っていました。
mynzさんのご指摘で気づきました。Rubyにはマクロはありません。メタプログラミングと完全に取り違えていました。大変申し訳ありません。

ただかなり引っかかる点もあって。
何かといえばPythonがLispに影響を強く受けている点です。
Lispのマクロは強力である反面、使用には注意が必要とされているので、Pythonの開発者がそれを嫌がった可能性は十分にあります。
でもそれによって実現可能な世界を簡単に捨てるでしょうか?
否!
僕にはおそらく別の何かを用意したと考えていいんじゃないかと思えたのです。

で、調べた。

Python で Rake を真似るとしたら
Python,Rubyの言語内DSL構築力:PythonでRakeをまねる場合を例に

なるほど。デコレータを使ってあれこれ行うわけですね。←まだよくわかっていない

Rake(Ruby版Make)のコードとPython版Rake(?)のコードを見る限り、Pythonでも似たようなことは出来そうです。
構文の好みもあるので、どっちがどうとは言えませんが、構文自体をゴリゴリ変更したいというような要望があるわけでもなければ、PythonスタイルのDSLは書けそうです。
もちろんどの程度のものかにもよるでしょうけども。

Rubyはブロック構文がやはりおもしろいですねー。
ブロックをブロックとして扱う(?)感覚ってのは他の言語にはないですね。
少なくとも今まで触ってきたものには、、、
あれこれ調べていたら俄然Rubyに興味が湧いたことは内緒です。。

またしても専門外のネタを書いたので、もろもろ間違いなどあるかもしれません。
何かあったら光速で突っ込んで頂きたいです。

 
で、早速DSLを使用したネタを考えてみました。
簡単に思いつくのはディスパッチャとかでしょうか。
かなり荒いアイディアですので、いろいろ考察が浅い点あると思いますがご容赦ください。

まずすごくシンプルなディスパッチャを考えてみます。
ユーザーがタスクを投げる、サーバーが受け取ってスレーブに投げる、スレーブは受け取ったタスクを処理して終了をサーバーに知らせる。
大体こんな感じでしょうか。

この場合、ユーザーが投げるタスクには、直接スレーブにわたるコマンドは含まれておらず、ディスパッチャが処理して適切なコマンドに変換します。

となると、ディスパッチャではそれぞれに対応した変換規則をもっていないとダメなわけです。
Mayaなら、AEなら、独自プログラムなら、、、
面倒くせーーー

じゃあたとえばユーザーがPythonのソースを送って、ディスパッチャはそれを処理すればどうだろうか。
でもイチイチPython書くのは面倒すぎる。
じゃあGUIを用意しよう。
でも結局送るコマンドはPythonのままだから、生のPythonじゃなくて、言語内DSLにしよう。
そうすればいったんファイルにだして書き換えたり、好きに手で書いたり出来る。
さらにPythonの機能もほぼ使えるはず。
便利!

ってことにはならんかな?

ただ単にきっちり設計して、API丁寧に揃えて、GUI付けてってやればいいだけなのかもしれないんですけど、他の人がやってることと全く同じこと考えても仕方ないので、可能性の1つとして考えてみました。

プログラムをかじったものなら大小あれどあこがれるオレオレ言語。
DSLならその欲望を少し満たしてくれるかも・・・?

この辺本気でやりたかったら、コンパイラの知識必要だなーと思いました。
ASTとかなんとかかんとか、さっぱりわからん。

PythonはJavaなどと同様に、VMを使用して実行するタイプのスクリプト言語で、一旦バイトコードにコンパイルされてから実行されます。(間違ってたらスマン)
Pythonには構文木にアクセスするためのモジュールがあって、コンパイルされたファイルからバイトコードが復元できるっぽいので、この辺知ってると一気にあれこれやれるようになるのかも?となんか良くわからないながら妄想を抱いています。

夢のみ広がる・・・
夢で終わらせないために現実的なところから意識してやっていく必要がありますねー。

人の命は有限なのだと肝に銘じて。

CG駄文

仕事が落ち着きました・・・
なんとも感慨深いです。。

終わってすぐにこんなん書いてるおれ乙、ってところですが、せっかく書いたので載せます。
 
今回の仕事を終えて、次の時代の絵作りを考えると、既存の方法ではそろそろ追いつかなくなってきそうだと思い、HDRI(OpenEXR)とGIを用いたレンダリングワークフローに想いを馳せてみました。
そろそろこの辺に目を向ける必要があるのは明白ですし、いろいろな面でぼちぼち現実的になって来たようにも思ったからです。

ただ、実現するにはいろいろ問題がありそうです。
続きを読む CG駄文

AS ONE

AS ONE from makoto yabuki on Vimeo.

タングラムの矢吹誠氏による作品。
タングラムってCGプロダクションってイメージないですけど、CG屋さんも採ってるんですね。
僕みたいなタイプには一切縁のない話ですが、、、

センスさえあればこんなかっこいい映像が作れるんだぞという良い例。すばらしい!