2008/07/30(水) [n年前の日記]
#1 [iappli] bacを読んでビルボードを分離等するスクリプトに手を入れたり
PACで保存したbacを読めるようにスクリプトに手を入れているのだけど。中間記録状態をダンプしてみたら、その時点で元々のbac(blenderでエクスポートしたbac)と内容がほとんど異なることに気がついた。blenderでエクスポートしたbacに比べて、PACで保存したbacは、以下の点が違う。
どうやらギリギリまで、PACでbac保存しないように作業を進めていかないとダメな予感。ビルボード用データとアタリデータを分離・出力したその後 ―― 「ここから先、このデータは表示にのみ用いられるデータなのだ」という段になったところで、PACでの編集を解禁、という感じの作業手順になりそう。…なんだか忘れちゃいそうだなあ。
- PACで保存されたbacは、各数値の少数点以下の桁数がグンと少なくなっている。根拠のない想像だけど、PAC内で扱える数値の桁数制限が、blender内で扱える数値の桁数制限より、はるかに少ない？
- 不要な項目・中が空欄の項目が、省略された状態で保存される。たとえば、全ポリゴンにテクスチャが貼ってある場合、blender版には空欄の "Colors" が含まれているが、PAC版は丸ごと省略される。
- Material名はそれぞれ異なるが使ってるテクスチャは同じ、というMaterialがあった複数あった場合、blender版は各Materialがそのまま列挙されるが、PAC版は1つのMaterialに置換されてしまう。
- PACで保存されたbacは、一部のMaterial名だけが消滅する。消滅する条件は不明。
どうやらギリギリまで、PACでbac保存しないように作業を進めていかないとダメな予感。ビルボード用データとアタリデータを分離・出力したその後 ―― 「ここから先、このデータは表示にのみ用いられるデータなのだ」という段になったところで、PACでの編集を解禁、という感じの作業手順になりそう。…なんだか忘れちゃいそうだなあ。
◎ そもそもMaterial名の有無は定義されてないのか。 :
BAC Ver.6.0のドキュメントを眺めたら、そもそも material の中に "name" という要素はなく。blenderのスクリプトではオマケで出力・PACその他では含まれていてもエラーにならなければいいや程度の扱いだったのかもしれん。
となると、ビルボード用データの出力も、アタリデータの出力も、本来はblender用のスクリプトを書いて対応すべき内容、なのだろうか。bacを解析してどうにかしようという方針自体に無理があるのかなあ…。
アタリ種類ごとに地形データをオブジェクトに分割して、という手もありそうなのだけど。その場合のメリットとしては、
となると、ビルボード用データの出力も、アタリデータの出力も、本来はblender用のスクリプトを書いて対応すべき内容、なのだろうか。bacを解析してどうにかしようという方針自体に無理があるのかなあ…。
アタリ種類ごとに地形データをオブジェクトに分割して、という手もありそうなのだけど。その場合のメリットとしては、
- オブジェクト単位なら "name" があることがBACのドキュメントにも明記されているので、問題が少ないかもしれない。
- blender上でMaterialの割り当て等が随分楽になる。
- 地形モデルデータの修正作業が面倒になる可能性が高い。異なるオブジェクト間で多数の点の座標を一致させるのが一苦労かもしれず。
- 点が共有されなくなって、頂点データの量が無駄に増える可能性がありそう。
[ ツッコむ ]
以上です。