属性
属性には大雑把に以下の3種類がある。
真偽値
真偽値は ASCII アルファベット1文字で表現される。 この対応関係は FBX バイナリ形式と同じである。
| 論理的な値 | 文字 |
|---|---|
false | T |
true | Y |
T と Y の由来が何なのかは不明。
数値
数値は整数であるか浮動小数点数であるかに関係なく、共通の10進数記法で表現される。
すなわち、 0 のような値があったとき、スキーマなしにこれが整数であるか浮動小数点数であるかを判別する術はない。
0, 42, -0, 123E-12 のような記法が観測されている。
-0 や 123E-12 のような記法は浮動小数点数由来のものと思われるが、これを整数としてパースすべきかは不明。
123E-12 はおそらく 123×10-12 である。
配列
配列は、擬似的にノードのように表現される。
以下は、属性として12要素の数値の配列ひとつだけを持つ Edges という名前のノードの例である。
Edges: *12 {
a: 0,1,2,3,4,5,6,7,8,10,14,18
}
a は array の略だろうか。
a: 以降に並べられる値は、末尾にコンマを持つことも持たないこともある。
規則があるかは不明。
文字列
文字列は "foo bar" のように、 ASCII の半角ダブルクォートで括られた形で表現される。
一部の文字についてエスケープが行われる。
| 元の文字 | 元の文字の ASCII コード | エスケープ後文字列 |
|---|---|---|
" | 0x22 | " |
| LF | 0x0a | &lf; |
| CR | 0x0d | &cr; |
これら以外の文字列についてはエスケープ等は行われない。
少なくとも ASCII 範囲 (0x00 〜 0x7f) では FBX SDK 2018.1 で上記のもの以外のエスケープが行われないことを確認した。
UTF-8 でエンコードされた日本語の文字列なども、エスケープなしにそのままテキストファイル中に出現する。
ここで注意すべきなのは、少なくとも FBX SDK 2016 では文字 & 自体がエスケープされないことである。
これが仕様か実装のバグかは不明だが、 " のような文字列自体を含む文字列は、書き込んだ値と異なる値が読まれることになる。
たとえば esc"esc, raw"raw という文字列を FBX テキスト形式で出力すると、ファイル上では "esc"esc, raw"raw" のような表現になる。
これを再度読み込むと、 esc"esc, raw"raw という文字列になる。
バイナリ
FBX テキスト形式でバイナリデータを保持する必要のある場面は極めて限定的である。
バイナリしか持たない FileId のようなノードはそもそもテキスト形式では存在しないし、テクスチャ等の埋め込みはそもそもテキスト形式では不可能である。
ユーザ定義のプロパティとしてバイナリを与えたとき、バイナリデータは配列と類似した、擬似的なノード風の構文で表現される。
P: "MyBlob", "Blob", "", "U",8 {
BinaryData: "cG95b3BveW8="
}
データ部は base64 でエンコードされた文字列である。
62 と 63 用の記号としては + と / が用いられる。
文字列が長すぎる場合、 base64 エンコード後の文字列で4の倍数文字ごとに分割が行われる。 以下は分割の例である。 (通常4文字毎での分割は行われず、3584文字などそこそこ長い単位で分割される。)
P: "MyBlob", "Blob", "", "U",8 {
BinaryData: "cG95",
"b3Bv",
"eW8="
}
分割後の2行目以降の各行先頭に空白文字がひとつ入っている。 これが必要かは不明。
分割されていた場合、最終行末尾のコンマが許されるかは不明。