CG業界の標準スクリプティング環境が Python+Qt でほぼ確定っぽいので、私も今後はこの環境で開発をしていくことにしました。個人的にはスクリプト言語は Ruby、GUI ツールキットは fltk が好きなんですけど、そこでわざわざマイノリティになっても仕方ないですからね。。。。
ここで問題になるのが、標準で配布されている PyQt には 64bit 版が存在しないことです。将来的には Maya にも標準で PyQt が添付されるようになるでしょうが、今のところは各自用意する必要があるようなので syoyo さんの記事を参考に自前ビルドをしてみました。
結論から言えば、時間はかかったもののアッサリと動きました。Maya 上の Python から Qt のサンプルを動かすのもバッチリです 
・・・と言いたいところですが、一つ致命的な問題があることに気づきました。
スクリプト実行中は Maya が固まる
はい、ちょっと考えれば当たり前ですねw しかし、このままでは使い物になりません。
どうしたものか。。。と悩みながらドキュメントを読んでいると、pumpThread というものを使えば解決するようです。これは Maya の devkit に含まれています(devkit/other/PyQtScripts/qt/pumpThread.py)。
pyQtScripts/userSetup.py を実行すると Maya のメニューバーに pythonScripts という項目が追加されて、サンプルを試すことができます。・・・が、これもまたきちんと動いていないようで、相変わらず Maya が固まってしまいます。
また、標準でついてくる pumpThread にはいろいろ問題があるらしく、改良版が python_inside_maya という ML の “PyQt in Maya examples” というスレッドに掲載されていました。ソースはまだ読んでいないので内容については何とも言えないものの、こちらを使用したほうがいいのかもしれません。
今のところ私がわかっているのはこれくらいです。PyQt on Maya についてはまだまだ調査を始めたばかりでわからないことだらけなので、何か情報をお持ちの方はぜひ教えてください 
64bit 版の Mayaプラグイン開発環境を作るためにやった作業メモ。ほとんど memlog さんからのコピペですwww
続きを読む…
完全にプライベートタイムを使って調べているのでなかなか捗らない(という言い訳をして数週間放置w)ですが、Twitter やコメント欄でいろいろな方に助けて頂きながら少しづつわかったことがあるのでまとめてみます。
・シェーダの割り当て
ボリュームシェーダを使用する際にも、サーフェースシェーダは指定する必要があります。ここでは、”何もしない” シェーダ、transmat を割り当てます。
・parti シェーダについて
Maya には parti シェーダのソースが付属しています(devkit/mentalray/shaders/physics/partishade.cpp)。
このソースの Description を読むとわかるのですが、parti シェーダは GI の使用が前提になっています。この時点で用がないなと見切りますwww
・raymarcherシェーダについて
parti シェーダ同様、ray marcher のソースも付属しています(devkit/mentalray/shaders/base/baseraymarch.cpp)。
コードを眺めてみると、拍子拔けするぐらい単純な構造になっていることがわかります。
ザックリと説明すると
- mib_ray_marcher() から raymarch() 関数を呼ぶ。これが ray marcher の本体
- 二点の mi_call_shader_x() で得られた値を比較する
- 最大分割数未満かつ、値の差が閾値以上なら recurse() 関数を呼ぶ
- 2と3を繰り返す
- 得られた結果を加算する(ここまでが raymarch())
- 最後に値を正規化してやる
これだけです。教科書に出てくる ray marcher そのものです。そして、このコードを読むと幾つか発見もあります。
- 最後に正規化してしまっているので、計算結果がそのまま得られない
- 結局単なる ray marcher なので、mi_call_shader_x() で呼ぶシェーダ次第
- シェーダの計算結果をそのまま足してしまっているので、多分綺麗な結果が得られない
1,2 に関してはコードを読んだそのままです。1 は正規化しないようにすれば解決できます(多分。mental ray のシェーダが、正規化した値しか返せない仕様だったりすると困ります)。2 は、コードを読めば一発でわかりますが、日本語読解力の弱いわたしにはドキュメントを読んだだけじゃわかりません(ぇ。
3 は、ライトを考慮したシェーダネットワークを組もうとすると問題になるのかなと思います。ライトの場合、ray marching した結果の color と alpha を使って光源の値を”削る”(マスクする)必要があると思うので、これ用の仕組みを別途作ってやる必要があります。まあ、サンプリングポイント毎に馬鹿正直に計算していたら重いと思うので Deep Shadow Map のようなものを使って計算するのが無難なのでしょう。
・結論
いろいろ書きましたが、結局 raymarcher はレイ・マーチングを正直に実装しただけのシェーダだったということです。
これだけで何かできるというわけではなく、シェーダネットワークを組むための部品の一つとして使うために存在するものなので、これを元に Phenomena を作るか自分でシェーダを書くのが正しいアプローチなんだろうなーと、至って普通な結論に逹しています。
Maya の Menta ray 上でボリュームレンダリングをするテストをしているのですが、これがなかなか一筋縄にいかなくて苦労しています。
・できたこと
- parti_volume シェーダを使ってボリュームライト的な表現をする→できたけど、目的とは違う
- mib_rey_marcher を使ってボリューム的な表現をする→こちらが目的に近い
・できてないこと
- ray_marcher を使ったとき、ボリュームの向こうにあるジオメトリがレンダリングされない(シェーダが起動しない?)
- セルフシャドウ
ray_marcher の資料が意外となくて、ほとんど手探り状態で進めています。英語でも全然使用例が見つからないんですよね。。。
とにかく、今できていない二点は何とか解決したいものです。はてさて、どうやってやればいいのやら。。。
Maya 標準のリジッドボディシミュレーションは、シミュレーションしたいオブジェクトの形を真面目に計算してしまうので結構重いです。Physx や ODE であればサクサク計算できてしまうようなシーンでもスムーズに計算できなくてイライラしている人が全国に百万人ぐらいいることと思います。
Physx や ODE が軽いのは、ジオメトリを単純な箱や球形状に置き替えて計算しているからです。この方法であれば、数千ポリゴンもあるような複雑なオブジェクトでも簡単に計算ができます。
しかし、Maya ではこのような proxy オブジェクトを計算する方法が用意されていません。困りました。proxyオブジェクトで計算させてコンストレインでハイモデルを動かすようなことをしてもいいのですが、あまり cool な方法とは言えません。
そこで、 rigidBody ノードに入力するメッシュを差し替えることで proxyオブジェクトを使ってリジッドボディシミュレーションを行う方法を考えました。
もしかしたら、この方法は FAQ に載っているようなアタリマエな方法かもしれません。
max から乗り移るために Maya の勉強をしていて、自分で見つけた嬉しさの余り書いた記事なので、やさしく見守って(そして、コッソリ教えて)ください
続きを読む…
ずーっと使っていなくて、すっかり忘れてしまったので Maya の勉強をしてみました。
今日のテーマは “Maya内部でのパーティクルの扱われ方”。
続きを読む…
