Post by kion on Jan 16, 2022 2:17:02 GMT -5
gitlab.com/megamanlegends/sulphur-bottom/-/wikis/Data-Type:-Entity-Mesh#entity-mesh-header
While writing the documentation for the mesh format, I noticed that I had a few unknowns in the struct format. Strictly speaking these don't seem to have any effect on the ability to parse and extract models from the game, but it's never fun to have holes in a struct documentation either.
In terms of approach the options for trying to figure out what these values do is to:
1. Scan though all of the files to see if there is a pattern
2. Edit the game's memory to see what happens when changed
3. Change the game's ISO to see what happens on load time
4. Dig through Ghidra to see if there are any hints
While writing the documentation for the mesh format, I noticed that I had a few unknowns in the struct format. Strictly speaking these don't seem to have any effect on the ability to parse and extract models from the game, but it's never fun to have holes in a struct documentation either.
In terms of approach the options for trying to figure out what these values do is to:
1. Scan though all of the files to see if there is a pattern
2. Edit the game's memory to see what happens when changed
3. Change the game's ISO to see what happens on load time
4. Dig through Ghidra to see if there are any hints
To start out, I want to scan the files to see if that provides any hints. Probably isn't going to have too much in terms of functionality, but might as well look around anyways. Right now I'm mostly interested in the fourth byte after the polygon count, and the first unknown dword. The 16 bytes of padding at the end is frustrating, but it doesn't present a gap, so I can try to ignore it for now.
Source Here: pastebin.com/S079c2Un
Full data Here: pastebin.com/LrNiNK66
It looks like the values for the third byte are either 1 or 3 which probably indicates it being used as some kind of flag. Probably 0b01 is always set. And 0b10 is only set occasionally. So we can see if there are any differences in the header when the values are 3 vs 1.
As for the unknown value, most of the time it seems to be zero. But when it does exist, it looks like a pointer or an offset. So I can generate a list of models that use the unknown offset and try to use them as a sample to see what's going on in the header.
Edit 1:
Just realized what the third byte does, it's the level-of-detail count. A model can have three level of details, high, medium and low depending on how far it is from the camera. But for other models, like Megaman or Roll, they're always close to the camera, so they only have one level of detail. The next is to try and figure out what the unknown value is. It looks like a pointer, so hopefully the functionality should be apparent from looking at the file, without having to test in game. But on the upside, if we do need to test in-game this should be easier to test than a flag.
Just realized what the third byte does, it's the level-of-detail count. A model can have three level of details, high, medium and low depending on how far it is from the camera. But for other models, like Megaman or Roll, they're always close to the camera, so they only have one level of detail. The next is to try and figure out what the unknown value is. It looks like a pointer, so hopefully the functionality should be apparent from looking at the file, without having to test in game. But on the upside, if we do need to test in-game this should be easier to test than a flag.
Edit 2:
For the second unknown, i have it listed as "bounding box" in my previous notes. Which was probably a complete guess as I really didn't care what's there. If it doesn't have too much to do with the asset, then I honestly don't care, but I want to build a more complete picture of what's going on. So the next step i want to scan through all of the headers for all of the values in the game. See which values are set, see which values are not set and try to get an idea for the length of this unknown area. If it is a fixed 0x14 bytes or something, then at least i can know that, and can come back to test later if I'm really annoyed by not having a complete picture. Also it looks like my theory about the LOD count was wrong for the first bit, so I might try start by comparing those two.
For the second unknown, i have it listed as "bounding box" in my previous notes. Which was probably a complete guess as I really didn't care what's there. If it doesn't have too much to do with the asset, then I honestly don't care, but I want to build a more complete picture of what's going on. So the next step i want to scan through all of the headers for all of the values in the game. See which values are set, see which values are not set and try to get an idea for the length of this unknown area. If it is a fixed 0x14 bytes or something, then at least i can know that, and can come back to test later if I'm really annoyed by not having a complete picture. Also it looks like my theory about the LOD count was wrong for the first bit, so I might try start by comparing those two.