several OpenGL conceptual questions

OpenGL OpenGL: Basic Coding
1

I am trying to display street maps and want to be able to show an entire State and zoom in/out, and around on the map. The map for a state can easily be four million lines.
I also want to be able to draw/modify the size of a circle or polygon on top of the map in real time using the mouse.
By the way everthing is done in ortho2D.

I have a 2GHz Athlon XP and a 6600GT graphics board and it takes 320 milliseconds to reload the data into the graphics board and redraw the screen.
This makes it way to slow to change the size of the circle/polygon in real time.
As far as I can tell most video boards don’t have on overlay plane available to do the circle/polygon on separately.

I bought a book on OpenGL and it completely glosses over anything to do with my questions.

The conceptual problem I have is with where the data is stored and where it goes after the matrix math is applied.
Does the data go back into the same place in memory after it is multiplied?
Does the original data still exist in the graphics card?
Is there anyway to get the data into the graphics card and zoom/move around the map without reloading the data?
Am I missing something obvious?
Other mapping programs I have tried are even slower than my code, sometimes as much as 100 times.
I do have hardware acceleration running and speed is essentially identical under WinXP and linux.

Another question has to do with resolution of the data, OpenGL allows 32 bit integer data and floats, but the OpenGL book says the data is converted to floats before being used. This would seem to imply a loss of 8 bits of resolution in the data.

email tpb@execpc.com

2

The conceptual problem I have is with where the
data is stored and where it goes after the matrix
math is applied.

Depends how you’re drawing it. If you’re just using immediate mode (glBegin/glEnd) or vertex arrays (glDrawArrays and friends) then it isn’t ‘stored’ anywhere.

Does the data go back into the same place in
memory after it is multiplied?

No; the transformed vertices are drawn and then thrown away.

Does the original data still exist in the graphics card?

Again, not by default (i.e. not with immediate mode or vertex arrays).

Is there anyway to get the data into the graphics card and zoom/move around the map without reloading the data?

Yes. For the old-school way, look at display lists. For a newer way, look at the ARB_vertex_buffer extension, though I doubt it would do much better than display lists in this case. Either way, you can store geometry data on the card (memory permitting, but 4 million lines shouldn’t be a problem) and draw it without bottlenecking on the bus transfer.

Either way, I’d suggest breaking your map data into square tiles and storing them individually. That way you can cull tiles that aren’t visible, and update display lists just for the affected tiles when you edit the data (not clear whether this is a requirement). ARB_vertex_buffer lets you be even more selective when updating, but it’s a bit fiddlier.

Another question has to do with resolution of the data, OpenGL allows 32 bit integer data and floats, but the OpenGL book says the data is converted to floats before being used. This would seem to imply a loss of 8 bits of resolution in the data.

Yes.

HTH
Mike

Edit PS: you might also consider putting “big” details into a separate display list, covering a wider area, than smaller details. You can then skip the smaller-detail lists when zoomed out, and ideally keep the amount of geometry drawn fairly constant.

3

The data is split up by counties already. My state has 72 counties, and when zooming in and out, I check if any data in the county is in the window. Actually the data is stored by county with the min/max XY extents, and that is checked against the window.
This speeds things up a lot, a single county displays in about 20 milliseconds and when zoomed inside a single county it drops down to minimum of about 6 milliseconds.

I was just hoping there was someway to load the data into the graphics board and somehow change the viewpoint and the window size on what is displayed without reloading and scaling the data each time.

One interesting driver anomaly I found is an older graphics card I originally tried my code on. I believe it was a 5200. That card rendered the image faster as I zoomed in, unlike the 6600GT. This was before I changed the code to check the data myself.
Apparently that driver checked the data to see if it was in the window somehow and only rendered that data. I sent an email to Nvidia asking them why the same driver file on the two boards worked so differently, and never got a reply.

I can live with the speed of redraw except when I zoom out and show all the data and then try to draw the circle/polygon on top of the map in real time.
Is there some method to draw and modify the circle/polygon on top of the map in real time without using an overlay plane?
How do people typically do selection boxes now? I’m talking about the typical selection rectangle where the user starts the mouse somewhere on the screen and holding the mouse button down, drags the rectangle corner making it larger and smaller in real time?

4

I was just hoping there was someway to load the data into the graphics board and somehow change the viewpoint and the window size on what is displayed without reloading and scaling the data each time.

There is. Display lists or ARB_vertex_buffer, as I said. You can change the viewpoint and/or the window size all you want without invalidating vertex data cached on the card using either of these methods.

I can live with the speed of redraw except when I zoom out and show all the data and then try to draw the circle/polygon on top of the map in real time.

Drawing a circle/polygon on top, in itself, should make no difference to anything. It’s the amount of map data that’s hurting you. Try display lists etc as suggested; if it’s still too slow, then think about whether you really need to display the entire dataset when fully zoomed out. Worst case is having to render the map to a screen-sized texture and then using that as a background, but you really shouldn’t need to go that far.

5

I am a beginning programmer in both C and OpenGl, and my conceptual problem is back.
If the matrix math used to scale the data or changing the viewport modifies or destroys the original data, how does ARB_vertex_buffer help?
Does gluOrtho2D not do matrix math on the data?
Again it seems I must be missing something here.

I have a switch in the program to use display lists using:
glNewList
glEndList
glCallList
and generate a list for each county.
The list is generated only once.
The display lists are actually slightly slower than just using glBegin and glEnd.

My problem with dragging the size of the rectangle or circle that in realtime is that it draws them multiple times as the size changes.
Is there a way to go back and erase the previous rectangles/circles when the new size is drawn, without redrawing the entire screen?
This is the main reason I was looking for more speed in updating the screen.

6

Does gluOrtho2D not do matrix math on the data?
Again it seems I must be missing something here.
In simple words:
application -> vertex buffer
vertex buffer & matrices -> transformation -> rasterization

gluOrtho2D and all other matrix operations only affect current matrices - they do not do anything with the data.
When you draw something, vertex coordinates are transformed by current matrices.

If you draw in immediate mode (using glVertex) there is no vertex buffer - vertices passed from application are transformed, rasterized and gone.

If you use vertex buffers then your applications places data into buffer. Then you setup the matrices - this does not affect data in buffer.
When you use these buffers for rendering, vertices are one by one taken from buffer, transformed and lines are drawn, but the transformed vertices are not written-back to the vertex buffer. Data in buffer remains unchanged - you ca nuse it again.

7

Ok, if I understand this correctly, to find out if the data is rendered faster from the graphics board memory, I would want to store my counties as vertex buffers on the graphics card.
The rendering using display lists on my 6600GT card is half the speed of immediate mode.
Are display lists stored in the graphics card memory?
If not is there a way to do this?
This would allow me to quickly test for speed improvments without first figuring out out to use ARB_vertex_buffers.