くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | プログラム | | 模型]

2007-12-05 さぼり

_ 今日は

今日は会社をサボってお送りしております。

あれ、もう寝る時間だ。

_ [COLLADA] 読み込み

モーションまで読み込みがたぶんできた。

多分っつーのはモーション作ってないからだが。

JOINTにバインド状態での逆行列も入ってるから楽だよねー、と思ってたんだが楽じゃねーじゃん。

ウェイト掛けて足しちゃったら逆行列意味ねーよ。 これってどうやって使うんだろう? あ、今の状態がバインドポーズじゃない時かな。

とりあえず、よくわからなかったので、バインドポーズでのJOINTの位置を引いてあげて対処した。まあべつに問題無いでしょ。

モーション読み込むのも比較的簡単だった。まあ結局FBX Converterでも出してくるアニメーションが使えねぇのでBlenderからBVHで出してCOLLADAに変換して読んだが…。

一旦BVHにするとバインドポーズでの骨の情報は移動のみになるんだが、元のモデルのCOLLADAでは骨の位置は回転とかも入ってるんだよねぇ、なぜか。だから混ぜて使えないという。

あれ? 混ぜられないならBVHから一旦COLLADAにする意味無くね…? ま、まあいいか…。

FBX Converterから出てくるアニメーションが使えねぇってのはあれだね、アニメーションが沢山出てくる問題。

BlenderからCOLLADAを直接出すと1チャンネル1アニメーションになって、骨毎に6アニメーションとか出てくる。

FBX Converterだと複数チャンネルをまとめて1アニメーションにしてくれてるので、それ程ではないが、しかし骨1本毎に1アニメーションにしてくれてしまっている。

うーん、BlenderでのActionがFBXでのTakeになってるところまではいいんだが、TakeがCOLLADAでのanimationになってくれないと使いづらくて困るんだけど。1ファイル1Take(Action)の扱いにするならこれでもいいんだが、それもなんだし。

あれ? これ1つのFBX内に複数のTakeがあったらどうなるんだろ…。

前気になった同じプリミティブがマテリアルの有無で2回出てくるのは、BlenderのUVテクスチャでのマテリアルと普通に割り当てたマテリアルの2回分っぽい。普通のマテリアルは割り当ててないので片方はマテリアル無しなのか。

しかし両方出されても困るんだがこれはFBX Converterが悪いのかBlenderが悪いのか判断つかんな。

polygonからtrianglesに変換するのがめんどいとか言ってたけどpolygonでもtriangle_fanで描画したらいけた。なんかダメな気もするが、まあ4角以上のポリゴンは無いと思うから、多分大丈夫だろう。

しかしFBX Converterから出てくるCOLLADAもおかしいな…。effect内のtextureのtexcoord属性はCHANNEL0とかなってるのに、instance_materialのbindでCHANNEL0に実際のテクスチャ座標割り当ててないから、どの座標使ったらいいのかわからん。

そのおかげでFX Composerで読んでもテクスチャ付かなくて真っ黒になるし。これはほんとに困る。

あとこれはFBX Converterじゃなくて俺が悪いんだと思うんだが、library_effectより前にlibrary_materialがありやがる。仕様書見てもlibrary_〜の並び順は規定されてないようだから正しいとは思うんだが、俺の書き方では読んだ順に処理していくようになってるから、先にmaterial読まれるとまだeffectの読み込みができてなくて困る。

これは先に全部読んで、必要になったら処理すればいいんだが、とてもとてもめんどいわ。

_ [Riko] 重くなった

文字描画を増やしたらめっちゃ重くなって困る。

うーん、FreeTypeで1文字ずつレンダリングしてRGBAにCPUで変換するのは重かったかー。

と思って念のため描画を調べてみたら変換したビットマップを描画するglDrawPixelsがめっちゃ重かった。4msとかねーよ。

まあ確かに重そうだが、DrawPixelsやめるのはめんどい。とりあえず1文字づつ描くのはやめて、文字列全部を1つのビットマップにして描画してやるようにしたら速くなってやったー。

それより怖かったのが、文字列のビットマップ配列の変なアドレスに間違って書いたらOSごとふっとんだ。

え? 今時アプリケーションが変なアドレスに書き込んだくらいで落ちるOSって…? Leopardさんしっかりしてください!

うーん、描画の時に変なアドレス渡したとか、MapしたBufferオブジェクトの変な場所に書こうとしたとかならまだ分かるんだが、普通に確保した配列なんだけどなぁ。大丈夫かよこのOS。

もしかしてメモリなんかの調子が悪いのかと思ってびくびくしたが、バグを直したら問題無く動いたようでなにより。でも怖いなぁ。

Rikoではないが、ゲームの方で当たり判定がマップの全てのオブジェクトに対して行われていたので、オブジェクトが増えると無闇に重くなっていた。

それをもうちょっとマシな状態にしたいと思って、適当にグリッドで分けて近くのオブジェクトとだけヒットを取るようにしたら逆に重くなってしまったぜ?

いや、しかし、判定自体は減ってると思うからほんとに重くなってんのかな? オブジェクトがもの凄く多くなるとたしかに前よりはちょっぴりマシだが。

あ、ヒットの判定自体はC++で書いてるからオブジェクトが少ないうちはRubyで書いた分のオーバーヘッドがでかいのかな。

うーん、グリッドで分けた方もC++にしちまおうか。そんなに複雑ではないし。

こういう数が多い計算ではやっぱりRubyの遅さが効いてくるなぁ。


ページのトップへ | トップ «前の日記(2007-11-30) 最新 次の日記(2007-12-12)» | 編集 | kumaryu.net by kumaryu