日々適当

今回発送する商品は以下のとおりです。
---------------------------------------------------------------------
数量 商品 価格 発送済み 小計
---------------------------------------------------------------------
1 新海誠美術作品集 空の記憶~The ￥2,800 1 ￥2,800

---------------------------------------------------------------------
小計: ￥2,667
配送料: ￥0
消費税: ￥133
Amazon Points ￥-9

発売日前にAmazonに予約をいれていたのだけど、僕にまで回ってこなかったらしいこの画集。今月のアフタンーンに「増刷決定」（だったかな）って書かれていたんで、そろそろ来るかなぁ、と思っていたところです。
ちょっとうれしい。

ちなみに昨日、カッパのクゥと夏休み（コレクターズBOX）だったかな（まだ箱を開けていないもので）が届いた模様。
ちょっと楽しみ。

当たり前と言えば当たり前の話なんだけど、合成時に色をいじりますよ、って作業の時の話。その場合、Vueで空気感を大切にするためにスペクトラル光源にすることが多いけど、その必要性はかなり薄れますな。
もちろん状況次第ではあるのだけど、例えば、

こーいうシンプルな構成のシーンの場合。
大気をスペクトラルと標準大気モデルの両方で出力してみます。スペクトラルの方基準で、標準大気の方で少し大気をいじっております。そうすると結果は以下の通り。

まぁ、どちらの方が美しい？って判断はさておいて、目指す方向はスペクトラルの方だとします。
レンダリング時間は
スペクトラル：12分26秒
標準大気モデル：8分46秒
となっており、1.4倍の時間差がついております。

まぁ今回は静止画なので、Photoshop上でいじってみてスペクトラルと並べてみます。

結構近づけることができそうです。

このシーンの場合は1.4倍の時間差となりますんで、アニメーションさせた時、フレーム数が長くなれば長くなる程、レンダリング時間の差が大きくなってきますんで（スペクトラルで3日かかるものが、標準大気モデルだと2日強で終わる）、状況によってはスペクトラル大気を使わないのもありっすねー。
（ってか、被写界深度系の処理とか、モーションブラーとか、レンダリングコストがかかるオプションは出来るだけ後処理でって考えると、どうしてもコンポジットソフトを通さざるえないから、もしかして、スペクトラルで出す必要の方がむしろ無いのか？）

もちろん、雲海とか、そのなかに光源があって雲が照らされているとか、ボリューム感のある雲とか、ゴッドレイとか、スペクトラルじゃないとどうしようもない、ってことはありますけどね（まぁ合成前提だと、その部分の素材をVueで出す必要も無かったりはするけど、手持ちのツールのなかで、やはりVueが一番簡単に作れそうだし）。

妄想を書き散らします。

QuickTime 7の登場は確かTiger登場と時を同じくしていたと思いました。2005年4月のことです。登場してからもう3年が経過しているわけですね。その間に、iTunesがらみやバグフィックス・セキュリティーアップデートなどでバージョンがあがっていっているものの、いずれにしても、メジャーバージョンナンバーは 7です。
ちなみに、QuickTime 6は2002年7月でした。QuickTime 5はその1年前の2001年5月。QuickTime 4は1999年の6月でした。3は98年だったみたいです。3から6までのスパンはちょっと異常とも言えるペースやもしれませんけど、6から7は3年であったことを考えると、8もそろそろでしょうか（そーいえばこの頻繁にアップデートしていた頃ってAppleはQuickTimeのためのイベントをしていましたよね。QuickTime Liveっての。4日間にわたるものだったみたい。こんなプレスリリース残っていましたよ）。

じゃあ8の目玉は何になるかというと、6であったMPEG4対応や、7のH.264対応的なものはともかくとして、間違いなく64bit化というのが含まれてくるでしょう。これに対応しないと、QuickTimeベースのアプリケーションも、あるいはQuickTimeムービーを書き出したいアプリケーションも64bit化できませんから（後者の場合は正確に書くなら、64bitアプリケーションからQuickTimeを利用できない、って感じかな）

そんな意味でたぶん、映像系（ってか3DCG屋からコンポジット屋さんあたり）の人々にアップデートを望まれているAppleのソフト・ナンバーワンはQuickTImeでしょう。MacよりWindows環境下の方がよりそののぞみは強いかもしれません（Mac環境での64bit化はまだまだこれからの話だし）。

ミドルレンジからハイエンドと呼ばれる3D CGツールは、Windowsにおいては軒並み64bit化されています。それらで、プレビューにレンダリングしてみましょうという時に、連番で吐き出すよりもムービークリップとして吐き出した方が、ちょっと見るには楽だったりしますが、64bitアプリケーションからはQuickTimeに吐き出すことができないわけですね。僕の場合は、それじゃってんで連番で吐き出して、必要があればAEあたりでQuickTimeに書き出しを行ったりします。
余談ながら、後処理を前提としたレンダリング（AfterEffectsに渡すための素材だしとか）や納品のためのレンダリングにおいて、ムービークリップにすることはありません。計算途中でソフトが落ちてしまったら、落ちるまでのレンダリング結果がすべてパーになる可能性が高いから。

今年のNABにAppleは出展しませんでした。
Leopard登場後ですし、AppleとしてはFinal Cut Studioソフトウェア群を64bit化しないわけにはいかないでしょう。その恩恵がとても大きいツールが多いですしね。
しかし、それらツールの64bit版が登場するためには、QuickTimeの64bit対応が欠かせません。

きっとAppleは、Appleにとって非常に重要なこの技術のアップデートのために現在がんばっているんじゃないかと思います。
もしかしたら、6/9から始まるWWDCで何らかの発表があるんじゃないかって期待をしているけど、さて、どうなりますか。

QuickTime 8では、後はどうなるかなぁ。ネガティブなこととしては、Sorenson Video 3のようなレガシーなコーデックをいよいよディスコンするとかあるかもしれない（再生はサポートするけど書き出しはもはや出来ない、みたいな。現在のバージョンにおいて、デフォルトでは書き出しの選択肢に出てこなくなってしまっているコーデックでの書き出しが出来なくなる日も近いんじゃないか、って思います）。そのかわり、マルチスレッドへの対応をより押し進めて、マルチコアのCPUをきっちり使ってくれるようなものになってくれるといいですな。あ、あと、WindowsでQuickTime Playerがもっとさくっと起動してくれるようになるといいなぁ…。もちろん、Mac版で動作が重くなるのは論外ですぜ

昨今はHD解像度で制作される作品も増え、結果として、上下黒の状態で放送されるものが多くなってきています。

そして、昨今は、16:10の縦横比を持つパソコン用ディスプレイも増えてきています。
4:3の解像度の映像をその画面でフル画面表示した場合、上下方向をいっぱいに使うようになるため、左右に黒が乗り、結果として、ディスプレイのサイズよりもずいぶんと小さく表示されてしまう、ということがおこります。

そこで、録画した素材の黒み部分をクロップしてしまおうと考えるわけです。

MPEG Streamclipでももちろんそれが可能であり、



というような感じで、指定してやることになります。ちなみに上記設定は、iPodでの再生は考慮していません。AppleTV でなら再生は出来ると思いますけど、ま、Macで再生できればいいや、っていう設定です。

試しにこの設定で6sのムービーを書き出してみました（ProRes 422の素材）。すると、11秒弱といったところでした。

同じ設定で、Croppingのチェックだけ外しても、その時間はほぼ変わりませんでした。

してみると、16:9の解像度の映像についは、Croppingを行ってもいいのかもしれないなぁ、とか思い始めています（現在は、4:3で黒が入ったまま書き出しているのですね）。

ちなみに、上記設定で書き出されたムービーのサイズは426×360。上下方向は120ピクセル分の黒をカットしたから納得できる数字として、左右方向は640から14をマイナスした数字になっているようです。左右のクロップ値はスケール後のサイズを考慮した方が良さそうです。

僕が山野りんりんのまんがを読むきっかけとなった「お風呂のアレ」がまんがくらぶオリジナルに載っておりました。最近単行本になった「ナギーにおまかせ！」のスピンアウト作品？ですな。

ナギーにおまかせ！を買ってみたものの、これにはお風呂のアレは収録されていませんでした。うーん、残念。

ちなみに本人サイトの連載してたり終わったりした漫画のことによると

「秋月りす先生ＳＰ」が出るとお呼びがかかる、不定期連載（？）。　
…だったのが、セレクションの構成が変わったせいか、はたまた人気がなかったのか（号泣）
お呼びがかからなくなりました…いつかまた描ける日を夢見て頑張ります。

となっておりました。人気、なかったのかなぁ？

ちなみに、アレとはお風呂に浮かべる黄色いアヒルのことですな。数百円で買えるみたいです。や、買わんけど。

こんなムービー

17日はとりあえず近場ということで、近所の沼の周囲を回ってみて素材を探してみたわけですけど、なかなかに難しいですね。

ズームレンジがこれぐらいあるから、水鳥も結構大きく撮れるんじゃないかって期待するものの、まぁ、それ以上に鳥は沖の方を飛んでいたり、ズームしている状態で飛んでいる鳥をとらえるのはなかなか難しかったりと、思うような絵が撮れないわけで。

特にハイスピードの素材をとろうと思ったら、SD残量なんか気にせずに、ずーっとまわし続けて、何か動きを検知したらあるいはその予感があったら、そこにレンズを向けるだけ、みたいな状況にしておかないといけないかもなぁ、とか思いました。

まぁ静止画って意味なら、いつも持ち歩いているGRでは決して撮れない絵が撮れるってのは大きいですけどね。



もっとも、絵のシャープさはGRには遠く、遥かに遠く及ばないので、EX-F1を持ち歩いているときも、GRは手放せない気はしますけど。



持ち運びに便利な三脚がほしいなぁ…。

根本的解決法じゃないのだけど、とりあえず回避可能であることが分かりました。
っていうか、迂闊すぎたんだけど、数値パネルのピボット位置において、それをワールド座標系で動かせるのですね。


サポートに、そうしてはどうですか、って教えてもらったのでした。
まぁ、サポートの聞いた主目的は、Vue内にオブジェクトが読み込まれたとき、そのセンター位置はどのようにして決定されているのか、なんですけど、とりあえず他の3DCGソフトと数字を一致させることができそうです。



試しに、XSI上でシーンを組んで、そのオブジェクト（この場合、いくつかのキューブ）をobjで吐き出し、Vueに読み込ませてみました。このとき、読み込み時の設定で、オブジェクトを手動リサイズし、縮尺設定を10にすると、1ユニットを1mとして読み込んでくれます。この設定は相手がmodoでも同じで、modoから描き出したオブジェクトを同じ設定で読み込むと、Vueシーンと単位を一致させることができます。



こうして読み込ませた上で、ピボット位置を触ってやると、XSIと同じ数値でオブジェクトをいじれるようになりました。
ついでに、60フレーム分のアニメーションを両者につけてみます。
1フレームと60フレームにカメラの位置と方向にキーフレームをうっています。もちろん、そこの部分の数値が同じになるようにしました（XSIのカメラはフリーカメラにしてあります。また、XSIのカメラで回転が(0, 0, 0)だと、グローバルのZ方向を見ますが、本来ZアップであるVueにおいては、カメラの回転が(0, 0, 0)だと、カメラは上方を向くことになります。ですから、回転の値はそれを補正するように入れてやる必要があります。ついでに、Vueのカメラのローテーションの数値は0～360の値しか持たないようです。つまり、365度という値は5度に補正されます）。

この結果、キーフレームをうった1フレーム目と60フレーム目は絵が一致しました。



キーフレームの補完方法が違うためでしょう。途中のフレームは全くあいませんでしたが、何か、一歩前に進めた感じがします。

修理に出していたMacBook Proが戻ってきました。
修理に出してきっかり1週間といったところです。
system.logをみると、7日にイジーニアスバーで起動して後、今日14日まで起動していないように見えます。

System.logの May 7 20:25:40 後が May 14 13:36:00 なのでね。
ただし、僕がMacBook Proを受け取ったのが15時半頃。

となると、パーツが今日、アップルストアに届いて、それで取り付けて起動させてみて、って感じだったのでしょうか（ちなみに、上ブタ部分（ディスプレイ部分）を全交換だったそうです）。

ともあれ、無事動いているし、HDDも初期化されていないし（うっかりAdobe系のアクティベーションを解除しないまま修理に出していたもので、初期化されてしまっていたらとても痛かった）、とりあえずはほっとしております。

2chの全然のびないVueのスレッドで、オブジェクトを読み込んだときのオブジェクトのセンター位置についての不明が述べられています（述べたのは僕だったりするのだが、まぁそれはいいや）。それに対して、高さの真ん中にくるんじゃね？、ってことを書かれている方がいましたが、そうじゃない感じなんですよね。

例えば以下のようなオブジェクトをlwoとして出力。Vueに読み込んでみます。



オブジェクトのセンターは中心（バウンディングボックスのセンター）にあり、高さ方向にのみ、それぞれの割合でエッジにより分割されたキューブです。キューブのサイズは1m四方となります。

これをVueに読み込ませると、以下のようになります。



正面からの投影図になります。それぞれのキューブに表示された座標軸は、オブジェクトのセンター位置を示しています。グローバルな位置としては、バウンディングボックスのセンターが高さ0、奥行き0、横方向に等間隔に分布という感じになっています。

これをみれば分かるように、分割なしと50%のものはどセンターにセンターがありますけど、25%と75%はそれぞれ上下にずれています。
このずれ幅は、25%のものが上方に6.25cm、75%のものは下方に6.25cmという所です（ちなみに、横方向と奥行き方向はオブジェクトの中心にセンターがあります）。

これにより、

• センター位置は保持されない
• センター位置を決める基準にバウンディングボックスは無い

ということが分かります。
また、単純にバーティクスの座標の平均値、という分けでもなさそうです。例えば、25%のものの場合、バーティクスは全部で12個有り、それぞれの位置は
(50,50,50)
(50,50,-50)
(-50,50,-50)
(-50,50,50)
(50,25,50)
(50,25,-50)
(-50,25,-50)
(-50,25,50)
(50,-50,50)
(50,-50,-50)
(-50,-50,-50)
(-50,-50,50)
となるわけですけど（Yアップの座標系です）、このY座標の平均値は8.33cmということになります。
試しに、25%のキューブをXSIに読み込ませ、Move center to Vertices を実行すると、センターのY座標は0.0833となり一致します。

そんなわけで、この、6.25cmという値が出てきた理由がどの辺にあるのか。
それを知りたい今日この頃だったりします。

追記
重心じゃね？、ってご意見が2chに書き込まれました。
3DCGソフトが一般的に扱うオブジェクトの重心って何なんだろ？
バーティクスのセンターじゃないのか？

追記
その後サポートからさらに返答をもらいました。
e onにまで聞いてくれたみたい。
それによると、やはり重心であるってのは正解みたいです。
ただ、一筋縄にはいかないみたいで、つまり、どうもVueはオブジェクトを読み込んだ後、ポイントを再構成しているらしいです。たぶん、バーティスクの位置が、外部3D CGツールと違う可能性がありうる、ということでしょう（実際に経験があるんですけど、同じオブジェクトを読み込んだはずなのに、センター位置が一致しない（微妙に違っている）ことがありました）。
そんなわけで、Vueの内部のアルゴリズムを完全に再現できないと、どうにも難しそうです（教えてはくれないでしょうし、教えてもらったとしても実装するのは大変そう…）。

ってことで、この件はあきらめることにします。

先週、実はちょっと大きめの衝動買いをしてしまっておりまして…
まぁ、カメラを買ったのですけど、こんな絵がとれます。



って面白みもなんにも無い絵ですが(^^;　ってか腕の無さを露呈している絵と言うか。ピンが甘いよ。

シャープな絵作りという意味では、GR DIGITALでとった方がずっといいものがとれるように思います。

んじゃ、なぜ衝動買いなんかしてしまったのか。
それはとても面白い動画を撮影できるから（職場に行く途中、ちょっとまわしてみたものです。盗撮っぽいっすな（苦笑）。や、ある意味盗撮なのだが…）。

買ったものはEX-F1。カシオのデジカメです。

でも、それを試し取りしている時間がなくて、遊べていません。
ってか、実用、という意味でとらえる場合、さて、何に使おう、って感じなんですけどねー（普通に高倍率な望遠レンズを持つカメラとして持ち歩いてもいいのだけど、さすがに普段持ち歩くにはおおきすぎる）。

HD動画撮影にでも使おうか。