« mixiからの読み取りまでのmake | メイン | マルチスレッドの話 »
2005年11月16日
Teaspire 開発日誌:: グラフィック周りの処理
Tweet @jin1016をフォロートランスフォーム以降の処理はDirect3Dに任せるので、それよりも前に必要な処理について整理。
・ユーザー入力やアニメーションによる移動、拡大縮小、回転
・移動と拡大縮小、回転の行列合成
・アニメーション時間を進める
・当たり判定とそれによる位置移動 (何度か繰り返す必要あり？)
・Zソート
・境界ボリュームの再計算
・カリング
すぐに思い付いたのはこれぐらい。
他にも気付いたら加筆していく。
ユーザー入力やアニメーションによる移動、拡大縮小、回転と移動と拡大縮小、回転の行列合成
移動などと同時に行列を合成してしまっても良いが、わざと別々にした方が良いかもしれない。
別々にすれば、移動の反映を意図的に遅らせることも出来る。
アニメーション時間を進める
シーングラフを巡回して、アニメーションオブジェクトのみに対して処理していくか、アニメーションオブジェクトのリストを別に持ちそれに対して操作するか。
シーングラフにあるノードの数とアニメーションオブジェクトの比で効率が大きく変わりそう。
アニメーションオブジェクトの方が圧倒的に少なくなりそうなので、リストを別に持つようにしたほうが良いかもしれない。
当たり判定とそれによる位置移動
位置を移動させた時に他のものに当たったら、食い込んだ分逆に移動させる必要がある。
逆に移動させたら、また他のに当たることもある。
無限ループにならないようにある程度で打ち切る必要もある。
LAMPでは、当たり判定を持つオブジェクトのグラフを表示とは別にしていた。
当たりを持たないオブジェクトや当たりの必要のないシーンを考慮し、効率を考えてそのようになっているのだろうか？
同じにするか別にするか考える必要がある。
Zソート
Zバッファを使っていても、半透明のオブジェクトを表示する場合は奥のものから描画するように並べ替えないといけない。
また、Zバッファを使うのなら、出来るだけ前のものから描画していったほうが効率的。
単純に奥のものから処理できるように順にソートするか、境界ボリュームや半透明の有無などから賢くソートするか。
初めは、単に奥から順にで良さそう。
境界ボリュームの再計算
シーングラフはツリー状に構築され、ノードも境界ボリュームを持っている。
これはツリー上方の境界ボリュームで視錐台に含まれないと判定出来た場合に、その下につながっているノードの描画処理を行わなくて良いからだろう。
このようにする場合、下方のオブジェクトが移動したり、境界ボリュームが変更された場合、親となるノードの境界ボリュームの再計算が必要になる。
カリング
視錐台に含まれるかどうかの判定を行い、描画処理の量を減らす。
いきなり視錐台で判定するのではなく、カメラの前後判定などをやってから視錐台をやった方が効率的かもしれない。
順番や処理方法を考えないと。
投稿者 Takenori : 2005年11月16日 00:51
comments powered by Disqus