(GameCube) Metal Gear Solid: The Twin Snakes models .kmy and .mar animations (partially researched)

[DreamingOxxy]

If you thought my last post was about an old and uncared for game, here's another one! (With hopefully some responses this time, as this format has some research!)

MGS:TTS (gamecube, uses .kmy for models and .mar for animations) presumably uses model and animation formats (that I assume are) similar to MGS2 (ps2, uses .kms/.evm for models and .mar for animations), and that format was investigated enough that there's a Noesis plug-in for the original PS2 MGS2, and the PC MGS2. Since the formats have such similar names, and even some models are shared or leftover in MGS2, I'm sure the format reading could be modified to read the TTS models and maybe animations if it's not too difficult. There IS already a kmy2obj mesh tool, but only works on normal game models or maps, cutscene models are basically unreadable, leaving a mess of a mesh behind, and given the OBJ format, it has no skeleton, which isn't a huge issue at times, things can be rigged by hand, but cutscene models being unusable is a pretty big problem, given the low poly nature of the in-gameplay models, the quality wanted for use in other media isn't there, and not all models have a gameplay alternative.

Here is a link to the MGS2 Noesis reader: https://github.com/Jayveer/MGS-KMS-EVM-Noesis

And a link to the kmy2obj tool: https://github.com/gdkchan/kmy2obj

Both with source code available for research into the formats. I figure if the knowledge of both could be combined, perhaps TTS models and animations could be extracted, textures aren't a huge deal but I'll attach some incase someone wants to make a new tool for it, however Solidus for MGS2 can extract the texture bundles already. I've attached quite a few files for testing with, including a range of KMYs and MAR files, some from a stage, some from a cutscene, and some from what I assume is global or gameplay orientated.
 

TTSMODELS.rar

[DreamingOxxy]

Well, after a few days of trying my heart out to understand model formats, I have made some amount of progress on these after all this time, the OBJ tool provides really good info on how the offsets are read and I've gotten consistent at being able to find the verts and UVs, but I cannot for the life of me figure out face data. I can get pretty close, but the indices just don't make sense to me, I can get most of the model with faces but many just stretch or don't connect correctly, and it might be because they have submeshes, I'm not sure, I've not enough experience to understand it fully yet. If anyone out there is reading this I would still appreciate help in getting these extracted. I've had a project I've wanted to do for a long while but I'm stuck at getting these out, especially when all that I can get is OBJ files with no materials or anything, I just pray for skeletons, I want to do face animation stuff.

[shak-otay]

10 hours ago, DreamingOxxy said:

I can get pretty close, but the indices just don't make sense to me, I can get most of the model with faces but many just stretch or don't connect correctly,

Nobody likes to start from scratch, usually. Why don't you show what you did/get so far?

[DreamingOxxy]

3 hours ago, shak-otay said:

Nobody likes to start from scratch, usually. Why don't you show what you did/get so far?

You're probably not after all this info, but I will provide it for anyone interested.

Using this attached file as an example, 00595CEA.kmy, but all the models seem to follow a strict pattern in the header-like area (I guess? It's top of the file, I'm still learning), I'm not sure what 0x0-0x30 is, but once you get to 0x40 there's a pretty consistent pattern, (all of this is big endian, btw, vertices are short signed, UVs too I believe, I'm so far unsure about triangles, they might be strips) not sure what the first 2 bytes are for, maybe a submesh count? But the next 2-4 there's always the vertices count, which for this file is 64. The next two are some sort of count, not sure, next two are the UV count. Things seem to stop there and start back up at 0x4c, where there's an integer that I'm not certain of (it leads right to the end of the file mostly, probably points to the end of reading?), at 0x50 there's always the offset for the vertices (kind of, I'll get to that in a minute), next integer is the normal vertices offset (I guess, not certain), then the UV offset, and finally this strange "basis" offset, which is where the offsets start at, in this file it's at decimal 96, or 0x60, then the offsets from earlier are relative to that point, which now makes them line up. Using these I can consistently get the verts and UVs for a mesh. I'm just completely unsure of where the triangles start, what format they're in, etc., I can sometimes get the model to load a somewhat amount of faces that look kind of correct, but I can't say for sure that I'm even in the right area. I can't find an offset that points to them, the KMY2OBJ converter says something about them but I can't understand the code, it gets a bit too complicated in that area for my understanding. And clearly something goes wrong in the conversion, because some of the models I've tried to use it on only get a piece of the model, just like chunks.

I really wish I could provide more about them like you've asked, but I honestly haven't a clue where the face indices start, I've taken some guesses on this model, but nothing really gives a good result. The attached file has an extracted OBJ from the singular tool that does exist, and actually seems to work on this model to a degree, so perhaps with some cross referencing it could be figured out, though honestly the code file probably makes more sense to someone who knows what they're doing, so I'll include it as well, it's how I managed to figure out most of this stuff. It's just a very bare bones converter and has issues with a lot of models, and is missing a lot of things I need.

Here's what I did get though, a prop and a character. A character which I will also include for experimenting, and the OBJ that is missing 90% of their mesh. I did see that the material ID is in the hex numbers (it matches the hashed .texturefile, which I've given as well, and it seems both models use this texture file), and seems to be repeated a few times, probably pointing to different textures within the file.
 

testfile.zip

[shak-otay]

Thanks. I only have minor problems with the face indices (you might have chosen the wrong start address), one submesh, using triangle strips:

edit: 2nd sub mesh:

Edited Wednesday at 05:41 PM by shak-otay

[DreamingOxxy]

Oh nice! Can you show me the offset you used for that model? I'm curious where I went wrong, I've been trying to learn how to reverse formats, and this game has been on my radar for years.

[shak-otay]

Here you go, parameters for hex2obj:

 

[DreamingOxxy]

Alright thank you so much! This will help a ton, not sure what's going on with the few incorrect faces here and there, but perhaps if I can learn to make a script for it myself I can better examine it, or maybe this will spark someone else's interest, either way, this is the best progress I've been able to get on a model so far, so thank you for the help.

[DreamingOxxy]

31 minutes ago, shak-otay said:

Thanks. I only have minor problems with the face indices (you might have chosen the wrong start address), one submesh, using triangle strips:

edit: 2nd sub mesh:

So I did notice something, the MGS2 models, which are the other format I mentioned in the initial post, .KMS, and .EVM, with the Noesis script to view them, a lot of the triangles are split into groups, many many groups, which you can see in this image I've attached, so perhaps these random faces are why? I always wondered why the MGS2 models exported like this with that plugin, but those wrongly-connecting faces might explain why, perhaps the MGS2 and MGSTTS formats really are similar.

[DreamingOxxy]

I'm not as worried about textures, since for the most part they can be ripped, and 3D rippers work well with not many downsides, but I did want to point out that the current tool used to extract them doesn't extract normal maps or alpha channel'd textures very well, alpha channel ones are easily fixable, seems like it just swap R and B, or G and B, Idr, but the normal and specular maps don't rip very well at all, they are extremely crunched and the colors are all wrong, attached are an example of one extracted and one ripped with a 3D ripper, along with a texture file in-case anyone has an urge to figure it out. Thanks again to anyone who helps out.

00413960.zip