How exactly do you end up spending this much time in front of a hex editor, equipped with, seemingly, a good amount of rendering/geometry knowledge, and not have programming experience? What are you, some kind of hardcore scripter? 
Eh, I should have said relative inexperience. I haven't made anything major, nothing 3D either.
Bad news, I can't seem to find any working SMD import plugins for Blender-- huh, spoke too soon, guess I'm not restricted to OBJ files anymore. Yay! Strangely, models from Gitaroo Man Lives seem to have inverted normals (which takes like 3 seconds to fix in Blender
). I wonder if there any other games with this issue, and if there is any way to tell in advance.
(Now don't get the impression that I actually know how to use Blender-- I'm bumbling and stumbling around that program like a drunken Flatlander.)
Now, below this line...
These are slightly more detailed descriptions of
the 0x80?? chunks from this post. Except that some of them are incomplete or unknown or blah blah blah.
================
All(?) chunks are padded to a multiple of 4 bytes.
Little-endian unless otherwise noted:
int8, int16, int32 -> signed 8/16/32-bit integer
uint8, uint16, uint32 -> unsigned 8/16/32-bit integer
float32 -> 32-bit floating point decimal
word -> 2 bytes
dword -> 4 bytes
0x8012 - File name (always texture?)
- A null-terminated string padded to 4 bytes.
Sometimes this isn't accompanied by file data, and even if it is, the file type might not match (e.g. texture.tga might be followed by GIM file data)
0x8013 - File data (always texture?)
- uint32 filesize, followed by the file data itself. (Nitpick: Although chunk is padded to 4 bytes, the uint32 filesize doesn't have to be a multiple of 4.)
0x8014
- unknown - contains 6 float32s
Has been seen under 0x0003 Sub-File, 0x0004 Bone Info, and 0x0005 Model Surface
0x8015 - Scale and Bias
- Uh, whatever MrAdults said on his blog page.
0x8041 (reference to parent bone?)
- dword [00 04 10 XX] where XX is the index of the parent(?) bone (as listed in the current Sub-File, starting at 0).
0x8044 - a big list of bones (help naming please)
- u32 numBones, followed by that many bone references. Each bone reference is a dword [00 04 10 XX] where XX is the index of the bone (as listed in the current Sub-File, starting at 0).
0x8045 - Base Pose Matrices
0x8048
0x804B
0x804C
0x804E - Reference to Model Surface
- dword [00 05 10 XX] where XX is the index of the Model Surface (as listed in the current Sub-File, starting at 0).
0x8061 - Reference to Material
- dword [00 06 20 XX] where XX is the index of the Material (as listed in the current Sub-File, starting at 0).
0x8062
- uint32 numWeightedBones (always between 1 and
, followed by that many uint32s. Each uint32 refers to a bone from the bone reference list in 0x8044.
0x8066 - "Reference to Vertices" / "Vertex Kick" / (help, I need a name!)
(or "Mesh Index Data" according to MrAdults)
- begins with dword [00 07 10 XX] where XX is the index of the Vertex Array (as listed in the current Model Surface, starting at 0).
0x8081
- unknown - contains 2 uint32s/int32s
0x8082
- unknown - contains 4 float32s
0x8083 (specular?)
- contains (4 float32s, uint32)
0x8085
- unknown - contains 4 float32s
0x8086 - Environment Mapping
- contains a single float32 (I don't know what effect the float32 has)
0x8091 - Reference to Texture
- dword [00 0A 20 XX] where XX is the index of the Texture (as listed in the current Sub-File, starting at 0).
0x8094
- unknown - contains 3 uint32s/int32s
0x80B1 (animation frames?)
- 2 float32s - first one is always(?) 0, second one would be the ending frame? (It's matched for the few I checked, but this needs double-checking)
0x80B2
- unknown - contains a float32
0x80B3 Bone-to-Animation-Node linker thing / (help, give me a name!)
Each of these links a Bone to a Animation Node, so there will be a lot of these. In the case of quats and XYZ positions, you'll find two of these referencing the same bone, each time getting linked to a different animation node.
- dword [00 04 10 XX] where XX is the index of the Bone (as listed in the current Sub-File, starting at 0).
- uint32 Animation Node Type: 47 = matrices, 48: quaternions, 4B: XYZ positions or whatever they're called.
- dword 0
- dword [00 0C 00 XX] where XX is the index of the Animation Node (as listed under the current Animation (0x000B chunk), starting at 0).
======
BONUS
This isn't a 0x80?? chunk... This is what appears under chunk 0x000C, aka Animation Node. (Remember my constant warning, "May Not Apply To Dissidia GMOs".)
(I wanted to tidy this up... but then I realized if I do that, this will never get posted. Not in this century, anyway.)
After the standard chunk header:
- This begins with a 16 byte header: dword unknown1, uint32 numWords, uint32 numEntries, dword unknown2.
unknown1 seems somehow related to the size and type of this Animation Node...
numEntries is, well, the number of entries in this Animation Node.
numWords is the number of words per entry (word just means 2 bytes). XYZ positions get 3, quaternions get 4, matrices get 16.
- Then it is followed by numEntries entries. Each entry is made of 2+(2*numWords) bytes. I guess each entry contains:
word time
word stuff[numWords]
I don't know what format time uses. stuff is a XYZ position, quaternion, or matrix.
