Open Xaymar opened 6 months ago
This mesh should have animation data: 0x990B45D5D75FFF3A, 28. File contains errors #4, #6 and #3. The values in 0x7, 0x1f suggest it is indeed (type_2b_wide)[4], but the order is not exactly described. It looks like it'd be half, though it is unclear what the 4th value is for. Most of the time, it is 0, but rarely it is non-zero in the "exact" amount that's missing from [nX, nY, nZ].
"Up" in the Mesh is X, "Forward" is unknown.
0xA1AD36AF446FCB7D, mesh 6: Position is offset by 8 bytes, but there's no noticable difference to other structures. In this file, offset 0x18C into the DataType structure is set to 1. The vertex stride here is still 1, so what is the difference?
It's 100% identical it terms of elements:
The only noticable difference is the single bit set to 1 suddenly:
The offset is exactly 8, and only necessary for the first vertex. After that, all data is consecutive again.
This difference is not present in the other variant of the same model, which does not have this offset. Not related to the datatype?
This dword is different at the end.
That same dword is different in every model, so probably not that?
Oh, there appears to be a lot more data for meshes that is currently ignored. Not quite sure how to parse it at all...
This may be a possible BMS export error, and not actually caused by my tool.
We've had the mesh structure all wrong, and didn't notice it until now.
This is big. It means that several meshes were incomplete by default, since we assumed there was only one set of vertex/index information. I'm not sure why the vertex_offset and vertex_count repeat as well, but they haven't changed yet.
0xA1AD36AF446FCB7D = 0x7DCB6F44AF36ADA1. Original BMS script had this set to BigEndian, but it's all LittleEndian. There are three copies of this file throughout the various data files, and only one of them has the 8 extra bytes at the start. The other two are fine.
Is there something in the data file that tells us more about why this is happening maybe?
Original BMS script is correct, it's easier to work with when it's big endian since the file name matches the bytes in the file. It's more like the id is 8 bytes long, so when we read it as an uint64_t it just ends up flipped.
Hashes appear to be MurmurHash(2) 64bit version. Not quite sure how to implement it, but I'll focus on proper exports for now.
When Type 6 or 7 is encountered, the data does not fit into the vertex stride anymore. They cannot reasonably exist in the same space as everything else.
The matrices and vectors in __unk1 seem to be related to something. There's some kind of relationship tree happening there, but I don't quite understand how it works yet.
Similarly, __unk6 seems to belong to the same type of relationship.
The end of unk1 overlaps with unk5 if __unk5 is present.
No apparent relation between bones file and __unk1. Number of bones doesn't ever match up with the number stored in there.
I'm probably approaching this from the wrong angle. I'm assuming that the game engine uses a model format, but this is clearly multiple models in one. It could very well have merged all the meshes into one cluster. It doesn't quite explain where animation and bone data goes though.
As far as I can tell, each of these .unit files is usually accompanied by .bones, .state_machine, .physics and .dfde6a8797b4c0ea. For units without a .bones file, the ones that are present are .physics and .dfde6a8797b4c0ea. For units with a .bones files, the .dfde6a8797b4c0ea is replaced with .state_machine often.
We also see .336bdb8766bd591d accompanying the same file - possibly another part of the .unit file.
Also of note is that several of the files are very clearly Havok Physics, and they all seem to be related to the bones in the model.
May have found some sort of LoD or similar?
unk0.unk_data[].__unk_data[].data[] is always lower than the maximum amount of meshes. Seems to cluster together around meshes.
__unk5 appears to also limit itself to the number of meshes in the unit file.
Unfortunately my theory about type 7 and 6 not fitting in the vertex stride was destroyed by another file having a vertex stride where they fit again.
Format 24 might be "Bone Indices" and Format 25 is "Bone Weights". These both appear to be u8vec4_t
Format 24, 25 and 26 are still unknown. 25 is definitely not bone indices, as either there are 65535 possible bones, or most models refer to bone 255 and assign a weight of 0 to it - assuming 24 is bone weights.
.bones
file, and entry for .bones
is empty.
__unk1.__unkf32mat4x4_1
may be Translation, Rotation and Scale in one Matrix?__unk1.__unk_u16vec2_0
may be u16vec2_t
determining some sort of relationship between nodes.
__unk1.__unkcommonhash
seems to be the hash table for nodes.
We now have a reasonably deep understanding to reproduce a mesh tree in glTF format.
Everything about the
.unit
file structure.Known Information
Related links: