PDA

View Full Version : Best Method for Off-Screen Rendering



DreamingMoon
04-07-2008, 11:45 AM
I'm working on a CAD application. I want to create icons that demo various texture map configurations. For a given combination of texture maps, material and color, I want to demo it by rendering a sphere with simple lighting onto a icon (maybe 72x72 pixels), capture that image and use it as an icon associated with the texture/material "bundle".

So, I want the rendering to happen off-screen. The image size and the geometry are tiny; also, this will happen typically a mere 0-12 times during a session, so worrying about performance is not an issue.

My requirements include satisfying an existing customer base. This is not a "you wanna play my new game, you gotta buy new hardware" situation. Many users will be running this on laptops that are more than 2 years old.

I'm somewhat shocked to find that pbuffers may not be the solution. For example, my NVidia Quadro FX 540 does not support the WGL_ARB_pbuffer extension--and GL_ARB_pixel_buffer_object doesn't seem to be useful for my purpose (please tell me I'm wrong). Meanwhile, framebuffers via GL_EXT_framebuffer_object are clearly too new for many my customers (right?). Is there a common extension I'm overlooking?

Our UI is managed by QT. We're stuck in 3.x, so the new QGLPixelBuffer is not an option. I tried renderPixmap() method of a temporarily created QGLWidget but it always shot blanks. I thought I'd give some low-level calls a try.

So please, what's the circa 2004-2005 solution?

Zengar
04-07-2008, 12:42 PM
GeforceFX was released in 2003 and it supports FBO. Atually, all cards released after 2003-2004 should support FBOs with the recent drivers. Also, I fail to see how your Quadro can't support pbuffers, because all Nvidia cards of that generation and earlier generations support them.

So my advice: use FBOs.

zed
04-07-2008, 04:15 PM
you could also render it to the main window + then use
glCopyTexSubImage2d(...) to update the texture, this will work provided the texture is smaller than the window with 72x72 pixels this wont be a problem
afterwards u can either clear the screen or just draw CAD application over the top thus the user wont actually see the texture creation phase onscreen during runtime

Zengar
04-07-2008, 05:02 PM
Yes, but that may not work if the window is only partially visible.

ProsperLOADED
04-08-2008, 05:07 AM
I'm quite sure the Quadro FX 570 does support the WGL_ARB_pbuffer extension. Maybe you looked for it in the OpenGL extension list ? It's an WGL extension, not an OpenGL one, so you should find it with the wglGetExtensionsStringARB function.

Duncan Champney
04-10-2008, 02:14 PM
I'm working on a CAD application. I want to create icons that demo various texture map configurations. For a given combination of texture maps, material and color, I want to demo it by rendering a sphere with simple lighting onto a icon (maybe 72x72 pixels), capture that image and use it as an icon associated with the texture/material "bundle".

So, I want the rendering to happen off-screen. The image size and the geometry are tiny; also, this will happen typically a mere 0-12 times during a session, so worrying about performance is not an issue.

My requirements include satisfying an existing customer base. This is not a "you wanna play my new game, you gotta buy new hardware" situation. Many users will be running this on laptops that are more than 2 years old.

I'm somewhat shocked to find that pbuffers may not be the solution. For example, my NVidia Quadro FX 540 does not support the WGL_ARB_pbuffer extension--and GL_ARB_pixel_buffer_object doesn't seem to be useful for my purpose (please tell me I'm wrong). Meanwhile, framebuffers via GL_EXT_framebuffer_object are clearly too new for many my customers (right?). Is there a common extension I'm overlooking?

Our UI is managed by QT. We're stuck in 3.x, so the new QGLPixelBuffer is not an option. I tried renderPixmap() method of a temporarily created QGLWidget but it always shot blanks. I thought I'd give some low-level calls a try.

So please, what's the circa 2004-2005 solution?


I had a similar need. I wanted to render a scene larger than the screen, and couldn't rely on FBOs being available. What I did was to draw to the back buffer, then make the back buffer the source for glReadPixels, and read the results from the back buffer. For my application I render multiple tiles and assemble them into a larger image. Your problem is much simpler.

I called glDrawBuffer(GL_BACK) to target the back buffer for drawing, and glReadBuffer(GL_BACK) to make the back buffer the source for glReadPixels.

Do you need your icon in main memory, or on the video hardware?
glReadPixels reads pixel data from video memory into main memory. If you want to copy your pixels to a target on the graphics hardware, use glCopyPixels instead.

CRasterImage
04-10-2008, 11:45 PM
GeforceFX was released in 2003 and it supports FBO. Atually, all cards released after 2003-2004 should support FBOs with the recent drivers. Also, I fail to see how your Quadro can't support pbuffers, because all Nvidia cards of that generation and earlier generations support them.

So my advice: use FBOs.


I advise against using FBOs, if you wish your program to be used by the general public. Too many computers out there are using Intel's integrated graphics chip crap. Which doesn't support FBOs.

They do support PBuffers, though.

F**king Bastards.

arekkusu
04-11-2008, 01:40 AM
Intel integrated drivers do support FBO, on Mac OS X. Also GLSL.

rockeye
04-11-2008, 08:19 AM
I'm working on a CAD application.


Too many computers out there are using Intel's integrated graphics chip crap. Which doesn't support FBOs.

I am also working on several CAD products and our clients are forced to own a "real" graphic card (Ati or Nvidia). If you want your soft to runs softly on all hardware configurations, from 10-years old PC to high-end, you will blow your head and your code... Clients who can afford a $1000 (often much more) software can buy a $100 gpu every 4 years...

I advise you to use FBO too.