| Message#29 | |
| post by mqdl | dondonさんのメッセージ(#27)への返事 > これ以上動きが複雑になると破綻する、とのことですが > これは判定対象となる物体のポリゴンが荒い（ポリゴンの目が大きすぎる） > ためにすり抜けてしまうということなのでしょうか？ いえ、ポリゴン数を増やしても基本的に同じ事象が発生します。 Keynoteに限った話ではありませんが、概念で言えばキーフレームの アニメーションの場合、動いているように見えますが、実は「動いていません」 現実世界でもそうであるように物体は力が加わってはじめて動きます。 静止した物体は静止したままです。 ではKeynoteのボーンがなぜ動いているように見えるかと言えば、 これは一種のテレポーテーションで、瞬間移動を高速に行っている為 動いているように見えます。簡単に言えばパラパラ漫画の原理です。 Keynoteで物体を高速移動させるアニメーションを作成すれば分かりやすいと 思うのですが、A地点からB地点まで高速に移動した場合、その中間は存在せず ワープしている動作が分かると思います。 つまりこの間にクロスが存在していれば、クロスをまたいでしまう訳です。 例えばゲームの壁とのあたり判定ではこの問題を解決する為に A地点とB地点の間、つまり2点を結んだベクトルと壁との当たり判定をします。 そこで現在KeynoteとBulletの物体移動の概念の違いを吸収できていない事もあり すり抜けが発生する結果となっています。 > また、動作が重いとのことですが、もともとシミュレート自体 > かなりの計算量になりますので、リアルタイム性がある程度犠牲になるのは > 仕方ないとも思うのですが……。 > 個人的には、keynoteで計算させたモーションをuolimやwarabiなど > 連動レンダラーでレンダリングできれば十分だと思います。 Keynoteはもともとワンショットアニメーションの製作ツールで ゲームなどへの流用を想定している為、物理エンジンの仕様もリアルタイム処理が 可能な範囲を想定しています。 ただ、この件は再考が必要であると考えています。 > nullに関しては……特殊な接頭辞をつけた透明度100%の物体をnull扱いとする… > のでは役に立たないんでしょうねえ(汗) NULLはともかく、Keynoteではボーンを△ポリゴンから算出しているので、 考えてみればアップベクターはこの△ポリゴンから算出できそうです。 ボーンの線分にならない残りの頂点への方向をアップベクターと考えれば 良いかな、と。 公開にはまだ時間がかかりそうですので今しばらくお待ち下さい。 またご意見があれば宜しくお願い致します。 2009年3月22日(日)09時35分 |