reduce pixels in terrain

OpenGL
1

Hi
I do:

for( int probeZ = 0; probeZ < 100; probeZ++)
{
for( int probeX = 0; probeX < 100; probeX++)
{
…
glBegin(GL_TRIANGLE_STRIP);
glNormal3f(tmpInfo.normalX, tmpInfo.normalY, tmpInfo.normalZ);
glVertex3f(tmpInfo.locationX, tmpInfo.locationY, tmpInfo.locationZ);
glVertex3f(tmpInfo.locationX+10, tmpInfo.locationY, tmpInfo.locationZ);
glVertex3f(tmpInfo.locationX+10, tmpInfo.locationY, tmpInfo.locationZ+10);
glVertex3f(tmpInfo.locationX, tmpInfo.locationY, tmpInfo.locationZ+10);

					            glNormal3f(tmpInfo.normalX, tmpInfo.normalY, tmpInfo.normalZ);
					            			glVertex3f(tmpInfo.locationX, tmpInfo.locationY, tmpInfo.locationZ + probeZ);
					            			glVertex3f(tmpInfo.locationX+10, tmpInfo.locationY, tmpInfo.locationZ + probeZ);
					            			glVertex3f(tmpInfo.locationX+10, tmpInfo.locationY, tmpInfo.locationZ+10 + probeZ);
					            			glVertex3f(tmpInfo.locationX, tmpInfo.locationY, tmpInfo.locationZ+10 + probeZ);
		        glEnd();
        glPopMatrix(

…

which brings down fps to it’s knees. Probably I’m doing something wrong or how to reduce drawn pixels? I want to draw
some quadratic terrain and tmpInfo gives me a height map. But I need only 2D, ie draw height with different colors.
Many thanks
Michael

2

tmpInfo gives me a height map. But I need only 2D, ie draw height with different colors

Then save tmpInfo as a RAW file and look at the resulting image in Photoshop or Paintshop pro.
It will, presumably, be a grey scale image.
RAW format BTW is a custom byte header specifying width, height and anything else you need, eg Bits Per Pixel. You can then read back your RAW file since you know what you put into the header. The important point though is the data (tmpInfo) follows the header - so it’s just really a memory dump with a tiny header.

3

no it’s dynamic changing with viewer’s location.

4

You’re rendering 10,000 triangle strips batches, each containing only 6 triangles, with immediate mode, and with state changes in between.

I guess I’m not too surprised that performance is horrible. Immediate mode is the most inefficient way to send geometry to the GPU. A mere 6 triangles per batch is horrible inefficient regardless. And doing state changes between each of these batches kills you too. Beyond that if your rendering a 2D mesh, indexed TRIANGLES is likely to be more efficient than TRIANGLE_STRIPs.

First thing’s first: refactor what you’re doing so your batch sizes are much bigger (that’s the part between each glBegin/glEnd pair). How about getting rid of that inner loop entirely? Then you’ve got 100 batches of 600 triangles each, and have gotten rid of a bunch of changes. That’s better.

Now terrain is typically static (unchanging). As a quick test, put your terrain batches in display lists. Then each frame just render the display lists. That’ll give you ideal best perf for that batching of triangles. Then try flipping to client arrays or server arrays (VBOs) to do your rendering. Essentially, this just means putting all of your glVertex/glNormal data in an array and telling the GPU with one call to render all of those triangles in one go – much more efficient than doing immediate mode.

There’s even more you can do here, but this should pick your FPS off the floor.

As a completely different alternative, if this is just a pre-colored image, you can just render it with glDrawPixels or texture it onto a QUAD.

5

Yeah, but the point is terrain vertex data is constant (unchanging) in OBJECT space. Sure, the VIEWING (camera) transform changes, which changes where the terrain appears on the screen, but because the data is constant in OBJECT space, you can just batch it up in an array and render it fast with display lists, client arrays, or server arrays (VBOs).