GMA Filetype Breakdown

[StarkNebula]

Related Threads
ARC (U8) Filetype Breakdown
TPL Filetype Breakdown
---------------------------------------------------------------------------------

GMA Header Structure:

*Nullified models appear as FFFF FFFF 0000 0000 in header, do not appear anywhere or alter anything in Name Entries.

[StarkNebula]

WIP - UPDATING INFORMATION

GMA Model Entry, Texturing information and Vertex Information
There's so much in so little space, I ran out of colours and had to make multiple copies highlighting different sections.
*GCMF is likely either "GameCube Model File" or "GameCube Model Flag."

Note: Volatile/Non-volatile indicates whether the values are flexible or not. If it is volatile, it will crash/hang the console.

• Purple: GCMF is the model flag.
• Pink: Unknown1: Not sure, but it's only present on test models and vehicle models (which are a little odd.) Non-volitile.
• Red: The model's offset from the origin point in floats.
• Blue: Object radius in floats.
• Orange: Texturing info; number of textures, Materials, and TL Materials (nb_tl_mat is a stat in the debug menu.)
• Yellow: Start of texturing library.
• Green: Vertex offset. From there on, vertices are described in 5 lines, proceeded by all it's segments simultaneously. (WRITING MORE INFO LATER).

- Wrap flags, modelling, ANISO stuff and more in the Google Spreadsheet linked at the bottom.

• Blue: This value does a few things:
  a. A value of 40 appears to be the flag to use to denote a reflective texture.
  b. A value of 02 appears to support 0214, 2014, and 2214 values in the 2 bytes after it. If it's not 02, all textures in model will have no mipmaps and will be all B/W.
  * I still need to look into alpha channel stuff here. Styling Flag?
• Green: Modelling type. In general it's simply 07. Some odd values occur though. Texturing Type
• Yellow: Wrap Flags. All the values are defined, and logged in Wrap Flags
• Orange: Calls the texture within the TPL. The line in the TPL = the number flag for the texture.
• Pink: ANISO Flag is the latter byte. The former, I'm not sure, but they appear non-volatile. ANISO Flags
• Purple: Texture Number, used in the debug menu. The same texture can appear multiple times due to other factors such as ANISO type, styling type, reuse of other parts of the model, etc.
• Red: Unknown2: The values are semi arbitrary with little to work with. Look for 0xC0 in this Google Spreadsheet. It's just WTF.
• Dark Grey: A constant value of 0030 present after a texture entry.

• Yellow: This changes the lighting effect 'within the debug menu.' Not sure if it does anything else. Notes.
• Orange: It's very linear and predictable, but has a few variations. Doesn't do anything if you mess with it.
• Red: Same as the orange one. Sometimes present, sometime not. I've only seen 0000 0000 00, FFFF FFFF A2, and FFFF FFFF 11 here.
• Dark Grey: Constant of FF.
• Pink: Denotes the texture(s) used on that section of the model.
  • 00 = nulled with FF
  • 01 = 0x06
  • 02 = 0x06 & 0x08
  • 03 = 0x06 & 0x08 & 0x0A, 0x04 = 00 instead of FF
  This may make more sense: Number of Textures
• Green: I HAVE TO REVISE THE MENTAL MODEL I'M PUTTING OUT. Gonna get that done soon... The 0x0E slot is cracked. Facings Flag - 0x0E
• Blue: Not sure. Perhaps related to UV mapping?
• Indigo: Perhaps another flag for UV mapping? Changing it does nothing (apparent.)
• Purple:Vertex flag.
  • 0098 = Float,
  • 0099 = Uint16
  (GMA.cpp source code.)
  I'm pretty sure 0x03 defines the amount of entries for that set of vertices. Don't bank on it though, since the next entries are not "flush", so to speak (not always 4byte chunks, not always a determinable length. You can't just Value = 5 = 5x4bytes = 20bytes.)

*? LSB to MSB.

Most of what I have is in this Google Spreadsheet.

</braindump>

[CosmoCortney]

Nice job!

Have you ever had a look at super monkey balls 2's GMA files? Maybe it could help you to get more information.

When will the breakdown thread about the collision files, gx-.lz files and ax-.lz files follow?

[StarkNebula]

Well, TPLs are done, so I can make that one any time. GMAs, while almost all done, could use a little updating. COLI files are hard. I've found some things, but my PC (hrm-iMac) isn't powerful enough to emulate GX at a sufficient pace to test out anything in a reasonable amount of time. So as for the COLI files, it's once I get myself a new PC.

Super Monkey Ball GMAs are identical in format to GX's, so there's nothing to work there. As for the LZ files, I don't know squat about it so I won't be working there for quite a while.

[CosmoCortney]

oh, i see. i was trying to modify the collision data on myself a few months ago. in the end you can find a list of all the bg_xxx.gma models loaded (and where they're placed?). I replaced these data with information of another collision-file. but no success, yet
i was trying to recreate the Port Town - Double Branches track. but the background went completely black. at least the game didnt crash lol
i can try out new things easily, because i can emulate gx at full speed most of the time (my old gtx 260 gfx-card causes some performance issues sometimes).

we could try finding out information about the collision-files by comparing the 4 Sonic Oval files. The Story mode and GP Mode versions of Sonic oval come with dash plates and energy pits. the other ones come without them. and one has no road- and trackwall texturing.

[CosmoCortney]

I've found out more things about the .gma files.
the padding between the ANISO flag and Unknown 2 will be filled with addresses that tell the game were to load the texture from. (this can be used to swap textures with geckocodes. to do: checking out if others' tpl's textures can be loaded. EDIT: it works).

the last 2 bytes of the texturing information show up the number of textures featuring alpha channel. by decreasing this value alpha textures will disappear. how ever, you can remove those textures with the previouse 2 bytes as well. but the last 2 bytes are exclusive for all alpha textures only.

unknown1 knows more values besides 0x00 and 0x01. the pilot objects with 100 polygons use the value 0x05 there. by changing it the object can become invisible. but i don't think it's supposed to have anything to do with the object's visibility.

it looks like that unknown2 defines the texture mapping. but i'm not sure! anyways, changing this value causes some messed up texture mapping (or freezes the game).

[Yoshimaster96]

I can help with the LZ files, I have the collision triangle format figured out. I also have programs to compress/decompress them, if you're interested.

[StarkNebula]

If that's the case, please post a detailed analysis of the collision format. If you are unsure of anything, specify that. Last I saw, you still had bugs with your collision. I also assume by something to decompress it, you mean a modified gxpand or LZSS decompressor that can decompress Super Monkey Ball files. I'd like to have a link on the forums here, it'd be handy. Perhaps it'd work with F-Zero AX.

[Yoshimaster96]

Compression tool:
Link

First 16 bytes:
?? ?? ?? ?? ?? ?? ?? ?? AA AA AA AA BB BB BB BB
A: Number of collision models
B: Offset to collision models

At offset B:
0x18 Unknown bytes
0x4 Size of this header minus 0x0C?
0x4 Collision triangle offset
0x4 Pointer to collision triangle indices pointers (Double pointer)

Collision triangle:

0x4 X1
0x4 Y1
0x4 Z1
0x4 Normal X
0x4 Normal Y
0x4 Normal Z
0x2 X Angle
0x2 Y Angle
0x2 Z Angle
0x2 Zero
0x4 DX2X1
0x4 DY2Y1
0x4 DX3X1
0x4 DY3Y1
0x4 ?
0x4 ?
0x4 ?
0x4 ?

At pointer to triangle indices:
0x4 Pointer to collision triangle indices list (256 of these)

At triangle indices:
2 byte triangle indicator, 0xFFFF terminated lists.

[StarkNebula]

Thanks. I had a quick test of the LZSS decompressor (which deosn't appear to decompress the files) and fix and couldn't operate it correctly. The LZfix would crash on me. Anything in particular that needs to be done in order for it to work?

[Yoshimaster96]

Use lzfix.exe first, selecting (B)efore Decompression (type capital B). Then, run through lzss decompressor. You might need this DLL:
http://bin.smwcentral.net/u/21732/msvcr100d.dll

[Yoshimaster96]

The 8 bytes after the "debug menu lighting" value seem to be RGBA values, perhaps used as constants in the TEV unit?
Also, what you labeled as "model code" is actually vertex flags. They seem to come directly from the GX library values (in general, they are 1<<vtx_attr_type :: http://libogc.devkitpro.org/group__vtxattr.html):
VertexAttributes:
00000001 - GX_VA_PTNMTXIDX //seems to be for transformation matrices
00000002 - GX_VA_TEX0MTXIDX //unused?
00000004 - GX_VA_TEX1MTXIDX //unused?
00000008 - GX_VA_TEX2MTXIDX //unused?
00000010 - GX_VA_TEX3MTXIDX //unused?
00000020 - GX_VA_TEX4MTXIDX //unused?
00000040 - GX_VA_TEX5MTXIDX //unused?
00000080 - GX_VA_TEX6MTXIDX //unused?
00000100 - GX_VA_TEX7MTXIDX //unused?
00000200 - GX_VA_POS
00000400 - GX_VA_NRM
00000800 - GX_VA_CLR0
00001000 - GX_VA_CLR1 //unused?
00002000 - GX_VA_TEX0
00004000 - GX_VA_TEX1
00008000 - GX_VA_TEX2
00010000 - GX_VA_TEX3 //unused?
00020000 - GX_VA_TEX4 //unused?
00040000 - GX_VA_TEX5 //unused?
00080000 - GX_VA_TEX6 //unused?
00100000 - GX_VA_TEX7 //unused?
00200000 - GX_POSMTXARRAY //unused?
00400000 - GX_NRMMTXARRAY //unused?
00800000 - GX_TEXMTXARRAY //unused?
01000000 - GX_LIGHTARRAY //unused?
02000000 - GX_VA_NBT //seems to be for transformation matrices

One last thing, the constant of 0x30 after texture entries does not occur in Super Monkey Ball GMA files for some reason.