You mean the fact that the verts are all offset a little bit from the origin? Yeah, I noticed that too. I also noticed that the bone reference table for each draw is the same, which means there's probably a "base" joint index for that table somewhere, could be packed where that 0x200 bit value is changing. Then you might end up having to reskin the verts based on the relative transforms of those joints or something from some bind pose matrix that would be identical for each VIF seg since the bind pose has no mirroring in it. Unfortunately that probably means having to dig skeletal poses out of the motion data as well to transform against, cause there's no non-bind-space transform in the obj files that I saw. That might be further than I'm willing to go, although that motion data looked to be lacking any difficult compression beyond basic quantization. But anyway, yeah, it seems like it isn't as simple as a mirror bit.
I meant global index - you'll notice that each of those tim2 entries has extension data containing GIDX entries. Those global indices are unique across all loaded resources, so you'll rightfully get some pretty big values there. Funny enough they stuck with this same scheme for the next-gen Tekken/Soul Calibur/etc. titles, so I bet it's the same in Tekken 5 as well. You just match the global index of the texture resource with the first 32 bits of the draw struct.
It's possible, though, that because you're dumping Tekken 5 models out of memory, that they remap those indices at runtime so matching them to the offline cooked texture data could prove more problematic. But maybe not, at least in DBD it looks like they generate unique ID's at cook time so no runtime remapping would be necessary.
TGE wrote:All this talk about vif commands urges me to ask a question.
I've been working on a vif style model format for ages (in maxscript) but the way weighted vertices are stored (overlapping several masked vertex arrays) drives me crazy.
So I might just want to learn noesis for this but before I do, what kind of output does the noesis' vif unpack give you?
Noesis has a couple of different unpacking modes, but only the dumb one is exposed in Python at the moment. I neglected it, because no one has been using it. The dumb one is the one that just parses through the VIF data and hands you back raw structures for each unpack detailing the size and type of the source data, so you get to handle actually interpreting it yourself.
It should be easy for me to hook the authentic mode up to Python for the next build too. It does the full-on unpacking according to all of the hardware specs and obeys all of the relevant registers (and allows you to emulate both VIF0 and VIF1 in a single context), so you end up with what you'd really end up with on hardware. All of your writes will be expanded out to 32 bits at 4 elements each in VU memory, and you get back a list of structures telling you where the unpacks took place with the relevant type info and start/end addresses in VU memory. Then you typically just do some rpgBind calls for the vertex buffers right over the emulated VU memory and you're good to go. This would probably instantly put an end to that Dirge of Cerberus thread that's been going on for years here.

I did write it from my own interpreted spec from the docs (didn't pull it from an emulator or anything), so there could be problems lurking, but... at least it's worked on all of the games I've encountered so far. Having more people using it would be good to discover any bugs or flat-out-broken things that I interpreted wrongly. I still need to get back to trying it on the MGS games too. revelation was kind enough to dump a bunch of info about them on me a long time ago, and... well, life.