CODEWITHSUNDEEP
c++qtopengl
Elliott
Elliott

Reputation: 1376

glColor not actually changing OpenGL's color

I am having a particularly annoying problem. In certain situations, calls to glColor appear to be ignored, resulting in objects being displayed with the incorrect color.

A Qt project which shows this problem can be found here.

When you run the program, all you see on the screen is two box-like objects, viewed from an angle. The object on the left is rendered by calling glCallList(boxModel1); and the object on the right is rendered by calling glCallList(boxModel2);. The two display lists are created by obviously-titled methods.

For both boxModel1 and boxModel2, I use a single display list called squareModel to render the sides of the boxes. I do this because while the square model in this case is trivial, the squareModel in my actual program is much more complex, with altered normals and etc.

The problem has something to do with the createManyRectangles method. When it is called with a small enough number (2715 for me), the colors appear normally: a blue box and a red box. When the number is high (2716 for me), the colors are ignored, and both boxes are rendered white.

Can anyone shed some light on what is happening here?

Upvotes: 3

Views: 7300

Answers (3)

David Muelheims
David Muelheims

Reputation: 11

I had a similar problem where I plotted a lot of points with different colors and afterwards a blue wireframe cube. (I used GLUT for my project.)

Initially my code looked like this:

glBegin(GL_POINTS);

    for(int i=0;i<N;i++)
     {
      glColor3f(R[i],G[i],B[i]);
      glVertex3f(X[i],Y[i],Z[i]);
     }

glEnd();
glColor3f(0.0f, 0.0f, 1.0f);
glutWireCube(2.0f);

However, this resulted in a flickering cube that continously changed it color from frame to frame to some unpredictable colors as if the last glColor3f is just ignored.

Solution: I put the glColor3f for the cube before the glEnd().

glBegin(GL_POINTS);

    for(int i=0;i<N;i++)
     {
      glColor3f(R[i],G[i],B[i]);
      glVertex3f(X[i],Y[i],Z[i]);
     }

glColor3f(0.0f, 0.0f, 1.0f);    // <= Changed only the position of this line
glEnd();
glutWireCube(2.0f);

I don't know WHY, but this solved my problem. Now I get a blue wireframe cube and the glColor3f is no longer ignored...

cheers,

David

Upvotes: 1

bernie
bernie

Reputation: 10400

Try to run your program with glIntercept. This allows you to record every OpenGL call made. Compare the output you get between the 2715 and 2716 number of rectangles. If there are any differences, it should lead you in the right direction.

edit

Since your actual OpenGL calls seem ok, it could be a driver problem as you mentioned. You could try different environments (video card, pc, etc) since as totem pointed out, he didn't experience your problem. Perhaps you could give some info on your environment?

Try rendering your rectangles without display lists to see if that helps. Where you would use glCallList, redo the sequence of OpenGL calls instead. If that solves the problem, you will know there is a problem with the display lists management in your app or in the driver.

Also, in case display lists turn out to be the problem, do you really need to use display lists? They have been less and less used for a while now in favor of VBOs. Perhaps you can "solve" your display list problem with that.

Upvotes: 0

Nicol Bolas
Nicol Bolas

Reputation: 474276

All rendering is done via display lists, but the problem occurs both when I specify the color in the display list and when I specify the color right before I call the display list.

Display lists are not self-contained. They do not restore OpenGL state after they have changed it. If a DL changes OpenGL state, then that will be OpenGL's state after the DL has executed.

You simply haven't posted enough code to definitively say anything; this is just the most likely explanation. Until you can post a reproducible case, there's no real way to help.

Upvotes: 3

Related Questions