くまりゅう日記

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

2006-04-08 バグってるよ

_ 配信

ねみー。

夜中1時から配信とかきつい。

_ [Riko] Ruby/DAE

ミスった。

前にも書いたけど、node要素の変形辺りの要素は出現する順番が重要になる。

回転とか移動とかの変形は左右可換じゃないからね。

で、問題発覚。

ruby/daeは要素の出現順番保持してねーや。

いや、正確には中途半端にしか保持してないと言うべきか。

各要素の種類別に、こう出現しなくちゃいけないはず、というのは保持してる。つかクラスがそうなってる。

node要素を書き出す時にはinstance要素の前に必ず変形辺りの要素が出てるはず。

あと同じ種類の要素は順番を守って出現する。

例えばX軸のrotate、Y軸のrotate、Z軸のrotateがその順番で出現していれば、読み込んだあとも、その順番は保持される。

でもね。

translateが3つ、rotateが3つ、translateが3つ、rotateが3つ、なんて形で出現されるとだ。

translateが6つあるのはわかるし、そのtranslate郡の中での順番は保持される。rotateも同じ。

でもtranslateとrotateが3つずつ交互に入ってたなんて情報は保持できてなかったわけだ。

つか、インターフェースを見る限りではC++のCOLLADA DOMも、特にそれを取得できるインターフェースは用意してないんだよね。いや、あるか。getChildrenだな。

つか、むしろ考え方がおかしかったっぽい。

childrenが主で、rotateとかの配列取得は、childrenの配列の差分を返すのが正しいのか。

そして、rotateなんかが返す配列を変更しても当然childrenには反映されない。childrenを直接いじれと。

たしかにその方が正しいな。ちょっと大々的な変更になるが。

そのうちやっておこう。うん、そのうち。

_ [Riko] アニメーション

で、Riko本体の方。

アニメーション、けっこうまとめられたけど、まだ色々と不安な点が。

今のところノードの変形をアニメーションさせるくらいなら出来る。

マテリアルのアニメーションも出来るかな? ちょっと対応させれば。

でもUVアニメーションとかってどうなんだ? どうすりゃいいのかわからん。

ああ、まあ、今のところわからんものは放置でいいか。

とりあえずノードの変形とマテリアルのアニメーションさえあればなんとかなるのかな?

ああ、なんかCOLLADAのアニメーションってひどいよなぁ。

いや、channelのtarget指定が無茶苦茶なのがひどいのか。target解決してみないと何のアニメーションなのかわからないのと、targetの書き方が適当すぎるのが困る。マジで困る。

なんか、とりあえず適当に対応するか。コンバートが無理な時は落ちるよ。うん。


ページのトップへ | トップ «前の日記(2006-04-06) 最新 次の日記(2006-04-17)» | 編集 | kumaryu.net by kumaryu