So, as I mentioned yesterday, I found a JT v9.5 file to work on, but it died very early in the import process. After a long, unproductive evening trying to figure out why the Tri-Strip Set Shape Node Element read was failing, I quickly started making progress this morning. Turns out there are several significant differences between 8.1 and 9.5 for this element:
- The Base Shape Node rules added an I16 version number field.
- The Vertex Shape Node rules are completely different. They added a version number, combined the former three binding fields into one, much more complicated U64 field, and then duplicated that U64 field (but only if the version number is not 1).
This gets the Tri-Strip Set Shape Node reading properly. Of course, the very next field in file also has a catastrophic failure, but still, progress!
Update: Oh, the next one was just adding version number fields to Base Attribute and Material Attribute. That gets me a lot further into the file.
Also, I’ve got to say using an UUID to identify what kind of element you have is really handy for this sort of debugging — the odds of accidentally generating a meaningful UUID from the next 128-bits in a file is very very low, so you always know which element’s import was incorrect.
Update the Second: The Base Property Atom has replaced the I32 object ID with an I16 version number. The Late Loaded Property Atom has added a version number and a couple of other fields. The String Property Atom has added a version number. (If you wondering how I’m generating these updates, I’m updating when I do a git commit of my changes.)
Update the Third: The Floating Point Property Atom has added a version number — I guess in case they decide to use a double instead of a float in the future? And with this change, I can read the entire elements section of the file.