2007/3/2

フライスルーカメラのスクリプト制御にハマると動画作りのコストが跳ね上がる件  VRMスクリプト禅問答
3/1付でリリースしたVRMoviesの最新作なんですが、これも前作に続きましてフライスルーカメラのスクリプトによる制御のサンプルになってます。

基本的には、ここで紹介したスクリプトの雛形を使って、カメラ位置と視線位置をそれぞれ経過時間から関数的に算出し、従来の編成カメラや地上カメラでは実現困難なカメラワークをやっています。

前回は、レイアウト(アレをレイアウトと呼んで良いものか悩ましいですが)内に固定された“戦艦”が被写体だったので、カメラの動線のみを考えれば良かったんですが、今回は走行する編成とシンクロさせている点で手間が増えています。具体的には、編成の経路上にセンサーを配置し、センサーイベントからフライスルーカメラ制御のメソッドを開始させています。

この、センサー位置の調整もさることながら、現在ボクが採用している手法には問題がありまして、実はSetEventAfter/Timerによって計られる時間は、素でビュワーを動かしている場合と、スクリーンショット取得中とで、かなりズレます。これが何を意味しているかというと、普通にビュワーを動かして完璧にリハーサルしたカメラワークも、いざ[F4]キーを押しながら連続スクリーンショットを取得すると、リハーサルとは編成の動きがズレてしまうということです。実は、これまでにも拙作動画内で多用している“gws/1.0自動ズームカメラ”(VRM4EG所収)でも同じコトが起きます。


仕方がないので、リハーサルの後で、フライスルーカメラ誘導関数の係数や、ズームカメラの単位時間遷移量を調整し、最後はトライ&エラーで動画を作っておるワケです。そういうワケで、VRMビュワーデフォルトのカメラワークのみを使う場合に比較して、やたらと製作コスト(時間)がかかっておる次第です。見た目、地味なのにね。

これについては、少なくともボクは開発元に文句を言う気はなくて(リファレンスでも、スクリプトによる計時が不正確であることは言及されています)要するに、ボクが「動画」という作品発表スタイルにこだわっているがゆえに勝手に背負い込んでいる問題だと思っています。

逆に、動画作りにこだわらなければ(或いは、[F4]によるスクリーンショット取得以外の、ビュワーに負荷のかからない方法で動画を生成するのであれば)フライスルーカメラのスクリプト制御は、これまでにない演出を可能にするので、願わくは読者諸兄にも積極的に挑戦していただいて、本年度のレイアウトコンテストに、そういうのを組み込んだ作品をぶつけて頂きたいな、と思っております。

とは言え、スクロール化済みのズームカメラはともかくとして、フライスルーカメラの任意制御は、VRMスクリプトにおける演算が、いわゆる“式”として記述出来ないことが足枷となり、敷居が高いのも事実であろうと思うワケです。たとえば・・・

x = 4000 + t
z = 4000 + 2t
y = 50

のような、数式でかけば何でもない記述であっても、

※ x,y,z,t は宣言済みであるとする

mov x t
add x 4000.0
mov z t
mul z 2.0
add z 4000.0
setf y 50.0

と、VRMスクリプトでは書かねばならんワケで、これはビギナーレベルのVRMユーザーはもちろんのこと、エキスパートレベルの諸兄におかれても、なかなか難物だろうと思うワケです。

で、まぁ、毎度のコトではあるんですが「こんなんやってみたいぜ!」とお気軽にネタを振っていただければ、いつでもスクリプト化(や、必要があればスクロール化も)しますんで、よろしくです。お声がけいただいた時点で、ボクがまだこのネタに飽きていなければ、即応出来ると思いますので。
0

コメントを書く

この記事にはコメントを投稿できません




teacup.ブログ “AutoPage”
AutoPage最新お知らせ