# OpenGL - question about glColorPointer

So, I'm just starting out with LWJGL, and my current task is to render two colored cubes on the screen. I can render them, however, I'm looking for some advice on the most efficient way to specify the colors. Currently, I'm doing this:

``````// specify vertices and colors
vertexData.put(new float[] { -0.5f, -0.5f, 0, 0.5f, -0.5f, 0, -0.5f,  0.5f, 0, 0.5f,  0.5f,  0, // 1st cube vertices
-1.0f, -2.5f, 0,    0, -2.5f, 0, -1.0f, -1.5f, 0,    0, -1.5f,  0 }); // 2nd cube vertices
colorData.put(new float[] { 1, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1, // colors for 1st cube
1, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1 } ); // colors for 2nd
``````

In the render loop:

``````glVertexPointer(vertexBufSize, GL_FLOAT, 0, 0L);
glColorPointer(colorBufSize, GL_FLOAT, 0, 0L);
...
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); // 1st cube
glDrawArrays(GL_TRIANGLE_STRIP, 4, 4); // 2nd cube
``````

This works, but I can't help but think that since I'm specifying the exact same color values for both cubes, I'm wasting memory. I was hoping to just have one set of vertex colors that could be applied to each cube that gets drawn. Can it be done? If so, what is the best way to do it?

Thanks

-

## 2 Answers

Why don't split the vertex array into two arrays, each one for a separate cube, then you can share the color array between these two vertex arrays, like these:

``````firstCubeVertexData.put(new float[] { -0.5f, -0.5f, 0, 0.5f, -0.5f, 0, -0.5f,  0.5f, 0, 0.5f,  0.5f,  0});// 1st cube vertices
secondCubeVertexData.put(new float[] {-1.0f, -2.5f, 0,    0, -2.5f, 0, -1.0f, -1.5f, 0,    0, -1.5f,  0 }); // 2nd cube vertices
colorData.put(new float[] { 1, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1}); // color data
``````

when you render, do:

``````glColorPointer(colorBufSize, GL_FLOAT, 0, 0L);
glVertexPointer(firstVertexBufSize, GL_FLOAT, 0, 0L);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); // 1st cube
glVertexPointer(secondVertexBufSize, GL_FLOAT, 0, 0L);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); // second cube
``````
-

Don't worry too much about "wasting memory" - the key to good performance with OpenGL is not so much how much memory you use, but rather using the API properly and in the way it was designed to be used.

This means that sometimes you need to burn a little extra memory and this can seem counter-intuitive, particularly if you have a background/culture that emphasises frugality.

In this case you can certainly do what has been suggested in the other answer (i.e. share the same glColorPointer for each cube) but this is actually going to work against you longer term.

• You need to partially respecify vertex format and layout each time you draw anything which may lead to performance loss (you'll particularly feel this when you move to VBOs).

• You're unable to interleave your vertex data which will lead to performance loss.

• You're unable to index your vertex data, which will also lead to performance loss.

In the trivial case where you're just drawing a couple of cubes none of this is going to matter so much. As scene complexity and vertex counts build up, you're really going to be hurt badly by it, and this single initial focus on not "wasting memory" will prevent you from hitting anywhere near your potential max performance. You may even run as slowly as 10% of what you would otherwise be capable of.

The moral of the story is that coding stuff to run on a CPU is not the same as coding stuff to run on a GPU. If you take a programming mentality that is evolved around the former (and that has an emphasis on ultra-frugality derived from a time when limited storage was most likely to be your primary bottleneck) and try to apply it to the latter, you'll have a very high risk of being burned. That's not an absolute rule of course; I'm not saying that it's OK to needlessly use extra memory all over the place; I am however saying that what looks like "wasting memory" from one perspective may well turn out to be just "using a relatively small amount of extra memory in exchange for gaining a relatively large amount of extra performance" from the other.

-