Large Offscreen Buffer Needed!!
Author
I am trying to render (non-realtime) a high quality image that is Not visible so that I can read it in and save it. I am running on windows and want it to be hardware accelerated so I can not use the DIB (Device independent Bitmap) option. Currently I use:
TempData->winClass.lpszClassName = "MY_WINDOWS_REAL3D";
TempData->winClass.cbSize = sizeof(WNDCLASSEX);
TempData->winClass.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC;
TempData->winClass.lpfnWndProc = WindowProc;
TempData->winClass.hInstance = me;
TempData->winClass.hIcon = NULL;
TempData->winClass.hIconSm = NULL;
TempData->winClass.hCursor = NULL;
TempData->winClass.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH);
TempData->winClass.lpszMenuName = NULL;
TempData->winClass.cbClsExtra = 0;
TempData->winClass.cbWndExtra = 0;
if( !RegisterClassEx(&TempData->winClass) )
int cc = 10; // ADD FAIL CODE HERE
TempData->g_hWnd = CreateWindowEx( NULL, "MY_WINDOWS_REAL3D",
"Soon To Be Offscreen",
NULL,
0, 0, 640, 480, NULL, NULL, me, NULL );
This creates a window offscreen, but it causes problems because it cuts of the edges due to the boarder and the title bar so I have to center it in the window. I am also limited to around a 1024x1024 area. Are there any workarounds to this which would be easier that would still allow hardware acceleration? Will I have to tile the image to get it bigger?
Depends on how large you need to go. You can use the OpenGLFrame Buffer Object extension to do offscreen, hardware accelerated rendering. There is a limit to the size, and it depends on the hardware, but it is usually quite large (usually 4096x4096, though I have seen 8192x8192 on some newer hardware). If you need to go larger than your hardware will support, you can just render multiple passes into the FBO and then manually stitch the images together in a huge buffer you keep in system memory. The stitching will not be accelerated by you GPU of course, but the rendering would still be.
Author
I am running a machine with OpenGL 1.4. I am looking through my extensions, but I don't see anything that looks like this. Did this come along in a later version?
FBO extension was written against the OpengGL 1.5 spec. OpenGL is implemented in your video card driver, so if you can update the driver you should get a newer version of OpenGL, hopefully with FBO support. What OS and what GPU are you using?
Author
CodeMunkie,
Thanks for your help so far!
My OpenGL specs are,
OpenGL Driver Info
==================
Vendor: Intel
Version: 1.4.0 - Build 4.14.10.4609
Renderer: Intel 915GM
I realize this is a very crappy Intel integrated graphics chip, but I am creating this product to sell and need to keep this compatible with as many computers as possible. Is there any other way to render offscreen (without aux buffers because my card does not have them)? As I said before, creating an invisible window and rendering and then calling glReadPixels works... it just becomes unstable when closing due to some issues in destroying the window. Is there a way to just grab a DC for the window?
-DJ
Thanks for your help so far!
My OpenGL specs are,
OpenGL Driver Info
==================
Vendor: Intel
Version: 1.4.0 - Build 4.14.10.4609
Renderer: Intel 915GM
I realize this is a very crappy Intel integrated graphics chip, but I am creating this product to sell and need to keep this compatible with as many computers as possible. Is there any other way to render offscreen (without aux buffers because my card does not have them)? As I said before, creating an invisible window and rendering and then calling glReadPixels works... it just becomes unstable when closing due to some issues in destroying the window. Is there a way to just grab a DC for the window?
-DJ
Yeah, intel, tough luck. Another way then is to instruct OpenGL to write directly to a DIB surface. You will still have a size limitation, but you can do the stitching like I mentioned. You just need to set up your PIXELFORMATDESCRIPTOR with the PFD_DRAW_TO_BITMAP option, then you should be able to create an HBITMAP, attach it to your window's DC, and then read the DIB out of the HBITMAP, stitch it into your monster buffer, and finally save the monster buffer out to file when the rendering is complete. It would be pretty messy if I tried to post all of the code to do that, and to be honest I have not had to use that method in a long time, but it should work with your old hardware, since this is the way we used to have to do it "way back when". If you do some searching on PFD_DRAW_TO_BITMAP you should stumble across example code that renders to a memory buffer and then retrieves the DIB section of the DC's bitmap.
Author
Yeah, this is the workaround I originally went with. The problem is that this causes the system to revert to software rendering which kill performance, especially with textures. I'll have to read into my host app SDK and see if I can't find a way to extract a DC out of it. If you've got any more idea's, let me know. Thanks!
-DJ
-DJ
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
