日々適当

これらは、連番のイメージファイルをひとつのかたまりとして見せてくれるソフトたちです。Compositは認識できないファイルフォーマットも表示しているために、連番のかたまりとしてztファイルを表示していませんがね。

ともあれ、こんなふうに連番をかたまりとして表示してくれる仕様をFinderあたりがもってくれるとうれしいですよね。ただし、MotionもCompositも表示されるまでかなり待たされてしまうので、それは勘弁なのですが、Softimageぐらいの速度で表示してくれるならFinderはこうあって欲しい。あるいはそう表示するオプションが欲しい。

個人的にはSoftimageの連番の取り扱いがとっても素敵だと思っています。
まず、連番はひとつのかたまりとして見せてくれます。フォルダ的に取り扱っているとでも申しましょうか。で、連番のかたまりをダブルクリックすると連番を構成する画像を1枚ずつ選択する事が出来る、っての。

この取り扱いと高速さを兼ね備えたFinderのプラグイン的な物があったりしないかなぁ、と思う今日この頃です。あ、Windowsのエクスプローラのでもいいよ。

カメラの振動や不意の回転を制限して安定した絵を撮るための仕組みなんですけどね。そんな装置が欲しい今日この頃です。

振動と回転をおさえるカメラを取り付けるための装置ですね。重量のあるカメラですと、そんな装置もしっかりしたものじゃないと駄目で、業務用なんかは腰で支える作りになっているのですけど、カメラがiPhone 4だったらどうざましょ。売り物もあったりするこの世界ですけど、自作している方々も結構いらっしゃるようです。

DIY iPhone 4 steadycam with gimbal is cheap, effective, cool

まぁ基本やじろべえを作る感じなんでしょうけど、そこそこ簡単な作りで作成可能な様子。

ちょっとチャレンジしてみたいかなー。うん、多分しないのだろうけど(^^;

こーいうの（HAGUE Mini Motion-Cam）を買ってもいいのかもしれない。別途iPhoneを固定するものは必要だけど、そこそこお安いらしい（自作でお安く、とは値段がずいぶんと違うけど、）。一眼レフも行けそうだし（片手でいけるのか？）。日本で正規に扱っているところは無いようなので輸入という形になるのだけろうけど、これも面白そうだなぁ。


これはXactiにつけてとっているみたいだけど、直接手持ちするとまずこんな滑らかな絵は撮れない。とれるとしたら、相当高度に体を制御できる人だよ。


7Dに600g強のレンズをつけた状態みたいですね。
一眼レフでもいけますなぁ。

こうしてると、欲しくなってきましたぞ(^^)

オチとしてはなんてこともない原因だったんだけど。

Vue 9のRenderCowをレンダリングの奴隷になるマシンに入れていたのだけど、Windows側でどうにもエラーになるんです。



起動するとこんなメッセージが出てくるわけで。既にそのポートは誰かが使っているよ、ってわけっすね。ちなみに、RenderCowが使用するデフォルトのポートは5004です。

そんなわけでトラブルシュート。誰がそのポートを使っているのかの特定です。そいつの使用するポートを変更するか殺してやる事にする予定。別の方法としてはVue 9 RenderCowの使用するポートを変更するというのがありますが、設定が面倒になるのでそれは却下。

まず誰が何のポートを使っているかを調べます。



netstat -oanってコマンドを使うと、そのポートを利用しているプロセスのIDを知る事が出来るそうですね。ってことで、ポート5004はPIDが556の物に使用されている事が分かりました。そこで、次はそのPIDがなんていう名前のプロセスなのか知る為のコマンドを投げます。
talklistというコマンドだそうです。


…、ありゃ、って感じです。
Vue 7のRenderCowとかぶっていたのでした。こちらもう使わないし死んでもらっていいんですよね。



ということで、無事にデフォルトのポートでRenderCowは動作するようになり、HyperVueからも認識され、RenderCowのアップデートもなされました。

ちなみに、VueのRenderCowは、開発元からVue本体の最新版のアップデータといっしょにインストーラが配布されているわけではありません。あくまでもインストーラは購入時に付属するものだけです。で、HyperVueに補足されると、そのHyperVueを起動しているVueのバージョンとバージョンがそろうように自動でアップデートがされます。この仕組み、バージョンを確実にそろえられるので良いです。この簡易な仕組みは、小規模な環境ではとっても役に立つので、他のツールもまねをして欲しいものですね。

…きっかけは某道場のスクリプト。



テストしてないので、ちゃんと動き続けるか知らんけど、手前の形状のUVを、後ろの形状に投影した形にする事をイメージしたコンパウンドを組んでみました。



ICEツリーは手前の形状に作成し、それをコンストラクションのモデリング階層の外に置いてやってます。
コンパウンドの中身はイカの通り。



ただ、参照する形状（後ろのグリッド）からはみ出すと、UVの座標が（0,0）になってしまうので、そのポイントについては破綻します。
こぉいうのの対処はどうしたもんかね。


コンパウンド

airpenPocket 新発売

売りは、Bluetoothでスマートフォンやパソコンにため込んだデータを転送したり、書いたはしから転送したりすることらしい。
Twitterアカウントが存在しており、そこにはこんな事が書かれている。

iPhoneに限らずスマートフォンへの対応は計画を進めています。近々、そのタイミングになりましたら、こちらでもtweetしたいと思います。

つまり現状iPhone対応に関するお話は無いようで、スマートフォンへの対応はAndroidなんすな。

ってことで、iPhone（iOS）への対応が出来たら考えてみたいアイテムです。

マニュアル読んでもよく分からなかったので。
でも幸い、Spin Particleはコンパウンドで、中身を見る事が出来ました。



分からないのは、SpiralとTumbleとRelative to Input Positionです。後の選択肢は想像がつきますが、これらはマニュアル見てもよく分からなかった。そこで、コンパウンドの中身のうち、回転軸に関する部分をビジュアル化してみたわけです。

まずはSpiral。運動ベクトル、つまりPointVelocityと回転軸が一致しています。



単純に、運動ベクトル方向に回転させているという事みたいですね。



TumbleとRelative to Input Positionはベクトルを入力し、その入力を元に回転軸が決定されます。入力はAxisとPositionがあるわけですが、TumbleがAxisを、Relative to Input PositionがPositionを参照しています。

ってことでTumble。





Axisとして入力されたベクトルとPoint Velocityのベクトルの外積を回転軸にとっているようです。

Relative to Input Positionは、





入力された位置とPoint Positionの差とPoint Velocityの外積となっとりますな。
ちなみに、Input Positionに対して、Multiply Vector by Matrixをかました値を使っているのは、Input Positionの値はグローバル値として扱いたい意図があるようですね。
XSISampleでは爆発の煙の表現のパーティクルでこれを使っておりました。

modo 501のスケマティック。処理は基本的に左から右に流れていくようなんだけど、図のようにまるでループしているかのような接続がなされることがあります。「？」って思ったんだけど、そのチャンネルにもともと設定されていた値を初期値に取る、というような時にそんな感じで接続するみたいですね。



この場合、回転xの値（rotx）をいじると、位置z（posz）の値が

posz = rotx/24 * 0.02 + 200mm

という式で与えられている形になっています。つまり、あらかじめチャンネルの位置zに200mmという値を入れておいた上で、スケマティックで位置zの入力に「+」からの出力を接続します。すると、それで、先の式が実現出来るみたいです。初期値をGUIから設定しておいて、そこから値をスケマティックから触っていこうって時に使うのかな？

ふーん、って思いました。

画面の大きさというより、解像度の話ですね。
曰く、次期iPadの画面解像度はiPhone 3GSからiPhone 4に変わった時のように、縦横2倍になり、2048 x 1536ピクセル四方になる、と。あるいは、それは次期ではなく、さらにその次の話である、と。



2048 x 1536ピクセルの画面の中に各ピクセルのサイズの長方形を置くと、上図のような感じになります。
現行iPadの2倍のサイズだから、それと比べてとても大きい事は分かりますけど、現在のiPadが再生可能なビデオの大きさ（720p）よりもはるかに大きく、フルHDであるところの1080の大きさよりもかなり大きいサイズである事が分かります。

現在販売されているパソコン用ディスプレイの解像度は30インチで2560 x 1600、27インチで2560 x 1440という大きさが主ですけど、それに次ぐ画素数と言えるんですよね。それがいきなりタブレットサイズにおりてくるというのは、実現したら素晴らしいけど、モニタのパネルの問題、そこに表示するためのハードウェアスペック（GPUやグラフィックメモリとか）の問題を想像するに、にわかには信用できない。うん、やっぱり次々世代ぐらいになるんじゃないの、って思います。

次世代で登場したら、迷わず買いですけど、次々世代だとしたら次世代はどうしよっかなぁ。

ちなみに、この密度でのパネルの安定供給が出来るようになるのなら、パソコン用の20インチオーバーのサイズのモニタでも、そんな密度で供給されるようになったらよいですね。もちろん、OS、アプリの対応は必須ですしハードウェアのスペックもかなり求められそうですけど、モニタに表示される内容が美しくなるのは大歓迎ですから。

ちなみに、iPadの現行の解像度は132ppiだそうです。だから縦横2倍だと264ppi。この解像度の23インチモニタはモニターの縦横比が16:9とすると、5292 x 2977ピクセルぐらいになるみたいです。



FCPでビデオ以外の表示の大きさを現状と同じとするなら、上図みたいなイメージ。おぉ、フルHDの素材もこんなサイズでスケーリングによる劣化無しでみる事が出来るよ。…それがいい事なのか悪い事なのか分からんけど、印象としてはとても快適そうですね。…まぁ、まだ夢かなぁ。

modo 501とSoftimage 2011SAPの間でのデータの受け渡しを試してみました。

まず、modo 501からオブジェクトを出力します。これはColladaで出しました。
それをSoftimageのCrosswalkで読込み、アニメーションをつけて、PointOvenでもってMDDファイルを出力します。



質感付けをmodoで行っていたオブジェクトについて、頂点の変形を伴ったアニメーションをするものをはSoftimageでアニメーション付けだけを行い、頂点の変形の情報をMDDファイルでmodoのオブジェクトに書き戻そう、というわけです。

で、modo上のオブジェクトにMDDファイルを適用します。



なんともあっさりと渡りました。
これなら行けそうですね。

ちなみにmodoはモーションベクトルな画像を出せるようになった事で、動画レンダリングにかなり使えるようになったと思います。



後は、イカに手軽にデータを行き来出るようにするか、ですな。

最新「単焦点28mm相当」を比較する [デジカメWatch]

面白そうなので読みました。
28mm相当ってのは、ボクのメインのカメラGR IIと同じ画角だし、気になるところです。

特に、GXRとGR LENS A12 28mm F2.5との組み合わせは、GR IIIの内容を持ったレンズと予想されるので、なおさら気になります。とはいえ、GXR登場と同次にでていた50mmレンズのAFの遅さは目に余ったような気がするんで、そこが心配です。記事ではそこにも触れていて

さほどストレスらしいストレスもなく撮影が楽しめる。

まぁまぁ、って所でしょうか。

レンズの描写特性を見ると、まず3本とも高い解像感だ。（中略）いずれも甲乙が付け難いもので、画面の隅々までシャープネスは高く、大きくプリントしてみたくなるような描写といってよい。

撮影サンプルを見ると、F22まで絞れるのはいいっすね。ISO800の感度があの程度なら俺的には十分実用です（GXRのお話）。

GXRのP10 28-300mm F3.5-5.6VC KITは3万半ばぐらいのお値段で売られているので、一見とってもお安く見える為に買いたくなるのですが、GR LENS A12 28mm F2.5は6万ほどのお値段で、トータル10万程になっちゃうのはちょっといたい。この値段になっちゃうと、GR IIもしくは買い替えてGR IIIと一眼にするか、とか思ってしまうのです。

GXRは、さらに面白いユニットが出てきたら考えるかな。