Translating the frame buffer?

OpenGL OpenGL: Basic Coding
1

Is there a way to shift the OpenGL frame buffer? Seems like a long shot, but if there was I’d be very interested.

The problem comes when I have a TON of vertices to draw, making up lines and polygons, but there are many. Over 200,000 and the hardware I’m using isn’t great. Display lists work well, but there are some memory issues and drawing every line every frame takes a lot of CPU and has a horrible refresh cycle.

I’m working with what I can and thought, “What if the whole buffer can be shifted? Then I could draw once with OpenGL and shift things around fairly cheap!” . . . but I may be way out in left field here.

Let me know, I’m braced for the worst.

Thanks,
Clay

2

Not quite sure what you are doing, but in theory you could render the scene to a texture in an FBO. That texture can then be used as the surface of a QUAD.

What you do then is up to you… Scroll by changing texture coords, or scroll by moving the QUAD past the viewpoint with the texture fixed in place.

In theory, and I am simply thinking out loud here, you could be drawing the new scene data to another FBO as you scroll your currently rendered one past…

3

Hmmm, I like the sound of that, it has potential. That captures the general idea of what I want to do: draw many lines/polygon quickly without exclusive use of display lists.

Some followup questions then for frame buffer objects:

What are some commands that use them? (“glXYZ()”, I’ll research them myself).

Is writing to them pretty quick? I would have many vector lines and polygons to draw in the object.

The FBO would take up texture memory, correct? Would a FBO be able to hold textures itself?

Thanks,
Clay

4

  1. good tutorials :
    http://www.gamedev.net/reference/programming/features/fbo1/
    http://www.gamedev.net/reference/programming/features/fbo2/

  2. yes, as quick as framebuffer (unless you use fancy formats and attachments)

  3. it takes memory from the accelerator card, and yes of course when used as texture is uses texture memory.
    “Would a FBO be able to hold textures itself?” -> what do you mean ?

5

I’ll look into those tutorials. Thank you!

Good to hear the drawing is fast, speed has been troubling as of late. I’m guessing since the rendering happens on the card there might not even be a delay to push the FBO texture to the card (where there is a slight delay using glTexImage2D()).

Without looking at the tutorials yet, I was wondering what can be drawn in a FBO. If I have a bunch of icon textures that I paste around my 2D screen, say in a display list or otherwise, I wondered if those could go into a FBO as well. I’m picturing FBOs as an alternative to DisplayLists or the like, where I can draw a bunch of things up front and then cheaply manipulate them on the screen (rotate, translate, etc).

Thanks again for your help, I’ll be sure to check back if I run into something.

Clay

6

FBO stands for framebuffer object. See them as invisible framebuffers, which can easily be turned into a texture.
Think about a scratchpad, a (big) postit, whatever temporary 2D array of data you can render into with colors, depth, float values, then copy/paste it to other framebuffers …

Display list is a completely different paradigm : it stores commands into the video card, in an optimized form, to be called at will without the driver overhead and the data transfer between CPU and GPU. Big static meshes, huge static textures, as DL compilation is long.

7

Also Display Lists are deprecated in OpenGL3.0 so better to not learn them and use the more progressive functions which will become the only functions available ultimately.