日々適当

日本でもリリースされたmodo 501。
早速購入したはいいけど、忙しくて触っている暇がありませんでした。
ちょっと落ち着いたので、触っております。

Mars Inc. > 製品 > modo 501 機能紹介ツアー [Mars Inc.]

ここを一つずつ見ていきましょう。

何よりの売りはレンダリングです。
まずはその速度ですね。

試しに、サンプルシーン3つを回してみました。

modo 501はCarbon版で試しています。

	401	501
9Shheres	15.6s	10.7s
Butterfly_01	1m30.5s	53.8s
PurpleThings	15.5s	27.7s

おやおや？一番最後の、ずいぶんと遅くなってますね。



出来上がりの絵は、もちろん全く同じということはないのだけど、差の絶対値で比較するとこんぐらい違います。



設定をいじればいいことだし、この差はあんまり意味はないことだとは思いますが、ともあれ、この計算時間の差は、大域照明時の前処理段階での速度に差がある印象でした。

Motion Vectorを書き出せるようになったそうです。
サンプルのMMDの中にある鳥のシーンを回してみました。



ん？　これはちょっと違うよな。



うん、これは正しそう。
カメラのモーション・ブラーを無効にしてやることでブラーがかかっていない状態のピクセルのモーションベクトルが書き込まれる模様。



とはいえ、あまり美しい結果は出ていませんね。
もうちょっと研究する必要があるなぁ。ちなみに、モーション・ブラーをかけてのmodo上でのレンダリングは爆速だと思います。

RSMB、Ver.4にしないとなぁ…

バンプのレンダリング品質云々は検証できていません。より繊細な結果が出てくるようになったみたいですけど、問題はアニメートした時にチラつきにならないか、っすね。まぁ、まだmodoでアニメーションをつくる気にはなりませんけど。

Mars Inc. > 製品 > modo 501 機能紹介ツアー [Mars Inc.] の1ページ目の内容はこんなところですかね。

TGA。Truevision Graphics Adapterの略だそうです。初めて知った。
CG屋さんでは結構使っている人も多いのではないかと思います。Mac OS Xもネイティブで対応しており、QuickLookやダブルクリックでのプレビュー.appでのオープンに対応しています。

ってことは、AppleScriptやAutomatorからtgaへの保存が出来るんじゃね？って思ったんですけど、開けるけど保存は出来ないのですよ、これが。このあたり、Image Eventsというソフトを介して対応しているファイルフォーマットへの保存を行うわけですけど、こいつが対応していない。

しかし、プレビュー.appでは出来るんですよね、tgaへの保存って。OS標準で可能なんじゃないの？と思うわけです。

バッチ処理をさせようと思った時、UNIXなららしくコマンドから行うべきで、それを可能にするのがsipsっての。

sips -s format tga infile.extension --out outfile.tga

となります。で、職場の人に教わったのですけど、このコマンド、最終的にはImgってパッケージのimg-tgaを呼んでいるらしい。
man img-tgaでマニュアル見ると、rleでの圧縮がデフォルトとなっておりました。


プレビュー.appもこの辺呼び出しているんですかね。

ともあれ、これでtgaの変換は行けますな。

set desktopPath to (path to desktop) as text

set aFile to (POSIX path of desktopPath) & "test.tif"



do shell script "sips -s format tga " & aFile & " --out " & (POSIX path of desktopPath) & "test.tga"

お仕事的に、Rendermapで焼き付けたテクスチャを、ビューポート上で確認するために、



というような設定をしています。そしたら、焼き付けたテクスチャを貼り付けた状態と、焼き付けるためのマテリアルの情報を両立出来るうえに、最終的にdotXSI 3.0で書き出す時に優先されるテクスチャは User specific Image/UV pairで設定している方なので、とっても都合が良いのです。

しかし、SI 2011にはdotXSI 3.0書き出しにバグがあるようで、UVが壊れる現象が発生する可能性があります。そこで、別フォーマットに書き出して、またSIに読込んで、その上でdotXSI 3.0に書き出す、という手順を踏みます。

この別フォーマットに書き出す際に利用するフォーマットの候補としては、dotXSI 6.0やFBXがあるのですけど（Colladaは未検証）、 User specific Image/UV pairで設定しているテクスチャ情報が重要なので、dotXSI 6.0は使えません。これ使うと、RenderTreeの情報はある程度保持してくれる一方、 User specific Image/UV pairの設定は保持されないのでね。

というわけで、fbxで書き出すわけですが、書き出したものを読込むと、



ひとつのマテリアルにいっぱいイメージクリップが…。
まぁ実害はないのですけど、もうちょっとfbxの取り扱いがいい感じなるとよいですなぁ。仮にもAutodesk純正アプリなんだからさ。

<追記>
実害、あった。
上図の状態になっているオブジェクトは、テクスチャサポートオブジェクトが大量にくっついた状態になっているんですよ。そっちが原因なのか、大量のイメージクリップが原因なのかは切り分けていないけど、こうしたオブジェクトはフリーズに時間がかかります。数が多いととっても待たされてしまうのですね（特に不要なテクスチャサポートがついている場合、フリーズMしたくなるわけですけど、そのまんまフリーズするととっても時間がかかってしまう）。
オブジェクトが数百ある物をフリーズした時、かなりいらつきましたですよ。
</追記>

Mac OS X 10.6 になり、COLLADAを標準で扱えるようになりました。

扱えると言うのは、FinderやQuickLook、PreviewといったOS標準ツールでプレビュー可能という意味です。



上図はPreviewでdaeファイル（Colladaファイル）を開いたところ。ウインドウ内でドラッグすると画面中心を中心として視点を回転できるし、Optionキーを押しながらドラッグすると、横方向へのドリーが可能です。ズーム（あるいはトラックアップ）はどうやるんだろ。

ともかく、そんなわけで、プレビュー出来るわけです。

ちなみに上図はUVが一つしかなく、質感は全部テクスチャにつけている（Colladaファイル内でPhongのイルミネーションは設定されているようですが）状態でした。
これがマルチUVの物で、各パーツごとに違うUV、違うテクスチャを貼り付けるとイカのようになります。



これ、Softimageから吐き出した物なんですけど、このdaeファイルをSoftimagenに読み込み直すとちゃんと表示されます。
つまり、マルチUVの扱いには問題あるみたいですね。



使用したデータは Poser ―(lwo)→ modo ―(dae)→ Softimage 的な手順でデータの移動を行っています。UVとテクスチャの作成はmodo上で行っており、modoからのマルチUVの書き出しは出来ていることになります。modoでパーツごとにマテリアルをわけ、それぞれに独自のUVを適用しているという形です。
ただ、それをSoftimageに読み込むと、modo上でマテリアルわけを行った物がちゃんとポリゴンクラスタとしてわけられて読み込まれ、また、UVもちゃんと存在しているのですけど、適切なUVが割り当てられていませんでした。惜しい、という感じです。

んで、そこからUVを割り当て直してSoftimageからdaeで書き出して、それをまたSoftimageに読み込み直したのが上図の状態なわけです。前述した通り、ちゃんとUV・マテリアルが割り振られています。

ついでに書くと、modoから書き出したdaeファイルのサイズは16.8MB。それを前述の手順でSoftimageから出力し直したものは77.9MBとなっています。ここまで大きな差がついてしまう理由は、より細かいパラメータをSIは記述しているっぽいってことっすね。modo 501になったら、Colladaのサポートもより手厚くなりそうですし、だいぶ変わるかな。

話をMacに戻すと、こうして出力したものをQuickLookやPreviewで見た時、意図しないシェーディングになっています。これは、Phongシェーディングされちゃっているから、みたいですね。別にMacが悪いわけではなく、modoから出力したdaeファイルにそう記述されてしまっていることが原因です。

そんなわけで、phongタグで囲まれているところをconstantタグに置き換え、テクスチャ情報が書き込まれているその内側のdiffuseタグをemissionタグに書き換えてやります。そしたら、



この通り、きちんとコンスタントな質感で読み込まれました（陰影はテクスチャに焼き付けられています）。

まぁ厄介なのは、modoにコンスタントなマテリアルっていう概念がないことですかね。
SoftimageではRender Tree上でイルミネーションをコンスタントにしてやればちゃんとこのように吐き出されるのですが。

ってことで、基本的な所の検証はこんな感じ。
今度、アニメーションがどうなのか、検証してみよう。いつになるか分からんけどね(^^;

<追記>
適当にSoftimage上で骨を仕込んでColladaで吐き出してみました。
そしたら、開けませんでしたよ。プレビューだと「ファイルが壊れているか、“プレビュー”が認識しないフォーマットを使用している可能性があります。」というメッセージがでます。
もちろん、吐き出したdaeファイルをSoftimageに読み込み直して、ちゃんとしていることは確認済み。
ちなみに下は読み込んだdaeファイルをループ再生させているものです。単純なSRTの物だとどうなのかね。そのうち検証しよう。



</追記>

Luxology

あんまり情報を追っていなかった身としては突然の発表となったmodo 501のリリース。もちろんまだ日本の代理店からの販売は行われていないために、そこ経由でライセンスを購入している私が触ることなぞ出来ないわけですが、Luxologyのサイトを見てワクワクしたいと思います。

modo 501の紹介ページは各機能をページを追って見て行く作りになっていますが、そこから察するに、レンダリングが一押しのようですね、今回のバージョンは。

実際、非常に高速になっているそうです。マシンを買い替えるのに匹敵する速度向上、とおっしゃっている方もいます。
その速度向上とともにメモリの取り扱いがうまくなっているそうです。巨大なテクスチャを使ってもへこたれない実力を手にいれたらしいですね。



上のムービーは1920 x 1080の解像度のものがアップされています。後半部分の様子を見ると、イカに巨大なテクスチャを貼り付けているか想像がつきましょう。

DOFの表現もとてもよさそうですね。そこにBokehの効果が加わって、よさげな雰囲気の絵作りが加速しそうです。もっとも、DOF系の処理って後処理でやることが多いんですけどね(^^)

Edge Contour renderingは、オブジェクトのエッジをラインとして出力することが出来ると言うものです。その効果は、セルアニメ調のものを作るのに利用できそうと期待しちゃいますけど、そっち方面に使うには、まだ違いそうではありますけどね。でもサンプルの一番最後の機械は非常に効果的にラインが使われていて、とてもかっこいいし、そんな表現の幅の向上は喜ばしいです。

Rendering Part 3 [Luxology]

それ以外にいろいろと新機能、強化された機能がレンダリング周りにあるようです。

そのようなレンダリングに欠かせないのが最終レンダリングのためのセッティングを詰めていくためのプレビュー。401でもかなり高速だったものが、さらに高速かつインテリジェントになっているようです。

つくずく、単独のレンダラーとしてでてくれないかなー、って思っちゃいますね。

そんなレンダリングするためのものを作る部分として、真っ先に取り上げられているのが、Pixar Subdivision Surfaces.
まぁ大層にピクサーのサブディビジョンサーフェースって書いてますけど、要するに、他の3DCGアプリとの互換性が非常に高まるサブディビジョンサーフェースを採用してくれたってことなんスよね、他のツールも使っている者としては。しかし、大歓迎な新機能です。
で、対MayaにおいてはFBX 2010.2でもって、クリースの値込みで持っていくことが出来るみたいですね。再現性が非常に高くなっている。対Softimageでどうなっているのか、個人的に非常に気になるところです。

modoを愛用している人がその理由としてあげている所として、モデラーの完成度・使いかってってところがありますけど、そこんところの強化も抜かりありません。
いくつかあげられていますけど、個人的には整列系のコマンドに興味が湧きました。
従来の複製コマンドは、始点と終点があって、オブジェクトが始点においてあり、終点までそのオブジェクトを等間隔に複製して配置したい時、頭の中で始点から終点までの距離と、必要なオブジェクトの個数から、オブジェクト間の距離を計算して、数値入力せねばなりませんでした。
今回強化された機能では、終点に複製した物を設定し、始点と終点の間に何個さらに複製するかという指定が出来るようです。これ、分かりやすくて良いなと思います。

頂点の整列も良く使いそうです。軸に対して傾いている面上に頂点を整列させたい時なんか、あまり考えずともそれができてしまいます。素敵。



使わずともその効果を想像できて便利だーと個人的に思う新機能が上記整列系ですけど、それ以外にもよさげな内容が見えます。早く触りたいですな。

んで、modoで僕自身はほとんど使っていない、Replicatorsの話が来ています。これを使うような用途を見いだしたいものです。modoをメインツールに据えた時、僕の場合は、その機能を活用するようになるのでしょうが…。

Multi-Res Sculpting。スカルプトが強化されております。zBrushライクなんていわれていますけど、さて、どんなもんでしょうか。これは使ってみないっとなんともですけど、軽快に動作するなら、401よりもかなり使いでがありそうですよ。

FurやHair。401で搭載された時、ぼろくそに言っている人もいたわけですけど、汚名は返上されたでしょうか。スタイリングがやりやすくなっていると良いですね。実際、やりやすくなっていることをうたっているみたいですが、さて。

そしてアニメーションです。
リグを組めるようになりました。しかもスケマティックビューと呼ばれるノードを組み合わせてオブジェクト間の関係性を組み上げていくことが出来る。
使ってみたいけど、触る機会あるかなぁ(^^;

UIまわりの強化ではRayGLってものが導入されています。ビューポート内で、オブジェクトを実際のレンダリング結果に近い状態で確認しながら作業を行うことが出来るそうです。経験したことがないモードなので、どんなもんなのか興味津々です。まぁたぶん、モデリング中にあまり使わないでしょうけど(^^)
Render Regionが導入されています。ビューポート内でかこった領域をレンダリングしてくれる機能（別ウィンドウが開くのではなくビューポート内でそのままレンダリングが始まる）。Softimageに搭載されている概念ですけど、SI使いとしては非常にうれしい機能強化と言えます。
それ以外にもいろいろあるようです。

以上、ざっと眺めてそれなりに理解できてほぉっと思った部分だけあげてみたわけですけど、ざっと見ただけでは理解できず取り上げることが出来ていない物が多いのは紛れもない事実なので、早いところ触ってみたいものです。

日本では24日から販売開始らしいので、楽しみですよ。

だいたい、たし算されているのかな、と。



ひとつのImageノードから2つのBump_mapノードにつないでやればいいんだけど、ちょっと別のことをやろうとしていて、Imageノードが二つ存在している状態です。まぁ、気にするなってことだな。

べつに「？」なんかいらなくて、たぶん、順当にIntel CPUを採用し続けるなら、普通に採用されるでしょうけど、それがどうも正式決定したようだ、ってのが先週流れた噂ですね。

Apple、次期MacBookシリーズに「Sandy Bridge」を採用?! [気になる、記になる…]

Sandy BridgeはIntelのイスラエルのチームが担当している事から注目されていたものだそうです。AppleがIntel CPUを採用したきっかけとなったCore DuoやCore 2 Duoを開発したチームですね。
モデルはCore i7、Core i5、Core i3というラインナップにわけられるのですが、見ての通り、現行のMacに採用されているものと名前は変わりません。それでは何が変わるのかというと、分かりやすいところではSIMD演算のためのユニット（Intel AVX）の高速化とGPUの完全な統合、第二世代のターボブースト、といった所のようです。リングバスといキーワードも見えます。

それが搭載されたマシンを使う際に、特に影響が大きそうなのが、GPUの完全な統合でしょうか。現在、IntelのGPUはパワー不足と言うことで、一部のモデルでNVIDIAのチップセットを採用し、いまだにCore 2 Duoを使うか、Intelのチップセットを採用しても、GPUとして独立したNVIDIAやAMDのGPUを搭載しているのですよね、Macは。MacBookクラスにおいては、Sandy Bridgeになればそのパワー不足もおおむね解消すると評価されたってことでしょう（そう期待しますが、さて）。

ちなみに、Sandy Bridgeはモバイル向けで4コアCPUがラインナップされていますが、現行MacBook Proにそのまま搭載するには、ちょっと最大TDPがおっきいようです。現行MacBook Proに採用されているCore i7は最大TDPが35Wのもの。一方、4コアのSandy Bridgeは45Wから55Wです。45Wの場合、クロック周波数も低めですね。順当に行けば、まだ、Appleのノートに登載されるCPUは2コアのもの、ってことなんでしょうなぁ。

ただし、演算力はそれなりに向上していそうです（Intel AVXを有効に使う処理ではかなりの向上が見込めるそうで）。
とりあえず、iMac、MacBook、MacBook Proを更新ですかねー。

樹に雪を積もらせてみよう、とふと思ったのです。

ということで、まずは樹を作ります。作るのは大変なので、Vueのオブジェクトを拝借します。



使用した樹はこの種類。これをVueシーンに読込みます。



Vue内でやるつもりはさらさら無いために（樹に雪を積もらせるって作業は大変そうです）、Vue内での設定はまったく行わず、Softimageに持ち込むために、lwoで吐き出す事にします。



テクスチャは色情報とアルファ情報（葉っぱの形のため）とバンプ情報を書き出しています。
ちなみに、Vueから樹オブジェクトを吐き出すと、葉っぱや幹、枝がひとつのオブジェクトにまとまってしまいます。SIに読込んだ時、それぞれの要素がクラスタにわけられている、という事もありません。UV座標系の上半分が幹や枝、下半分が葉っぱ、というようなテクスチャを貼り付けられるようなオブジェクトとして書き出されてきます。

ですから、SI上でのマテリアルの設定は、たとえばイカのような感じなります。



アルファの情報を使って、Spriteで葉っぱの形を抜いている、というわけですね。

そして、雪を積もらせるという作業は、ICE ParticleとPolygonizerを使います。
ICEの設定は以下の通り。一応、方向を見て、密度差が発生するつもりな組みかたですけど、そこんところは適当すぎます。
本気でやるなら、もっとちゃんと組んでやらないといけないでしょう。



樹オブジェクトにTexture_mapを設定し、そこに樹のアルファのテクスチャを指定。そのアルファの白黒を見て、葉っぱが無いところのパーティクルを削除するように設定してあります。

そんな感じで設定した樹や地面を設定して、シーンが一応完成するわけですが、しかし、無駄に重いですな。
最終的にはPolygonizerで作成されたメッシュをフリーズして、リダクションして、より扱いやすいシーンを目指すべきでしょう。



<追記>
最近のSoftimageの影の中の影。 [A-s-C-e-n-S-i-o-N] にてSprite使用禁止令がおりたので、まんま参考にさせてもらって、樹のRenderTreeを組直しました。




</追記>

何となく、購入してしまいました。AppleTV。

非常にシンプルな構成で、無線LAN環境が用意できるのなら、電源ケーブルをコンセントに、HDMIケーブルをテレビにつなげるだけのシンプルさ。テレビの入力をHDMIに切り替えればもう設定のための画面が開いています。

とはいえ、付属リモコンを使っての文字入力はやはり面倒で、いくつか入力を行わねばならない設定にはちょっといらっときます。無線LANをパスワード無しで運営していることはないでしょうし、iTunes内のコンテンツを見るためにAppleIDを入力しなければならない。内容自体は難しい事はないのだけど、面倒です。

AppleIDはホームシェアリング、という事を行う時に必要です。
その設定がオンになっているiTunesが起動しているマシン内の音楽や映像、写真をApple TVで見ることが出来るわけですね。
ただ、そのためにはそれを行うマシンすべてで同じAppleIDが必要になるわけですけど、iTunesで使用しているApple StoreのIDとは別に設定されるみたいで、だから家族で一つ共通のIDを用意すれば、AppleTVを共有することが出来そうです。

そんなわけで、その設定が終われば、まぁまぁ良い世界が待っています。

iTunes Storeの映画予告を見たり、レンタルしたり、YouTubeの映像を見たり。
ただ、これらコンテンツは、自分で「これを見たい」って探してやらないといけないのが面倒といえば面倒です。YouTubeでは「検索」という動作が必須でしょう。それを付属リモコンで入力するのは苦痛以外の何ものでもない。
ってことで、iPadやiPhone, iPod touchから使えるRemoteってアプリが大活躍するわけっすな。
正直、これを持っていないのなら、AppleTVをYouTubeを見るために導入するのはやめたほうが良い、と思えるぐらいのもんです。

まぁまぁ良いと書いたのは、iTunes Storeのラインナップがまだ充実していないってのと、映画予告にしても、アメリカの上映中の映画が基準になっている上に、当然予告は向こう向けの内容であることにちょっと不満ってのがあります。向こうの予告はもちろん見てて楽しいし、あるほうが良いのはもちろんなんだけど、日本で上映中の映画の予告もゆくゆくは欲しいですね。頼みますよ、日本の映画配給会社さん。

でもって、予告って基本的に長さが短いから、その予告たちを連続で再生するようなモードがあるといいっすね。だらーっと流しておくのにそんなモードが欲しいです。

一方で、非常に良いのはiPhoto内の写真をテレビで見ることが出来る、ってこと。
iTunesでiPhoto内の写真をすべて共有するように設定しておくことで、AppleTVでそれを見ることが出来ます。
あるいは、iPad内の写真も見ることが出来るわけですけど、写真の選択をより直感的に行うことが出来、プレゼンの現場なんかでも活躍できるかもしれないと思わせられました。

そんなiPad内のコンテンツを見ることが出来るものとして、ビデオがありますけど、たとえばAir Videoでそれができると最高なんですけどね。Air Videoの操作画面にAir Playのアイコンが出てくるから期待したんだけど、音しか飛んでくれませんでしたよ。

そのようなわけで、全体としては満足しています。
お値段もお手ごろだし、テレビのHDMIの入力に余裕があるiPhone, iPad, iPod touchユーザなら検討してみてもよいと思いますよ。

Space Battleship ヤマト

実写版ヤマト。見てきました。
日本でかつてない規模で制作された特撮映画、という言い方でいいのでしょう。
オリジナルの宇宙戦艦ヤマトをベースに、実写に起こし、大物と言われる俳優と日本最高峰であろう特撮スタッフとともに、山崎貴監督が作り上げたこの映画。特撮は見事なものでした。中盤までは、かなーりいい感じに楽しめましたですよ。
って書いた通り、お話の展開がね。ちょっと、んー、飽きた(^^;

この戦場は何なんだろう。あんなに大変だったのに、なんであんなに簡単に帰れるの、とか。なんでこんなにヤマト内であんな事をやっている時間的余裕があるの、とか。まぁ、その辺は「ヤマト」だからって事もあるんだけど、それにしても…、って思ってしまったのです。
（俺の右側で見ていた人なんかは、明らかに飽きてた）

うん、15分は短くできたんじゃないかな。

ガミラスがあーいう風に描かれていたり、その他設定部分には、ヤマトに別段思い入れないし、それは別によいので、故に不満点はそんな白けるぐらい長く描かれ過ぎたさまざまな描写、って所に主にあります。

もう一つ不満点を上げるなら、なんか画面が「狭い」って印象を持ってしまったところですかね。これは好みの問題でしょうけど、もうちょっと俯瞰する絵を多用して欲しかった、って感じかなぁ。

リアルで作成された艦内のセットの作りもちょっと残念でしたね。
艦内がずっときれいなままだったり、ってのはもうちょっとこだわりをもって汚しても良いのではないかと思ったりはしたけど、それはまぁいいんです。残念なのは、2010年の現在、普通に使われているモニターやキーボードと言ったパーツがそのままの姿で登場してしまった事です。そこはちょっとデザインをして欲しかった。

でも、CG部分の映像は素敵でした。さすがです。
ヤマトのディテール、地球のその他の船。かなり良いですね。そんな舞台装置を用意しての冒頭の地球艦隊とガミラスとの戦闘時の地球艦隊の展開の仕方なんかとてもよろしかった。
イスカンダルへ降下する部分の絵なんか、かなりきれいだった（引きの絵をもっと見せても良かったんじゃないかなぁ。ってか引きの絵ってあったっけ？）。

だから、残念だなぁ、って気分で劇場を後にしたのでした。