I have produced a model format which depends upon deflating the various coordinate data and packaging that into a nice container for easy management (including a string name for the planned resource manager/resource packager). The specifications are a WIP, but are as follows (note HTML massacred the nice alignment. Also, the number in brackets is the size in bits):
===================================================================================
STATIC MODEL V0
===================================================================================
[32] Identification
This is the identification of the file, “tm m”.
[8] Version
The version of the file format. The value zero indicates this model format.
[8] Length of Name
The number of characters in the following model name.
[8*Delta] Name
A character-string of length Delta where Delta is the previous field. This
is used when the file is loaded to reference it upon loading.
[4] LOD Count
The number of levels of detail to be specified.
[32*3] Minimum Bounding Box
The smallest vertex position coordinates in IEEE floating-point format,
three 32-bit values: x, y, and z respectively.
[32*3] Maximum Bounding Box
The biggest vertex position coordinates in IEEE floating-point format,
three 32-bit values: x, y, and z respectively.
{Repeat for Each LOD}
[5] LOD for Positions
[5] LOD for Normals
[5] LOD for UVs
[32] Number of Verticies
[32] Number of Polygons
{Repeat for Each Vertex}
[LODp*3] Vertex Position
The fields of this vector are signed.
[LODn*3] Vertex Normal
The fields of this vector are signed.
[LODuv*2] Vertex UV
{End Repeat}
{Repeat for Each Polygon}
[Omega*3] Polygon Vertex Indicies
{End Repeat}
{End Repeat}
[?] Padding
Aligns to the next byte.
[128] Checksum
Just an XORing of all bytes up to and including the padding. Gives a high
probability the data is valid if passes.
[8] EOF Confirmation
The value ‘E’, indicating a safe end of file was reached.
===================================================================================
FAST STATIC MODEL V0
===================================================================================
[32] Identification
This is the identification of the file, “tm m”.
[8] Version
The version of the file format. The value one indicates this model format.
[8] Length of Name
The number of characters in the following model name.
[8*Delta] Name
A character-string of length Delta where Delta is the previous field. This
is used when the file is loaded to reference it upon loading.
[8] LOD Count
The number of levels of detail to be specified.
{Repeat for Each LOD}
[32] Number of Verticies
[32] Number of Polygons
{Repeat for Each Vertex}
[32*3] Vertex Position
Three IEEE 32-bit floating-point values.
[32*3] Vertex Normal
Three IEEE 32-bit floating-point values.
[32*2] Vertex UV
Two IEEE 32-bit floating-point values.
{End Repeat}
{Repeat for Each Polygon}
[32*3] Polygon Vertex Indicies
{End Repeat}
{End Repeat}
===================================================================================
2D MATERIAL v0
===================================================================================
[32] Identification
This is the identification of the file, “tm t”.
[8] Version
The version of the file format. The value zero indicates this format.
[8] Length of Name
The number of characters in the following model name.
[8*Delta] Name
A character-string of length Delta where Delta is the previous field. This
is used when the file is loaded to reference it upon loading.
[4] Top Diffuse Texture Dimension (Two’s Exponent)
The base dimension of the texture to be stored. Id est, if the texture
is 512px by 512px, the value 9 is stored (2^9 = 512). The value zero is
invalid, and anything greater than 11 (2^11 = 2048) is most likely invalid.
[1] Stored MipMaps
If this is 1, mipmaps will be stored, otherwise only the base full texture
is used.
[4] Compression of Diffuse Map and MipMaps
0 – No compression
1 – JFIF (JPEG) lossy compression
2 – Lossless compression
3 – Bit depression
4-15 – Reserved
[4] Top Emission Map Texture Dimension
Same idea as the diffuse map dimension, but for the emission map (emission
maps are generally lower-quality). The value zero specifies that no emission
map is used.
[1] Stored MipMaps for Emission
If this is 1, mipmaps will be stored, otherwise only the base full texture
is used. Generally this is not used, but can be for high-quality textures.
If the emission map dimension is zero this is ignored.
[4] Compression of Emission Maps
Same values as “Compression of Diffuse Map and MipMaps” but for the emission
map. If the emission map dimension is zero this is ignored.
[4] Top Normal Map Texture Dimension
Same idea as the diffuse map dimension, but for the normal map. If zero no
normal mapping is used.
[1] Stored MipMaps for Normal Map
If this is 1, mipmaps will be stored, otherwise only the base full texture
is used. If the normal map dimension is zero this is ignored.
[4] Compression of Normal Maps
Same values as “Compression of Diffuse Map and MipMaps” but for the normal
map. If the normal map dimension is zero this is ignored.
{Repeat for Each LOD of Diffuse}
[?] Texture Data
This data depends on the compression field.
{End Repeat}
{Repeat for Each LOD of Emission}
[?] Texture Data
This data depends on the compression field.
{End Repeat}
{Repeat for Each LOD of Normal}
[?] Texture Data
This data depends on the compression field.
{End Repeat}
[?] Padding
Aligns to the next byte.
[128] Checksum
Just an XORing of all bytes up to and including the padding. Gives a high
probability the data is valid if passes.
[8] EOF Confirmation
The value ‘E’, indicating a safe end of file was reached.
{END OF FILE}
The philosophy behind the static model is that it will compress well while giving predictable results (LOD-wise). The fast static model is meant to be easily loaded into memory (ideally models are shipped/uploaded with the former and converted to the latter). The texture file is going to employ my own attempt at fourier series (JPEG-like) compression and the loss-less (non-patented) method used by the PNG format. The uncompressed format is for debugging primarily, and bit depression is simply reducing the number of bits per channel. The rest are reserved in case I want to bring along alpha maps or something later. I have not included alpha maps as is because they usually cause a dirty render with depth-sorting, which I don’t want to deal with at the moment.
Eventually multiple model/material files will be stored in a resource file and compressed further.
I may add my mesh optimization idea into a new model format which would be tasked with loading quickly and having the optimizations pre-calculated.
The resource file, later, will specify exactly what data is already calculated and still must be. For example, to personify the resource loader: “this model has its LOD and optimizations done, load it quickly. This one is compressed and needs to have its optimizations and LOD calculated and stored for further runs. This one is compressed, but so rarely used just leave it compressed, but on load calculate its LODs every time”.
Bah, in less than 9 hours I move to UCLA.
OH MY GOD FILTER KEYS FREAKED ME OUT WITH THE BEEP.
Until later, this shall all have to wait.
Tags: c++, computer graphics, directx, Programming
