Problems with creating pbuffer
I'm trying to create a pixel buffer, but for some reason it keeps failing on me. What I'm doing is very basic:
NSOpenGLPixelBuffer *pbuffer = [[NSOpenGLPixelBuffer alloc] initWithTextureTarget:GL_TEXTURE_2D textureInternalFormat:GL_RGBA textureMaxMipMapLevel:0 pixelsWide:width pixelsHigh:height];
Width and height are 640 and 480 and I'm able to confirm that via a printf.
The return from this call is always nil for reasons that I don't quite understand.
Running 10.3.7 on a Powerbook G4 1.25 if that help any.
NSOpenGLPixelBuffer *pbuffer = [[NSOpenGLPixelBuffer alloc] initWithTextureTarget:GL_TEXTURE_2D textureInternalFormat:GL_RGBA textureMaxMipMapLevel:0 pixelsWide:width pixelsHigh:height];
Width and height are 640 and 480 and I'm able to confirm that via a printf.
The return from this call is always nil for reasons that I don't quite understand.
Running 10.3.7 on a Powerbook G4 1.25 if that help any.
GL_TEXTURE_2D's dimensions have to be powers of two. You'll need to either change 640x480 to 1024x512 (or 512x512 if you can afford to lose a bit of width), or use GL_TEXTURE_RECTANGLE_EXT, which loses you Rage 128 support.
- Alex Diener
- Alex Diener
Keep in mind if you use GL_TEXTURE_RECTANGLE_EXT you also lose mipmap and wrapping support.
Hmmm, that seems so strange though that I would lose all this functionality just to get a pbuffer that isn't pow(2), but if that's what it takes to make the code actually work
arekkusu Wrote:Keep in mind if you use GL_TEXTURE_RECTANGLE_EXT you also lose mipmap and wrapping support.
Does this mean I lose it for everything in my entire application? If so, is there a way to render in a headless manner that wouldn't result in this?
You only loose it for rectangle targets. Of course you can mix and match 1D, 2D, 3D, rectangle, and cube textures in an app.
If all you want is an accelerated offscreen window, there is an alternative to pbuffers. Make a window containing a GLview and just never show the window. The dimensions can be whatever you want.
But if you want to use that surface as a texture either the dimensions need to be POT, or you have to use rectangle textures (or stitch a few POT textures, or just waste texture space and render in a portion of a bigger POT texture.) None of the options are great if you require mipmaps.
If all you want is an accelerated offscreen window, there is an alternative to pbuffers. Make a window containing a GLview and just never show the window. The dimensions can be whatever you want.
But if you want to use that surface as a texture either the dimensions need to be POT, or you have to use rectangle textures (or stitch a few POT textures, or just waste texture space and render in a portion of a bigger POT texture.) None of the options are great if you require mipmaps.
Well basically what I'm doing is creating a PBuffer that will be transferred to another language (Java in this case) as a rectangular array of pixels to be displayed as an image. So what I want to do is render to the PBuffer all of my geometry, call glReadPixels (or similar), dump those pixels in a Java BufferedImage and rinse repeat every so often.
An offscreen window (of NPOT dimensions) will work fine in this case. Just don't expect blazing performance with glReadPixels.
I'll talk to the architecture folks about this as it wouldn't be a proper pBuffer binding in that particular case and the project I'm updating is a Java OpenGL binding (LWJGL in particular). I think that replacing the NSOpenGLPixelBuffer with a GLView may be more performant in this case, but may actually be architecturally wrong.
From a performance perspective I don't really expect blazing performance - just adequate performance for something that will be house inside a Java Swing container. The rest of the system uses native drawing and is more than fast, so this is more to appease a particular set of requirements (tools that use AWT/Swing) than it is anything else.
I'll check back though. Thanks a bunch for the assist.
From a performance perspective I don't really expect blazing performance - just adequate performance for something that will be house inside a Java Swing container. The rest of the system uses native drawing and is more than fast, so this is more to appease a particular set of requirements (tools that use AWT/Swing) than it is anything else.
I'll check back though. Thanks a bunch for the assist.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| pbuffer blending problem on macmin g4 | madjerry | 4 | 3,258 |
Nov 27, 2009 03:14 AM Last Post: madjerry |
|
| Pbuffer problems on Intel NVIDIA GeForce 7300 GT | NYGhost | 5 | 3,720 |
Oct 26, 2006 09:39 AM Last Post: NYGhost |
|
| pBuffer - how to draw in it, then display it? | taojones | 0 | 2,099 |
Nov 13, 2005 09:54 AM Last Post: taojones |
|
| PBuffer & Render to Texture (read & write) | habicht | 4 | 3,428 |
Feb 7, 2005 05:33 PM Last Post: habicht |
|

