Phew, Zeality lays the smackdown.
If it's any consolation Sora, there's only, oh, 5 whole Sections in the character model format we haven't even begun to analyze yet. And that isn't counting subsections.
But yaz0r's made major progress on the weapon models at the same time, so everything's going very smoothly all things considered. Admittedly progress probably would have been faster had I abandoned the character models in favor of the weapon models, but I'm really liking the fact that we're looking at more than one type of model at the same time. For example, yaz0r's observation about the presence of triangles AND quads in the weapon models taught me that models aren't necessarily exclusive in the type of polygons they use, which helped shape my experiments examining Section 1-2, etc.
Sora, if you've got the time, I invite you to take a look at the File Structure wiki, which should lead you to the character model sections we haven't started examining yet (the Section offsets are listed in the character battle model headers). You're welcome to dive in yourself and look for interesting hex patterns. Even if you have suggestions on how to improve the battle model format wiki entries, that would be welcome too.
Anyway, here's tonight's food for thought. First, some hex code, followed by pics:
The 8-byte hex strings labeled "1", "2", etc., correspond to the same labels on the pics. Specifically, the pics are the result of zeroing out the corresponding hex string. Now, according to the theory I subscribe to on how Section 1-2 works, hex string #2 should NOT be UV data, because it contains the value "FF" - a value beyond the bounds of the character's battle texture.
HOWEVER -- string #1 is in the correct position to be a UV map for a quad. And it apparently acts as such -- zeroing out its data causes a quad to turn a blackish color without becoming a window through the model. This, despite the "FF" value it contains!
Now for some complicating factors. Zeroing out string #3 should have erased the quad mapped by #1 according to the model I settled on last night:
But zeroing out #3 erases a DIFFERENT quad, and possibly a triangle instead. Zeroing out #2 should have erased a different quad, but *may* have erased the SAME quad #1 refers to! I have to do some more experimentation on this to confirm that the pattern of UV Map -> Polygon Pointer has been reversed in this instance. Weird!
But the moral of tonight's lesson is, whichever polygon byte string #1 is associated with, it still functions as a UV Map, despite its containing an "FF." I'm not completely comfortable with that idea, and will delve even further to get this answered in my own mind.
@Cyb: The value being a pointer makes very good sense, and that would explain it. In which case, it may be preceded by a pointer to the triangle data. I'll compare Serge's model with Kid's. If they follow the same pattern, then we've got pointers to the quad and triangle data! And that will explain part of the purpose of Section 1-1! Yay!