Vertex positions are based on the distance from some origin of the model. For the cube it's the origin is the center and the vertices' positions are some distance from the center.
The order in which you put those vertices depends on what API you are using and how it calculates whether a triangle is facing toward the camera or away. This is called the winding order. If I recall correctly, DX uses a clockwise winding order. Since the 3D Fundamentals framework is based on D3D, it too uses clockwise winding order. One of the issues I've had over and over while trying to generate my own geometry like this is making sure that mentally you rotate the cube so that each face is facing you when you list out the vertices. Same holds true for any shape you are trying to generate.
Texture coordinates describe how far into a texture a vertex would be if flattened and overlaid on top of it. In the case of the cube in this example, each face would take up the entire texture since the coordinates are from 0.0 - 1.0. You could also unfold the cube so look like a cross where all faces share the same texture. The texture coordinates for each vertex would then be some scaled down version to fit in the range of 0.0 - 1.0.
Say your texture is 100x100 ( normally you'd want a texture to be a power of 2, but this is example ) and your cube was unfolded instead of each face having it's own texture. Again, the cube laid out to look like a cross, the top 2 vertices might be the bottom edge of the top face. Assuming the mesh is stretched to go from top to bottom of the texture and the mesh is centers horizontally.
As you can see, there are 6 faces and 14 vertices.
Starting from the top of the ascii diagram the faces might be:
top
left, front, right
bottom
back
So, the texture coordinates might be something like:
top face:
/*top edge*/ ( .40f, .00f ), ( .60f, .00f ) // pixel position in 100x100 texture ( 39, 0 )
/*bottom edge*/ ( .40f, .25f ), ( .60f, .25f ) // pixel position in 100x100 texture ( 39, 25 )
left face:
/*top edge*/ ( .20f, .25f ), ( .40f, .25f ) // pixel position in 100x100 texture ( 19, 24 ), ( 39, 24 )
/*bottom edge*/ ( .20f, .50f ), ( .40f, .50f ) // pixel position in 100x100 texture ( 19, 49 ), ( 39, 49 )
front face:
/*top edge*/ ( .40f, .25f ), ( .60f, .25f ) // pixel position in 100x100 texture ( 39, 24 ), ( 59, 24 )
/*bottom edge*/ ( .40f, .50f ), ( .60f, .50f ) // pixel position in 100x100 texture ( 39, 49 ), ( 59, 49 )
right face:
/*top edge*/ ( .60f, .25f ), ( .80f, .25f ) // pixel position in 100x100 texture ( 59, 24 ), ( 79, 24 )
/*bottom edge*/ ( .60f, .50f ), ( .80f, .50f ) // pixel position in 100x100 texture ( 59, 49 ), ( 79, 49 )
bottom face:
/*top edge*/ ( .40f, .50f ), ( .60f, .50f ) // pixel position in 100x100 texture ( 39, 49 ), ( 59, 49 )
/*bottom edge*/ ( .40f, .75f ), ( .60f, .75f ) // pixel position in 100x100 texture ( 39, 74 ), ( 59, 74 )
back face:
/*top edge*/ ( .40f, .75f ), ( .60f, .75f ) // pixel position in 100x100 texture ( 39, 74 ), ( 59, 74 )
/*bottom edge*/ ( .40f, 1.0f ), ( .60f, 1.0f ) // pixel position in 100x100 texture ( 39, 99 ), ( 59, 99 )
Here instead of using the range 1-100 or 0-100, I used 0-99 because it makes indexing easier, but the way chili does it is 0-100 and just clamps the upper value to to the range 0-99 so any TC that is < 0 ends up getting index 0 and any TC that is >= 1.0 gets index 99.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com