I see your reply… looks like you are 100% headed in the right direction…some of what I write here is a rehash of stuff you discovered… for some of your questions I don’t answer here I’ll plop in a new post;)
So far you have read one byte at a time from a hex editor and either decoded it in the trusty ASCII table or simple looked at the readable text the hexeditor decoded for you.
The reason why you do not see any numbers in the hex editor, however, is for the following reason:
1-byte is capable of holding 256 different values… no more. Take a look at your ASCII table designed for decoding a single byte… it only has 256 different entries in it 
Therefore, representing a number in a single byte limits the programmer to using a integer value between -128 and 127 or 0-255. Pretty restrictive demands… what if a mesh has 300 faces? Uh oh.
This is where additional bytes come in:
- Tack on a second byte and suddenly you can store up to 65,535 different values
- Tack on two more for a total of four bytes and now you can represent a number up to 4,294,967,295 :eek:
4-byte integers are what the average programmer tends to use these days for storing basic positive and negative integers. So this is likely what you’ll find in your .cdt file for things like # of faces, # of meshes, # of vertices, etc.
4-bytes are also the most commonly used size for storing decimal numbers (i.e 5.432). This is how normals, vertices coordinates, etc will likely be stored in your .cdt.
So summary:
1-byte = storage size for characters in a string
4-byte = storage size for integer or decimal numbers
For a full list of data types and their sizes you can always look here: http://msdn.microsoft.com/en-us/library/s3f49ktz.aspx
Now applying that knowledge to Mr. Hexeditor. Back to my original lone cube + .stl export here is the file contents immediately following the 80-byte header:
0c00 0000 0000 0000 0000 0000 0000 0000 ................
0400 803f f7ff 7f3f 0000 803f 0000 803f ...?...?...?...?
ffff 7f3f 0000 80bf ffff 7fbf 0000 803f ...?...........?
0000 803f 0000 0000 0000 0000 0000 0000 ...?............
0000 0000 803f ffff 7f3f 0000 80bf faff .....?...?......
According to the .stl binary read function the next item in the file is a 4-byte integer (representing the # of faces in the mesh). These four bytes are: 0c00 0000. Believe it or not that is the number of faces in the mesh (in hex), with one minor twist.
Most computers these days store multi-byte data types (i.e. a 4-byte integer) in reverse. This is known as little endian storage :rolleyes:. So before using 0c00 0000 you have to reverse it. See image: http://www.mediafire.com/i/?n4f46dmaarsybad
So the actual value is 0000000c. If you google “hex to integer converter” and plug in that hex number you will get an output of 12. This is supposed to be the # of triangle faces in a cube and indeed it is.
To give a quick overview of the rest… here is an image outlining the header, # of faces, the 3 normals of the first face, and the 3 vertices of the first face in the .stl file format (see below for color key). http://www.mediafire.com/i/?tx45117m4kl58cl
-
Brown = 80-byte header
-
Green = 4-byte integer (# of mesh faces)
-
Blue = 3 four-byte decimal numbers (describing the normal’s x,y,z components for this face) Note: Yes they are zero. The .stl exporter looks like it doesn’t actually write out the normal values, but rather expects the application importing this mesh to auto recalculate the normals for each face. Lazy exporter 
-
Yellow = 9 four-byte decimal numbers (each of the vertices for this face [made up of x,y,z components])
-
Purple = 2 bytes of garbage
For the green you would reverse the bytes and pass it into a hex to integer converter for the blue and yellow since they are floating point numbers you would reverse the bytes for each as described earlier and pass into a hex to floating point converter.
P.S. I’ll give you a few tips in my next post so that you do not have to manually find, reverse the bytes, and pass the resulting 4-byte hex value into a converter just to see whats in a file. So don’t feel bummed about my above tooth-pulling explanation… its just important you know how it works before I give you some shortcuts.