ミスった。
前にも書いたけど、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本体の方。
アニメーション、けっこうまとめられたけど、まだ色々と不安な点が。
今のところノードの変形をアニメーションさせるくらいなら出来る。
マテリアルのアニメーションも出来るかな? ちょっと対応させれば。
でもUVアニメーションとかってどうなんだ? どうすりゃいいのかわからん。
ああ、まあ、今のところわからんものは放置でいいか。
とりあえずノードの変形とマテリアルのアニメーションさえあればなんとかなるのかな?
ああ、なんかCOLLADAのアニメーションってひどいよなぁ。
いや、channelのtarget指定が無茶苦茶なのがひどいのか。target解決してみないと何のアニメーションなのかわからないのと、targetの書き方が適当すぎるのが困る。マジで困る。
なんか、とりあえず適当に対応するか。コンバートが無理な時は落ちるよ。うん。