v4games
/
assimp
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

corrected misinformation in the documentation 

> corrected note saying that the header was 500 bytes long (512 bytes are written and the number 512 is given elsewhere)
> altered confusing language about how long the chunks are ("length of chunk" implies the number includes the chunk-header. chunk-data-length less so, and reflects the fact that the number written doesn't include the chunk-header)
> removed mistake about how texture coordinates are encoded (the last release, and the current head both write texture coordinates as 3 float components regardless of what they actually are)
pull/575/head
Peter LaValle 2015-05-30 23:40:17 +01:00
parent ab95b1a3c1
commit 6ddb67b321
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
code/assbin_chunks.h
View File

@ -47,7 +47,7 @@ in <tt>&lt;root&gt;/tools/assimp_cmd/WriteDumb.cpp</tt> (yes, the 'b' is no typo
------------------------------------------------------------------------------- -------------------------------------------------------------------------------
---------------------- ----------------------
| Header (500 bytes) | | Header (512 bytes) |
---------------------- ----------------------
| Variable chunks | | Variable chunks |
---------------------- ----------------------
@ -100,11 +100,12 @@ byte[64] Reserved for future use
integer Magic chunk ID (ASSBIN_CHUNK_XXX) integer Magic chunk ID (ASSBIN_CHUNK_XXX)
integer Chunk data length, in bytes integer Chunk data length, in bytes
(unknown chunks are possible, a good reader skips over them) (unknown chunks are possible, a good reader skips over them)
(chunk-data-length does not include the first two integers)
byte[n] length-of-chunk bytes of data, depending on the chunk type byte[n] chunk-data-length bytes of data, depending on the chunk type
Chunks can contain nested chunks. Nested chunks are ALWAYS at the end of the chunk, Chunks can contain nested chunks. Nested chunks are ALWAYS at the end of the chunk,
their size is included in length-of-chunk. their size is included in chunk-data-length.
The chunk layout for all ASSIMP data structures is derived from their C declarations. The chunk layout for all ASSIMP data structures is derived from their C declarations.
The general 'rule' to get from Assimp headers to the serialized layout is: The general 'rule' to get from Assimp headers to the serialized layout is:
@ -133,14 +134,14 @@ The general 'rule' to get from Assimp headers to the serialized layout is:
[number of used uv channels times] [number of used uv channels times]
integer mNumUVComponents[n] integer mNumUVComponents[n]
float mTextureCoords[n][mNumUVComponents[n]] float mTextureCoords[n][3]
-> more than AI_MAX_TEXCOORD_CHANNELS can be stored. This allows Assimp -> more than AI_MAX_TEXCOORD_CHANNELS can be stored. This allows Assimp
builds with different settings for AI_MAX_TEXCOORD_CHANNELS to exchange builds with different settings for AI_MAX_TEXCOORD_CHANNELS to exchange
data. Unlike the in-memory format, only the used components of the data.
UV coordinates are written to disk. If mNumUVComponents[0] is 1, the -> the on-disk format always uses 3 floats to write UV coordinates.
corresponding mTextureCoords array consists of mNumTextureCoords*1 If mNumUVComponents[0] is 1, the corresponding mTextureCoords array
single floats. consists of 3 floats.
- The array member block of aiMesh is prefixed with an integer that specifies - The array member block of aiMesh is prefixed with an integer that specifies
the kinds of vertex components actually present in the mesh. This is a the kinds of vertex components actually present in the mesh. This is a