How to create basic scrolling display

[Charlie Martin]

I'm working on a scrolling type of display, where new objects will be added at the right side of the window, and continually progress to the left in real time. When an objects moves out of view on the left, I don't need to be able to recall it.

How should I think of this in GL terms, regarding the modelview and projection? Do these need to change as the display scrolls?

What is the basic sequence of GL actions that I would use to implement this?

Because one can zoom and pan using scaling and translation commands, I'm guessing that GL is keeping all of the vertices (etc.) that have been sent to it. In a scrolling display like this, what keeps GL from eventually running out of space? Perhaps my understanding is flawed here?

Thanks,
Charlie

[Aeluned]

OpenGL doesn't keep track of all vertices sent to it.

In fact, it's quite the opposite : you give OpenGL some vertices, it transforms those vertices by the modelviewprojection composite matrix (these transformed values are what you eventually end up seeing on screen) and never even looks back on them. it performs absolutely no vertex management for you.

the zooming and panning factors alter the modelview matrix which in turn produce different outputs for the final pixel resting place on screen after matrix transformations.

all vertex data is either stored by your application in arrays (for vertex arrays) or sent in 'immediate' mode by issuing glVertex* commands.

in your application your objects should be encapsulated in some object along wiht the vertex data that defines it. when finally the object is translated off screen you delete it. you can test if it's still on screen using an 'occlusion query' to count how many pixels of the object actually made it to the screen - if none, it's gone.

you could store all of your objects in a list and each frame simply iterate the list rendering each object.

hope at least some of that made sense.

[lgrosshennig]

Aside from what has been said already, the fewer data you send to OpenGL the better.

But I would not use the occlusion query the way Aeluned proposed, because it may give you false positives if a object is in view frustrum but completly covered by another object, plus in order to start a query you have to send the object down the pipe in the first place.

Instead I would go for basic frustrum culling. Generate a simple bounding box around your objects and only send them to OpenGL if there are either completly or partialy inside the frustrum.

There are a lot of articles on the net how to do frustrum culling. Its pretty simple and fast too.

[MikeC]

Followup to lgrosshennig's post - it's actually spelled "frustum" if you want to Google for it.

(Although for some reason I always want to spell it with an extra 'R' too. Spent ages the first time I used it wondering why I kept getting linker errors. And judging by the 866 hits returned by Google for "frustum culling" we aren't the only ones.)

[lgrosshennig]

Yeah, that is correct .

One more bad habit to get rid off, I guess.

Thanks to MikeC for pointing it out.