Thread: [PyOpenGL-Users] bug in glDrawBuffers?
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-users
|
From: Gijs <in...@bo...> - 2009-02-15 16:48:30
|
Hello List,
I am trying to use glDrawBuffers to render to multiple textures using
shaders. However, I'm running into a problem (otherwise I wouldn't be
posting here ofcourse :) ). When I call glDrawBuffers with *any*
buffer-type, it fails with the following error:
File
"/Library/Python/2.5/site-packages/OpenGL/platform/baseplatform.py",
line 275, in __call__
return self( *args, **named )
File "/Library/Python/2.5/site-packages/OpenGL/error.py", line 194, in
glCheckError
baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1280,
description = 'invalid enumerant',
baseOperation = glDrawBuffers,
cArguments = (
1,
[
GL_COLOR_ATTACHMENT0_EXT
],
)
)
This is ofcourse just an example but I want to use it to enable 8
buffers (the maximum that is supported by my card). When I call
glDrawBuffer with GL_COLOR_ATTACHMENT0_EXT it does work so I know it
*should* work. I am using python 2.5.1 and Mac OS X 10.5. Below is part
of my test-render code for 3 buffers:
glUseProgram(p_multiple_output)
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, b_multiple_output)
glActiveTexture(GL_TEXTURE0)
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, int(input_images[0]))
glActiveTexture(GL_TEXTURE1)
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, int(input_images[1]))
glActiveTexture(GL_TEXTURE2)
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, int(input_images[2]))
glActiveTexture(GL_TEXTURE0)
drawingBuffers = list([GL_COLOR_ATTACHMENT0_EXT,
GL_COLOR_ATTACHMENT1_EXT, GL_COLOR_ATTACHMENT2_EXT])
glDrawBuffers(3, drawingBuffers)
glCallList(quadid)
Hope someone knows what's going on under the hood.
Regards
|
|
From: Mike C. F. <mcf...@vr...> - 2009-02-17 23:05:12
|
Gijs wrote:
> Hello List,
>
> I am trying to use glDrawBuffers to render to multiple textures using
> shaders. However, I'm running into a problem (otherwise I wouldn't be
> posting here ofcourse :) ). When I call glDrawBuffers with *any*
> buffer-type, it fails with the following error:
>
Can you add this to tests/test.py and then alter it with fragments of
your usage/code until it shows your error:
def test_glDrawBuffers_list_valid( self ):
"""Test that glDrawBuffers with list argument where value is set"""
fbo = glGenFramebuffersEXT(1)
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
try:
img1,img2 = glGenTextures(2)
for img in img1,img2:
glBindTexture( GL_TEXTURE_2D, img )
glTexImage2D(
GL_TEXTURE_2D, 0, GL_RGB8,
300, 300, 0, GL_RGB,
GL_INT,
None # no data transferred
)
glFramebufferTexture2DEXT(
GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT,
GL_TEXTURE_2D, img1, 0
)
glFramebufferTexture2DEXT(
GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT1_EXT,
GL_TEXTURE_2D, img2, 0
)
drawingBuffers = [
GL_COLOR_ATTACHMENT0_EXT,
GL_COLOR_ATTACHMENT1_EXT,
]
glDrawBuffers(2, drawingBuffers )
finally:
glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 )
then send back the error-ing version so that I can look into what's
going wrong without having to guess too much?
> Hope someone knows what's going on under the hood.
>
I *think* this should be working, I haven't had time to sit down and do
shadow-casting myself, so I don't have any real-world code to test it.
The code is pretty much just passing your values off to the C code, so
there's not a lot under the hood that's PyOpenGL specific.
HTH,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Gijs <in...@bs...> - 2009-02-18 09:39:57
|
Mike C. Fletcher wrote:
> Gijs wrote:
>> Hello List,
>>
>> I am trying to use glDrawBuffers to render to multiple textures using
>> shaders. However, I'm running into a problem (otherwise I wouldn't be
>> posting here ofcourse :) ). When I call glDrawBuffers with *any*
>> buffer-type, it fails with the following error:
>>
> Can you add this to tests/test.py and then alter it with fragments of
> your usage/code until it shows your error:
>
> def test_glDrawBuffers_list_valid( self ):
> """Test that glDrawBuffers with list argument where value is set"""
> fbo = glGenFramebuffersEXT(1)
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
> try:
> img1,img2 = glGenTextures(2)
> for img in img1,img2:
> glBindTexture( GL_TEXTURE_2D, img )
> glTexImage2D(
> GL_TEXTURE_2D, 0, GL_RGB8,
> 300, 300, 0, GL_RGB,
> GL_INT,
> None # no data transferred
> )
> glFramebufferTexture2DEXT(
> GL_FRAMEBUFFER_EXT,
> GL_COLOR_ATTACHMENT0_EXT,
> GL_TEXTURE_2D, img1, 0
> )
> glFramebufferTexture2DEXT(
> GL_FRAMEBUFFER_EXT,
> GL_COLOR_ATTACHMENT1_EXT,
> GL_TEXTURE_2D, img2, 0
> )
> drawingBuffers = [
> GL_COLOR_ATTACHMENT0_EXT,
> GL_COLOR_ATTACHMENT1_EXT,
> ]
> glDrawBuffers(2, drawingBuffers )
> finally:
> glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 )
>
> then send back the error-ing version so that I can look into what's
> going wrong without having to guess too much?
>> Hope someone knows what's going on under the hood.
>>
> I *think* this should be working, I haven't had time to sit down and do
> shadow-casting myself, so I don't have any real-world code to test it.
> The code is pretty much just passing your values off to the C code, so
> there's not a lot under the hood that's PyOpenGL specific.
>
> HTH,
> Mike
>
Hello Mike,
Thanks for your reply. I needed to cast some arguments (img, fbo) to int
and after that the code ran just fine, but the error remains (pasted
below). Also, I made a Python-C module to see whether the same error
would occur there. But with the exact same code in C, I could call
glDrawBuffers to draw to multiple buffers without any problems. So even
though the Python code should not really do much with the call, it does
something to mess it up.
Traceback (most recent call last):
File "./multiple-output.py", line 201, in <module>
test_glDrawBuffers_list_valid()
File "./multiple-output.py", line 197, in test_glDrawBuffers_list_valid
glDrawBuffers(2, drawingBuffers)
File
"/Library/Python/2.5/site-packages/OpenGL/platform/baseplatform.py",
line 275, in __call__
return self( *args, **named )
File "/Library/Python/2.5/site-packages/OpenGL/error.py", line 194, in
glCheckError
baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1280,
description = 'invalid enumerant',
baseOperation = glDrawBuffers,
cArguments = (
2,
[
GL_COLOR_ATTACHMENT0_EXT,
GL_COLOR_ATTACHMENT1_EXT
],
)
)
Regards,
Gijs
|
|
From: Mike C. F. <mcf...@vr...> - 2009-02-18 16:20:28
|
Gijs wrote: ... > I was running 3.0.0b8 and after I upgraded to the latest version, > 3.0.0c1, the glDrawBuffers call worked perfectly :). The casting was > however still required. The type fbo was <type 'numpy.uint32'>. It > failed with: ... > ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong > type > > I tend to cast everything that needs to be passed to OpenGL and is > returned from OpenGL functions (like the genTextures and > genFramebuffers function). Guess I kinda got used to it but I knew it > wasn't normal. Okay, that would seem to be final confirmation that we have bugs in handling of numpy uints on 32-bit platforms. Luckily we now have a test-case I can run to provoke it :) . Thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Mike C. F. <mcf...@vr...> - 2009-02-22 04:43:09
|
Mike C. Fletcher wrote: > Gijs wrote: > ... > ... > >> ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong >> type >> >> I tend to cast everything that needs to be passed to OpenGL and is >> returned from OpenGL functions (like the genTextures and >> genFramebuffers function). Guess I kinda got used to it but I knew it >> wasn't normal. >> > Okay, that would seem to be final confirmation that we have bugs in > handling of numpy uints on 32-bit platforms. Luckily we now have a > test-case I can run to provoke it :) . > Can you confirm that the machine exhibiting the problem is running something less than Python 2.5.2? I can duplicate the effect on my 32-bit Vista machine *only* if I downgrade to 2.5.1. Thinking back on it, this must be the bug that we discovered which had us add the ALLOW_NUMPY_SCALARS flag to the OpenGL.__init__ module. Thomas had said he was intending to fix it in ctypes, and it looks like he did just that in 2.5.2. 2.5.4 does not exhibit the problem. Assuming that you can confirm it seems we'll either have to tell people to use >= 2.5.2 and/or document the use of ALLOW_NUMPY_SCALARS for those weird cases where for some reason someone needs to use an older version. Will need to test with Python 2.4 and/or stand-alone ctypes to determine the versions to recommend. Thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Mike C. F. <mcf...@vr...> - 2009-02-18 14:28:05
|
Gijs wrote: ... > Hello Mike, > > Thanks for your reply. I needed to cast some arguments (img, fbo) to > int and after that the code ran just fine, but the error remains > (pasted below). Also, I made a Python-C module to see whether the same > error would occur there. But with the exact same code in C, I could > call glDrawBuffers to draw to multiple buffers without any problems. > So even though the Python code should not really do much with the > call, it does something to mess it up. Hmm, you *shouldn't* have to cast arguments, that code ran without errors on my machine. Can you confirm that you're running PyOpenGL 3.0.0c1? Also, do you have numpy installed? (Default array return value is numpy arrays). If you can print or pdb at the failing point and tell me precisely what types the values are, it may be that on your platform we're hitting a different code-path than on amd64-linux. Thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Gijs <in...@bs...> - 2009-02-18 15:04:29
|
On 2/18/09 3:28 PM, Mike C. Fletcher wrote:
> Gijs wrote:
> ...
>> Hello Mike,
>>
>> Thanks for your reply. I needed to cast some arguments (img, fbo) to
>> int and after that the code ran just fine, but the error remains
>> (pasted below). Also, I made a Python-C module to see whether the same
>> error would occur there. But with the exact same code in C, I could
>> call glDrawBuffers to draw to multiple buffers without any problems.
>> So even though the Python code should not really do much with the
>> call, it does something to mess it up.
> Hmm, you *shouldn't* have to cast arguments, that code ran without
> errors on my machine. Can you confirm that you're running PyOpenGL
> 3.0.0c1? Also, do you have numpy installed? (Default array return
> value is numpy arrays). If you can print or pdb at the failing point
> and tell me precisely what types the values are, it may be that on your
> platform we're hitting a different code-path than on amd64-linux.
>
> Thanks,
> Mike
>
I was running 3.0.0b8 and after I upgraded to the latest version,
3.0.0c1, the glDrawBuffers call worked perfectly :). The casting was
however still required. The type fbo was <type 'numpy.uint32'>. It
failed with:
Traceback (most recent call last):
File "./test-buffers.py", line 35, in <module>
test_glDrawBuffers_list_valid()
File "./test-buffers.py", line 20, in test_glDrawBuffers_list_valid
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
File
"/Library/Python/2.5/site-packages/OpenGL/platform/baseplatform.py",
line 275, in __call__
return self( *args, **named )
ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type
I tend to cast everything that needs to be passed to OpenGL and is
returned from OpenGL functions (like the genTextures and genFramebuffers
function). Guess I kinda got used to it but I knew it wasn't normal.
Regards,
Gijs
|
|
From: Gijs <in...@bs...> - 2009-02-18 15:14:39
|
On 2/18/09 4:04 PM, Gijs wrote: > On 2/18/09 3:28 PM, Mike C. Fletcher wrote: >> Gijs wrote: >> ... >>> Hello Mike, >>> >>> Thanks for your reply. I needed to cast some arguments (img, fbo) to >>> int and after that the code ran just fine, but the error remains >>> (pasted below). Also, I made a Python-C module to see whether the same >>> error would occur there. But with the exact same code in C, I could >>> call glDrawBuffers to draw to multiple buffers without any problems. >>> So even though the Python code should not really do much with the >>> call, it does something to mess it up. >> Hmm, you *shouldn't* have to cast arguments, that code ran without >> errors on my machine. Can you confirm that you're running PyOpenGL >> 3.0.0c1? Also, do you have numpy installed? (Default array return >> value is numpy arrays). If you can print or pdb at the failing point >> and tell me precisely what types the values are, it may be that on your >> platform we're hitting a different code-path than on amd64-linux. >> >> Thanks, >> Mike >> > I was running 3.0.0b8 and after I upgraded to the latest version, > 3.0.0c1, the glDrawBuffers call worked perfectly :). The casting was > however still required. The type fbo was<type 'numpy.uint32'>. It > failed with: > Traceback (most recent call last): > File "./test-buffers.py", line 35, in<module> > test_glDrawBuffers_list_valid() > File "./test-buffers.py", line 20, in test_glDrawBuffers_list_valid > glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo) > File > "/Library/Python/2.5/site-packages/OpenGL/platform/baseplatform.py", > line 275, in __call__ > return self( *args, **named ) > ctypes.ArgumentError: argument 2:<type 'exceptions.TypeError'>: wrong type > > I tend to cast everything that needs to be passed to OpenGL and is > returned from OpenGL functions (like the genTextures and genFramebuffers > function). Guess I kinda got used to it but I knew it wasn't normal. > > Regards, > > Gijs Oh, and yes, I have numpy installed. |
|
From: Gijs <in...@bs...> - 2009-02-22 15:02:02
|
On 2/22/09 5:43 AM, Mike C. Fletcher wrote: > Mike C. Fletcher wrote: >> Gijs wrote: > ... >> ... >>> ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: >>> wrong type >>> >>> I tend to cast everything that needs to be passed to OpenGL and is >>> returned from OpenGL functions (like the genTextures and >>> genFramebuffers function). Guess I kinda got used to it but I knew >>> it wasn't normal. >> Okay, that would seem to be final confirmation that we have bugs in >> handling of numpy uints on 32-bit platforms. Luckily we now have a >> test-case I can run to provoke it :) . > Can you confirm that the machine exhibiting the problem is running > something less than Python 2.5.2? I can duplicate the effect on my > 32-bit Vista machine *only* if I downgrade to 2.5.1. Thinking back on > it, this must be the bug that we discovered which had us add the > ALLOW_NUMPY_SCALARS flag to the OpenGL.__init__ module. Thomas had > said he was intending to fix it in ctypes, and it looks like he did > just that in 2.5.2. 2.5.4 does not exhibit the problem. > > Assuming that you can confirm it seems we'll either have to tell > people to use >= 2.5.2 and/or document the use of ALLOW_NUMPY_SCALARS > for those weird cases where for some reason someone needs to use an > older version. Will need to test with Python 2.4 and/or stand-alone > ctypes to determine the versions to recommend. > > Thanks, > Mike > It's running Python 2.5.1. It is the standard version of Python that got delivered with Mac OS X 10.5. So unless people upgraded to a higher version of Python, it should affect everyone that's running Mac OS X 10.5. Regards, Gijs |
|
From: René D. <re...@gm...> - 2009-03-20 06:44:55
|
Hi, I tried with python2.5.2 (preinstalled python) and python2.5.4 on osx 10.5.6 and it fails with both. I made a small pyrex wrapper of the functions, and dropped them into the test, and they worked. So I'm guessing it's a ctypes issue of some sort maybe. cu, On Mon, Feb 23, 2009 at 2:01 AM, Gijs <in...@bs...> wrote: > On 2/22/09 5:43 AM, Mike C. Fletcher wrote: >> Mike C. Fletcher wrote: >>> Gijs wrote: >> ... >>> ... >>>> ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: >>>> wrong type >>>> >>>> I tend to cast everything that needs to be passed to OpenGL and is >>>> returned from OpenGL functions (like the genTextures and >>>> genFramebuffers function). Guess I kinda got used to it but I knew >>>> it wasn't normal. >>> Okay, that would seem to be final confirmation that we have bugs in >>> handling of numpy uints on 32-bit platforms. Luckily we now have a >>> test-case I can run to provoke it :) . >> Can you confirm that the machine exhibiting the problem is running >> something less than Python 2.5.2? I can duplicate the effect on my >> 32-bit Vista machine *only* if I downgrade to 2.5.1. Thinking back on >> it, this must be the bug that we discovered which had us add the >> ALLOW_NUMPY_SCALARS flag to the OpenGL.__init__ module. Thomas had >> said he was intending to fix it in ctypes, and it looks like he did >> just that in 2.5.2. 2.5.4 does not exhibit the problem. >> >> Assuming that you can confirm it seems we'll either have to tell >> people to use >= 2.5.2 and/or document the use of ALLOW_NUMPY_SCALARS >> for those weird cases where for some reason someone needs to use an >> older version. Will need to test with Python 2.4 and/or stand-alone >> ctypes to determine the versions to recommend. >> >> Thanks, >> Mike >> > It's running Python 2.5.1. It is the standard version of Python that got > delivered with Mac OS X 10.5. So unless people upgraded to a higher > version of Python, it should affect everyone that's running Mac OS X 10.5. > > Regards, Gijs > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
|
From: Gijs <in...@bs...> - 2009-03-20 08:27:03
|
On 3/20/09 7:44 AM, René Dudfield wrote: > Hi, > > I tried with python2.5.2 (preinstalled python) and python2.5.4 on osx > 10.5.6 and it fails with both. > > I made a small pyrex wrapper of the functions, and dropped them into > the test, and they worked. So I'm guessing it's a ctypes issue of > some sort maybe. > > > cu, What kind of version do you have of PyOpenGL? I'm running Python 2.5.4 and PyOpenGL 3.0.0c1 and that works perfectly without any extra work. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X