Xファイル書き出しに関する覚え書き

①UVを作る際にポリゴンが重なっている、もしくは非連続ポイントの位置によってはスキンアニメーションが破綻するケースがある。
②ただし重複部分のUVを別々に作ったうえで改めて重ねなおすとこの問題は回避される。
③また適正に作成されたデータもいったん結合解除した上で結合しなおすと破綻が生じることがある。

UVのポイントマップとウェイトのポイントマップが書き出し時に混同されて書きだされているようないないようなそんな印象。
おまけに、不正なポイントがあるとそれとは無関係な部位に不正な変形が生じたりする。
以前のメモでUVが適用されていないポイントがあると変形に不具合が生じるという記述があったけど、それと一緒で、スキンアニメーションの不具合の原因は必ずしもウェイトマップだけとは限らない。
UVマップとウェイトマップにはなんらかの因果関係が存在している。
ただし、例のごとくビュワーによって変形の結果は異なる。
DirectX SDK付属のビュワーでは不正に表示されたモデルもLW付属のビュワーでは正しく表示される。
書き出し時にLWネイティブの何かがあるのかも。
いったんFBXにしてMAYAからエクスポートしたらどうなるのかはまだ未調査。
XNA開発を念頭において考えるなら、そもそもFBXで書き出せばいいだけの話じゃね？って気もするけど、Xファイルに関しては十分解析を済ませておかないと後々泣きを見る気がするので、引き続き要検証。

追記：問題をはらんでいる箇所を別レイヤーに移し、結合解除＞WeldUV（UVの結合）を繰り返すことで全ての問題箇所を回避終了。
やはり、ポリゴンの重複というよりは、非連続UVの処理の問題な感じ。
結合解除後、ポイント結合をする際UVのマージを同時に行うオプションがあるけど、実行すると確実にツールがクラッシュする。本来ならこれで一発なはず。
あと、まだ未解決なのがサーフィスが違うもの同士をマージするとダメっぽい。
別サーフィスにした場合はそこで結合しないほうがいいのかも。

DirectX

まず、こいつを見てくれ。
昨日言っていた透過表現。
試してみたらあっさりと成功した。
やり方はとても簡単。
フォトショップでテクスチャを作るときにアルファ付きの32bit画像を作って、それを適用した状態で出力するだけでOK。
ただし、半透過表現は無理みたい。
白＝不透明
黒＝透明
の白黒二階調で要はクリップマップと同じ仕様。
ちなみに白と黒以外の色を使うとその部分は強制的に白になります。
でもこれで髪の毛や木の表現なんかが出来そう。

DirectX物語 動きのないアニメーションと透過表現

出力時の問題点はほぼ全て洗い出されたのではないかと思う。
モーションのついていないボーンに関しても
Animationタブ＞RemoveUnusableKeyframesのチェックを外しておけばちゃんと「静止しているモーション」として書き出されることが判明した。
このチェックは必ず外しておく事。
あとはオブジェクト名・サーフィス名・テクスチャ名等の命名ルールを徹底する事。書き出し後にファイル名を変更するだけではNG。なぜかというとこれらのファイル名の情報が書き出し時にxファイル内に格納されるから。
命名ルールは必ず守ること。

今日たまたま思いついた事なんだけど、ポリゴンの透過に関してはテクスチャを32bitで作れば出来るんじゃないかとちょっと思った。
まだ試していないけど可能性は非常に高い。
明日はこれを試してみるつもり。

DirectX2008_01書き出し覚え書き

（形状書き出しじの注意点）
　①全てのポイントに対してUVマップを「1つ」設定する。（1つ以外はNG）
　②ウェイト値に0%のものがあるとNG
　③ボーンの数とウェイトの数は1：1

（まだ良くわかっていないこと）
　①ウェイト値に100%以外を割り当てた時にそれが反映されるのか？
　②一つのポイントに対して2つ以上のウェイトを割り当てるとどうなるのか？

誰かわかったら教えてください。



（良くわかっていないこと：アニメーション編）
モーションのついていないBONEはそのボーンの回転値情報が書き出されない（もしくはアニメーション切り替え時に反映されない）模様。つまりポーズが違ってもキーフレームアニメーションがないBONEの場合、アニメーション切り替えをしてもそのポーズ変更が反映されず、その前まで再生されていたモーションの最後のボーズがそのBONEに反映されるみたい。
これは大問題。
プログラム的に解決できる問題なのか、それともDirectXのデータを書き出す時に解決しなければならない問題なのか…。
目下はこの問題が最優先課題。


（そのほか的な注意点）
LW上でいう所のBONEやオブジェクトなどの「アイテム」は書き出し後DirectX上の用語では「フレーム」と呼ばれている。
LWで言うところのフレーム（＝時間軸）と混同しないように注意。
とくにプログラム班の人と話をする時は注意。彼らの言う「フレーム」と言はLWでいうところの「BONE」のこと。逆にこちらから話をするときもその辺を意識する必要がある。重要。



まだあるかも

DirectX

過去のDirectX関連の記事を「DirectXの研究」というカテゴリーに分けて整理中（来週あたままでには終わらせる予定）なので、これから書出し作業を始める際に一通り目を通して参考にしてください。

色々とわかってきた

①モーションXは書き出し時のファイル名とanmationSetが同名になるので書き出し後にファイル名を変えないほうがいい。

②モーションX用に書き出すためのダミーとなるMeshはNullではNG。NullだとそもそもMeshの記述が全て欠落してしまう。1ポイントオブジェクトをあらかじめモデラーで作っておいてそれと置き換えれば00メッシュを配置できる。

③標準IKはまだ未確認だけど各種モーションは一度、各ボーンのキーフレームアニメーションにに変換してからでないと書き出されない。BakeMotionを使うか、一度書き出してキーフレームにしたあともう一度書き出しなおせばOK

④モーションの再生FPSがイマイチ謎。60FPSらしけどサンプルのXファイルを見ると再生ステップが100FPSになっている。まあ、これは感覚で合わせればいんだろうけど。

でも、今回のファイルはわりと自信があるので早く試してみてもらいたい。
火曜ってライセンス朝からあるんだったっけ…？

ヒテンミツルギスタイル お取り寄せ

今、自分のつくったXファイルを眺めていて、ふと気がついたんだけど、Xファイルの中にはIKのゴールオブジェクト用のNullも一つのフレームとして登録されている。ということはゴールのヒエラルキを入れ替えてもファイルの構造が変わってくるのではないのか？
そういえば先週の時点で用意したファイルはアニメーションを作りやすいようにとゴールのヒエラルキの試行錯誤と平行して書き出しをしたものなので、メッシュXとモーションXでは構造が違ってしまっている可能性も充分考えられる。

先週末に週明けには改善されたファイルを渡すよと大きい事を言ってしまってちょっと後悔していたけど、色々いじってみれば案外色んな手がかりがつかめた気がする。このファイルの是非を速く確かめてみたい。

わかったこと

メッシュXファイルとモーションXファイルにはそれぞれ以下のような事が書かれていた。（覚書程度なので未整理部分も多い）
この記事は後々書き足しをする予定。

（共通）
xof 0303txt 0032

template XSkinMeshHeader {
<3cf169ce-ff7c-44ab-93c0-f78f62d172e2>
WORD nMaxSkinWeightsPerVertex;
WORD nMaxSkinWeightsPerFace;
WORD nBones;
}

template VertexDuplicationIndices {
<b8d65549-d7c9-4995-89cf-53a9a8b031e3>
DWORD nIndices;
DWORD nOriginalVertices;
array DWORD indices[nIndices];
}

template SkinWeights {
<6f0d123b-bad2-4167-a0d0-80224f25fabb>
STRING transformNodeName;
DWORD nWeights;
array DWORD vertexIndices[nWeights];
array FLOAT weights[nWeights];
Matrix4x4 matrixOffset;


メッシュXファイルのファイル構成

Mesh（ポイント情報）
MeshNormals（ポリゴン情報）
MeshTextureCoords（おそらくUV情報？）
VertexDuplicationIndices（ポイント数、ポイント番号の定義？）
MeshMaterialList（サーフィスが変換されるもの？）
　Materials
　　1.000000;1.000000;1.000000;1.000000;;（この辺は恐らく光沢等の設定）
51.200001;
0.100000;0.100000;0.100000;;
0.000000;0.000000;0.000000;;
TextureFilename {
"Face_C.dds";(テクスチャの指定)
XSkinMeshHeader
SkinWeights（ここ以降各ボーンごとにどのポイントがWeightに何パーセントでアサインされているかの指定）
　F2_CTRL_C_Back
　F3_CTRL_C_Lowerlip
　F4_CTRL_C_Root
　F5_CTRL_C_Upperlip
　F6_CTRL_C_Waist
　F7_CTRL_L_Ankle
　F8_CTRL_L_Elbow
　F9_CTRL_L_Finger0
　F10_CTRL_L_Finger1
　F11_CTRL_L_Finger2
　F12_CTRL_L_Finger3
　F13_CTRL_L_Finger4
　F14_CTRL_L_Knee
　F15_CTRL_L_Lipside
　F22_CTRL_L_Thigh
　F25_CTRL_L_Toe
　F26_CTRL_L_Upperarm
　F27_CTRL_L_Wrist
　F28_CTRL_R_Ankle
　F29_CTRL_R_Elbow
　F30_CTRL_R_Finger0
　F31_CTRL_R_Finger1
　F32_CTRL_R_Finger2
　F33_CTRL_R_Finger3
　F34_CTRL_R_Finger4
　F35_CTRL_R_Knee
　F36_CTRL_R_Lipside
　F43_CTRL_R_Thigh
　F46_CTRL_R_Toe
　F47_CTRL_R_Upperarm
　F48_CTRL_R_Wrist
　F51_DEST_L_Breast1
　F53_DEST_R_Breast1
　F55_EFCT_C_Back
　F56_EFCT_C_Head0
　F57_EFCT_C_Head1
　F59_EFCT_C_Neck1
　F60_EFCT_C_Waist
　F61_EFCT_L_Ankle0
　F62_EFCT_L_Ankle1
　F63_EFCT_L_Ankle2
　F65_EFCT_L_Crotch0
　F67_EFCT_L_Crotch11
　F68_EFCT_L_Elbow0
　F69_EFCT_L_Elbow1
　F70_EFCT_L_Elbow2
　F71_EFCT_L_Finger00
　F72_EFCT_L_Finger01
　F73_EFCT_L_Finger10
　F74_EFCT_L_Finger11
　F75_EFCT_L_Finger20
　F76_EFCT_L_Finger21
　F77_EFCT_L_Finger30
　F78_EFCT_L_Finger31
　F79_EFCT_L_Finger40
　F80_EFCT_L_Finger41
　F81_EFCT_L_Hip0
　F82_EFCT_L_Hip1
　F83_EFCT_L_Hip2
　F84_EFCT_L_Hip3
　F85_EFCT_L_Hip4　
　F86_EFCT_L_Knee0
　F87_EFCT_L_Knee1
　F88_EFCT_L_Knee2
　F89_EFCT_L_Lowerarm0
　F90_EFCT_L_Lowerarm1
　F91_EFCT_L_Lowerarm2
　F92_EFCT_L_Lowerarm3
　F93_EFCT_L_Lowerarm4
　F94_EFCT_L_Shin0
　F95_EFCT_L_Shin1
　F96_EFCT_L_Shin2
　F97_EFCT_L_Shin3
　F98_EFCT_L_Shin4
　F99_EFCT_L_Shoulder0
　F102_EFCT_L_Shoulder20
　F103_EFCT_L_Shoulder21
　F104_EFCT_L_Shoulder22
　F105_EFCT_L_Shoulder23
　F106_EFCT_L_Shoulder30
　F107_EFCT_L_Shoulder31
　F108_EFCT_L_Shoulder32
　F109_EFCT_L_Shoulder33
　F110_EFCT_L_Thigh0
　F111_EFCT_L_Thigh1
～以下略
　F184_EFCT_R_Wrist1

Frame F185_ROOT（ルートの指定？）
ここ以下はボーンの階層構造と初期値
　


モーションXファイルのファイル構成
Mesh
MeshNormals
MeshMaterialList
XSkinMeshHeader
Frame F185_ROOT（ルートの指定？Mesh側と同じ数値）
ここ以下はボーンの階層構造（Mesh側と同じ数値）
AnimationSet AnimationSet_00R_Run（上で記述されているフレーム（F○○○で表記、ボーン）一つ一つに対して以下の書式でアニメーション値が記述されている）

Animation Animation0 {
{ F1_NULL_Layer1 }
AnimationKey {
4;
30;
0;16;1.000000,0.000000,0.000000,（以下数値は略恐らく座標値、回転値）;;,
100;16;1.000000,0.000000,0.000000,（以下数値は略恐らく座標値、回転値）;;,

Tk原君に依頼

今の問題はメッシュとモーションを別々のX-fileにした場合それを正しく読み込むことが出来ないということ。

理由がファイルの作り方に問題があるのか、それとも読み込むプログラムに問題があるのかそれがわからない。
F3D班のほうでも皆目見当がつかないって言っていたから、とりあえず今の僕に出来る事は、サンプルデータをひたすら解析してそのファイル構成のとおりに自分のデータを作る事ぐらい。

んで、ここからが要望なんだけど、ビュワーにモーションの切り替えの機能を実装して欲しい。
今のビュワーみたくEXEファイルと同一フォルダ内にメッシュXとモーションXを配してTXTでそのファイル名を指定し、実行するとボタンでモーションが切り替わるもの。これを作っておいてもらえばファイルのデバッグが3D班のほうで行えるから、イチイチ手を煩わせずにすむ。
お願いできますか？

単位の共有とか移動座標の算出とか

昨日F3Dの面々と話していて気がついたんだけど、LightWave上の縮尺と、プログラム上での縮尺を確認しておいたほうがいいなと思った。
どういうことかというと、プログラム上であるメッシュの座標を「1」移動させたとすると、それがLightWave上での「何メートル」に相当するかということ。

歩き系のモーションに関して、
①キャラの前進移動をモーション上で制御して、1ループするごとに基準点をまとめて一気に前進させるべき
か、もしくは
②モーションはあくまでも「その場歩き」で前進は全てプログラム上で制御するべき
か、そんな話が出た。
①のメリットはなんといってもモーションの接地感が出しやすくて、モーションそのものが自然に見えることだと思う。
②はいろんな意味で「扱いやすい」（多分）。たとえば、実際ゲームになったときにキャラにターゲットを設定したり、衝突判定を設定したりするときにプログラム上ではそのキャラのファイルのルート座標を参照すればいいだけなので、とてもシンプルだと思う。それに対して、①の場合はxファイル内の特定の座標（キャラの全身の移動を制御しているBoneの座標）を特定のフレームで参照してから算出しなければならないわけだから、キャラのモーションのフレーム数がかわったりするだけでもかなり厄介なことになる気がする。わかんないけど。違うのかな？＞プログラムの人

T田くんが扱うことになったカメラの追従に関する事とか。思いっきりこのことに関係してるよね。どうなの？


で、まあ、話はそれたんだけど、とにかく縮尺をあわせておくことはたいして大変な事じゃないし、早い時点でやっといて損はないことかなと。
要はキャラの歩幅にあわせて入力に対する座標移動値を決めれば接地感は出る訳なんだから、こちらでその数値を調べといて、それをファイルを受け渡す時に一緒に渡せばいいんだと思う。
結論。
「10cm幅かなんかでグリッドを表示させた基準オブジェクトをTTM君とTK原君に渡す。」