|
|
« on: July 23, 2011, 09:50:54 AM » |
|
this thread will have a full description of the MDL0 file format (better than the wiki) this post will focus on v9, while the others will be using specs from v9 for the other versions. Please PM me if you have any new info. Thank you :)
the MDL0 header defines the basis for the MDL0 standards Global MDL0 Header: 0x00: 'MDL0' 0x04: string table offset 0x08: version 0x0C: BRES offset
the Resource List structure is determined by the MDL0 version: Lists: 0x00(4): Definitions List 0x04(4): Bones List 0x08(4): Vertices List 0x0C(4): Normals List 0x10(4): Colors List 0x14(4): UV Points List 0x18(4): Materials List 0x1C(4): Nodes List 0x20(4): Objects List 0x24(4): Textures List 0x28(4): Pallets List
the Local Header: gives info about the MDL0 Local Header: 0x2C(4): Name Offset 0x30(4): properties length 0x34(4): properties Offset 0x38(4): unknown (0) 0x3C(4): unknown (0) 0x40(4): Vertices count 0x44(4): Faces count 0x48(4): unknown (0) 0x4C(4): Link count 0x50(4): unknown (0x01010000) 0x54(4): properties length (copy??) 0x58(24): Bounds
Sections (Lists): -Definitions -Bones -Vertices -Normals -Colors -UV's -Materials -Nodes -Objects -Textures -Pallets
after the header comes the Links which link to the bones, Definitions, materials, etc... 0x00(4): count 0x04(4*count): ID
If a model has 7 bones, 13 weights, and bones 0 and 3 are dummy's the Links would look like this: 00000001 00000002 00000004 00000005 00000006 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 00000003
so the Links to weighted bones come first, then it's the dummy bones.
the Link index in the bones would index to it's weighted position here... eg: bone 0's index would be 11 bone 5's index would be somewhere w/in the weight links (say... 8) and if bone 6's index is 10, I'm assuming bone 5 would use both 8 and 9 (all the weighted bones own at least 1 weighted index)
after that comes the resource group table. the List offsets (in the header) point to the group data, and the data offset + the list offset points to the data eg: Object_Data = (Objects_List+data_offset)
here's what the relocation group data looks like:
relocation group header: 0x00(4): block length 0x04(4): number of offsets
resource group offsets: 0x00(2): Group ID 0x02(2): pad 0x04(2): Prev ID 0x06(2): Next ID 0x08(4): string offset 0x0C(4): data offset
directly after the resource groups comes the Textures (the references) we'll deal with those later... let's just cover the sectioning data for now :)
Definitions: these aren't front-forward in 3D applications... (same as the Links)
but basically... they link the data between ojects, materials, and bone weights. BJ knows about how they work.
Type 1: 0x00(1): '01' (Stop command) stops the read process
Type 2: 0x00(1): '02' 0x01(2): Bone index 0x03(2): Parent Bone ID will add description later
Type 3: 0x00(1): '03' 0x01(2): ID 0x03(1): Weight Count 0x04(2): Bone Table index 0x06(4): Weight -0x0A(2): Bone Table index -0x0C(4): Weight these hold the weights for the bone with this weight ID (not the bone ID), and are also used for returning the bone matrix (the bone matrices are used for generating the transformed vertices)
Type 4: 0x00(1): '04' 0x01(2): Object index 0x03(2): Material index 0x05(2): Bone index 0x07(1): unknown will add description later all I know is it's for material linkage
Type 5: 0x00(1): '05' 0x01(2): ID 0c03(2): Bone ID used for bones with single or no influence
Bones: the bones here don't really act for anything but animation. they control a vert's position in a 3D vector space based on it's influence (it's weight) to that bone.
however, IK bone chains are kind of a special case... these deal with 1 bone acting as a muscle (when scaled), causing a chain of say... 3 bones to move along with it. (such as bones in a finger, a leg, or an arm)
the muscle bone is basically a dummy bone... all the influences are affected by the bones this bone controls.
0x00(4): Block Length 0x04(4): MDL0 Offset 0x08(4): String Offset 0x0C(4): Bone ID 0x10(4): Link index (use the list if -1) 0x14(4): Flags (not all are known) 0x18(4): Pad 1 0x1C(4): Pad 2 0x20(12): Scale 0x2C(12): Rotation 0x38(12): Translation 0x44(24): Bounds 0x5C(4): Parent Offset 0x60(4): Child Offset 0x64(4): Next Offset 0x68(4): Previous Offset 0x6C(4): Bone Strings/Properties Offset (part2)
0x70(48): BindMatrix 4x3 0xA0(48): InverseBindMatrix 4x3
Flags: 0001 - NoTransform 0002 - FixedTranslation 0004 - FixedRotation 0008 - FixedScale 000C - unknown 000F - unknown
0010 - unknown
0100 - unknown 0200 - HasGeometry 0300 - unknown '031F' appears to be the typical flags
Vertices: vertices are one of the main building blocks of a model. they control what the model looks like, how it will move when animated, along with other things
The verts follow the global vector header defined here:
Global Vector Header: 0x00(4): Block size 0x04(4): MDL0 Offset 0x08(4): Data Offset 0x0C(4): String Offset 0x10(4): Index ID 0x14(4): Has Bounding Box 0x18(4): Data type 0x1C(1): Entry Stride 0x1D(1): Divizor 0x1E(2): Entry count
0x20(4): Bounds (+padding)
the data type further defines how the data is read: 0: u8 / pow(2.0,Divizor) 1: s8 / pow(2.0,Divizor) 2: u16 / pow(2.0,Divizor) 3: s16 / pow(2.0,Divizor) 4: float
Normals: the normals control basically which direction the texture will display on a polygon. there are other advanced features I've seen in the MDL0 format that appear to be controlled by nodes
the normals follow the same data format as the verts
Colors: these would be your typical vertex colors in 3D applications. these are actually a seperate instance from materials that work to re-define a material color.
0x00(4): Block size 0x04(4): MDL0 Offset 0x08(4): Data Offset 0x0C(4): String Offset 0x10(4): Index ID 0x14(4): Has Alpha 0x18(4): Format 0x1C(1): Entry Stride 0x1D(1): unknown 0x1E(2): Entry count
the color formatting is further defined here:
Formats: 0: RGB565 1: RGB8 2: RGBX8 (24bit RGB??) 3: RGBA4 4: RGBA6 5: RGBA8
UV's: the UV's control the position of a texture on a polygon. there are seperate channels (up to 8) to control the positioning for different textures. (for say... using the same model with different textures to be used as costumes)
these also follow the vert data format.
Materials: the materials alone don't control much but color, texturization, and speculation. most of the magic is done by the shaders contained w/in the material. the shaders control a slue of things from making a model appear like glass to renderring fur. the shaders also control the shadow cast of a model.
very little is known about the MDL0 data though 0x00(4): Block size 0x04(4): MDL0 Offset 0x08(4): String Offset 0x0C(4): ID 0x10(4): unknown 0x14(1): Texture count 0x15(1): Layer count 0x16(1): Shader Type (same on linked Node) 0x17(1): unknown 0x18(4): Normal settings 0x1C(1): unknown 0x1D(1): unknown 0x1E(1): Shader Texture layers (max 10) 0x1F(1): unknown 0x20(4): unknown 0x24(4): unknown 0x28(4): Node offset (references the linked Node) 0x2C(4): Texture count 0x30(4): Layer offset 0x34(4): unknown 0x38(4): offset to Shader registers 0x3C(4): unknown offset
these are some of the settings for the above data: shader types: 0: unknown 1: light/glow* 2: Toon 3: Lambert 4: metal* 5: reflective* 6: environ.* 7: Phong 8+: unknown (all parameters marked with * don't exist in 3D applications)
normal settings: 0: double sided 1: display inside 2: dispay outside 3: display none
the shader actually starts just after the pading after the material header, and ends after the registers.
the Shader registers are located directly at that offset. it normally has a TEV structure just after a few settings. after that structure comes 3 structures that set the registers (hi and lo), set the null register values (I think), and set the texture reference values.
after that comes 1 or 2 XF blocks that define the texture layers. (1 XF block per texture layer)
There's still further documentation to come on these. >_>
Nodes: Not too much is known about the data here either...
the nodes control alot of similarities to the shaders, but the nodes can handle more on the fine detailing end, where as the shaders can't.
what the nodes control can be a range of things dealing with the visual element... (color, hue, sat, clarity, specularity, texture affection, and a whole bunch of other things) there are also logic nodes that are controlled by scripts to control how they work. (image timing, color blinking, and other things)
Header: 0x00(4): Block Length 0x04(4): MDL0 Offset 0x08(4): Node ID 0x0C(1): Shader type 0x0D(3): RES0 - RES2 0x10(8): TREF0 - TREF7 0x18(8): padding
currently known structures: (data follows the wii format code)
FE Mask'00000F' F# - KSel[#]
FE Mask'FFFFF0' F# - KSel[#] 2# - Tref[#] C# - ColEnv[#] D# - ColEnv[#] (optional) C# - AlpEnv[#] D# - AlpEnv[#] (optional) 1# - Cmd[#] 1# - Cmd[#] (optional)
FE Mask'00FFE3' (defined in the shaders (materials)) 41 - CMODE0 42 - CMODE1 00 - unk (optional)
I'll be deleting this block when I can get to a compy. known codes: '61 ##'#define IND_MTXA0_ID 0x00000006 #define IND_MTXB0_ID 0x00000007 #define IND_MTXC0_ID 0x00000008 #define IND_MTXA1_ID 0x00000009 #define IND_MTXB1_ID 0x0000000a #define IND_MTXC1_ID 0x0000000b #define IND_MTXA2_ID 0x0000000c #define IND_MTXB2_ID 0x0000000d #define IND_MTXC2_ID 0x0000000e #define IND_IMASK_ID 0x0000000f #define IND_CMD0_ID 0x00000010 #define IND_CMD1_ID 0x00000011 #define IND_CMD2_ID 0x00000012 #define IND_CMD3_ID 0x00000013 #define IND_CMD4_ID 0x00000014 #define IND_CMD5_ID 0x00000015 #define IND_CMD6_ID 0x00000016 #define IND_CMD7_ID 0x00000017 #define IND_CMD8_ID 0x00000018 #define IND_CMD9_ID 0x00000019 #define IND_CMDA_ID 0x0000001a #define IND_CMDB_ID 0x0000001b #define IND_CMDC_ID 0x0000001c #define IND_CMDD_ID 0x0000001d #define IND_CMDE_ID 0x0000001e #define IND_CMDF_ID 0x0000001f
#define RAS1_SS0_ID 0x00000025 #define RAS1_SS1_ID 0x00000026 #define RAS1_IREF_ID 0x00000027
#define RAS1_TREF0_ID 0x00000028 #define RAS1_TREF1_ID 0x00000029 #define RAS1_TREF2_ID 0x0000002a #define RAS1_TREF3_ID 0x0000002b #define RAS1_TREF4_ID 0x0000002c #define RAS1_TREF5_ID 0x0000002d #define RAS1_TREF6_ID 0x0000002e #define RAS1_TREF7_ID 0x0000002f
#define PE_ZMODE_ID 0x00000040 #define PE_CMODE0_ID 0x00000041 #define PE_CMODE1_ID 0x00000042 #define PE_CONTROL_ID 0x00000043 #define PE_TOKEN_ID 0x00000047 #define PE_TOKEN_INT_ID 0x00000048
#define TEV_COLOR_ENV_0_ID 0x000000c0 #define TEV_ALPHA_ENV_0_ID 0x000000c1 #define TEV_COLOR_ENV_1_ID 0x000000c2 #define TEV_ALPHA_ENV_1_ID 0x000000c3 #define TEV_COLOR_ENV_2_ID 0x000000c4 #define TEV_ALPHA_ENV_2_ID 0x000000c5 #define TEV_COLOR_ENV_3_ID 0x000000c6 #define TEV_ALPHA_ENV_3_ID 0x000000c7 #define TEV_COLOR_ENV_4_ID 0x000000c8 #define TEV_ALPHA_ENV_4_ID 0x000000c9 #define TEV_COLOR_ENV_5_ID 0x000000ca #define TEV_ALPHA_ENV_5_ID 0x000000cb #define TEV_COLOR_ENV_6_ID 0x000000cc #define TEV_ALPHA_ENV_6_ID 0x000000cd #define TEV_COLOR_ENV_7_ID 0x000000ce #define TEV_ALPHA_ENV_7_ID 0x000000cf #define TEV_COLOR_ENV_8_ID 0x000000d0 #define TEV_ALPHA_ENV_8_ID 0x000000d1 #define TEV_COLOR_ENV_9_ID 0x000000d2 #define TEV_ALPHA_ENV_9_ID 0x000000d3 #define TEV_COLOR_ENV_A_ID 0x000000d4 #define TEV_ALPHA_ENV_A_ID 0x000000d5 #define TEV_COLOR_ENV_B_ID 0x000000d6 #define TEV_ALPHA_ENV_B_ID 0x000000d7 #define TEV_COLOR_ENV_C_ID 0x000000d8 #define TEV_ALPHA_ENV_C_ID 0x000000d9 #define TEV_COLOR_ENV_D_ID 0x000000da #define TEV_ALPHA_ENV_D_ID 0x000000db #define TEV_COLOR_ENV_E_ID 0x000000dc #define TEV_ALPHA_ENV_E_ID 0x000000dd #define TEV_COLOR_ENV_F_ID 0x000000de #define TEV_ALPHA_ENV_F_ID 0x000000df #define TEV_REGISTERL_0_ID 0x000000e0 #define TEV_REGISTERH_0_ID 0x000000e1 #define TEV_REGISTERL_1_ID 0x000000e2 #define TEV_REGISTERH_1_ID 0x000000e3 #define TEV_REGISTERL_2_ID 0x000000e4 #define TEV_REGISTERH_2_ID 0x000000e5 #define TEV_REGISTERL_3_ID 0x000000e6 #define TEV_REGISTERH_3_ID 0x000000e7
#define TEV_FOG_PARAM_0_ID 0x000000ee #define TEV_FOG_PARAM_1_ID 0x000000ef #define TEV_FOG_PARAM_2_ID 0x000000f0 #define TEV_FOG_PARAM_3_ID 0x000000f1 #define TEV_FOG_COLOR_ID 0x000000f2
#define TEV_ALPHAFUNC_ID 0x000000f3 #define TEV_Z_ENV_0_ID 0x000000f4 #define TEV_Z_ENV_1_ID 0x000000f5 #define TEV_KSEL_0_ID 0x000000f6 #define TEV_KSEL_1_ID 0x000000f7 #define TEV_KSEL_2_ID 0x000000f8 #define TEV_KSEL_3_ID 0x000000f9 #define TEV_KSEL_4_ID 0x000000fa #define TEV_KSEL_5_ID 0x000000fb #define TEV_KSEL_6_ID 0x000000fc #define TEV_KSEL_7_ID 0x000000fd
Objects: this is where all the data is combined. the objects basically define a model space, and link all the model and material data in MDL0 files, the objects hold the faces (polygons) that link the verts, normals, and UV's
objects also allow parenting to other objects, and are usually parented to bones
Header: 0x00(4): Block Size 0x04(4): MDL0 offset 0x08(4): Bone table ID (if -1, use weight table) 0x0C(8): CP format specs (hi and lo) 0x14(4): XF Normal specs 0x18(4): attributes block size 0x1C(4): attribute flags 0x20(4): attributes offset 0x24(4): data Size 0x28(4): data Size (copy??) 0x2C(4): data offset 0x30(4): XF format specs 0x34(4): Unknown (Always 0x00000000) 0x38(4): String offset 0x3C(4): ID 0x40(4): Number of vertices 0x44(4): Number of faces
0x48(2): vert input 0x4A(2): Normal input 0x4C(2): Color0 input 0x4E(2): Color1 input 0x50(2): UV0 input 0x52(2): UV1 input 0x54(2): UV2 input 0x56(2): UV3 input 0x58(2): UV4 input 0x5A(2): UV5 input 0x5C(2): UV6 input 0x5E(2): UV7 input
0x60(4): Weight table offset (0x64 in v11 MDL0's)
Weight table 0x00(4): Number of weights 0x##(2): Weight ID
the attributes come after the Weight table and define alot of what's in te header: they also follow the wii format code note: this is what's actually used (not the data in the header) attribute definitions: 08 00 = host - colors, normals, and textures 08 10 = unknown 08 20 = unknown 08 30 = SetMatricesA 08 40 = SetMatricesB 08 50 = CP hi 08 60 = CP lo 08 70 = UVAT Group 0 08 80 = UVAT Group 1 08 90 = UVAT Group 2
up next is the Primitives the Primitives contain data that's used either for transform puposes, or geometric purposes.
Primitive Types: 20 - vert transform 28 - Normal transform 30 - UV transform 38 - Light transform
80 - Quads 90 - Triangles 98 - Tristrip A0 - Trifan A8 - Lines B0 - Linestrip B8 - Points
chunks of data are defined to hold the transform primitives before the geometry primitives.
vert/normal transform primitives work as such: 0x00(1): '20' or '28' 0x01(2): weight ID 0x03(.5): unknown 0x03.5(1.5): index/12 as for the facepoints, the length of the facepoint is defined by the CP list.
here's an example CP list: [1,0,1,0,0,0,0,0,0,3,3,2,0,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0] this would define a facepoint with a length of 9 ('## ## #### #### ## ####')
here's how it works: the CP hi defines the: -vertex/Normal transform -UV0 transform ... -UV7 transform -Vertex index -Normal index -Color0 index -Color1 index
the CP lo defines the: -UV0 index ... -UV7 index - vert mtx array - normal mtx array - UV mtx array - light mtx array - NBT - Max number of attributes - end marker (0xff)
the values in the above list determine the length of the read values in the facepoints: 0 - null 1 - direct (memory access) 2 - 8bit index 3 - 16bit index
Textures: soon... (I need to find my notes)
Pallets: I will come back to these
_________________________________________________ ______________________________________
I should get alot more filled in as I go ;) I'll be covering alot more info than the wiki, as you can already see :) just give me some time is all
|
|
« Last Edit: April 07, 2012, 10:45:59 AM by Tcll »
|
Logged
|
|
|
|
|
|
|
« Reply #1 on: July 23, 2011, 09:13:29 PM » |
|
post reserved for v10 MDL0's
|
|
|
Logged
|
|
|
|
|
|
|
« Reply #2 on: July 23, 2011, 09:13:47 PM » |
|
all I know about the v11 MDL0 format so far is the lists:
0x00(4): Definitions 0x04(4): Bones 0x08(4): Vertices 0x0C(4): Normals 0x10(4): Colors 0x14(4): UV's 0x18(4): unknown 0x1C(4): unknown 0x20(4): Materials 0x24(4): Nodes 0x28(4): Objects 0x2C(4): Textures 0x30(4): Pallets 0x34(4): unknown
|
|
« Last Edit: August 11, 2011, 02:03:17 PM by Tcll »
|
Logged
|
|
|
|
|
|
|
« Reply #3 on: July 23, 2011, 09:14:01 PM » |
|
post reserved for v12 MDL0's
|
|
« Last Edit: August 11, 2011, 02:04:34 PM by Tcll »
|
Logged
|
|
|
|
|
|
|
|
« Reply #5 on: January 11, 2012, 07:45:25 PM » |
|
If this thread is open (I'll delete post if it isn't) but what are the main differences between the different versions of the mdl0?
|
|
|
Logged
|
|
|
|
|
|
|
|
|
« Reply #8 on: January 22, 2012, 08:45:48 PM » |
|
Labels are opinions, yada-yada-yada....
|
|
|
Logged
|
|
|
|
|
|
|
|
« Reply #10 on: January 23, 2012, 03:58:20 AM » |
|
Labels are opinions, yada-yada-yada....
actually... labels do hold a purpose... sometimes... (this time being one of them...) and blah... and blah... and blah blah blah...
and BJ... Shaders can't manipulate model or texture colors... let alone be a seperate instance from the material...
no... my labels are correct in this case...
IK I promised not to argue with you, but this particular argument is valid >:3
PROOF: play around with Material-Nodes and shaders in blender and then come back to me on this discussion
do I have any other mislabled things is what I'm asking. (I won't argue with you on these terms)
|
|
« Last Edit: January 23, 2012, 04:04:02 AM by Tcll »
|
Logged
|
|
|
|
|
|
|
« Reply #11 on: April 07, 2012, 10:44:37 AM » |
|
hey, I just noticed something...
from my experiences in 3D the material is only good for it's ambient, diffuse, and specular colors and 1 texture. the shader and nodes do everything else. >_>
now I've seen how Melee use Materials, but from what I've noticed about Brawl/Pokepark, nintendo doesn't appear to use materials in MDL0s <_< from studying the material data, EVERYTHING here makes reference to the shader's functions >_>
this would make sense as in game development, shaders have been overtaking materials in almost every way. <_<
|
|
« Last Edit: April 07, 2012, 10:55:34 AM by Tcll »
|
Logged
|
|
|
|
|
|