« アニメーション | メイン | 範囲外のデータの取り扱い »
2007年08月31日
アニメーションライブラリ:: アニメーションのデータ構造
Tweet @jin1016をフォローアニメーションでは座標情報などの変化する値を保持する必要がある。
このような情報はどのように保持するか。
最もシンプルなものは、フレームを基準とし、全てのフレームでコピー元と先の座標などのデータを持つ構造ではないだろうか。
各スプライトの前後関係は、単純にデータの並びで表現する。
このような構造であればフレーム間の依存性はなくなり、任意のフレームをすばやく再生(表示)できる。
描画するほうも特に何かを考慮する必要はなく、単純にコピー元と先の座標を参照してその通りに画像をコピーすれば期待した表示結果が得られる。
難点はフレーム間の粒度が固定されてしまうことだ。
つまり、保存されているフレームレート以外のレートで再生しても、表示の速度が変わるのみで間は補間されたりしない。
考慮することや処理することは少ないのでかなり非力なマシンでは有用かもしれないが、今だとこの形はあまり使おうとは思わない。シンプルで楽なんだけれども。
もう少し融通が利くようにするには、スプライトを基準としたデータ構造にする必要がある。上記の方式はフレームがスプライトを持っているが、そうではなくスプライトがフレームの情報を持つ形。
そして、アニメーションデータはこのスプライトの集合を持つ。
この形であれば、スプライト単位での操作も可能となる。
スプライトを基準とした場合、フレームをどのように保持するかによってデータ構造は幾通りか考えられる。
1. 最初に挙げたフレームを基準とした方法のように、全フレームで全座標情報を持たせる方法。
2. いくつかのフレームをキーフレームとして、間のフレームは補間によって位置を決める方法。
この2つ以外にも考えられるが、
1.は最初に挙げたものと同じような特徴がある。ただ、スプライトが基準となっているので補間しようと思えば補間出来る。
ただし、その場合は2番目のキーフレームで補間するのと大差ない上に、データ量が多くなってしまうのであまり意味はない。
では、それなりマシンパワーがあるのならキーフレーム方式にしてしまえばいいのかと言うと、別の問題がある。
アニメーションを作るツールだ。
使用するツールがキーフレーム方式で且つ、キーフレームの情報を直接取れるのであれば、キーフレーム方式はすんなり使える。
しかし、そうでない場合使えないとはいえないが、全てのフレームでデータを持つのと等しくなってしまう。
キーフレームで情報を持つといっても、最終的にはフレームごとに位置などの情報が割り出されるわけで、全てのフレームでデータを持つ方法の方はどのようなツールからでもデータを作りやすい。
まあ、キーフレーム方式で全てのフレームをキーフレームとした場合は、そのキーフレームの時間情報分データ量が多くなるのと、フレームの割り出しにオーバーヘッドが伴う程度なので、それが問題ないレベルであればキーフレーム方式にしてしまった方が両方に対応できていい。
(全てのフレームでデータを持つ場合、単純な配列のインデックスとしてフレームを割り出せるのに比べて、キーフレーム方式場合は各キーフレームの時間で検索する必要があり、その分フレームを割り出すのに時間がかかる。当然キーフレームの量が増えればその時間は増加する。)
スプライトを基準とした場合キーフレーム方式とするかどうか以外にも、座標などの変化する各値が独立した状態で値を持つか、全ての値をまとめて持つかの2通りの持ち方が考えられる。
当然のことながら、各値が独立した状態の方が柔軟性がある。
ただし、データ量の増加と処理時間の増加がある。
データ量の増加は、それほど生じない可能性もある。各値が独立していれば、変化しない値は1つだけ値を持てばよい。これが全ての値をまとめて持つとなると、変化していない値も他の値が変化するのであれば保持しなければならない。
この事から一概に増加するとは言い切れない面もある。
処理時間は確実に増える。全ての値をまとめて持つ場合、フレームの検索は1度で済むが、独立していると、その種類の数だけ検索する必要がある。
今まで作ったアニメーション再生ライブラリは以上のデータ構造の組み合わせのいずれかになっていた。
ただし、最大限に柔軟性のある方式は選択したことがない。
そして今回はその方法で行こうと思っている。
つまり、スプライトがフレームを持ち、フレームはキーフレーム方式で、各値は独立している形。
少し重いかもと思わないでもないが、CPU速いし余裕だろう。
投稿者 Takenori : 2007年08月31日 00:14
comments powered by Disqus