pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Chris B. - N. F. <chr...@no...>]

On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher
<mcf...@vr...> wrote:
> Actually ctypes *does* now support sized types:
>
>     ctypes.c_int8 ctypes.c_int16 ctypes.c_int32 ctypes.c_int64

cool! I didn't see that in the docs I was looking at...

> As for the original error, it *could* be that there's a problem with 64-bit
> windows there, but I'm a bit skeptical, as 64-bit Linux doesn't show any
> problems, and the test_core.py script actually generates a framebuffer
> during testing if glGenFrameBuffers is available.  That's my very first
> smoke-test for the build working on any platform.

well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and
Windows (MSVC) gives you 23 bits for an "int", or something like that
-- there is defiantly a difference in there somewhere (maybe it's
long?) Anyway, I think it sure could be a non-issue on LInux, and kill
you on windows.

-Chris


> Something to verify to debug the issue:
>
> the address printed out as the access violation is *precisely* the same as
> the result of ctypes.addressof( variable ) when doing the raw API query
>
> if we're looking at different values, then we likely have the wrapper wrong
> (i.e. somehow it is changing the value passed in), if they are the same,
> then there's something preventing the writing to that address... which I
> don't have much to contribute...
>
> HTH,
> Mike
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

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

On 13-04-04 11:55 AM, Chris Barker - NOAA Federal wrote:
> On Wed, Apr 3, 2013 at 10:24 AM, Cyrille Rossant
> <cyr...@gm...> wrote:
...
> well, that is a bigger-than-32bit address -- I suppose it's possible
> that this is a 32/64 bit issue.
>
> Can you test it with 32 bit python? Even if you don't want to
> ultimatley go that route, it may give you a hint.
>
> Also, from teh ctypes docs:
>
> c_uint	is a unsigned int
>
> you may have some issues there, an "int" is a really poorly defined
> type, and depending on the compiler, it may be 32 bits on 32bit
> systems, and 32 or 64 bit on 64 bit systems (and the MS compilers and
> gnu do it differently), so there couldn be some mis-match there.
>
> It's beyond me that C has survived this long with such soft defining
> of type sizes! Here's hoping that people start using the C99 defined
> size integer types sooner than later...
>
> (though from the looks of it, ctypes doesn't support those either...)
Actually ctypes *does* now support sized types:

     ctypes.c_int8 ctypes.c_int16 ctypes.c_int32 ctypes.c_int64

(this is on python 2.7.3 Linux 64-bit).  I actually am using them while 
working on the EGL wrapper, and will likely switch to using them on the 
GL level too (since e.g. GLint is explicitly 32-bit, *not* platform 
specific).
.
     ctypes.c_size_t

is also pretty useful, and I will likely use that as appropriate.

As for the original error, it *could* be that there's a problem with 
64-bit windows there, but I'm a bit skeptical, as 64-bit Linux doesn't 
show any problems, and the test_core.py script actually generates a 
framebuffer during testing if glGenFrameBuffers is available.  That's my 
very first smoke-test for the build working on any platform.

Something to verify to debug the issue:

  * the address printed out as the access violation is *precisely* the
    same as the result of ctypes.addressof( variable ) when doing the
    raw API query

if we're looking at different values, then we likely have the wrapper 
wrong (i.e. somehow it is changing the value passed in), if they are the 
same, then there's something preventing the writing to that address... 
which I don't have much to contribute...

HTH,
Mike

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Chris B. - N. F. <chr...@no...>]

On Wed, Apr 3, 2013 at 10:24 AM, Cyrille Rossant
<cyr...@gm...> wrote:

> How much RAM do you have? If you have an Intel HD card I suppose that you
> don't have so much memory that you absolutely need Python 64 bits (with 32
> bits you're probably limited to ~4GB objects).

actually 2GB on Windows, and I think that's for the whole process --
but that's still a lot for most applications.

>> I replaced
>>
>>          self.framebuffer_id = glGenFramebuffers(1);
>>
>> with
>>
>>          fbo = ctypes.c_uint(1)
>> OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1,
>> ctypes.byref(fbo))
>>          self.framebuffer_id = int(fbo.value)
>>
>> I'm not sure if the code is ctype-wise correct but I think that doesn't
>> make a real difference for the error:
>>
>> Traceback (most recent call last):
>> ...
>>    File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 203, in
>> __init__
>>      OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1,
>> ctypes.byref(fbo))
>>    File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py",
>> line 379, in __call__
>>      return self( *args, **named )
>> WindowsError: exception: access violation writing 0xFFFFFFFFE812A790

well, that is a bigger-than-32bit address -- I suppose it's possible
that this is a 32/64 bit issue.

Can you test it with 32 bit python? Even if you don't want to
ultimatley go that route, it may give you a hint.

Also, from teh ctypes docs:

c_uint	is a unsigned int

you may have some issues there, an "int" is a really poorly defined
type, and depending on the compiler, it may be 32 bits on 32bit
systems, and 32 or 64 bit on 64 bit systems (and the MS compilers and
gnu do it differently), so there could be some mis-match there.

It's beyond me that C has survived this long with such soft defining
of type sizes! Here's hoping that people start using the C99 defined
size integer types sooner than later...

(though from the looks of it, ctypes doesn't support those either...)

Not sure this is any help, though.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Ian M. <ia...@ge...>]

Hi,

Just a reminder; in my experience, Intel chipsets have extremely poor
reliability and standards compliance with regard to graphics. Even things
that ought to work don't necessarily. Writing a test program in C would be
informative.

Ian

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Cyrille R. <cyr...@gm...>]

> I have tested my program on MacOSX 10.7.5 with NVIDIA GeForce 9400M with
> PyOpenGL 3.0.2a5. It runs fine there. On a third machine running Windows
> 7 with 32 bit python, PyOpenGL 3.0.2b2 and "Intel HD Graphics" (don't
> know which one) the program runs but doesn't display what it's supposed
> to display (which may be a bug in my program).
>
> My guess is that the problem is either restricted to 64 bit python on
> Windows or to 64 bit python with my specific Intel graphics drivers. Are
> there other configurations with 64 bit python on Windows 7 on which
> glGenFramebuffers is reported to work?
>

Yes: I have a Windows 8 64 bits OS with AMD Radeon HD 7870, Python 64 bits,
PyOpenGL 3.0.2 and glGenFramebuffers works fine. More precisely, my
visualization library Galry works on multiple different configurations,
including this Python 64 bits config, except a laptop with the Python 64
bits and Intel HD 3000 card (but works with 32 bits). You can find a
selection of computers where the library works here:
https://github.com/rossant/galry/wiki/Benchmarks


> If it's a problem with the Intel drivers it should also occure when I
> use the native C interface of OpenGL shouldn't it? So if I write a litte
> C test program and compile it once in 32 bit mode and once in 64 bit
> mode I could see if it works, couldn't I? I would be surprised if it
> didn't though since some game developer would have stumbled upon this
> driver bug already, I guess. What do you think?
>

I'd be very interested in seeing the results if you're willing to make the
experiment! My bet is that it will work fine though, and I guess the
problem comes from an interaction between the Python OpenGL bindings and
the drivers.

In fact I think to remember that, when I was investigating this issue, it
was as if the Python bindings were incorrect, in that PyOpenGL tried to
link to the *native* Windows OpenGL 1.1 drivers functions and not the
graphics card drivers ones. So any call to an OpenGL function available in,
say, OpenGL 2.1 and not OpenGL 1.1 would result in a crash.
glGenFramebuffers is such an example, but there were a lot of similar other
OpenGL commands which yielded the same issue. You could try to look for
such commands not available in OpenGL 1.1 and see if this observation is
correct.

I'm writing a scientific program for point cloud processing. While at
> the moment my datasets as well as the memory required for the algorithms
> fit into 4 GB of RAM this may change within the near future (my machine
> has 8 GB). So 32 bit python is only a temporary solution for me. At the
> moment most of my algorithms are CPU based, therefore the graphics
> hardware is mainly needed for display purposes. Therefor the moderately
> fast onboard Intel chip is suficient at the moment. On the other hand it
> even has support for OpenCL which makes it usefull for OpenCL algorithm
> development.


You may be interested in Galry <http://rossant.github.com/galry/>, it is
specifically adapted to OpenGL-based scientific visualization. Let me know
if you make some progress in fixing this bug, as I'd be interested in
including any fix in the library!

Cheers,
Cyrille

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Cyrille R. <cyr...@gm...>]

Do you have the possibility to test your program on another configuration?
I had a program working perfectly well on multiple configurations (Windows,
Mac, Linux, etc.), except a particular one (Windows 8 64 bits, Python 64
bits, Intel HD 3000). So this bug might be due to some interaction between
the Intel Windows drivers and PyOpenGL/Python 64 bits. I fear that this bug
may be very hard to fix (especially if the drivers contain a bug somewhere).

How much RAM do you have? If you have an Intel HD card I suppose that you
don't have so much memory that you absolutely need Python 64 bits (with 32
bits you're probably limited to ~4GB objects). Those who will really need a
64 bits distribution will probably have a better graphics card anyway and
may be able to use your program.

Cyrille

2013/4/3 Patrick Dietrich <pyo...@pd...>

>
> As I'm trying to get my program fit for the future, I would like to
> avoid "downgrading" to 32 bit python.
>
> I tracked the problem a bit further:
>
> I replaced
>
>          self.framebuffer_id = glGenFramebuffers(1);
>
> with
>
>          fbo = ctypes.c_uint(1)
> OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1,
> ctypes.byref(fbo))
>          self.framebuffer_id = int(fbo.value)
>
> I'm not sure if the code is ctype-wise correct but I think that doesn't
> make a real difference for the error:
>
> Traceback (most recent call last):
> ...
>    File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 203, in
> __init__
>      OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1,
> ctypes.byref(fbo))
>    File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py",
> line 379, in __call__
>      return self( *args, **named )
> WindowsError: exception: access violation writing 0xFFFFFFFFE812A790
>
> Could anyone from the developers please help me track down the problem
> further? I'm very happy to assist in fixing this problem!
>
> Cheers,
> Patrick
>
>
> Am 03.04.2013 17:50, schrieb Cyrille Rossant:
> > I had a similar problem with a similar configuration and a similar
> > graphics card. I couldn't solve the problem, so I ended up removing my
> > whole 64 bits Python distribution and reinstalling everything with
> > Python 32 bits... and it worked.
> >
> > Cyrille
> >
>

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Patrick D. <pyo...@pd...>]

As I'm trying to get my program fit for the future, I would like to 
avoid "downgrading" to 32 bit python.

I tracked the problem a bit further:

I replaced

         self.framebuffer_id = glGenFramebuffers(1);

with

         fbo = ctypes.c_uint(1)
OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, 
ctypes.byref(fbo))
         self.framebuffer_id = int(fbo.value)

I'm not sure if the code is ctype-wise correct but I think that doesn't 
make a real difference for the error:

Traceback (most recent call last):
...
   File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 203, in __init__
     OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, 
ctypes.byref(fbo))
   File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", 
line 379, in __call__
     return self( *args, **named )
WindowsError: exception: access violation writing 0xFFFFFFFFE812A790

Could anyone from the developers please help me track down the problem 
further? I'm very happy to assist in fixing this problem!

Cheers,
Patrick


Am 03.04.2013 17:50, schrieb Cyrille Rossant:
> I had a similar problem with a similar configuration and a similar 
> graphics card. I couldn't solve the problem, so I ended up removing my 
> whole 64 bits Python distribution and reinstalling everything with 
> Python 32 bits... and it worked.
>
> Cyrille
>
>
> 2013/4/3 Patrick Dietrich <pyo...@pd... 
> <mailto:pyo...@pd...>>
>
>     Hi everyone,
>
>     I have a problem when calling glGenFramebuffers on Windows 7 64 bit:
>
>     Traceback (most recent call last):
>          ...
>        File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 197,
>     in __init__
>          self.framebuffer_id = glGenFramebuffers(1);
>        File "latebind.pyx", line 32, in
>     OpenGL_accelerate.latebind.LateBind.__call__
>     (src\latebind.c:667)
>        File "wrapper.pyx", line 308, in
>     OpenGL_accelerate.wrapper.Wrapper.__call__ (s
>     rc\wrapper.c:5356)
>        File
>     "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py",
>     line 379
>     , in __call__
>          return self( *args, **named )
>     WindowsError: exception: access violation writing 0xFFFFFFFFEA94A760
>
>     My PyOpenGL version is 3.0.2, including PyOpenGL_accelerate 3.0.2. I
>     have installed both packages with the windows installers (AMD64
>     versions). My graphics adaptor is an Intel HD Graphics 4000 for which
>     I'm using the newest drivers (version 9.17.10.2843).
>
>     Calling bool(glGenFramebuffers) just before the call to
>     glGenFramebuffers returns True. I have also tried to use the extension
>     version glGenFramebuffersEXT but with the same result.
>
>     What might be the problem and how can I work around it?
>     How can I access the low level C-routines of OpenGL?
>
>     Cheers,
>     Patrick
>
>
>     ------------------------------------------------------------------------------
>     Minimize network downtime and maximize team effectiveness.
>     Reduce network management and security costs.Learn how to hire
>     the most talented Cisco Certified professionals. Visit the
>     Employer Resources Portal
>     http://www.cisco.com/web/learning/employer_resources/index.html
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Users mailing list
>     PyO...@li...
>     <mailto:PyO...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>

Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Cyrille R. <cyr...@gm...>]

I had a similar problem with a similar configuration and a similar graphics
card. I couldn't solve the problem, so I ended up removing my whole 64 bits
Python distribution and reinstalling everything with Python 32 bits... and
it worked.

Cyrille


2013/4/3 Patrick Dietrich <pyo...@pd...>

> Hi everyone,
>
> I have a problem when calling glGenFramebuffers on Windows 7 64 bit:
>
> Traceback (most recent call last):
>      ...
>    File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 197, in
> __init__
>      self.framebuffer_id = glGenFramebuffers(1);
>    File "latebind.pyx", line 32, in
> OpenGL_accelerate.latebind.LateBind.__call__
> (src\latebind.c:667)
>    File "wrapper.pyx", line 308, in
> OpenGL_accelerate.wrapper.Wrapper.__call__ (s
> rc\wrapper.c:5356)
>    File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py",
> line 379
> , in __call__
>      return self( *args, **named )
> WindowsError: exception: access violation writing 0xFFFFFFFFEA94A760
>
> My PyOpenGL version is 3.0.2, including PyOpenGL_accelerate 3.0.2. I
> have installed both packages with the windows installers (AMD64
> versions). My graphics adaptor is an Intel HD Graphics 4000 for which
> I'm using the newest drivers (version 9.17.10.2843).
>
> Calling bool(glGenFramebuffers) just before the call to
> glGenFramebuffers returns True. I have also tried to use the extension
> version glGenFramebuffersEXT but with the same result.
>
> What might be the problem and how can I work around it?
> How can I access the low level C-routines of OpenGL?
>
> Cheers,
> Patrick
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

[PyOpenGL-Users] access violation when calling glGenFramebuffers

[Patrick D. <pyo...@pd...>]

Hi everyone,

I have a problem when calling glGenFramebuffers on Windows 7 64 bit:

Traceback (most recent call last):
     ...
   File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 197, in __init__
     self.framebuffer_id = glGenFramebuffers(1);
   File "latebind.pyx", line 32, in 
OpenGL_accelerate.latebind.LateBind.__call__
(src\latebind.c:667)
   File "wrapper.pyx", line 308, in 
OpenGL_accelerate.wrapper.Wrapper.__call__ (s
rc\wrapper.c:5356)
   File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", 
line 379
, in __call__
     return self( *args, **named )
WindowsError: exception: access violation writing 0xFFFFFFFFEA94A760

My PyOpenGL version is 3.0.2, including PyOpenGL_accelerate 3.0.2. I 
have installed both packages with the windows installers (AMD64 
versions). My graphics adaptor is an Intel HD Graphics 4000 for which 
I'm using the newest drivers (version 9.17.10.2843).

Calling bool(glGenFramebuffers) just before the call to 
glGenFramebuffers returns True. I have also tried to use the extension 
version glGenFramebuffersEXT but with the same result.

What might be the problem and how can I work around it?
How can I access the low level C-routines of OpenGL?

Cheers,
Patrick

Re: [PyOpenGL-Users] PyOpenGL GLX extension problem

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

On 13-03-29 07:30 AM, Jean-Baptiste Molle wrote:
> |Hi,
>
> I'm trying to create a program with PyOpenGL but I'm stuck with a GLX problem.
> |
|Attached find a script that does what your code is doing AFAICS, though 
without a pixmap to actually use, it doesn't do anything useful.  It is 
written to be run from the PyOpenGL source-code checkout tests 
directory|, but that's just so that I don't have to go about creating 
contexts and the like.

Quick summary:

  * you need the [0]'th element of the returned Display pointer to get
    the Display reference that all other calls are expecting (you have
    to dereference the pointer, basically)
  * the array-of-enums pattern is shown, in this case I'm using ctypes
    arrays to create the data:
      o note that you need an ordered sequence (list or tuple) not a set
        (the C syntax for arrays happens to look like a literal set in
        Python)
      o GLint * len(attributes) -> creates an array type
      o (*attributes) --> then creates an instance of that array type
        which is initialized to the values in the list
  * you could also have used:
      o GLintArray.asArray( attributes )
      o but I'd suggest being explicit about this kind of thing where
        possible

Note that the GLX API is not "wrapped" in the same way as the GL API, 
it's an auto-generated/raw wrapper with little or no attempt to make the 
API clean or friendly.

Hope that helps,
Mike

[PyOpenGL-Users] PyOpenGL GLX extension problem

[Jean-Baptiste M. <jb...@ho...>]

Hi,

I'm trying to create a program with PyOpenGL but I'm stuck with a GLX problem.

Here is my code:
# pixmap is the XID of an X Pixmap

from OpenGL import GLX, GL
from OpenGL.raw._GLX_NV import glXBindTexImageEXT #I have an NVidia graphic card

d = GLX.glXGetCurrentDisplay()

elements = c_int()
configs = GLX.glXChooseFBConfig(d, 0, None, byref(elements))

glxpix = GLX.glXCreatePixmap(d, configs[12], pixmap, None)


GL.glEnable(GL.GL_TEXTURE_2D)
texture_id = GLuint()
GL.glGenTextures(1, texture_id)
glXBindTexImageEXT(d, glxpix, GLX.GLX_FRONT_EXT, None)

When I run the program I got an error:
ctypes.ArgumentError: argument1: : expected LP_struct__XDisplay instance instead of LP_struct__XDisplay

How can I solve this problem?

Also in all the examples I've seen, it is written:
configs = GLX.glXChooseFBConfig(d, 0, None, byref(elements))

How could I pass attribList to glXChooseFBConfig? 
Instead of sending None, I would like to have attribList = { 
    GLX_BIND_TO_TEXTURE_RGBA_EXT, True,
    GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT,
    GLX_BIND_TO_TEXTURE_TARGETS_EXT, GLX_TEXTURE_2D_BIT_EXT,
    GLX_DOUBLEBUFFER, False,
    GLX_Y_INVERTED_EXT, GLX_DONT_CARE,
    None
}

But if I write configs = GLX.glXChooseFBConfig(d, 0, attribList, byref(elements)), I get this error:
ctypes.ArgumentError: argument 3: <type 'exceptions.TypeError'>: expected LP_c_int instance instead of set

Thanks a lot for your help,
JB
 		 	   		  

Re: [PyOpenGL-Users] PyOpenGL crash on Intel HD 3000

[Cyrille R. <cyr...@gm...>]

Some precisions that may be useful:

  * the same script works fine on other machines
  * glGetString(GL_VERSION) returns OpenGL 3.1
  * same crash with PyQt4 or GLUT
  * same crash with a bunch of different GL commands, like
"glGetStringi(Gl_EXTENSIONS, 0)"

Here is the script:

import sys
from OpenGL.GLUT import *
from OpenGL.GL import *
from OpenGL.GLU import *

def init():
    buffer = glGenBuffers(1)

glutInit(sys.argv)
glutInitWindowSize(600, 600)
glutCreateWindow("Sample")
init()
glutMainLoop()

Thanks for your help.
Cyrille


2013/3/7 Cyrille Rossant <cyr...@gm...>

> Hi,
>
> I have an issue with PyOpenGL 3.0.2 on a Windows 8 64 bits laptop with an
> Intel HD 3000 graphics chipset. Any call to glGenBuffers(1) crashes:
>
>   File ".\sample.py", line 7, in init
>     buffer = glGenBuffers(1)
>   File "latebind.pyx", line 32, in
> OpenGL_accelerate.latebind.LateBind.__call__ (src\latebind.c:768)
>   File "wrapper.pyx", line 308, in
> OpenGL_accelerate.wrapper.Wrapper.__call__ (src\wrapper.c:5811)
>   File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py",
> line 379, in __call__
>     return self( *args, **named )
> WindowsError: exception: access violation writing 0x00000000720CF630
>
> I have the latest version of the GPU driver (15.28.12.64.2932) which
> supports OpenGL 3.1.
>
> Any ideas?
>
> Thanks,
> Cyrille
>
>
>

[PyOpenGL-Users] PyCon 2013

[Larry C. <cu...@we...>]

Hello PyOpenGL users,

Anyone going to Pycon next week?

At last year's Pycon, I didn't notice much presence 
of Python-based computer graphics. 

In fact, I didn't see any. 

Maybe I wasn't looking in the right place and I 
missed it, but it would be helpful if we had 
a Birds-of-a-Feather meeting or something.
I, for one, would like to meet other PyOpenGL users. 

Who's in?

Larry Cuba

[PyOpenGL-Users] PyOpenGL crash on Intel HD 3000

[Cyrille R. <cyr...@gm...>]

Hi,

I have an issue with PyOpenGL 3.0.2 on a Windows 8 64 bits laptop with an
Intel HD 3000 graphics chipset. Any call to glGenBuffers(1) crashes:

  File ".\sample.py", line 7, in init
    buffer = glGenBuffers(1)
  File "latebind.pyx", line 32, in
OpenGL_accelerate.latebind.LateBind.__call__ (src\latebind.c:768)
  File "wrapper.pyx", line 308, in
OpenGL_accelerate.wrapper.Wrapper.__call__ (src\wrapper.c:5811)
  File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py",
line 379, in __call__
    return self( *args, **named )
WindowsError: exception: access violation writing 0x00000000720CF630

I have the latest version of the GPU driver (15.28.12.64.2932) which
supports OpenGL 3.1.

Any ideas?

Thanks,
Cyrille

Re: [PyOpenGL-Users] glGet issues

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

On 13-02-07 09:29 AM, Tomasz Wesołowski wrote:
> Hello,
>
> I've noticed that this call:
>
> 	out = GL.glGetTexParameteriv(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_SWIZZLE_B)
...
> This is probably because the list of parameter sizes hardcoded in
> glget.h is a bit out-of-date:
>
> 	TEX_PARAMETER_SIZES = {
> 	    simple.GL_TEXTURE_MAG_FILTER: (1,),
> 	    simple.GL_TEXTURE_MIN_FILTER: (1,),
> 	    simple.GL_TEXTURE_WRAP_S: (1,),
> 	    simple.GL_TEXTURE_WRAP_T: (1,),
> 	    simple.GL_TEXTURE_BORDER_COLOR: (4,),
> 	    simple.GL_TEXTURE_PRIORITY: (1,),
> 	    simple.GL_TEXTURE_RESIDENT: (1,)
> 	}
Yes, basically all of the image manipulation code is a hand-coded 
wrapper around the raw operations. What needs to happen is parsing the 
various spec files looking for:

New Tokens

Accepted by the <...> parameter of ... GetTexParameteriv

and generating a line like this:

glget.addGLGetTexParameterConstant(GL_TEXTURE_SWIZZLE_B,(1,))

in the wrapper (currently these are added to the hand-coded wrappers). 
Currently I do those by hand, but that just isn't keeping pace with the 
various extensions (or even core, really). Each of those calls actually 
needs review to see what size the result should be, too.

Lastly, the image wrapping code likely needs to be more robust to be 
able to handle un-declared constants.
> Sadly, I aparrently can't call this function "normally", without the
> ctypes enhancement:
>
> 	out = ctypes.c_int()
> 	GL.glGetTexParameteriv(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_SWIZZLE_B,
> ctypes.byref(out))
If you need the raw operation:

GL.glGetTexParameteriv.wrappedOperation

which is still ctypes, but doesn't have the wrapper code applied.

Hope that helps,
Mike

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

[PyOpenGL-Users] [ pyopengl-Feature Requests-739335 ] Only create Tk root if necessary...

[SourceForge.net <no...@so...>]

Feature Requests item #739335, was opened at 2003-05-17 21:08
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=739335&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tk
Group: v2.1
Status: Open
Resolution: None
Priority: 4
Private: No
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Only create Tk root if necessary...

Initial Comment:
Importing the OpenGL.Tk module currently automatically
creates a Tkinter root.  Would be nice if this was only
done if there is no root when creating an actual
widget.  Work-around is to do:

from Tkinter import *
my_root = Tk()
from OpenGL.Tk import *

But that's sub-optimal.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2013-02-12 14:15

Message:
zlSLrP  <a href="http://djburtggeohk.com/">djburtggeohk</a>,
[url=http://dlubbfoagpmm.com/]dlubbfoagpmm[/url],
[link=http://jyccdeabrjlc.com/]jyccdeabrjlc[/link],
http://vogyorguibtc.com/

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2011-10-12 22:08

Message:
p5XExi  <a href="http://kedxhepoqujd.com/">kedxhepoqujd</a>,
[url=http://evpccagkcfpt.com/]evpccagkcfpt[/url],
[link=http://utqlsgddkgig.com/]utqlsgddkgig[/link],
http://bnijxxraehas.com/

----------------------------------------------------------------------

Comment By: Rene Liebscher (rliebscher)
Date: 2003-05-19 01:10

Message:
Logged In: YES 
user_id=28463

Maybe moving some initialization code to first class use
will do.
Please check this.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=739335&group_id=5988

[PyOpenGL-Users] glGet issues

[Tomasz W. <ko...@gm...>]

Hello,

I've noticed that this call:

	out = GL.glGetTexParameteriv(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_SWIZZLE_B)

raises:

	KeyError: ('Unknown specifier GL_TEXTURE_SWIZZLE_B (0x8E44)',
'Failure in cConverter <OpenGL.converters.SizedOutput object at
0x02F8A300>', (GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_B), 2,
<ctypes.glGetTexParameteriv object at 0x02F9D238>)

This is probably because the list of parameter sizes hardcoded in
glget.h is a bit out-of-date:

	TEX_PARAMETER_SIZES = {
	    simple.GL_TEXTURE_MAG_FILTER: (1,),
	    simple.GL_TEXTURE_MIN_FILTER: (1,),
	    simple.GL_TEXTURE_WRAP_S: (1,),
	    simple.GL_TEXTURE_WRAP_T: (1,),
	    simple.GL_TEXTURE_BORDER_COLOR: (4,),
	    simple.GL_TEXTURE_PRIORITY: (1,),
	    simple.GL_TEXTURE_RESIDENT: (1,)
	}

Sadly, I aparrently can't call this function "normally", without the
ctypes enhancement:

	out = ctypes.c_int()
	GL.glGetTexParameteriv(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_SWIZZLE_B,
ctypes.byref(out))

because of:

	ValueError: glGetTexParameteriv requires 2 arguments (target, pname),
received 3: (GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_B, <cparam 'P'
(03513AA8)>)

Is that a bug?

BTW I've also noticed that GL.glGetTexParameteriv(GL.GL_TEXTURE_2D,
GL.GL_TEXTURE_WRAP_S) returns a numpy.int32, not
opengl.constant.IntConstant - is it intended?

Regards,
-- Kos

Re: [PyOpenGL-Users] Opengl Constant problem

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

On 13-01-19 07:20 PM, Wojciech Daniło wrote:
> Thank you for your response! The version without ARB suffix seems to 
> work. I'm facing right now another problem with this snippet - the 
> program starts and gets segmentation fault when calling 
> glUseProgram(self.program).
> `print self.program` gives number 1.
> Additional, as you can see in the code,  `self.program = 
> compile_program(self.vertex_shader_src, self.fragment_shader_src)` 
> which is a function returning the output of `glCreateProgram()`
> There is no additional information about it, only segfaul. Could ou 
> please tell me what can cause this?
Well, there are lots and lots of things that can cause it, mostly 
uninitialized variables, telling it to render too much data from a 
buffer, pointing to a NULL when you intended to point to a data-value, 
basically anything where there's a pointer that's getting the wrong 
value.  I haven't pieced together all of the various pieces of the code 
to see it run, but the code does seem to be checking that there is a 
properly compiled shader.  Are you sure it's actually failing during the 
glUseProgram call?  I'd have expected it more commonly to fail during 
the glDrawArrays calls, when it actually tries to read from the data.

HTH,
Mike
>
>
> 2013/1/19 Mike C. Fletcher <mcf...@vr... 
> <mailto:mcf...@vr...>>
>
>     On 13-01-18 07:32 PM, Wojciech Daniło wrote:
>     > Hi! I'm new to OpenGL and PyOpenGL, but Im trying to create a
>     project
>     > to my colledge and I'm facing a big problem. I was trying to resolve
>     > it but without luck :(
>     >
>     > I'm trying to execute the python example (volume rendering in
>     > pyopengl) from http://www.siafoo.net/snippet/310, which uses the
>     code
>     > from http://www.siafoo.net/snippet/142 and in that code the author
>     > uses PyOpenGL constant GL_STATIC_DRAW_ARB.
>     >
>     > Unfortunatelly my Python (2.7) with PyOpengl 3.0.2-r1000 complains,
>     > that this variable is not defined (gentoo linux, x86 64).
>     >
>     > It is used though in some examples like:
>     > http://www.songho.ca/opengl/gl_vbo.html.
>     >
>     > So the api has changed? Or maybe the example is wrong?
>     The namespace was cleaned up, so that you only get the ARB
>     constants if
>     you explicitly import them, but your snippets are actually using
>     *core*
>     entry points, so you may as well use the core constant:
>
>     GL_STATIC_DRAW
>
>     if you really want to use the ARB version:
>
>     from OpenGL.GL.ARB.vertex_buffer_object import *
>
>     but there's no reason to do that unless you want to use
>     glBufferDataARB too.
>
>     > How can I use glBufferData from OpenGl and what to pass as fourth
>     > argument to make it working?
>     >
>     > In the example there was glBufferData(GL_ARRAY_BUFFER, data[i],
>     > GL_STATIC_DRAW_ARB), where data is numpy array containing volume
>     > representation of an object.
>
>     Just drop the _ARB. There is also an OpenGL.arrays.vbo.VBO helper
>     class
>     that can be used, should you want to avoid some of the lower-level
>     details.
>
>     Hope that helps,
>     Mike
>
>     --
>     ________________________________________________
>        Mike C. Fletcher
>        Designer, VR Plumber, Coder
>     http://www.vrplumber.com
>     http://blog.vrplumber.com
>
>
>     ------------------------------------------------------------------------------
>     Master Visual Studio, SharePoint, SQL, ASP.NET <http://ASP.NET>,
>     C# 2012, HTML5, CSS,
>     MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
>     current
>     with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>     MVPs and experts. SALE $99.99 this month only -- learn more at:
>     http://p.sf.net/sfu/learnmore_122912
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Users mailing list
>     PyO...@li...
>     <mailto:PyO...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>


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

Re: [PyOpenGL-Users] Opengl Constant problem

[Wojciech D. <woj...@gm...>]

Thank you for your response! The version without ARB suffix seems to work.
I'm facing right now another problem with this snippet - the program starts
and gets segmentation fault when calling glUseProgram(self.program).
`print self.program` gives number 1.
Additional, as you can see in the code,  `self.program =
compile_program(self.vertex_shader_src, self.fragment_shader_src)` which is
a function returning the output of `glCreateProgram()`
There is no additional information about it, only segfaul. Could ou please
tell me what can cause this?

Thank you!

2013/1/19 Mike C. Fletcher <mcf...@vr...>

> On 13-01-18 07:32 PM, Wojciech Daniło wrote:
> > Hi! I'm new to OpenGL and PyOpenGL, but Im trying to create a project
> > to my colledge and I'm facing a big problem. I was trying to resolve
> > it but without luck :(
> >
> > I'm trying to execute the python example (volume rendering in
> > pyopengl) from http://www.siafoo.net/snippet/310, which uses the code
> > from http://www.siafoo.net/snippet/142 and in that code the author
> > uses PyOpenGL constant GL_STATIC_DRAW_ARB.
> >
> > Unfortunatelly my Python (2.7) with PyOpengl 3.0.2-r1000 complains,
> > that this variable is not defined (gentoo linux, x86 64).
> >
> > It is used though in some examples like:
> > http://www.songho.ca/opengl/gl_vbo.html.
> >
> > So the api has changed? Or maybe the example is wrong?
> The namespace was cleaned up, so that you only get the ARB constants if
> you explicitly import them, but your snippets are actually using *core*
> entry points, so you may as well use the core constant:
>
> GL_STATIC_DRAW
>
> if you really want to use the ARB version:
>
> from OpenGL.GL.ARB.vertex_buffer_object import *
>
> but there's no reason to do that unless you want to use glBufferDataARB
> too.
>
> > How can I use glBufferData from OpenGl and what to pass as fourth
> > argument to make it working?
> >
> > In the example there was glBufferData(GL_ARRAY_BUFFER, data[i],
> > GL_STATIC_DRAW_ARB), where data is numpy array containing volume
> > representation of an object.
>
> Just drop the _ARB. There is also an OpenGL.arrays.vbo.VBO helper class
> that can be used, should you want to avoid some of the lower-level details.
>
> Hope that helps,
> Mike
>
> --
> ________________________________________________
>    Mike C. Fletcher
>    Designer, VR Plumber, Coder
>    http://www.vrplumber.com
>    http://blog.vrplumber.com
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122912
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Opengl Constant problem

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

On 13-01-18 07:32 PM, Wojciech Daniło wrote:
> Hi! I'm new to OpenGL and PyOpenGL, but Im trying to create a project 
> to my colledge and I'm facing a big problem. I was trying to resolve 
> it but without luck :(
>
> I'm trying to execute the python example (volume rendering in 
> pyopengl) from http://www.siafoo.net/snippet/310, which uses the code 
> from http://www.siafoo.net/snippet/142 and in that code the author 
> uses PyOpenGL constant GL_STATIC_DRAW_ARB.
>
> Unfortunatelly my Python (2.7) with PyOpengl 3.0.2-r1000 complains, 
> that this variable is not defined (gentoo linux, x86 64).
>
> It is used though in some examples like: 
> http://www.songho.ca/opengl/gl_vbo.html.
>
> So the api has changed? Or maybe the example is wrong?
The namespace was cleaned up, so that you only get the ARB constants if 
you explicitly import them, but your snippets are actually using *core* 
entry points, so you may as well use the core constant:

GL_STATIC_DRAW

if you really want to use the ARB version:

from OpenGL.GL.ARB.vertex_buffer_object import *

but there's no reason to do that unless you want to use glBufferDataARB too.

> How can I use glBufferData from OpenGl and what to pass as fourth 
> argument to make it working?
>
> In the example there was glBufferData(GL_ARRAY_BUFFER, data[i], 
> GL_STATIC_DRAW_ARB), where data is numpy array containing volume 
> representation of an object.

Just drop the _ARB. There is also an OpenGL.arrays.vbo.VBO helper class 
that can be used, should you want to avoid some of the lower-level details.

Hope that helps,
Mike

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

[PyOpenGL-Users] Opengl Constant problem

[Wojciech D. <woj...@gm...>]

Hi! I'm new to OpenGL and PyOpenGL, but Im trying to create a project to my
colledge and I'm facing a big problem. I was trying to resolve it but
without luck :(

I'm trying to execute the python example (volume rendering in pyopengl)
from http://www.siafoo.net/snippet/310, which uses the code from
http://www.siafoo.net/snippet/142 and in that code the author uses PyOpenGL
constant GL_STATIC_DRAW_ARB.

Unfortunatelly my Python (2.7) with PyOpengl 3.0.2-r1000 complains, that
this variable is not defined (gentoo linux, x86 64).

It is used though in some examples like:
http://www.songho.ca/opengl/gl_vbo.html.

So the api has changed? Or maybe the example is wrong?

How can I use glBufferData from OpenGl and what to pass as fourth argument
to make it working?

In the example there was glBufferData(GL_ARRAY_BUFFER, data[i],
GL_STATIC_DRAW_ARB), where data is numpy array containing volume
representation of an object.

I would be very thankful for any help!

All the best,
Wojtek

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

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

On 13-01-15 01:43 PM, Tomasz Wesołowski wrote:
> On 15 January 2013 18:21, Mike C. Fletcher <mcf...@vr...> wrote:
>> My understanding is that implementations are free to parse each element
>> within the set as a separate set of statements, while some
>> implementations decide to concat the whole and then parse it.  Thus some
>> implementations (Intel) will accept a shader which is passed as a string
>> (which gets turned into N single-character strings), while others (ATI)
>> demand that each fragment be a valid set of statements in GLSL.
> Hmm. I have written a script to check that and I confirm that AMD is
> also okay with keeping statements (or even tokens) span through
> several shader strings.
You seem to be correct that the strings are working if they are split, 
even within a single token (i.e. that the parser is (loosely speaking) 
concat-ing the strings before parsing)... which begs the question of why 
the single character strings weren't working. Weird.

I don't actually have any machines with Nvidia or Intel, so I'm afraid I 
can't help with that testing.

I do like the idea of the independent test context decorator, so I've 
added one to the pyopengl/tests directory (using raw Pygame).

Enjoy,
Mike

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

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Tomasz W. <ko...@gm...>]

On 15 January 2013 18:21, Mike C. Fletcher <mcf...@vr...> wrote:
> My understanding is that implementations are free to parse each element
> within the set as a separate set of statements, while some
> implementations decide to concat the whole and then parse it.  Thus some
> implementations (Intel) will accept a shader which is passed as a string
> (which gets turned into N single-character strings), while others (ATI)
> demand that each fragment be a valid set of statements in GLSL.

Hmm. I have written a script to check that and I confirm that AMD is
also okay with keeping statements (or even tokens) span through
several shader strings.

I remembered that supplying source lines as separate shader strings is
useful because the lines end up being displayed in compilation error
messages - an important trait if you want good diagnostics.
Interestingly, that's not exactly the case now. On AMD the syntax looks like...

    Separate strings:
    ERROR: 4:1: error(#143) Undeclared identifier: three
    One string:
    ERROR: 0:5: error(#143) Undeclared identifier: three

So the error location appears to be in format "A:B", where A is
zero-based string index and B is one-based line number in a given
string (w/r/t newline characters in it).
If this kind of behaviour is consistent across drivers, then indeed
there's no benefit at all to splitting source into lines.

Additionally, I also haven't found any reference at all to semantic
meaning of "shader strings" as accepted by glShaderSource, or
specifically to their relation to lines of code.

Please go ahead and tinker with my code here:
https://gist.github.com/4540890 . I'm very interested how Nvidia and
Intel format the error locations.

Regards,
-- Kos

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

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

On 13-01-15 11:57 AM, Tomasz Wesołowski wrote:
> Hello,
>
> On 15 January 2013 15:51, Mike C. Fletcher <mcf...@vr...> wrote:
>> Anyway, wrapping with a list should be fine, as it's what the API
>> actually expects.
> Just a little point- Wouldn't a .linesplit() on the string be more
> suitable than wrapping with a single-element list?

My understanding is that implementations are free to parse each element 
within the set as a separate set of statements, while some 
implementations decide to concat the whole and then parse it.  Thus some 
implementations (Intel) will accept a shader which is passed as a string 
(which gets turned into N single-character strings), while others (ATI) 
demand that each fragment be a valid set of statements in GLSL.

That said, I can't readily point to a spec saying that's how it is 
*supposed* to work, that just seems to be how it works in reality. The 
shader fragments are null-terminated, not line-terminated, so there's no 
reason I can see to use \n as a splitting character, and I'd rather not 
introduce any arbitrary changes there.  Particularly thinking of things 
like this:

matrix = [
     ...
];

which would, I'm guessing, blow up on any of the finicky implementations 
if we did line-by-line splits.

HTH,
Mike

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

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Tomasz W. <ko...@gm...>]

Hello,

On 15 January 2013 15:51, Mike C. Fletcher <mcf...@vr...> wrote:
> Anyway, wrapping with a list should be fine, as it's what the API
> actually expects.

Just a little point- Wouldn't a .linesplit() on the string be more
suitable than wrapping with a single-element list?

Regards,
-- Kos
http://kos.gd