OpenGL, how to output an image larger than your display

[Duncan C]

I'm a neophyte when it comes to OpenGL. I'm getting reasonable results in rendering my 3D fractals to the screen.

I now want to add the ability to save 3D renderings to a file, or send them to a printer. For those output targets, the user may well want to create images larger than the current display size.

A buddy of mine who knows more about OpenGL than I do tells me that you have to create a viewport within the limits of the current display, move it from place to place in your image space, capture the pixels from that viewport, then assemble them into a bitmap of the whole image.

This seems like an awful hack. Most display engines I've used recently include support for offscreen image buffers, and I know that OpenGL supports double-buffering for fast screen refresh. Is there a way for me to render my 3D image to an offscreen buffer bigger than the display?


Duncan

[cKleinhuis]

right now i can just say, capturing the pixels from an opengl viewport is no problem at all, in fact it is offscreen rendering, if you do not post a refreshdisplay to opengl, \
it should be easily possible to set the current rendering frame to something bigger than the viewport temporarly for rendering, but keep in mind that zou can not use screen resolutions ofer 2048x2048, or is it 4096x4096 i think this is what your friend meant with assembling the parts, this has to be done anyway for images exceeding 4096x4096 or so pixels ....

[Duncan C]

right now i can just say, capturing the pixels from an opengl viewport is no problem at all, in fact it is offscreen rendering, if you do not post a refreshdisplay to opengl, \
it should be easily possible to set the current rendering frame to something bigger than the viewport temporarly for rendering, but keep in mind that zou can not use screen resolutions ofer 2048x2048, or is it 4096x4096 i think this is what your friend meant with assembling the parts, this has to be done anyway for images exceeding 4096x4096 or so pixels ....

Trifox,

I've learned quite a bit about this since posting my question.

You can't draw to an area larger than your viewport. You run into pixel ownership problems. It might work on some implementations, but the results are undefined.

If your driver supports it, you can use framebuffer objects (FBOs) attached to a renderbuffer object, and draw offscreen into that. However, that doesn't buy you very large output sizes. On my platform, the driver claims it can handle a renderbuffer of up to 4096 x 4096, but the driver crashes if you try to create a renderbuffer that big. Plus, FBOs are not supported on all implementations.

Instead, I create a pixel map in main memory, then use the current viewport. I create a series of tiles that are as big as the current viewport or smaller. I adjust the view frustum so that the viewport shows a portion of the whole image I want to render, render that portion to the back buffer, use glReadPixels to copy the pixels into my pixel map, then move on to the next tile. It was a fair amount of work to do, but it works perfectly, and can output at an arbitrary output size.

I used a GNU licensed code library called "tr" as the model for my code. I did not want to put my code into the public domain, so I just studied how the "tr" library worked and then wrote my own version.


Duncan C

[keldor314]

The likely reason the driver crashed was that a 4096x4096 is pretty darn big!  At 32-bit color, it would translate to about 67 MB.  If your card didn't happen to have that much memory...

[Duncan C]

The likely reason the driver crashed was that a 4096x4096 is pretty darn big!  At 32-bit color, it would translate to about 67 MB.  If your card didn't happen to have that much memory...

That's the odd thing. I get the same result, at the same size, regardless of the amount of memory on the card. Plus, there's a specific error code that's supposed to be returned if the driver runs out of memory. It's supposed to report an error if you try to do something that it can't do.

On an older machine with limited video memory, it crashes at the same size. Below that threshold, it gets REALLY, REALLY slow, but it still works. The slowdown is to be expected, since the card starts thrashing back and forth from video memory to main memory.


Duncan C

[David Makin]

I used a GNU licensed code library called "tr" as the model for my code. I did not want to put my code into the public domain, so I just studied how the "tr" library worked and then wrote my own version.
Duncan C

Hi Duncan, am just starting to use OpenGL - am programming for iTouch/iPhone - could you point me at the link to the "tr" library please ? Alternatively just send me a zip of yours I need to quickly display areas from a bitmap of up to 2048*2048 and doing it through Quartz etc. looks a like it will be a little slow.

[Duncan C]

I used a GNU licensed code library called "tr" as the model for my code. I did not want to put my code into the public domain, so I just studied how the "tr" library worked and then wrote my own version.
Duncan C

Hi Duncan, am just starting to use OpenGL - am programming for iTouch/iPhone - could you point me at the link to the "tr" library please ? Alternatively just send me a zip of yours I need to quickly display areas from a bitmap of up to 2048*2048 and doing it through Quartz etc. looks a like it will be a little slow.

David,

Here's a link to the tile rendering library:

TR - OpenGL Tiled rendering

[David Makin]

Thanks !