ハリウッドVFX業界就職の手引き

ハリウッドVFX業界就職の手引き
鍋潤太郎氏による、海外のVFX業界で働くための手引き。お薦めです。

2014年11月11日火曜日

プログラムを書いてみる その3

「プログラムを書いてみる」の3回目です。前回お話しした通り、今回はCG屋がPythonを使う場合の問題点についてお話ししたいと思います。


Python 2.Xと3.X

Pythonはプログラミング言語ですが、バージョンがあります。これは言語の仕様が少しずつ進化してきたためで、Pythonのようなスクリプト言語は組み込みの機能が多いため、とりわけバージョンアップによる進化が大きく、時としてそれがコードの互換性にすら影響を与える場合があります。Python 2.Xと3.Xに起きているのがまさにその問題であり、Python 3.0が登場したときに2.XまでのPythonで 書かれたコードと後方互換がない、という問題が発生してしまいました。これはPythonをより良いプログラミング言語として改良した結果であり、厳密には問題というのは言い過ぎかもしれませんが、いずれにせよコードによっては3.X以降では動かなくなる事があるのは事実です。Pythonコミュニティではこうしたコードを3.X以降で動く様に変換するツールなども提供していますが、多くのユーザーが2.X台のPython(2.Xと3.Xはまだ別々にメンテナンスされており、このブログを書いている時点で2.Xは2.7.8が最新です)を今だに利用しています。私が知る限りでは、Pythonインタープリタを内蔵している多くのCGソフト(MayaやHoudiniなど)も2.Xを利用しています。従って、皆さんもPythonを勉強する場合は2.Xでやるのが良いでしょう。いずれはCGのコミュニティも3.Xに移行していくかもしれませんが、それまでPythonがスクリプト言語としての今日の地位を維持し続けているかもわかりませんし、2.XでPythonを勉強しておけば、3.Xへの移行もそれほど難しくはないはずです。

PyQtとPySide

今日のコンピュータのOS上で、特にCGのエンドユーザー向けのツールを作る場合、GUIはほぼ必須になります。しかしGUIを設計する作業は非常に手間がかかる作業であり、プログラムの種類によっては書くコードの半分以上がGUIのためのものになるくらいです。そこで、どんなプログラミング言語にもGUIの開発を支援するライブラリやフレームワーク(ライブラリなどを含む開発用のツールや決まり事などを構造的に提供するもの)が提供されています。しかしちょっと前まで、こうしたライブラリなどはOS毎にまちまちなものを使うのが普通でした。そのため、マルチプラットフォームのアプリケーション(CGでいうとMayaやHoudini、Nukeなどが複数のOSに対応しています)を書くデベロッパは、OS毎にこの辺の書き方を変えなければならず、非常に手間のかかる作業でした。

そこで、あらゆるOS上で全く同じツールキットを提供してそれでGUIを書けば、コードをほとんど書き換える事なくマルチプラットフォームに対応したアプリケーションの開発が可能になるはずだ、というもくろみの元に開発されたのがQt(公式にはキュートと発音するようです)です。QtはもともとC++用につくられたオープンソースのライブラリ・キットであり、そのもくろみ通り非常に成功したため、その後他のプログラミング言語でも使える様にと移植が進みました。PyQtとPySideはその全く同じ目的のために開発された、全く同じようなPythonライブラリ・モジュールです。

では何故同じような目的のものが2つ存在するのか、という事ですが、これは主に権利関係の問題に関わっています。この辺は私も専門家ではありませんので、多少不正確なのを承知で簡略化してお話ししますが、QtはGPLとLGPL、商用という3つのライセンシング形態を採用していました。

  • GPL ... このライセンスの下で公開されたものを利用して2次創作物を作った場合、それもフリーウェアとして公開しなければならない
  • LGPL ... このライセンスの下で公開されたものを利用して2次創作物を作った場合、必ずしもそれをフリーウェアとして公開する必要はない
  • 商用 ... フリーウェアとして公開する必要はいっさいない。ライセンシングのためにお金を払う必要がある。
かなりおおざっぱな説明だというそしりは免れないと思いますが、とりあえずここでは話を先に進ませてください。最初に開発されたのはPyQtで、これはイギリスのリバーバンクという会社が開発しました。そしてこの会社はPyQtをGPLか商用のみでリリースしました。当時Qtの開発を主導していたフィンランドのNokia社はQt同様PyQtもLGPLで公開するよう交渉したようですが失敗に終わり、代わりにPySideがLGPLのオープンソース・プロジェクトとして立ち上げられたようです。リバーバンクがLGPLを採用しなかったのは恐らく商用ライセンスの利用を促すためではないかと思いますが、こういった経緯から、商用ソフトウェアにPython用のQtツールキットを含めたいと考えていた多くの(AutodeskやThe Foundryを含む)ソフトウェア会社はリバーバンクから商用ライセンスを買うよりも、PySideを選ぶ事になりました。

ではもしCG屋としてPython用のQtツールが必要になった場合、どちらを選ぶか、ですが、AutodeskやThe FoundryがPySideを彼らのソフトウェアのパッケージングに含めている以上、PySideを使うのが自然である様に思えます。しかし、プログラマのコミュニティの中にはPySideの将来を危ぶむ声もあります。PySideは有志によって支えられたオープンソースのコミュニティですが、コミュニティ自体の規模があまり大きくないため、開発が思った様に進んでいない様に見える、という意見があります。実際、Qtの最新バージョンがこのブログを書いている現在5.3.2であるのに対し、PySideの最新バージョン1.2.2はQt 4.8をベースにしています。一方PyQtはQt 5.Xをサポートしており、PySideが後じんを拝している様に見えます。ただ、PySideもPyQtも基本的な構文はきわめて似ており、インポートするライブラリの名前やバインディング部分(他の言語で書かれたライブラリをPythonに持ってくる機能)を書き換えれば、ほとんど問題なくコードの互換性を保てる、という話もありますので、とりあえずはPySideで書きつつ、今後の動向を見守る様にしておけば良いでしょう。

maya.cmdsとpymel

これはAutodesk Mayaユーザー限定のお話しになりますが、以前もお話しした通り、MayaはPythonをサポートしています。そして、PythonスクリプトからMayaの機能を利用できるライブラリとしてmaya.cmdsというライブラリが提供されています。ところでこのmaya.cmdsはリリースされた当初からある種の批判がつきまとっていました。それはオブジェクト指向のコンセプトとmaya.cmdsが相容れないというものです。

Mayaユーザーであれば誰しもMELを使ったか、あるいは少なくともそのコマンドがスクリプト・エディタを流れていくのを目にした事が一度はあるのではないかと思います。MELはMayaの最初のバージョンから搭載されていたこのアプリケーションの組み込み言語であり、今日のMayaの地位を築いた傑出した機能の1つです。しかしこのスクリプト言語はいわゆる手続き型言語であり、オブジェクト指向ではありませんでした。AutodeskがPythonをMayaに組み込むにあたって、彼らはPythonのライブラリを極めてMELに似せたものにしてインプリメントする、という判断を下しました。これは従来のMELでプログラミングしていたユーザーに対する配慮だった訳ですが、元々オブジェクト指向ではないMELのコマンドをインプリメントしたPythonライブラリは当然ながらオブジェクト指向の利点を十分には生かせないものとなってしまい、そこに不満を持ったプログラマ達によってpymelが生み出されました。pymelはLAに拠点を持つ中堅のVFXプロダクションLuma Picturesのプログラマが中心となって生み出したMaya用のPythonライブラリであり、Autodesk純正のmaya.cmdsと異なりきわめてオブジェクト指向ライクなのが特徴です。実は私pymelを使った事がありませんので、この辺の詳しい説明は出来ませんが、最終的にはこのオープンソース・プロジェクトはMayaのパッケージに同梱されて出荷されるほど多くのユーザーから支持を集めました。

ではmaya.cmdsとpymel、どちらを使うべきか、というお話ですが、申し上げた通り私自身はpymelを使った事がありませんので、この辺に関しては客観的な意見を申し上げにくいところですが、私自身の事を申し上げると、今後pymelを勉強する予定はありません。理由は幾つかあります。

まずpymelはMayaのパッケージングに含まれて出荷されているとは言え、Autodeskのサポートの対象ではない、という事です。pymelはオープンソース・プロジェクトであり、Autodeskはこれをユーザーの利便性のために同梱しているだけで、このライブラリに何か問題が発生しても対応してくれる訳ではありません。

2番目の問題として、pymelはコミュニティとして小さすぎる、という問題があります。pymelを元々開発していたのは先にご紹介したLuma Picturesの他にImageMovers Digitalという会社がありました。しかしご存知の方も多いかと思いますが、この会社は親会社Walt Disney Companyの方針で2011年にシャットダウンされてしまいました。以後はほとんどLuma Pictures単独で開発が進んでいるようですが、オープンソース・プロジェクトであるにもかかわらずコミュニティが小さいという事は、問題が発生した時の対処に不安感を残します。

もし皆さんの中でpymelを使ってみたいという方は、この辺の事を考慮に入れた上で、自らがpymelの開発コミュニティに積極的に関わっていくくらいの気概で取り組んだ方がいいと私は思います。そうでなければ、maya.cmdsで開発をするのが無難でしょう。maya.cmds自体は確かにオブジェクト指向的な書き方ではありませんが、ご自分のPythonコードをオブジェクト指向に書く事はいくらでも可能ですし、より高度な機能を実現したい場合はmaya.cmdsではなくMaya Python APIを使ってプラグインなどを書く事も出来ます。

次回はパイプラインを支えるCG屋にとって現在、そして今後有望そうな技術について焦点を当てたいと思います。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。