BGBTech3 Engine, possible mesh format.

Mesh Model Format (Possible, for BGBTech3 Engine):
* May contain basic non-animated meshes.
** May also allow for animated meshes.
** Single bone only for now.
* One mesh per material, up to 1024 vertices per mesh.
* Format will be image-like.
** Will be defined in terms of offsets relative to image base.

Mesh Vertex:
* 64-bit
** (63:56): Bone ID (if animated, 0=Base)
** (55:44): T
** (43:32): S
** (31:27): Exponent
** (26:18): Frac Z
** (17: 9): Frac Y
** ( 8: 0): Frac X

S/T coordinates will be mapped roughly -0.500 to 1.499, with a fixed point accuracy of 1/2048 over the skin texture. Coordinates outside the range of 0.0 to 1.0 are primarily intended to deal with seams.

Vertex coordinates will be stored relative to the local coordinate space of the bone in question.

Mesh Triangle (32 bit):
* (31:30): Tag
* (29:20): V2
* (19:10): V1
* ( 9: 0): V0

Bone Tranform
* (63:56): Rot R (F8A)
* (55:48): Rot K (F8A)
* (47:40): Rot J (F8A)
* (39:32): Rot I (F8A)
* (31:27): Org Exponent
* (26:18): Frac Org Z
* (17: 9): Frac Org Y
* ( 8: 0): Frac Org X


F8A: S.E3.F4, Unit Range
* For I/J/K/R, these will be interpreted as a unit quaternion.
** After unpacking, the quaternion is to be normalized.

Anim Rotation (32 bit)
* (31:24): Rot R (F8A)
* (23:16): Rot K (F8A)
* (15: 8): Rot J (F8A)
* ( 7: 0): Rot I (F8A)

Anim Translation or Scale (32 bit)
* (31:27): Exponent
* (26:18): Frac Z
* (17: 9): Frac Y
* ( 8: 0): Frac X

The fraction will be a signed-extended non-normalized value which will be scaled by the exponent.


 Header {
 u32 magic1;		//00, 'BMD1'
 u32 resv1;			//04, MBZ
 u32 resv2;			//08, MBZ
 u32 resv3;			//0C, MBZ
 u32 ofs_meshes;	//10, Mesh List
 u32 sz_meshes;		//14, Size of Mesh List (bytes)
 u32 ofs_lods;		//18, LODs List
 u32 sz_lods;		//1C, Size of LODs List (bytes)
 u32 ofs_bones;		//20, Bone List, MBZ if static
 u32 sz_bones;		//24, Size of Bones (bytes), MBZ if static
 u32 ofs_anims;		//28, Anim List, MBZ if static
 u32 sz_anims;		//2C, Size of Anim List, MBZ if static
 }

 MeshDef {
 u32 ofs_vtx;		//00, offset of vertices list in image
 u32 ofs_tris;		//04, offset of triangles list
 u32 ofs_mat;		//08, material name string
 u16 n_vtx;			//0C, number of vertices (0..1024)
 u16 n_tris;		//0E, number of triangles
 }

 LodDef {
 byte id_mesh;		//00, Index of first mesh at LOD level
 byte n_mesh;		//01, Number of meshes in LOD level
 byte ld_sc;		//02, Nominal scale (F8A)
 byte resv1;		//03, MBZ
 }

 BoneDef {
 u64 xform;			//00, base transform (MBZ for Bone 0)
 u32 ofs_name;		//08, bone name string (Bones 1+)
 byte id_parent;	//0C, parent bone (MBZ for 0, 0xFF for Pseudo-Bone)
 byte id_solid;		//0D, mesh to use for solid def for bone.
 byte resv1;		//0E, MBZ
 byte resv2;		//0F, MBZ
 }

 AnimDef {
 u32 ofs_name;		//00, Offset of animation name
 byte n_framees;	//04, number of frames in this animation loop
 byte fl_hz;		//05, (7)=No Loop, (6:0): Anim Hz (in units of 0.25 Hz)
 byte resv1;		//06, MBZ
 byte resv2;		//07, MBZ
 u32 ofs_frames;	//08, Offset of frames list
 u32 sz_frames;		//0C, Size of frames list.
 }

If the mesh ofs_mat is 0 (Null String), this mesh nay not be drawn. However, non-drawn meshes may be used for bone solids.

Each LOD will be defined as a range of meshes. Only drawable meshes will be present in a LOD. Nominal scale algo will be defined as 1.0/(dist+1.0) with the distance defined in meters from the viewer.

Meshes used for bone solids need not be renderable, but may be renderable. They will be required to be in BREP form (fully enclosed volume, may be non-convex but may not self-intersect). The entire mesh is to be mapped to a single bone (equal to the bone for which the solid is being defined, or to bone 0). The coordinate space will be understood as relavite to the bone they are applied to (regardless of the bone specified for the vertex).

Note that if vertices are duplicated for sake of texture seam handling, even if at the same location in 3D space, the mesh will no longer be in BREP form.

Renderable meshes with more than 1024 vertices may be subdivided into meshes with fewer than 1024 vertices, which are also by definition not in BREP form. However, this format isn't really indended to be used for high triangle count models.

Possible, Pseudo-Bones:
* Will be special bones.
* xform will be understood as 4 bone IDs, and 4 F8A weights.

Pseudo bones will follow after any normal bones and their transforms will not be specified in animation frames. Their position in a given animation frame will be calculated based on the weights (after any interpolation for the normal bones). As for mesh vertex transform, they are handled the same as normal bones.


Animation frames will nominally represent n_frames*n_bones sets of transformations.

However, animation frames will be stored in a compacted form, with a tag byte:
* (7): Rotation Present
* (6): Translation Present
* (5): Scale Prsent
* (4:0): Number of preceding bones to skip during this frame.

A tag of 00 will signal the end of the current frame.
* Each tag will be followed by the rotation, translation, and scale, if present.

If a value is skipped in the current frame, its value will be interpolated.
* If absent in all frames, it will assume a default (identity) value.

The defined interpolation will be to linearly interpolate values, with rotations being renormalized after interpolation. The combination of rotation, translation, and scale, may be used to construct a transformation matrix that may be applied when calculating final mesh vertex positions for a given frame.