気になるニュースなど

最近更新滞ってたので、今の時点で記憶に残ってて印象的なニュースなどを軽くまとめて見たいと思います。


SPIがインハウスライティングツールのKatanaをFoundryに売却
Foundry Acquires Katana from SPI for Nuke
* little things of mine * : Foundry Acquires Katana from SPI for Nuke

SPIにはPython+PyQtでかなりの部分が書かれてるライティングツールがあるんだぜ!て話は方々から聞いてたんですが、実際にどういうものなのかは知らず。
Katanaに関しての詳しい情報は上記、ますおさんのブログをどうぞ。

コンポジットソフトとライティングソフト、今後はどんどん境がなくなっていくんだろうなーと思っています。というかそうなって欲しい。
こういう素材が必要で、それらはこういう手順で準備する、というのを一緒に扱えちゃえば、あれこれクリアになるよなーと思うのです。
要は各レイヤーが3D情報であるというか、別に連番画像じゃなくてもいいんじゃないの?というか。
元のデータがあれば最悪コンポジット時にマスクぐらいならさくさく取れる、って感じでしょうか。
実際には連番画像になるんだと思いますが、それはただの成果物というか、実際にはそれを準備するためのシーンなりがあるわけで、それをそのままレイヤーとして扱えれば、何か不備が出たときにもそのまま対応できるというか。exrの代わりにribやらmaやらmaxやらってことですね、乱暴に言えば。
いやもちろん最終結果は連番画像なので、現状でも似た状況のフローことは出来るんですけども、画像のパス名とかで。というかそれが普通だと思うんですが。
ただそれ以上にクリアというか、わかりやすい気がします。

で、Nukeに組み込むと考えた際、通常の合成作業ではイメージ入力→なんらかの処理モゴモゴ→出力、って流れのフローが組まれると思うんですが、たとえばこのイメージ入力のところがKatanaノード、みたいなものに置き換わって、その上流(Houdini的に中でも可か)には、レイヤーがどう作られるか、みたいなものが存在していて。
中ではシーンを構築してレンダリング、で、そのノードの出力が従来通りの画像データ的なもので、あとは足したり乗せたり好きにやればいいんだと思うのです。
もちろんここはレンダラとも関わる部分なので、ターゲットのレンダラにKatana、というかNukeが対応している必要があるわけなんですが。

というところからFoundryはKatanaそのものを買って売るというよりは基幹技術としての買収、みたいな形をとったのかなと思います。
今後ここの部分はV-Rayだとかmental rayだとかでも使えるように、ある程度オープンなAPIにしていくほうが間違いなく広がっていきそうですし。

ただこれは理想的な形でしかないというか、結局はレンダリングの時間はどう考えるかとか、コンポジタの仕事が増えるだけじゃないかとか、まぁあれこれ解決しないといけない問題はあるんだと思うんです。そもそもますおさんが仰るとおり、日本みたいに分業じゃない社会では意味あるあのかどうかとか。そういう意味では別のツールのままでも問題ないんじゃない?って気もしますが、どうなんですか実際。
実のところ僕の頭でもあまり理解しきれていません。理想的な形というのが。

と思ったところでこれです。

BAKERY RELIGHT™
* little things of mine * : BAKERY RELIGHT™

こちらもますおさんのブログで取り上げられていたのですが、つまりこういうことなのかなーなんて。BAKERY RELIGHTの場合は、リライティングエンジン、レンダラ、コンポジットツールまでをすべて独自開発し(!)、relightingベースのレンダリングワークフローを1から作ったようです。
3Dシーンの入力もMayaやSIなどに対応していたり、既存ツールとの橋渡しも問題なく行えそうです。

恐らくNukeが目指すところもこういう感じなのかなと。ただレンダラ部分は個々で好きなものが使えるように拡張性高くしようぜ、て感じで考えてるって感じでしょうかね。
まぁよくわかってない人間の予想でしかないのでアレですが。
なんにせよ今後のこの辺の動向はレンダラ周りと併せて要チェックなのかなーと思います。

あとSPIがFoundryにKatanaを売ったことで、実質SPIもNuke使いますよ、という宣言がされたと考えて良いのだと思われます。
とするとハリウッド大手のILM、Weta、SPI、本家開発元のDDはNukeユーザーとなるわけです。とするとなんとなくMayaの時みたいに右に倣えではないですが、Nuke採用する会社は増えてくるんだろうなと思います。実際ユーザーが増えるわけなので、会社としても買いやすくなるんじゃないかなーと。
あとはNukeが立体視に強いというのも、ユーザーの増加を後押ししそうです。

Toxikは思ったほど奮わないかもしれませんね。
1年遅かった、という気がしないでもない。
ただなんだかんだで標準で搭載、というのはジワジワ来るんですよね。
mental rayの時なんかもそうでしたし、徐々に使われるんだと思います。
Nuke持ってる会社が好んで使うかといわれたらアレですが。
僕はまだ試せてないのですが、今度Mayaの体験版入れていじってみようと思います<Toxik

 
余談ですが、これでまたPython、PyQtのCG業界デファクト率がUPしたような気がします。
個人的に作りたいお遊びアプリがあるのですが、PyQtでやってみようかなー。
重要な部分はCで書いた、とか良く言いますけど、あれってPythonをC拡張したってことなんでしょうか?
どなたかご存知なら是非教えて欲しいです。

あと地味にOSLの採用率が広まりそうな予感。
KatanaはSPIのデファクトとりますぜ運動の一環だったりして・・・!!
まぁそんなデファクトなら全然歓迎ですな!いいぞSPI!もっとやれ!!ww

 
さてKatanaネタはこのぐらいにして次。

米ワーナーが日本映画に本腰 まず「忠臣蔵」

Twitterで拾ったネタです。
個人的にはこれ朗報だと思うんですよね。日本の映画業界的に。

ラストサムライなどを製作したワーナーが忠臣蔵を映画化!『ラストチューシングラ』

こちらを眺める限りでは批判的な意見が多いんですが、忠臣蔵に関しては監督が日本人なんですよね。
もちろんプロデューサであるとかクライアントであるとか、お上の意見てのはかなり映画の内容に反映されると思うんですが、監督が日本人か否か、ってのは結構大きいと思うんです。

だから映画として楽しい映画になるかどうかはまた別としても、業界が潤うんじゃないかな、と。そしてこれらは日本のコンテンツを海外へ売り込むためのものだと思うので、良い布石にもなってくれるんじゃないかなと。

アニメになりますが、アニマトリックス、バットマン、HALOあたりは海外資本での制作ですし、最近ではマッドハウスがマーベルのスーパーヒーローものをアニメ化するなんて話もありました。

マッドハウス マーベルのスーパーヒーローをアニメ化 2010年
マッドハウス版「アイアンマン」「ウルヴァリン」2011年米国放送予定

こういう感じでガンガン海外売っていって欲しいですねー。
ちょっとアレな話になってしまいますが、実際発注額てどんなもんなんですかね。

日本のアニメって、もっと世界意識して作れば良いのにと思うことがあるんですが、多分日本人だけだと世界向けって出来ないと思うんです。
日本人が思っている以上に日本の映画は難解で地味。多分。
そういう意味も含めてアメコミのアニメライズってすごく良い題材だなーと思うのです。
あっちのテンションで日本の作画で、ってのは非常に見てみたいです。

と、話ちょっとそれましたが、同様な理由から日本映画もガンガン世界向けて売っていけばいいのに、と思うのです。
忠臣蔵だとかは確かに日本だぜ!って言って売り易いですよね、チョンマゲだし。
なのでまぁ最初はこういうところから始めてどんどんやれやれと思います。

日本の原作物はやはり日本で作るのが一番だと思うんですけど、日本には体力がない。
これからどんどん体力つけて、頑張りましょう日本映画界。
貪欲にやらねば。

 
と、最近の気になるネタを二つほど取り上げてみました。
余談ですが、最近個人的にMaxの体験版をインスコして、主にPFlow周り触ってましたが、まぁ一長一短てところでしょうか。
Mayaよりも優れてるなーってところは確かにありますが、これどうなの?ってところもあるし、そもそもプラグイン増強しなかったらデフォルトではやはり貧弱。

まぁ、最強のツールはHoudiniってこtゴホゴホっっ!!いや、そんなものはないってことですね。
向き不向きはあるけどね。
まぁでももうどうでもいいやそんなの。

とはいえ好きなので楽しいので技術的な話(含ツール)をしがちですがね、僕は。
でもまぁいいよね。TDたるもの技術的な話をおろそかにしてはいかn(ry

 
今回も長々失礼。あー書いた書いた。満足(・・)ノシ

「気になるニュースなど」への3件のフィードバック

  1. > 重要な部分はCで書いた、とか良く言いますけど、あれってPythonをC拡張したってことなんでしょうか?

    1)PythonをC拡張(スクリプトでコントロールできるので柔軟、使うPythonスクリプトと密接に結びつく)
    2)別にアプリケーションを作ってos.system()やpipeで別プロセスとして実行(作るのが簡単、Pythonに依存しない)
    3)dll/soとして作ってctypesなどを使って呼び出し(dll作り慣れてる人には手っ取り早いかも)
    他にもあると思いますが1)と2)が多いと思います。

  2. >hohehohe2さん
    なるほど!参考になります!

    たとえばGUIはPyQtで書いて処理はCで、とかって話になるとやっぱり1のPythonをC拡張、ってことになるんですかね。
    2の別アプリ立ち上げだとまた違って来る気もしますし。

    でもそうなると起動元はPythonってことになりそうですし、メインはPythonでやれそうですね。
    んー、Python強化月間として(?)この辺も調べてみたいです。

    情報ドモです!(・・)ノシ

コメントを残す

メールアドレスが公開されることはありません。