hardware question

[mikau]

I'm practicing openGL on my brand new laptop, which has an integrated graphics card. I'm still learning openGL and I haven't gotten into display lists yet, or the use of vertex arrays. Right now I just wrote some code to draw ellipsoids because I found you can draw quite a few interesting shapes by combining ellipsoids of various sizes and colors. Each ellipsoid has 20x20 or 400 quad primitives to describe it. I thought this was fairly modest amount but when i draw 6 or 7 such shapes, the frame rate begins to drop below 60 per second.


I thought maybe my code was inefficient so I added some timers, but they quickly revealed the drawing was by far the longest operation.

Is this merely because I am drawing primitives one by one, or is it more likely my cheap graphics card? Still, this is a brand new windows 7 laptop and I'm pretty sure its capable of more than this!

[pjcozzi]

Are you computing the ellipsoids every time you draw? Or are you just calling glVertex3f, etc? If you are computing them every time, all the trig can become a bottleneck.

It doesn't sound like you are drawing much even for an integrated graphics card. Try using display lists or VBOs for a performance boost.

Regards,
Patrick

[mikau]

I am updating the ellipsoids which uses a lot of trig, but that is done in my update() function which takes less than 1 millisecond according to my experiments. The drawing function which uses no trig functions, takes about 16 milliseconds.

Will display lists make that big a difference?

[mark ds]

what framerate do you get if you draw just one (out of the 400) quads?

[mikau]

mark_ds,

hmm.. the frame rate increases to around 720 fps, about 12 times faster for 1/400 the amount of drawing. That makes little sense.. maybe computation is the issue here. Doesn't agree with my time measurements though.. strange.

[mikau]

okay, the following code is enough to reduce my speed to about 60 fps:

	glColor3f(0.5,0.5,0);
	for (int i = 0; i < 35; i++)
	{
 
		for (int j =0; j < 35; j++)
		{
			glBegin(GL_QUADS);
				glVertex3f(i,j,0);
				glVertex3f(i+1,j,0);
				glVertex3f(i+1,j+1,0);
				glVertex3f(i,j+1,0);
			glEnd();
		}
	}

thats just a 35x35 checkerboard. Something seems wrong here.

[marshats]

How much faster if you replace the code with a display list as follows:

static GLuint list=0;
 
if (list==0) {
  list=glGenLists(1);
  glNewList(list,GL_COMPILE);
 
  glColor3f(0.5,0.5,0);
  for (int i = 0; i < 35; i++)
  {
 
    for (int j =0; j < 35; j++)
    {
      glBegin(GL_QUADS);
        glVertex3f(i,j,0);
        glVertex3f(i+1,j,0);
        glVertex3f(i+1,j+1,0);
        glVertex3f(i,j+1,0);
      glEnd();
    }
  }
 
  glEndList();
}
 
glCallList(list);

[pjcozzi]

If you are constantly updating the data, I'm not sure how much display lists will help since they need to be compiled. Can you just compute a sphere up front and use translations, rotations, and non uniform scales? Note that the surface normals will be incorrect due to the non uniform scale but you might be able to tolerate it.

Regards,
Patrick

[mikau]

marshats: it was a liiittle better. But not significantly.

Isn't that strange?

[mikau]

Okay well here is a review of the graphics chip, its an Intel Media Accelerator 4500MHD: http://pcgamingcorner.com/wordpress/?p=820

apparently it is not at all suitable for high speed graphics. However! What I'm doing is not even close to the kind of graphics quality in todays games.