.x files for directx support animations in both text and binary formats. can also look into smd which seems popular. but i can't really say. One of the things i plan on looking into is a better way of handling export to other format. Given i am a programmer and not an artist it has never really been that high on my priority list, but i want to change that for things like the tools i will release eventually.
TyPikachu - 0x6AB8
i'll try and take the time to color code this a little later if the explanation doesn not help.
The above hex block is a portion of the display list vertex format and attribute information. Each structure within the list is 0x18 bytes in length. It is structured like so:
The list is terminate when the attr0x00 value is equal to 0x000000FF.
There are other values which you may be able to find by looking up gamecube programming documentation, but some of the main ones of interest are:
0x0 = Position Normal Matrix Index
0x9 = Position
0xA = Normals
0xD = Texture Coordinate 0
This value determines whether or not a particular value is even present as vertex data. As mentioned before, the position element is the only one required every time. The values should appear in the order expected, but for all intents and purposed you should be able to sort the attr value from lowest to highest for correct ordering and usage. Thus a position element will always be assumed to come before a normal element, and those always before texture coordinate elements.
The attribute type can be:
0 = None
1 = Direct
2 = 8-bit index
3 = 16-bit index
None and Direct designation mean the values are not indexed, and thus do not have an index value present in the display list (0x9800, etc. data).
The component count gives and indication of the size of the data element based on whether it contain x, y, and z..or just x and y values for example. It will usually be 0 or 1:
0 = Pos_XY, Norm_XYZ, Color_RGB, Tex_S
1 = PosXYZ, Color_RGBA, Tex_ST
So you should be able to match how the values are structured within the data.
The component type tells the actual size of each value within a structure and other information about the type:
0 = U8, RGB565
1 = S8, RGB8
2 = U16, RGBX8
3 = S16, RGBA4
4 = F32, RGBA6
5 = RGBA8
With U = unsigned, S = signed, F = float, and the numbers being the bit size.
So as an example:
Would give:
attr = 9
attrType = 3
compCnt = 1
compType = 3
which is:
position (9), 16-bit index (3), xyz (1), signed short (3)
So vertex data (deduced from this being position data) represents the vertex position stored with xyz components as signed short values, thus 6-bytes per vertex, 2-bytes per component, and the index value in the display list will be 16-bit.
From this information you should be able to gather everything you need to determine the sizes of things in the file.
Hopefully this will be helpful in the mean time. i hope to finish with the rest of the structures in this file format soon.
Big thanks to breakpoint for his help, as it allowed me get past a roadblock in understanding some of the things in the format (silly pointer relocation table). Hope to be able to share more soon as i clarify my findings and clean everything up. Wish me luck, heh.
TyPikachu - 0x6AB8
Code:
00 00 00 09 00 00 00 03 00 00 00 01 00 00 00 03
0B 00 00 06 00 00 00 00 00 00 00 0A 00 00 00 03
00 00 00 00 00 00 00 03 0E 00 00 06 00 00 2C E0
00 00 00 0D 00 00 00 03 00 00 00 01 00 00 00 03
0C 00 00 04 00 00 5A 60 00 00 00 FF 00 00 00 02
00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00i'll try and take the time to color code this a little later if the explanation doesn not help.
The above hex block is a portion of the display list vertex format and attribute information. Each structure within the list is 0x18 bytes in length. It is structured like so:
Code:
// vertex declaration and attribute information
// attr, type, cnt, data_type, flags?, file_offset
struct VERTEX_DESCFMT
{
// 0x00
uint32 attr0x00; // vertex attribute
uint32 attrType0x04; // vertex attribute type
uint32 compCount0x08; // vertex component count
uint32 compType0x0C; // vertex component type
// 0x10
uint32 unknown0x10;
uint32 dataOffset0x14 <format = hex>; // data offset
};The list is terminate when the attr0x00 value is equal to 0x000000FF.
There are other values which you may be able to find by looking up gamecube programming documentation, but some of the main ones of interest are:
0x0 = Position Normal Matrix Index
0x9 = Position
0xA = Normals
0xD = Texture Coordinate 0
This value determines whether or not a particular value is even present as vertex data. As mentioned before, the position element is the only one required every time. The values should appear in the order expected, but for all intents and purposed you should be able to sort the attr value from lowest to highest for correct ordering and usage. Thus a position element will always be assumed to come before a normal element, and those always before texture coordinate elements.
The attribute type can be:
0 = None
1 = Direct
2 = 8-bit index
3 = 16-bit index
None and Direct designation mean the values are not indexed, and thus do not have an index value present in the display list (0x9800, etc. data).
The component count gives and indication of the size of the data element based on whether it contain x, y, and z..or just x and y values for example. It will usually be 0 or 1:
0 = Pos_XY, Norm_XYZ, Color_RGB, Tex_S
1 = PosXYZ, Color_RGBA, Tex_ST
So you should be able to match how the values are structured within the data.
The component type tells the actual size of each value within a structure and other information about the type:
0 = U8, RGB565
1 = S8, RGB8
2 = U16, RGBX8
3 = S16, RGBA4
4 = F32, RGBA6
5 = RGBA8
With U = unsigned, S = signed, F = float, and the numbers being the bit size.
So as an example:
Code:
00 00 00 09 00 00 00 03 00 00 00 01 00 00 00 03Would give:
attr = 9
attrType = 3
compCnt = 1
compType = 3
which is:
position (9), 16-bit index (3), xyz (1), signed short (3)
So vertex data (deduced from this being position data) represents the vertex position stored with xyz components as signed short values, thus 6-bytes per vertex, 2-bytes per component, and the index value in the display list will be 16-bit.
From this information you should be able to gather everything you need to determine the sizes of things in the file.
Hopefully this will be helpful in the mean time. i hope to finish with the rest of the structures in this file format soon.
Big thanks to breakpoint for his help, as it allowed me get past a roadblock in understanding some of the things in the format (silly pointer relocation table). Hope to be able to share more soon as i clarify my findings and clean everything up. Wish me luck, heh.
text animations...