pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] PyOpenGL3.0.0c1 - Python 2.6 - numpy1.2.1

[Mike C. F. <mcf...@vr...>]

Faudot Timothe wrote:
> Hello,
>
> I've been using opengl with c++ for quite a while now and as my interest 
> went to python recently I must say that pyopengl is a lifesaver, thanks 
> for the great job!
>
> I am however confronted with a small error that annoys me...
>
> whenever I try to put lights on my scenes (using glLightModelfv for 
> instance), I get an import error, which should not occurs imoo... The 
> errors talks about Numeric which is not present in my system, of course 
> it isn't! I have numpy, not Numeric which is long dead...
>   
Something in your configuration has set the logging level for 
OpenGL.formathandler all the way up to INFO (rather than the default of 
WARN).  You can either configure logging for the "OpenGL.formathandler" 
logger down to WARN again, or set OpenGL.WARN_ON_FORMAT_UNAVAILABLE to 
False.
> Any ideas of where does this comes from?
> Thanks a lot.
>   
It's from the FormatHandler class' plugin mechanism, intended to warn 
you if a format plug-in is missing during development.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] passing multiple values to glUniform

[Mike C. F. <mcf...@vr...>]

Gijs wrote:
> Hello,
>
> I'm kinda running into a problem here using the glUniform functions. I 
> use the following piece of code to set 8 values in the fragment shader:
> input_image  = glGetUniformLocationARB(program, "input_image")
> glUniform1ivARB(input_image, 8, array([0, 1, 2, 3, 4, 5, 6, 7], 'i'))
>   
There's a definite bug in the wrapper, it was written before I realized 
that you could pass multiple values to the vector forms.  In 
GL/ARB/shader_objects.py line 53, change "size" to None in the call and 
it *should* work.  I'll need to construct a test case and apply it to 
the 2.0 version as well, of course.

Thanks for the bug report,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] passing multiple values to glUniform

[Gijs <in...@bs...>]

Hello,

I'm kinda running into a problem here using the glUniform functions. I 
use the following piece of code to set 8 values in the fragment shader:
input_image  = glGetUniformLocationARB(program, "input_image")
glUniform1ivARB(input_image, 8, array([0, 1, 2, 3, 4, 5, 6, 7], 'i'))

When I use that piece of code, I get the following error:
glUniform1ivARB(input_image, 2, array([0, 1, 2, 3, 4, 5, 6, 7], 'i'))
   File "/Library/Python/2.5/site-packages/OpenGL/wrapper.py", line 
1273, in __call__
     return self.finalise()( *args, **named )
   File "/Library/Python/2.5/site-packages/OpenGL/wrapper.py", line 543, 
in wrapperCall
     pyArgs = tuple( calculate_pyArgs( args ))
   File "/Library/Python/2.5/site-packages/OpenGL/wrapper.py", line 328, 
in calculate_pyArgs
     yield converter(args[index], self, args)
   File 
"/Library/Python/2.5/site-packages/OpenGL/arrays/arrayhelpers.py", line 
41, in asArraySize
     incoming,
ValueError: ('Expected 1 item array, got 8 item array', array([0, 1, 2, 
3, 4, 5, 6, 7]), <function asArraySize at 0x6d79f0>)

Now I don't really understand what I'm doing wrong. Passing only one 
value works perfectly, but I'd rather pass the entire array at once 
instead of passing every single value.

(Python version 2.5.4, PyOpenGL version 3.0.0c1)

Regards, Gijs

[PyOpenGL-Users] PyOpenGL3.0.0c1 - Python 2.6 - numpy1.2.1

[Faudot T. <fau...@la...>]

Hello,

I've been using opengl with c++ for quite a while now and as my interest 
went to python recently I must say that pyopengl is a lifesaver, thanks 
for the great job!

I am however confronted with a small error that annoys me...

whenever I try to put lights on my scenes (using glLightModelfv for 
instance), I get an import error, which should not occurs imoo... The 
errors talks about Numeric which is not present in my system, of course 
it isn't! I have numpy, not Numeric which is long dead...

here is the error:
      INFO 2009-03-11 13:51:43,546 Unable to load registered array 
format handle
r numeric:
Traceback (most recent call last):
  File 
"c:\python26\lib\site-packages\pyopengl-3.0.0c1-py2.6.egg\OpenGL\arrays\f
ormathandler.py", line 74, in loadPlugin
    plugin_class = entrypoint.load()
  File 
"c:\python26\lib\site-packages\pyopengl-3.0.0c1-py2.6.egg\OpenGL\plugins.
py", line 14, in load
    return importByName( self.import_path )
  File 
"c:\python26\lib\site-packages\pyopengl-3.0.0c1-py2.6.egg\OpenGL\plugins.
py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File 
"c:\python26\lib\site-packages\pyopengl-3.0.0c1-py2.6.egg\OpenGL\arrays\n
umeric.py", line 15, in <module>
    raise ImportError( """No Numeric module present: %s"""%(err))
ImportError: No Numeric module present: No module named Numeric


Any ideas of where does this comes from?
Thanks a lot.

br

Re: [PyOpenGL-Users] glGenBuffers on Windows XP and Intel 82855

[Ontje L. <Th...@gm...>]

Hi Mike,

Am Donnerstag 05 März 2009 15:04:54 schrieb Mike C. Fletcher:
> Are you calling glGenBuffersARB, or glGenBuffers ?  Your driver likely
> only provides the extension-based entry point (the one with the ARB
> suffix).  See the OpenGL/arrays/vbo.py module for some code showing use
> of the "alternate" function to make using promoted extensions easier.
> Oh, it also provides a basic VBO wrapper as an array data-type.
I tried both glGenBuffersARB and glGenBuffers but without success. It seems that 
glGenBuffersARB is completely not available ( bool(GL.glGenBuffersARB) raises an 
AttributeError ) while calling glGenBuffers exhibits some strange behaviour:

 - bool(GL.glGenBuffers) == False
 - calling GL.glGenBuffers() with a wrong amount of arguments throws a 
ValueError which informs about the calling signature of that method. So I 
assume PyOpenGL must have gathered that information from somewhere.
 - However: Checking the method availability with bool(GL.glGenBuffers) returns 
False and calling the method with correct arguments throws a NullFunctionError 
telling me to check for the method :)

Thanks to your suggestions I looked into the vbo.py module and used the 
vertex_buffer_object from PyOpenGL.GL.ARB directly. This module exposes the 
*ARB variants of those methods and guess what: Those work as expected! Thank 
you :D

Is the vertex_buffer_object module the preferred way of using this extension?

Thanks,
Ontje

Re: [PyOpenGL-Users] glGenBuffers on Windows XP and Intel 82855

[Mike C. F. <mcf...@vr...>]

Ontje Lünsdorf wrote:
> Hi,
>
> I'm trying to use vertex buffer object on a laptop with an intel 82855 graphic 
> chipset. GL_EXTENSIONS contains GL_ARB_vertex_buffer_object and GLView reports 
> that the glGenBuffers function should be available.
> If I try to call the function PyOpenGL will raise the a NullFunctionError. 
> However if I don't specify the buffer count PyOpenGL will complain about a 
> missing argument for that function.
> The same code runs without any problems on a machine with a nvidia card.
>
> Is this a PyOpenGL, driver bug or am I missing something?
>   
Are you calling glGenBuffersARB, or glGenBuffers ?  Your driver likely 
only provides the extension-based entry point (the one with the ARB 
suffix).  See the OpenGL/arrays/vbo.py module for some code showing use 
of the "alternate" function to make using promoted extensions easier.  
Oh, it also provides a basic VBO wrapper as an array data-type.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Gijs <in...@bs...>]

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

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Mike C. F. <mcf...@vr...>]

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

Re: [PyOpenGL-Users] glGetTexImage weirdness

[Gijs <in...@bs...>]

On 2/19/09 6:02 PM, Mike C. Fletcher wrote:
> Gijs wrote:
> ...
>> Hmm ok, guess I'll use the array-functions then.
>>
>> Btw, when I use glGetTexImageub and I set the fragment shader to 
>> output 1/256 on every pixel, I get a 0 in every pixel instead of a 1. 
>> And every subsequent number returns the number-1, so 34/256 returns 
>> 33. Does this also have something to do with backwards compatibility?
> Nope, that sounds like a rounding or similar error to me.  PyOpenGL 
> doesn't really touch the data involved, just shuffles it from OpenGL 
> over to numpy/ctypes/strings/etc  It might be possible that it's doing 
> that translation wrong, but an off-by-one for all numbers isn't a 
> likely failure mode for the data translation process.
>
> If I understand what you are doing correctly, you wouldn't expect 
> 256/256 to produce a "256" in the result (max num is 255), so I'm 
> thinking you wanted your divisor one less?  What happens if you set 
> the operation to 1/255 or 34/255?  Even there you could see an 
> off-by-one with rounding errors and subsequent "floor" on the number, 
> but save for those you should be much closer to the number you expect.
>
> HTH,
> Mike
>
Well, the problem that I had was that I wanted to count all pixels of a 
specific color in the shader with the reduction-technique. Normally 
you'd think you just literally count all the pixels and add them 
together and have an answer. But in the case of 8 bit color channels, 
you cannot output any number higher than 1.0 (which you probably already 
knew), since it will just ceil it to 1.0. So I'd thought I'd set every 
pixel to 1/256 in the Red channel, if it's the correct color, and set it 
to 0 if it's not the correct color. By using the other color channels as 
a 2nd, 3rd and 4th "byte" I would be able to output a number (max of 
2^(4*8)) that I could translate back to its real value. Yesterday I 
found out I could have just used 32bit color channels, too bad I didn't 
know that beforehand.

You were right that it was a rounding-error, if I divide numbers by 255 
it would give me the correct number which I set beforehand in the 
shader. Guess I could have used 255 and adjust the calculations, but I 
solved the problem in the end by reading floats and multiplying them by 
256. This did give me the correct answer. So I guess that was a bug on 
my end.

Re: [PyOpenGL-Users] glGetTexImage weirdness

[Gijs <in...@bs...>]

On 2/19/09 5:42 PM, Mike C. Fletcher wrote:
> Gijs wrote:
> ...
>> data = glGetTexImageub(GL_TEXTURE_2D, 0, GL_RGBA)
>> print data
>> data = glGetTexImage(GL_TEXTURE_2D, 0, GL_RGBA, GL_UNSIGNED_BYTE)
>> print data
>>
>> As I expect that PyOpenGL would pass GL_UNSIGNED_BYTE to the
>> underlying function when I use glGetTexImageub, and that if I pass
>> the type myself directly, the result would be the same. But in the
>> first case I get a proper response, containing [[[97 97 97 97]]], and
>> the second I get a rather weird response "aaaa" (a string). In the
>> end it's of course quite easy to work around it, since you can just
>> use the glGetTexImageub function, but when I stumbled upon it, it
>> took me quite some time to find it since I assumed both would be the
>> same.
> It's a legacy compatibility feature requested to be re-instated by the
> Pygame folks.  See the flag:
>
>    UNSIGNED_BYTE_IMAGES_AS_STRING
>
> in the OpenGL/__init__.py module for how to go back to always getting
> back your "normal" array types.  IIRC some common function in the
> released versions of Pygame was using the function expecting a string
> back (PyOpenGL 2.x behaviour) and broke with 3.x returning the
> registered preferred array handler type.
>
> HTH,
> Mike
>
Hmm ok, guess I'll use the array-functions then.

Btw, when I use glGetTexImageub and I set the fragment shader to output 
1/256 on every pixel, I get a 0 in every pixel instead of a 1. And every 
subsequent number returns the number-1, so 34/256 returns 33. Does this 
also have something to do with backwards compatibility?

Re: [PyOpenGL-Users] glGetTexImage weirdness

[Mike C. F. <mcf...@vr...>]

Gijs wrote:
...
> data = glGetTexImageub(GL_TEXTURE_2D, 0, GL_RGBA)
> print data
> data = glGetTexImage(GL_TEXTURE_2D, 0, GL_RGBA, GL_UNSIGNED_BYTE)
> print data
>
> As I expect that PyOpenGL would pass GL_UNSIGNED_BYTE to the underlying 
> function when I use glGetTexImageub, and that if I pass the type myself 
> directly, the result would be the same. But in the first case I get a 
> proper response, containing [[[97 97 97 97]]], and the second I get a 
> rather weird response "aaaa" (a string). In the end it's of course quite 
> easy to work around it, since you can just use the glGetTexImageub 
> function, but when I stumbled upon it, it took me quite some time to 
> find it since I assumed both would be the same.
>   
It's a legacy compatibility feature requested to be re-instated by the 
Pygame folks.  See the flag:

    UNSIGNED_BYTE_IMAGES_AS_STRING

in the OpenGL/__init__.py module for how to go back to always getting 
back your "normal" array types.  IIRC some common function in the 
released versions of Pygame was using the function expecting a string 
back (PyOpenGL 2.x behaviour) and broke with 3.x returning the 
registered preferred array handler type.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] PyOpenGL, Numpy and 3.0

[Mike C. F. <mcf...@vr...>]

Rodney Stephenson wrote:
> This is more of a general question: where/how does Numpy fit into 
> PyOpenGl. There is the numpymodule and a few other references to numpy 
> around the place. Given that there is a lot to do to get Numpy to 2.6, 
> let alone 3.0, what is the long term strategy here?
>   
One of the big advantages of the PyOpenGL 3.x architecture is that it 
has the ability to use run-time pluggable data formats.  It currently 
can use:

    * Numpy arrays
    * ctypes pointers
    * ctypes arrays
    * strings
    * lists
    * tuples
    * VBO objects (written in Python in the module OpenGL/arrays/vbo.py )

So that it should be able to use whatever is available on the platform 
where it's running.  There's even a legacy Numeric format handler, 
though honestly I haven't got any setup for testing that it remains valid.

That said, a 2.6 port is likely to happen relatively soon (though I'm 
personally not really motivated to do it before numpy ports, as all of 
my own code is numpy-using).  The 2.6 port should be relatively trivial 
and we could likely be waiting for numpy on the other side without much 
effort.

3.x porting is going to take a while unless someone else wants to handle 
(and most importantly, maintain) it.  That's again just an interest 
thing.  I have close to 0 interest in Python 3.0 as a development 
platform, and the amount of work involved in porting to it easily swamps 
that level of interest.  I'm more likely to spend any extra time I find 
trying to get PyPy to work nicely with PyOpenGL code to produce (fast) 
executables, but realistically I don't often get that kind of extra 
time.  Maybe 3.0 will become more compelling at some point and I'll find 
my interest-level de-swamped, but I don't see a lot of movement that way.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] glGetTexImage weirdness

[Gijs <in...@bs...>]

Hello List,

I'm trying to find why glGetTexImage works the way it does. With the 
following piece of code, I expect both prints to be the same.

pixels = zeros(1*4, 'i') + 97
img = glGenTextures(1)
glBindTexture(GL_TEXTURE_2D, int(img))
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 1, 1, 0, GL_RGBA, 
GL_UNSIGNED_BYTE, pixels)

data = glGetTexImageub(GL_TEXTURE_2D, 0, GL_RGBA)
print data
data = glGetTexImage(GL_TEXTURE_2D, 0, GL_RGBA, GL_UNSIGNED_BYTE)
print data

As I expect that PyOpenGL would pass GL_UNSIGNED_BYTE to the underlying 
function when I use glGetTexImageub, and that if I pass the type myself 
directly, the result would be the same. But in the first case I get a 
proper response, containing [[[97 97 97 97]]], and the second I get a 
rather weird response "aaaa" (a string). In the end it's of course quite 
easy to work around it, since you can just use the glGetTexImageub 
function, but when I stumbled upon it, it took me quite some time to 
find it since I assumed both would be the same.

Regards,

Gijs

[PyOpenGL-Users] PyOpenGL, Numpy and 3.0

[Rodney S. <rod...@gm...>]

This is more of a general question: where/how does Numpy fit into 
PyOpenGl. There is the numpymodule and a few other references to numpy 
around the place. Given that there is a lot to do to get Numpy to 2.6, 
let alone 3.0, what is the long term strategy here?

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Mike C. F. <mcf...@vr...>]

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

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Gijs <in...@bs...>]

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.

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Gijs <in...@bs...>]

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

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Mike C. F. <mcf...@vr...>]

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

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Gijs <in...@bs...>]

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

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[Mike C. F. <mcf...@vr...>]

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

Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

[Joshua R. D. <jd...@ca...>]

Mike C. Fletcher" <mcf...@vr...> wrote:
> I'm able to run that code with my AMD64 Ubuntu machine using numpy 1.1.1 
> on Python 2.5.2 .  Can you print the *type* of framebuffer.  My guess is 
> that it's a numpy uint object (it is on my machine) and that for some 
> reason on your machine that type isn't getting properly registered as a 
> uint-compatible type (possibly a 64-bit versus 32-bit issue, maybe a 
> numpy version issue, or maybe numpy isn't on your machine and you're 
> getting something else entirely).

The type of framebuffer is <type 'numpy.uint32'>. But it appears that some combination of updating PyOpenGL to 3.0.0c1 and updating Python to 2.5.4 has fixed everything; no more problems. That'll teach me to use old versions. Thanks for your help.

Joshua Davis

Re: [PyOpenGL-Users] Please test PyOpenGL 3.0.0c1

[Mike C. F. <mcf...@vr...>]

Ben Smith wrote:
> "Alternate" platform, Win XP SP3.  bzr revision 67
>
> I don't have any pyopengl apps of my own to try out, but I figure I 
> may as well report what I get from running the tests.  I'm afraid I 
> haven't used pyopengl much, either, so pardon me if I make assumptions 
> about the code when I share a suggestion.
Thanks a lot for testing, very helpful.
> Python 2.5.1
>
> C:\mypathisasecret\pyopengl\tests>python tests.py
> ......No ARB imaging extension
> ...E...OpenGL 1.2 support
> .................
> ======================================================================
> ERROR: Test that we support framebuffer objects
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "tests.py", line 578, in test_fbo
>     glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
>   File 
> "c:\python25\Lib\site-packages\OpenGL\platform\baseplatform.py", line 
> 275, in __call__
>     return self( *args, **named )
> ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type
>
> ----------------------------------------------------------------------
> Ran 30 tests in 22.968s
>
> FAILED (errors=1)
This lends more strength to the idea that we've got a problem with 
32-bit platforms with some integer-like types.  Did you have numpy 
installed on 2.5.1?
> Python 2.6.0
>
> C:\mypathisasecret\pyopengl\tests>python26 tests.py
> Traceback (most recent call last):
>   File "tests.py", line 6, in <module>
>     from Numeric import *
> ImportError: No module named Numeric
>
> Obviously, in this case I don't have Numeric installed.  A few minutes 
> of monkeying around didn't get me a numeric install from pypi or build 
> from source in python 2.6.  This test maybe should be skipped for this 
> platform, for now, but I think it shouldn't stop the other tests from 
> running.  I don't know how much more is expected to work without numpy 
> and on python 2.6.
I've committed changes to the test suite so that it should skip all 
numpy-using tests if it can't import numpy.
> Python 3.0.0
>
> C:\mypathisasecret\pyopengl\tests>python30 tests.py
>   File "tests.py", line 5
>     except ImportError, err:
>                       ^
> SyntaxError: invalid syntax
>
> Probably smoother and more explicit to detect python 3000 and a 
> message about not supporting it. 
>
> I don't mind submitting some hack and slash editing to get around 
> these, or trying out any changes. 
Python 3.x is going to require an extremely *large* amount of work to 
support.  At this point I'm just not intending to work on 3.x support.  
Until there's some compelling reason for people to use 3.x I'm just too 
time-poor to be dedicating time to supporting it.  I guess in theory we 
could hack around it by having a separate test suite that's imported 
solely if we're not on 3.x, but it seems like too much machinery for 
what's essentially going to be a "you're running 3.x, we don't support 
that" message.  (3.x is going to fail, as you saw, even trying to 
compile the test module, so the driver script needs to be some hacked 
code that just checks for 3.x in a 3.x and 2.x compatible format and 
then does the import).

Thanks a lot for your tests,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

[Mike C. F. <mcf...@vr...>]

Joshua R. Davis wrote:
> ----- Original Message -----
> From: "Mike C. Fletcher" <mcf...@vr...>
> To: "Joshua R. Davis" <jd...@ca...>
> Cc: pyo...@li...
> Sent: Saturday, February 14, 2009 5:10:59 PM GMT -06:00 US/Canada Central
> Subject: Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes
>   
...
> Thanks a lot, Mike. I no longer crash when making multiple calls to glGenFramebuffersEXT(). However, I now crash on the first call to glBindFramebufferEXT(). This demo...
>   
...
>> python fbotest.py
>>     
> 1
> Traceback (most recent call last):
>   File "fbotest.py", line 14, in <module>
>     main()
>   File "fbotest.py", line 12, in main
>     glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, framebuffer)
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/platform/baseplatform.py", line 275, in __call__
>     return self( *args, **named )
> ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type
>
> This kind of code used to work, when I was using the DLL. Can anyone help?
>   
I'm able to run that code with my AMD64 Ubuntu machine using numpy 1.1.1 
on Python 2.5.2 .  Can you print the *type* of framebuffer.  My guess is 
that it's a numpy uint object (it is on my machine) and that for some 
reason on your machine that type isn't getting properly registered as a 
uint-compatible type (possibly a 64-bit versus 32-bit issue, maybe a 
numpy version issue, or maybe numpy isn't on your machine and you're 
getting something else entirely).

Thanks for the report, hopefully we can track down what's gone wrong here,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] Please test PyOpenGL 3.0.0c1

[Ben S. <gu...@gm...>]

"Alternate" platform, Win XP SP3.  bzr revision 67

I don't have any pyopengl apps of my own to try out, but I figure I may as
well report what I get from running the tests.  I'm afraid I haven't used
pyopengl much, either, so pardon me if I make assumptions about the code
when I share a suggestion.



Python 2.5.1

C:\mypathisasecret\pyopengl\tests>python tests.py
......No ARB imaging extension
...E...OpenGL 1.2 support
.................
======================================================================
ERROR: Test that we support framebuffer objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests.py", line 578, in test_fbo
    glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
  File "c:\python25\Lib\site-packages\OpenGL\platform\baseplatform.py", line
275, in __call__
    return self( *args, **named )
ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type

----------------------------------------------------------------------
Ran 30 tests in 22.968s

FAILED (errors=1)







Python 2.6.0

C:\mypathisasecret\pyopengl\tests>python26 tests.py
Traceback (most recent call last):
  File "tests.py", line 6, in <module>
    from Numeric import *
ImportError: No module named Numeric

Obviously, in this case I don't have Numeric installed.  A few minutes of
monkeying around didn't get me a numeric install from pypi or build from
source in python 2.6.  This test maybe should be skipped for this platform,
for now, but I think it shouldn't stop the other tests from running.  I
don't know how much more is expected to work without numpy and on python
2.6.



Python 3.0.0

C:\mypathisasecret\pyopengl\tests>python30 tests.py
  File "tests.py", line 5
    except ImportError, err:
                      ^
SyntaxError: invalid syntax

Probably smoother and more explicit to detect python 3000 and a message
about not supporting it.

I don't mind submitting some hack and slash editing to get around these, or
trying out any changes.

-b


On Sun, Feb 15, 2009 at 4:00 PM, René Dudfield <re...@gm...> wrote:

> Hi,
>
> here's how you can test pyopengl.
>
>
>
> 1. run the unittests.  There's not many that come with pyopengl...
>    python tests/tests.py
> 2. run your opengl programs unittests.
> 3. run your programs, and see if they work as expected.
>
>
> When finished, please email back here your results.
>
> Thanks!
>
>
>
> #=========
> #  here's how to download, build, install, and then test on unix
> (ubuntu, debian, osx, etc) if you have bzr installed
> (http://bazaar-vcs.org/).
>
> bzr branch lp:pyopengl
>
> cd pyopengl
> python setup.py build
> sudo python setup.py install
> python tests/tests.py
>
>
>
>
> #==========
> #  here's results for unittests on one machine.
>
> $ uname -a
> Linux macpro2-linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC
> 2009 x86_64 GNU/Linux
>
> $ python tests/tests.py
> ...........Warning: texture 2 residence expected 0 got 1
> ..OpenGL 1.2 support
> .................
> ----------------------------------------------------------------------
> Ran 30 tests in 8.440s
>
> OK
>
>
>
>
>
>
>
>
>
> On Sun, Feb 15, 2009 at 1:27 PM, Mike C. Fletcher
> <mcf...@vr...> wrote:
> > Hi all,
> >
> > I'm intending to release approximately the current trunk of PyOpenGL in
> > bzr as 3.0.0 final, barring any show-stopping bug reports.  So, if you
> > have show-stoppers that haven't been addressed, let me know.  The
> > 3.0.0c1 release is basically the same as the b8 release with a few bug
> > fixes and binary versions of GLUT and GLE32 for Win32 users.  Going
> > forward, I'm thinking I may focus much of my energy on getting developer
> > documentation and the like written so that more contributors can work on
> > the package.  At some point I'd also like to revisit the idea of
> > unifying the Pyglet and PyOpenGL generators so that we're able to avoid
> > duplication of effort somewhat.
> >
> > Downloads are available from:
> >
> >
> https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035
> >
> > Enjoy yourselves,
> > Mike
> >
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [PyOpenGL-Users] Please test PyOpenGL 3.0.0c1

[René D. <re...@gm...>]

Hi,

here's how you can test pyopengl.



1. run the unittests.  There's not many that come with pyopengl...
    python tests/tests.py
2. run your opengl programs unittests.
3. run your programs, and see if they work as expected.


When finished, please email back here your results.

Thanks!



#=========
#  here's how to download, build, install, and then test on unix
(ubuntu, debian, osx, etc) if you have bzr installed
(http://bazaar-vcs.org/).

bzr branch lp:pyopengl

cd pyopengl
python setup.py build
sudo python setup.py install
python tests/tests.py




#==========
#  here's results for unittests on one machine.

$ uname -a
Linux macpro2-linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC
2009 x86_64 GNU/Linux

$ python tests/tests.py
...........Warning: texture 2 residence expected 0 got 1
..OpenGL 1.2 support
.................
----------------------------------------------------------------------
Ran 30 tests in 8.440s

OK









On Sun, Feb 15, 2009 at 1:27 PM, Mike C. Fletcher
<mcf...@vr...> wrote:
> Hi all,
>
> I'm intending to release approximately the current trunk of PyOpenGL in
> bzr as 3.0.0 final, barring any show-stopping bug reports.  So, if you
> have show-stoppers that haven't been addressed, let me know.  The
> 3.0.0c1 release is basically the same as the b8 release with a few bug
> fixes and binary versions of GLUT and GLE32 for Win32 users.  Going
> forward, I'm thinking I may focus much of my energy on getting developer
> documentation and the like written so that more contributors can work on
> the package.  At some point I'd also like to revisit the idea of
> unifying the Pyglet and PyOpenGL generators so that we're able to avoid
> duplication of effort somewhat.
>
> Downloads are available from:
>
> https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035
>
> Enjoy yourselves,
> Mike
>