Thread: [PyOpenGL-Users] Reading Depth Component - not working anymore?
Brought to you by:
mcfletch
From: Hart's A. <bha...@ya...> - 2007-12-28 18:44:27
|
I am using the latest pyopengl (ctypes based) release for Ubuntu Gusty. I am unable to read the zbuffer using glreadpixels GL_DEPTH_COMPONENT, my function had worked before with the much older pyopengl2.x series. I'm not sure if this is a bug in new ctypes-pyopengl or is it my ATI drivers not supporting that feature. I'm wondering if anybody has had any luck doing this? One note is that i can read the zbuffer directly into a texture (for shadows) with no problem using glCopyTexSub2d. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |
From: Mike C. F. <mcf...@vr...> - 2007-12-28 18:55:52
|
Hart's Antler wrote: > I am using the latest pyopengl (ctypes based) release for Ubuntu Gusty. I am unable to read the > zbuffer using glreadpixels GL_DEPTH_COMPONENT, my function had worked before with the much older > pyopengl2.x series. I'm not sure if this is a bug in new ctypes-pyopengl or is it my ATI drivers > not supporting that feature. I'm wondering if anybody has had any luck doing this? One note is > that i can read the zbuffer directly into a texture (for shadows) with no problem using glCopyTexSub2d. > If you can send me a sample script that demonstrates the problem I can far more easily fix the bug. It does sound like a bug, incidentally. The image handling code is completely rewritten, so it's not unlikely there would be differences between the old and new implementations. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Hart's A. <bha...@ya...> - 2007-12-28 19:32:46
|
--- "Mike C. Fletcher" <mcf...@vr...> wrote: > Hart's Antler wrote: > > I am using the latest pyopengl (ctypes based) release for Ubuntu Gusty. I am unable to read > the > > zbuffer using glreadpixels GL_DEPTH_COMPONENT, my function had worked before with the much > older > > pyopengl2.x series. I'm not sure if this is a bug in new ctypes-pyopengl or is it my ATI > drivers > > not supporting that feature. I'm wondering if anybody has had any luck doing this? One note > is > > that i can read the zbuffer directly into a texture (for shadows) with no problem using > glCopyTexSub2d. > > > If you can send me a sample script that demonstrates the problem I can > far more easily fix the bug. It does sound like a bug, incidentally. > The image handling code is completely rewritten, so it's not unlikely > there would be differences between the old and new implementations. > i dont have a stripped down example, but the code is just 3 lines you can insert into any pyopengl demo. data = glReadPixels(0,0,x,y, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE) # note x,y are screen size img = Image.fromstring( 'L', (x,y), data ) # requires PIL img.save( 'z.bmp' ) # when you open z.bmp you will find that it is blank - all white. ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping |
From: Mike C. F. <mcf...@vr...> - 2007-12-29 23:40:26
|
Hart's Antler wrote: > --- "Mike C. Fletcher" <mcf...@vr...> wrote: > ... > i dont have a stripped down example, but the code is just 3 lines you can insert into any pyopengl > demo. > data = glReadPixels(0,0,x,y, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE) # note x,y are screen size > img = Image.fromstring( 'L', (x,y), data ) # requires PIL > img.save( 'z.bmp' ) # when you open z.bmp you will find that it is blank - all white. > I can reproduce the effect you are reporting if I have a large frustum where the near and far clipping plans are at .01 and 1000 respectively. If I bring those down so that the geometry is just bracketed by the clipping planes, the depth buffer "image" shows up as black for that touching the front clipping plane (lowest depth) and white for that touching the back clipping plane (highest depth). That is, the wrapper *seems* to be working fine (though the extremely high (.999+) values in the float mode with a large frustum surprise me, they *seem* to represent real depth values). The code I'm using to test is available in the CVS here: http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGLContext/tests/saveimage.py?view=markup You can see the commented-out code that uses GL_FLOAT type and maps the values to the 0-255 range using array operations as well. I'm open to the possibility that something is going wrong in the wrapper, but it *looks* like something unexpected in the GL, rather than something wrong with the wrapper. This URL http://www.opengl.org/resources/faq/technical/depthbuffer.htm would seem to suggest that the likely culprit for this kind of error is specifying a zNear which is too near to the camera. Hope this helps, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Hart's A. <bha...@ya...> - 2008-01-05 23:09:37
|
Hi Mike, sorry for the late reply, i just tried your saveimage.py but am unable to run it, it crashes with this error glibc detected *** python: free(): invalid pointer: 0x08860808 i'm using the latest release of OpenGLContext, i installed from source via python setup.py install - no errors i could see. I think my problem might be in Ubuntu, python2.5 in Gusty seems to crash pretty often. I did try adjusting to a narrower z-range as you suggest in my own tests, but that had no effect. I will test on a Nvida machine next week, maybe my problems are from the ATI drivers. -brett ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |