lo48576
commented
4 years ago Thank you for reporting.
I checked your FBX file using binary editor, and I'm fairy certain that the FBX file is broken (i.e. fbxcel worked as expected and correctly detected the data error).
However, the data is syntactically wrong but still meaningful (i.e. maybe semantically not broken).
I'll let the parser support such data with emitting warning (see #3).
TL;DR:
- The FBX file has an error.
- However, the error would not be clitical (unsure but I hope so).
- The
Properties70node which caused the error should have a NULL record because it has no node properties and no children, but it has none.
- I'll update
fbxcelto support such FBX data with non-critical errors if possible.- If you want to read such files directly (without fixing the data), you can wait #3 until I implement it.
- I recommend you to report the issue to developers of Blender (especially FBX exporter).
(I can also report the issue, but I've been busy these days and I'll put off reporting...)
- Use the info below.
Details of the error
By running cargo run --example dump-pull-parser-events -- cylinder_rig.fbx >/dev/null, you can see the output below:
thread 'main' panicked at 'Failed to parse FBX file: Error { repr: Repr { error: Data(NodeLengthMismatch(9687, None)), position: Some(SyntacticPosition { byte_pos: 9687, component_byte_pos: 9662, node_path: [(8, "Objects"), (0, "NodeAttribute"), (1, "Properties70")], attribute_index: None }) } }', src/libcore/result.rs:1165:5This means:
- A node starting at offset 9662 has an error.
- Length info or actual data length of the node seems wrong.
- The node is
Properties70node,- which is the second child of
NodeAttribute, which is the first child ofObject, which is the ninth toplevel node.
- which is the second child of
Lets see the node.
FBX version
First, the FBX version is 7.4.
$ hexdump -C ~/temp/transient/cylinder_rig.fbx -n 32
00000000 4b 61 79 64 61 72 61 20 46 42 58 20 42 69 6e 61 |Kaydara FBX Bina|
00000010 72 79 20 20 00 1a 00 e8 1c 00 00 63 07 00 00 00 |ry .......c....|
00000020The first 23 bytes are magic (header), and e8 1c 00 00 in little endian is the FBX version.
0x00001ce8 is 7400.
This means that end offset of nodes, number of node properties, and length of node attributes are represented by 4 bytes respectively, and NULL record at ends of some nodes are 13 bytes.
The node
$ hexdump -C ~/temp/transient/cylinder_rig.fbx -s 9648 -n 80
000025b0 46 6c 61 67 73 53 04 00 00 00 4e 75 6c 6c d7 25 |FlagsS....Null.%|
000025c0 00 00 00 00 00 00 00 00 00 00 0c 50 72 6f 70 65 |...........Prope|
000025d0 72 74 69 65 73 37 30 00 00 00 00 00 00 00 00 00 |rties70.........|
000025e0 00 00 00 00 2f 2d 00 00 03 00 00 00 2d 00 00 00 |..../-......-...|
000025f0 08 47 65 6f 6d 65 74 72 79 4c 9b 8c 66 00 00 00 |.GeometryL..f...|
0000260053 04 00 00 00 4e 75 6c 6c (S.....Null in the right column) seems to be an attribute value of the previous node.
S means string, 04 00 00 00 means the string is 4 bytes, and 4e 75 6c 6c (Null) is value.
(Flags before them is part of the node name, TypeFlags.)
Next of the attribute, from offset 9662 (0x25BE), a new node begins.
First 4 bytes d7 25 00 00 (= 0x25d7 = 9687) is end offset of the node.
Next 4 bytes 00 00 00 00 (= 0) is the number of node properties.
Next 4 bytes 00 00 00 00 (= 0) is the length of node properties in bytes.
Next 1 byte 0c (= 0x0C = 12) is the length of node name in bytes.
Next 12 bytes Properties70 is the node name.
At this point, offset of the next byte is 9687 (= 9662+4+4+4+1+12), so Properties70 ends here.
Lack of NULL record
However, this is odd.
NULL record can be omitted only when (1) it has one or more node properties and (2) it has no children.
(This condition is same as the condition of braces can be omitted in FBX ASCII format.)
The Properties70 node here has no node properties, so it should have NULL record.
Next 13 bytes filled by 00 is a NULL record, but this seems to be not for Properties70, but for the parent node NodeAttribute (starting at offset 0x2557 and ends at offset 0x25E4).
And after the NULL record, the next node Geometry (which should be a sibling of NodeAttributes node) begins.
In conclusion, Properties70 (starting at offset 0x25BE) should have NULL record for it, but it has none.
This is the error reported by fbxcel crate.
FBX exporter should emit NULL record for the Properties70.
andreasterrius
Hello, so I've been playing around with fbxcel and fbxcel_dom to try and import fbx files from blender
I encountered an error during an import of a test scene
The scene in question is a simple cylinder with a rigged bone https://github.com/andreasterrius/alers/blob/debug/fbx-loader/cylinder_rig.blend
This is the exported fbx https://github.com/andreasterrius/alers/blob/debug/fbx-loader/cylinder_rig.fbx
Weirdly, when I imported the fbx back into blender it works and I noticed that blender added an extra bone on top of the existing one. I am not entirely sure why since I'm not well versed in this field. Maybe it added an extra bone during the import process ? If I export the scene that was imported by blender as fbx again, I can load it using fbxcel_dom, which leads me to to think that it might be the blender exporter that didn't write the fbx properly during the first export.