2007/09/29(土) [n年前の日記]
#1 [iappli] 地形データの持ち方で悩む
blenderで地形のモデルデータを作ったり、空の半円球のモデルデータを作ってエミュレータで表示してたのだけど。何か根本的に間違えてる気がしてきた。そもそも、 figure に格納されたモデルデータの頂点情報・面情報にアクセスできないのではなかろうか。となると、地形とのアタリ判定もできないわけで。
木を生やす方法に関しても悩む。最初は、特殊プリミティブのポイントスプライト(必ずカメラの方向を向いてる矩形ポリゴン)が使えるかなと思ったけど、件のプリミティブは、Zソート・Zバッファの対象にならないわけで。ということでblender上で十字状のポリゴンをチマチマ置いてみたのだけど、作業がめちゃくちゃシンドイ。こんな作業では、そう何本も置けない。それにそもそも木とのアタリ判定が現状では取れない予感。やはり、何か根本的に方法を間違えてる気がする。
自前でデータ内容を決めて、三角ポリゴンプリミティブを逐一発生させたほうがいいのでは…。いや、いっそのこと、テクスチャとの絡みも考えて、描画部分も自前で作るとか。処理速度はめちゃくちゃ遅くなるだろうけど画面の品質は上がりそう。しかしそうなると、画面描画が遅すぎて、リアルタイムに視点を変えることができなくなるか。レンダリングした結果画像をどこかに記録しておいて、2Dで合成していく感じになるのだろうな。
木を生やす方法に関しても悩む。最初は、特殊プリミティブのポイントスプライト(必ずカメラの方向を向いてる矩形ポリゴン)が使えるかなと思ったけど、件のプリミティブは、Zソート・Zバッファの対象にならないわけで。ということでblender上で十字状のポリゴンをチマチマ置いてみたのだけど、作業がめちゃくちゃシンドイ。こんな作業では、そう何本も置けない。それにそもそも木とのアタリ判定が現状では取れない予感。やはり、何か根本的に方法を間違えてる気がする。
自前でデータ内容を決めて、三角ポリゴンプリミティブを逐一発生させたほうがいいのでは…。いや、いっそのこと、テクスチャとの絡みも考えて、描画部分も自前で作るとか。処理速度はめちゃくちゃ遅くなるだろうけど画面の品質は上がりそう。しかしそうなると、画面描画が遅すぎて、リアルタイムに視点を変えることができなくなるか。レンダリングした結果画像をどこかに記録しておいて、2Dで合成していく感じになるのだろうな。
◎ 背景の半円球も気になる。 :
テクスチャが引き伸ばされて、見た目がかなり汚い。2D描画にしたほうがいいのかもしれん。でも、どうやって表示位置を算出したらいいのやら。カメラの角度が絡んでくるのであろうことは判るけど、カメラ位置は絡むのかしら。遠景は非常に遠くにあるはずのものだから、位置は関係ないのか。…頭が悪いからよくわからん。
◎ 座標系もよくわからない。 :
blender と MascotCapsule の座標系の違いがよく分からない。MascotCapsule のドキュメントには、x:右、y:下、z:奥、とあるけれど、エミュレータ上で表示してる感じでは、x:右、y:上、z:手前、のようだし。…いや待てよ。視点で変換した際に、yが上になってるだけ？
こうしてみると、blender上で、x軸回りで90度回転したデータなら PVMicro で表示した際に正面を向いてくれるのもなんだか判るような…。しかしどうにも作業中に混乱してしまう。yをzに、zを-yにして出力したら blender 上の見た目と合ってくれないものだろうか。と思ったが、法線ベクトル、translate、rotate も変更しないといかんのか…。もしかすると頂点の順番も関係してくるだろうか。混乱してきた。
こうしてみると、blender上で、x軸回りで90度回転したデータなら PVMicro で表示した際に正面を向いてくれるのもなんだか判るような…。しかしどうにも作業中に混乱してしまう。yをzに、zを-yにして出力したら blender 上の見た目と合ってくれないものだろうか。と思ったが、法線ベクトル、translate、rotate も変更しないといかんのか…。もしかすると頂点の順番も関係してくるだろうか。混乱してきた。
◎ bmpをテクスチャとして使うのも気になる。 :
ベタでデータを持ってる画像形式だから、そのままだと容量を食うわけで。何かしらの圧縮をしてスクラッチパッド上に置かないといけない予感。今までは、画像の類はgifだったから、圧縮してもたいして減らない ―― プログラム部分の容量をそれなりに消費する割には得られる効果が薄いだろうということで圧縮の類はしてなかったけど。いい加減今回はちゃんと勉強しないと…。
[ ツッコむ ]
以上です。