Python

今年もまた誰もがノータッチなのでやったりました。
卯、辰、巳とCG屋的には当たり年なのに誰もそこに触れない、気づかないのが残念でなりませんよ！！

兎といえばスタンフォードバニー、
龍もこれまたスタンフォードドラゴン、
そして来年蛇といえばこれしかないでしょう。

今年はアジアンドラゴンとどちらにするか迷ったのはナイショです。

ライティングのイメージはコーネルボックスです。
新年からひどいCGオタクっぷりっですね。こじらせています。

来年こそは皆様の力作に期待しています（？）

さ、て。

早々に話がそれましたが、新年初ポストはここ最近ちょろっと触った
NukeのPythonで割と使いそうなネタのメモをコピペ。
今後もうちょい活用の道を見出していきたいところです。

Continue reading

この間Twitterで質問して教えてもらったネタを書いておきます。
Continue reading

簡単な、ほんとにほんとに簡単なpymel事例のご紹介です。
Continue reading

最近またMaya仕事ばっかりやってる僕です。
Maya仕事となると割とスクリプト書くので、大分しばらくぶりにちょいちょいスクリプト書いてます。
が、時間が経つと人というものは変わるものですね。
ここ数年まともにツールを作っていなかったためか、スクリプト書くのがまぁめんどくせーめんどくせー。
ツール書くのが嫌いになったとかそういうことではないのですが、
簡単なツールを書くのに時間がとられるのがもう嫌で嫌で。
簡単に言うと面倒くさがりが加速してしまったのです。悲しいことです。

なんとか楽にスクリプティングは出来ないものかと思い、以前からなんとなく気になっていたpymelを試してみることにしました。
pymel
Continue reading

仕事ですこーーーーしだけHOMを使ったスクリプトを書いたので、その際に残したメモを置いておきます。

Continue reading

ものぐさな性分で、Explorerをいちいちダブルクリックしてパスを辿って行って、、とかもうホントにごめんなさい、大嫌いです。
そもそもダブルクリックが大層苦手なもので、エクスプローラ開いてからの
最初の目的地（たとえばシーンファイルのパスとか）へはパスを直打ちして移動することにしてます。

が、それも何回もやってると面倒なので、1個Houdini用のスクリプトを書きました。
現在開いているシーンのディレクトリを開くだけの簡易スクリプトです。
今開いてるシーンのデータをバックアップするだとか新しくフォルダ作るだとか、
そういうのは結構頻繁に行うので、比較的簡単に開きたいなと思って書きました。

以下にソース↓
Continue reading

そのまんまなんですが。

最近Houdini使ってて、Expressionなどもある程度ちょこちょこ使いつつ作業をしていたのですが、どこまでがノードでどこまでがExpressionでなのか、というところが徐々に見えてきました。

となったところで丁度良く大量のノードを扱いたくなりまして。
ざっくり言うと、アニメーション済みのオブジェクトをMayaに持っていくために、1つのオブジェクトをグループごとに切り分けて大量のオブジェクトを作成しないといけなかったのです。
それこそ数百という数だったし、グループ名にもルールはあるものの手で直せる量ではなかったため、これはスクリプトの出番だな、と思ってえいやっとPython書きました。

それに関するメモなど。

Continue reading

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

マクロを使用する際の目的として多いのが、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には構文木にアクセスするためのモジュールがあって、コンパイルされたファイルからバイトコードが復元できるっぽいので、この辺知ってると一気にあれこれやれるようになるのかも？となんか良くわからないながら妄想を抱いています。

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

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

先日inagakiさんにお勧めしていただいたPyQt本を会社で買ってもらったので、読み進め中。

まだほとんど読んでないし実際にほとんど触ってないけど、ちょっと感想。

・クラス名に全部Qがつくのが若干ウザい。
　→その代わり本では*でインポートしてるからモジュール名がついてない。慣れですかね。
・QtDesignerいいっすね。
　→.uiファイルをそのまま読んだり、pythonコードを出力したりできるっぽい。
　　pythonコードにする方がなんとなく楽そうな予感。
・実はwindows版てPyQtだけインストールすればいいっぽい。
　→もっといろいろ必要なものがあると思ってた。
　　でもこれは試してないので本当かどうかは怪しい。

なんとなく業界標準的なのはQtっぽいので、今後はQtでいろいろ作る予定。
すみません長いものには巻かれさせてください。

また読み進めたらいろいろ書く予定。

某社はこれでライティングシステムのUIとか書いてるって言うし、いろいろ挑戦してみたいなー。

タイトルの通りなので、それを踏まえたうえで読むようにしてください。　
一切責任は持たん！
てそれはこの記事に限ったことではないんですが:P

—————————————————————————大馬鹿野郎のささやきはここから↓↓

意味ねぇぇぇぇぇぇぇぇぇぇと思っていたものに対して、まぁこういう使い方もあるか・・・と思ったのでメモ。

Continue reading