diff options
| author | gman@google.com <gman@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-11 03:32:34 +0000 |
|---|---|---|
| committer | gman@google.com <gman@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-11 03:32:34 +0000 |
| commit | 0288c4228f20e07762c4322a5c2d868d4f61c6f1 (patch) | |
| tree | 3b7bf434d6fec24ca03d171e1b97a67e34555f93 /o3d | |
| parent | e99c5a5995b8f00e46f218f48df269ab3ef27071 (diff) | |
| download | chromium_src-0288c4228f20e07762c4322a5c2d868d4f61c6f1.zip chromium_src-0288c4228f20e07762c4322a5c2d868d4f61c6f1.tar.gz chromium_src-0288c4228f20e07762c4322a5c2d868d4f61c6f1.tar.bz2 | |
Document the O3D binary formats.
I just wrote up some small docs to kind of get this out
of the way. If Josie wants to write a more formal doc
to put on the website we can do that but at least with
this it's documented.
Going through it I have a minor concern. The Buffer
format is fine because it spells out exactly how much
data it expects.
The Skin and Curve formats do not so if pass in a
valid offset but an invalid length when you call
Cuvre::Set(myRawData, validOffset, invalidLength)
you get undefined results and possibly no errors
depedning on what data it runs into.
This may or may not matter as it's unlikely the
user will get very far with an invalid length. The
issue is just more that it's possible.
Review URL: http://codereview.chromium.org/155246
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20457 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'o3d')
| -rw-r--r-- | o3d/serializer/cross/README.txt | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/o3d/serializer/cross/README.txt b/o3d/serializer/cross/README.txt new file mode 100644 index 0000000..9292bfb --- /dev/null +++ b/o3d/serializer/cross/README.txt @@ -0,0 +1,67 @@ +These are the formats for the various O3D objects that can be stored in binary.
+
+NOTE:
+All int16, uint16, int32, uint32 and floats are stored in LITTLE ENDIAN format.
+
+------------------------ Buffer ------------------------------------------------
+A Buffer (VertexBuffer, SourceBuffer, IndexBuffer) are all stored as follows.
+
+// Header
+uint8[4] id : A 4 byte ID with the ascii characters "BUFF"
+int32 version : A version number. Must be 1
+int32 numFields : The number of fields in the buffer.
+
+// For each field
+ uint8 fieldType : Type of field. 1 = FloatField, 2 = UInt32Field, 3 = UByteNField.
+ uint8 numComponents : The number of components for that field.
+// End for
+
+// stored once.
+uint32 numElements : The number of elements in the buffer.
+
+// For each field. Depending on the type of field
+ // If FloatField
+ float[numElements * numComponents]
+
+ // If UInt32Field
+ uint32[numElements * numComponents]
+
+ // If UByteNField
+ uint8[numElements * numComponents]
+// End for
+
+
+------------------------ Curve -------------------------------------------------
+A Curve is stored as follows.
+
+// Header
+uint8[4] id : A 4 byte ID with the ascii characters "CURV"
+int32 version : A version number. Must be 1
+
+// For each key in the Curve
+ uint8 keyType : The type of key. 1 = StepCurveKey, 2 = LinearCurveKey, 3 = BezierCurveKey
+ float input : The input of the key
+ float output : The output of the key
+ // If it is a BezierCurveKey
+ float inTangentX : the x component of the in tangent.
+ float inTangentY : the y component of the in tangent.
+ float outTangentX : the x component of the out tangent.
+ float outTangentY : the y component of the out tangent.
+// End for
+
+
+------------------------ Skin --------------------------------------------------
+A Skin is stored as follows.
+
+// Header
+uint8[4] id : A 4 byte ID with the ascii characters "SKIN"
+int32 version : A version number. Must be 1
+
+// For each vertex in the skin
+ int32 numInfluences : The number of influences on this vertex.
+ // For each influence
+ int32 matrixIndex : the Index of a matrix that affects this vertex.
+ float weight : The weight for this matrix.
+ // End for each influence
+// End for each vertex
+
|