If you played with the Stage3D spinning cube sample I linked in the previous post, you will notice one thing: the vertex colors in the vertex buffer are given as 3 floats (red, green and blue). This is rather wasteful in most cases because color components often vary between 0.0 and 1.0, and it’s more efficient to specify vertex colors (including alpha) as a single 32-bit value. For example, in hexadecimal notation, 0xFF800040 would mean alpha of 1.0 (0xFF), blue 0.5 (0x80), green 0 (0x00) and red 0.25 (0x40).

If you look in the Stage3D docs, you will find the constant Context3DVertexBufferFormat.BYTES_4 to use in the call to Context3D.setVertexBufferAt(). But if you naively just change the vertex buffer array to turn each vertex color’s set of 3 components into a single hex value, make dataPerVertex = 4 instead of 6, and use BYTES_4 for va1, then you will find that the colors are coming out wrong. Why? Because the function VertexBuffer3D.uploadFromVector() always stores the values from the Vector in floating point format. Of course! This is the most common situation for the components of the vertex positions, normals, texture coordinates and such. But we need our BYTES_4 color value to be stored verbatim as a 32-bit uint.

Vector. and uploadFromVector() do not give you control over the byte format of value. How do you solve this?

You must use a ByteArray, to which you will copy the values manually with the right format. In our example above, 3 writeFloat() calls plus a writeUnsignedInt() for the 32-bit color. A detail that stumped me for a while is that you must ensure the ByteArray is Endian.LITTLE_ENDIAN, it defaults to BIG_ENDIAN. I wrote this function to perform this process, with the aid of an array that stores the format of each varying parameter:

So, in the case of the spinning cube, the component array would be:

With that array in hand, another useful function to set the array components into the context: