pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Format of New glReadPixels

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

Amazingly, this seems to work:
r = glReadPixels(0,0,screen_size[0],screen_size[1],   GL_RED,
GL_UNSIGNED_BYTE)
g = glReadPixels(0,0,screen_size[0],screen_size[1], GL_GREEN,
GL_UNSIGNED_BYTE)
b = glReadPixels(0,0,screen_size[0],screen_size[1],  GL_BLUE,
GL_UNSIGNED_BYTE)
image = pygame.Surface(screen_size)
for y in range(screen_size[1]):
    for x in range(screen_size[0]):
        image.set_at((x,screen_size[1]-y-1),(r[y][x],g[y][x],b[y][x]))
pygame.image.save(image,"screenshot.png")

Ian

[PyOpenGL-Users] Format of New glReadPixels

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

Hi,

The return value of glReadPixels seems to have changed since Py 2.5. To
take a screenshot, one used to be able to go:
data = glReadPixels(0,0,screen_size[0],screen_size[1], GL_RGB,
GL_UNSIGNED_BYTE)
image = pygame.image.fromstring(data,screen_size,"RGBA",True)
pygame.image.save(image,"screenshot.png")

This doesn't work anymore. It returns some data type that seems to
encapsulate a 3D array. I wasn't able to track down where this datatype was
defined. My best effort to reverse engineer it was unsuccessful (the output
is garbled):
data = glReadPixels(0,0,screen_size[0],screen_size[1], GL_RGB,
GL_UNSIGNED_BYTE)
r,g,b = data[0],data[1],data[2]
image = pygame.Surface(screen_size)
for y in range(screen_size[1]):
    for x in range(screen_size[0]):
        image.set_at((x,screen_size[1]-y-1),(r[y][x],g[y][x],b[y][x]))
pygame.image.save(image,"screenshot.png")

What is the return value format of glReadPixels?

Thanks,
Ian

Re: [PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

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

On Sat, Jun 15, 2013 at 11:23 PM, Nathaniel Virgo
<nat...@gm...>wrote:

> Thank you for the pygame recommendation. I had looked into it already, but
> when searching for things like "pygame opengl vsync" all I saw was
> questions about how to turn vsync on, but no answers besides the code I
> already posted, which crashes. However, after your mail I played around
> with some example code, and it seems that vertical sync is enabled in
> pygame whenever you enable double buffering. I don't know whether this
> behaviour is cross-platform or not, but I'm only likely to run this code on
> my Mac in the near future, so I'm only slightly worried by this and will
> probably use this solution.
>
VSync is enabled by default in Windows as well in PyGame. When writing a
windowing backend, it's something that the OpenGL context must disable.


> Note that vertical sync and double buffering are separate issues. I'm
> using double buffering, of course. However, when using PyOpenGL/GLUT on OS
> X it doesn't wait for the vertical refresh before swapping the buffers. The
> result of this is tearing and inconsistent timing, and for what I'm doing
> these are things I absolutely need to avoid. I think most other people will
> also need to avoid these things in most other situations as well. IMHO, the
> only time you wouldn't want to wait for the vertical refresh is when
> profiling, so that you can accurately measure how many frames per second
> can be rendered. In just about any kind of production code there's no point
> in rendering faster than the display can handle, and it's much more
> important to have consistent timing and to avoid tearing.
>
In my limited experience with GLUT, VSync is always disabled on any
platform.

The situation is more complicated than you describe. In particular,
disabling VSync can lead to much higher framerates if you're limited below
the screen's refresh rate, and framerates higher than 60Hz *do* lead to
better quality if triple buffering is available. VSync is enabled for
applications that demand no tearing and disabled everywhere else for
maximum performance. It does complicate timing, so I typically clamp to
60Hz and enable VSync.


> I had already worked around the issue by using pyglet to manage the
> windows. However, I don't like this solution because nobody seems to be
> developing it anymore and there's no official release that works on OS X
> Mountain Lion. I installed from the latest source, which does work, but I
> don't hold out much hope that it will continue to work after future OS
> upgrades - so now I will probably switch to pygame instead.
>
> I'm not a huge fan of GLUT either, but if you're going to go to the bother
> of wrapping it, it seems weird not to also provide a method for toggling
> VSync. Especially since (as far as I can gather) VSync is enabled on
> Windows/PyOpenGL/GLUT but disabled on Mac/PyOpenGL/GLUT, which basically
> guarantees that anyone who does develop using it will have unresolvable
> differences in behaviour between platforms. All I'm suggesting is that
> there should be a special OpenGL.platform.enableVerticalSync() function
> that wraps the platform-specific stuff for this task. Without it, the
> PyOpenGL wrapping of GLUT is quite limited in its usefulness in my opinion.
>
I agree. GLUT is useless. That's not PyOpenGL's fault, though--the C
version of GLUT that PyOpenGL wraps is useless. Since GLUT does not provide
a portable way to toggle VSync, neither does PyOpenGL's wrapper. Perhaps
something could be added to help. Really though, the best solution is to
just leave GLUT. The only place I ever see it used is in toy examples.


> Best regards,
> Nathaniel
>
Ian

Re: [PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

[Nathaniel V. <nat...@gm...>]

On 15 June 2013 16:13, Ian Mallett <ia...@ge...> wrote:

>
>>
>> I meant, that link has some of the information to get you started.
> Getting started with double-buffering instead of tweaking VSync is probably
> the solution to most problems. Because of the way displays work, a
> completely rendered graphics frame is much more important than
> synchronizing display blit to the actual rendering.
>
> Many windowing systems automatically enable VSync initially. SDL (PyGame
> in Python) is one example. GLUT is not one, as I remember. Ultimately any
> solution is platform specific--though it may be masked in a platform
> independent layer. GLUT apparently doesn't provide such a platform
> independent layer for you, so any solution is going to be platform specific.
>
> But that's already been established. GLUT has other problems. Its callback
> methods are crude and inflexible. Its support for context creation is
> lacking. It's built on ancient technology and is semi-proprietary. It
> supports only one window and has a restricted set of controller inputs and,
> as you see, poor platform abstraction for some tasks.
>
> I don't know what's wrong with your ctypes code, but I *can* tell you
> that there are much better options than GLUT. PyGame, which I mentioned
> earlier is an excellent choice. It is better than or equal to GLUT in
> literally every way, including VSync support--which you can toggle when
> creating a window. I know it's not really what you asked for, but it's my
> recommendation.
>


Thank you for the pygame recommendation. I had looked into it already, but
when searching for things like "pygame opengl vsync" all I saw was
questions about how to turn vsync on, but no answers besides the code I
already posted, which crashes. However, after your mail I played around
with some example code, and it seems that vertical sync is enabled in
pygame whenever you enable double buffering. I don't know whether this
behaviour is cross-platform or not, but I'm only likely to run this code on
my Mac in the near future, so I'm only slightly worried by this and will
probably use this solution.

Note that vertical sync and double buffering are separate issues. I'm using
double buffering, of course. However, when using PyOpenGL/GLUT on OS X it
doesn't wait for the vertical refresh before swapping the buffers. The
result of this is tearing and inconsistent timing, and for what I'm doing
these are things I absolutely need to avoid. I think most other people will
also need to avoid these things in most other situations as well. IMHO, the
only time you wouldn't want to wait for the vertical refresh is when
profiling, so that you can accurately measure how many frames per second
can be rendered. In just about any kind of production code there's no point
in rendering faster than the display can handle, and it's much more
important to have consistent timing and to avoid tearing.

I had already worked around the issue by using pyglet to manage the
windows. However, I don't like this solution because nobody seems to be
developing it anymore and there's no official release that works on OS X
Mountain Lion. I installed from the latest source, which does work, but I
don't hold out much hope that it will continue to work after future OS
upgrades - so now I will probably switch to pygame instead.

I'm not a huge fan of GLUT either, but if you're going to go to the bother
of wrapping it, it seems weird not to also provide a method for toggling
VSync. Especially since (as far as I can gather) VSync is enabled on
Windows/PyOpenGL/GLUT but disabled on Mac/PyOpenGL/GLUT, which basically
guarantees that anyone who does develop using it will have unresolvable
differences in behaviour between platforms. All I'm suggesting is that
there should be a special OpenGL.platform.enableVerticalSync() function
that wraps the platform-specific stuff for this task. Without it, the
PyOpenGL wrapping of GLUT is quite limited in its usefulness in my opinion.

Best regards,
Nathaniel

-- 
Nathaniel Virgo
http://nathanielvirgo.com

Re: [PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

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

On Fri, Jun 14, 2013 at 8:03 PM, Nathaniel Virgo
<nat...@gm...>wrote:

> Hi Ian
>
> As far as I can tell, the glX* functions referred to in that link are the
> platform-specific stuff for X Windows, whereas the CGL* functions used in
> the code I posted are the equivalent for a Mac. However, the problem is
> that I can't seem to call any of these platform specific functions from
> within Python without causing a segmentation fault.
>
> Of course, if you or anyone else has any code for calling glX* functions
> on linux from PyOpenGL it would really help a lot, because maybe I can
> modify it to use the CGL* functions that I need to use on OS X.
>
> Kind regards,
> Nathaniel
>
I meant, that link has some of the information to get you started. Getting
started with double-buffering instead of tweaking VSync is probably the
solution to most problems. Because of the way displays work, a completely
rendered graphics frame is much more important than synchronizing display
blit to the actual rendering.

Many windowing systems automatically enable VSync initially. SDL (PyGame in
Python) is one example. GLUT is not one, as I remember. Ultimately any
solution is platform specific--though it may be masked in a platform
independent layer. GLUT apparently doesn't provide such a platform
independent layer for you, so any solution is going to be platform specific.

But that's already been established. GLUT has other problems. Its callback
methods are crude and inflexible. Its support for context creation is
lacking. It's built on ancient technology and is semi-proprietary. It
supports only one window and has a restricted set of controller inputs and,
as you see, poor platform abstraction for some tasks.

I don't know what's wrong with your ctypes code, but I *can* tell you that
there are much better options than GLUT. PyGame, which I mentioned earlier
is an excellent choice. It is better than or equal to GLUT in literally
every way, including VSync support--which you can toggle when creating a
window. I know it's not really what you asked for, but it's my
recommendation.

Ian

Re: [PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

[Nathaniel V. <nat...@gm...>]

On 15 June 2013 04:57, Ian Mallett <ia...@ge...> wrote:

>
>  This seems relevant to GLUT VSync-ing:
> www.opengl.org/discussion_boards/showthread.php/173017-Vsync-with-glut
>
> Ian
>

Hi Ian

As far as I can tell, the glX* functions referred to in that link are the
platform-specific stuff for X Windows, whereas the CGL* functions used in
the code I posted are the equivalent for a Mac. However, the problem is
that I can't seem to call any of these platform specific functions from
within Python without causing a segmentation fault.

Of course, if you or anyone else has any code for calling glX* functions on
linux from PyOpenGL it would really help a lot, because maybe I can modify
it to use the CGL* functions that I need to use on OS X.

Kind regards,
Nathaniel


-- 
Nathaniel Virgo
http://nathanielvirgo.com

Re: [PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

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

On Fri, Jun 14, 2013 at 3:18 AM, Nathaniel Virgo
<nat...@gm...>wrote:

> Hi all
>
> I need to turn on vsync. Does anyone have a way to do this on OS X?  I
> found the following code on the web, but when I run it (after creating a
> Glut window) it always causes a segmentation fault:
>
> import sys
>
> def enable_vsync():
>     if sys.platform != 'darwin':
>         return
>     try:
>         import ctypes
>         import ctypes.util
>         ogl = ctypes.cdll.LoadLibrary(ctypes.util.find_library("OpenGL"))
>         # set v to 1 to enable vsync, 0 to disable vsync
>         v = ctypes.c_int(1)
>         ogl.CGLSetParameter(ogl.CGLGetCurrentContext(), ctypes.c_int(222),
> ctypes.pointer(v))
>     except:
>         print "Unable to set vsync mode, using driver defaults"
>
> My (very uneducated) guess is that this is because CGLGetCurrentContext
> returns an int, whereas CGLSetParameter expects a pointer to a struct as
> its first argument. I have tried many permutations of the above code, but I
> don't know enough about ctypes to be able to fix it.
>
> From looking at the PyOpenGL source, it looks like there's some stuff in
> there that's aimed at exposing this kind of platform-specific stuff, but I
> couldn't find any documentation for it. Is there a "correct" way to call
> CGLSetParameter and similar functions?
>
This seems relevant to GLUT VSync-ing:
www.opengl.org/discussion_boards/showthread.php/173017-Vsync-with-glut

Ian

[PyOpenGL-Users] Controlling vertical sync on Mac OS X / crashes when trying to access platform-specific stuff via ctypes

[Nathaniel V. <nat...@gm...>]

Hi all

I need to turn on vsync. Does anyone have a way to do this on OS X?  I
found the following code on the web, but when I run it (after creating a
Glut window) it always causes a segmentation fault:

import sys

def enable_vsync():
    if sys.platform != 'darwin':
        return
    try:
        import ctypes
        import ctypes.util
        ogl = ctypes.cdll.LoadLibrary(ctypes.util.find_library("OpenGL"))
        # set v to 1 to enable vsync, 0 to disable vsync
        v = ctypes.c_int(1)
        ogl.CGLSetParameter(ogl.CGLGetCurrentContext(), ctypes.c_int(222),
ctypes.pointer(v))
    except:
        print "Unable to set vsync mode, using driver defaults"

My (very uneducated) guess is that this is because CGLGetCurrentContext
returns an int, whereas CGLSetParameter expects a pointer to a struct as
its first argument. I have tried many permutations of the above code, but I
don't know enough about ctypes to be able to fix it.

>From looking at the PyOpenGL source, it looks like there's some stuff in
there that's aimed at exposing this kind of platform-specific stuff, but I
couldn't find any documentation for it. Is there a "correct" way to call
CGLSetParameter and similar functions?

By the way, I think it would be really great if a specific
platform-independent way to control vsync could be added to PyOpenGL. It's
a pretty important thing to be able to control.

Best regards,
Nathaniel

-- 
Nathaniel Virgo
http://nathanielvirgo.com

[PyOpenGL-Users] ERROR: Function <glutSwapBuffers> called with no current window defined.

[Catalin <cat...@gm...>]

I need help .
I got this error and I don't know where is the problem.

This is my source code :
http://fpaste.org/17739/
Thank you.

-- 
python-catalin.blogspot.com
www.free-tutorials.org

[PyOpenGL-Users] ERROR: Function <glutSwapBuffers> called with no current window defined.

[Catalin <cat...@gm...>]

I need help .
I got this error and I don't know where is the problem.

This is my source code :
http://fpaste.org/17739/
Thank you.

-- 
python-catalin.blogspot.com
www.free-tutorials.org

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

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

On 13-05-29 12:23 PM, Matt Williams wrote:
> On 29 May 2013 06:53, Gabriele Lanaro <gab...@gm...> wrote:
>> I'm having the same problem in python 3 (not being able to compile the
>> shaders because it gets an invalid literal). Did you find any actual
>> workaround for that?
> The only solution I found was to update to the latest version in bzr.
> Have you tried that?
>
> I agree that it's not an ideal solution but it worked for me.
I've released a 3.1.0a1 on PyPi (hidden, so they are not automatically 
installed when users ask to install PyOpenGL).  You should be able to 
pull the equivalent of bzr head with:

     pip install "PyOpenGL==3.1.0a1" "PyOpenGL-accelerate==3.1.0a1"

with the caveat that those are source-code only releases at the moment, 
so your target platform will need a Python-module compilation 
environment available.  The tarballs include the still-in-process egl 
and es[1,2,3] packages, those are *not* ready for *any* use.

HTH,
Mike

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

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Gabriele L. <gab...@gm...>]

@Chris yes, that's basically the issue. The function glShaderSource in py3
wants an 'str' object instead of a 'bytes' one. If you pass a 'bytes' you
have to convert it to 'str'. And in the non-bzr version there is probably
some code that doesn't correctly handles bytes strings.

I was able to solve the problem by backporting the function compileshader.
In this way it works with both py2 and py3:

def compileShader( source, shaderType ):

    """Compile shader source of given type
        source -- GLSL source-code for the shader
    shaderType -- GLenum GL_VERTEX_SHADER, GL_FRAGMENT_SHADER, etc,
        returns GLuint compiled shader reference
    raises RuntimeError when a compilation failure occurs
    """
    if isinstance(source, str):

        source = [source]
    elif isinstance(source, bytes):

        source = [source.decode('utf-8')]

    shader = glCreateShader(shaderType)
    glShaderSource(shader, source)
    glCompileShader(shader)
    result = glGetShaderiv(shader, GL_COMPILE_STATUS)

    if not(result):
        # TODO: this will be wrong if the user has
        # disabled traditional unpacking array support.
        raise RuntimeError(
            """Shader compile failure (%s): %s"""%(
                result,
                glGetShaderInfoLog( shader ),
            ),
            source,
            shaderType,
        )
    return shader




On Wed, May 29, 2013 at 9:23 AM, Chris Barker - NOAA Federal <
chr...@no...> wrote:

> On Tue, May 28, 2013 at 10:53 PM, Gabriele Lanaro
> <gab...@gm...> wrote:
> > I'm having the same problem in python 3 (not being able to compile the
> > shaders because it gets an invalid literal). Did you find any actual
> > workaround for that?
>
> IIUC shaders have to be written in ASCII, perhaps with Py3, you are
> passing unicode in -- ty encoding it to ascii and passing the bytes
> object instead.
>
> Or maybe I totally mis-understand the issue!
>
> -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] Shader doesn't compile with Python 3

[Matt W. <li...@mi...>]

On 29 May 2013 06:53, Gabriele Lanaro <gab...@gm...> wrote:
> I'm having the same problem in python 3 (not being able to compile the
> shaders because it gets an invalid literal). Did you find any actual
> workaround for that?

The only solution I found was to update to the latest version in bzr.
Have you tried that?

I agree that it's not an ideal solution but it worked for me.

Matt

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

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

On Tue, May 28, 2013 at 10:53 PM, Gabriele Lanaro
<gab...@gm...> wrote:
> I'm having the same problem in python 3 (not being able to compile the
> shaders because it gets an invalid literal). Did you find any actual
> workaround for that?

IIUC shaders have to be written in ASCII, perhaps with Py3, you are
passing unicode in -- ty encoding it to ascii and passing the bytes
object instead.

Or maybe I totally mis-understand the issue!

-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] Shader doesn't compile with Python 3

[Gabriele L. <gab...@gm...>]

I'm having the same problem in python 3 (not being able to compile the 
shaders because it gets an invalid literal). Did you find any actual 
workaround for that?

Re: [PyOpenGL-Users] Cannot access "pyopengl.sourceforge.net/documentation" from China

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

On 13-05-24 11:58 AM, Matthew Brett wrote:
...
> Have ya'll in PyOpenGL disabled the default export blocking to (China, Cuba...):
>
> http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/
Thanks for letting me know, I hadn't realized the setting existed.

HTH,
Mike

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

Re: [PyOpenGL-Users] Cannot access "pyopengl.sourceforge.net/documentation" from China

[Matthew B. <mat...@gm...>]

Hi,

On Fri, May 24, 2013 at 4:23 AM, Hugo H <he...@gm...> wrote:
> Hi Kang,
>
> I downloaded the website "pyopengl.sourceforge.net" into a zip archive. Can
> you get it from the following URL ?
> http://demo.ovh.com/en/67a94595a1c5218316e3997180605274/
>
> You could also try using proxies or TOR, but I don't know how legal these
> are in China.

Have ya'll in PyOpenGL disabled the default export blocking to (China, Cuba...):

http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/

The procedure is:

* Go to the project page
* Admin menu
* Metadata from left side buttons

Uncheck 'export control' checkbox if checked,

Cheers,

Matthew

Re: [PyOpenGL-Users] Cannot access "pyopengl.sourceforge.net/documentation" from China

[Hugo H <he...@gm...>]

Hi Kang,

I downloaded the website "pyopengl.sourceforge.net" into a zip archive. Can
you get it from the following URL ?
http://demo.ovh.com/en/67a94595a1c5218316e3997180605274/

You could also try using proxies or TOR, but I don't know how legal these
are in China.

Bests,
Hugo

http://demo.ovh.com/en/67a94595a1c5218316e3997180605274/

On Fri, May 24, 2013 at 2:52 AM, Kang Zhao <zha...@gm...> wrote:

> Hi all,
>
> It seems the access to URLs like "pyopengl.sourceforge.net" is blocked
> from China, however I am able to visit URLs like "
> http://sourceforge.net/projects/pyopengl/".
>
> Now my trouble is I cannot visit PyOpenGL documents located at "
> pyopengl.sourceforge.net/documentation". Is there any workaround? Or can
> I find the latest PyOpenGL documents somwhere else on internet or in PDF
> format?
>
> Thanks,
> Kang
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>

[PyOpenGL-Users] Cannot access "pyopengl.sourceforge.net/documentation" from China

[Kang Z. <zha...@gm...>]

Hi all,

It seems the access to URLs like "pyopengl.sourceforge.net" is blocked from
China, however I am able to visit URLs like "
http://sourceforge.net/projects/pyopengl/".

Now my trouble is I cannot visit PyOpenGL documents located at "
pyopengl.sourceforge.net/documentation". Is there any workaround? Or can I
find the latest PyOpenGL documents somwhere else on internet or in PDF
format?

Thanks,
Kang

Re: [PyOpenGL-Users] Help: glReadPixels error on OS X

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

On Thu, May 23, 2013 at 7:15 AM, Ian Mallett <ia...@ge...> wrote:

> Instead of:
> pixel = ord(pixel[0]), ord(pixel[1]), ord(pixel[2])
> Try this:
> pixel = pixel[0][0][0],pixel[1][0][0],pixel[2][0][0]
> Python 3 handles strings much differently from Python 2. I suspect PyOpenGL
> was changed, intentionally, to make this string functionality consistent
> across Python versions.

couldn't it return a bytes object in both cases? (which is a string on
py2, of course...)

or maybe even better an array.array object.

(just sayin')

-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] Help: glReadPixels error on OS X

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

On Wed, May 22, 2013 at 6:38 PM, Hugo H <he...@gm...> wrote:

> Hello all,
>
> I am facing an issue with using glReadPixels returning a <c_byte_Array>
> object instead of the expected string.
>
> Is this a bug ? Any idea how to get the pixel's value ?
>
> Thank you in advance !
> Greetz,
>
> Hugo
>
Instead of:
pixel = ord(pixel[0]), ord(pixel[1]), ord(pixel[2])
Try this:
pixel = pixel[0][0][0],pixel[1][0][0],pixel[2][0][0]
Python 3 handles strings much differently from Python 2. I suspect PyOpenGL
was changed, intentionally, to make this string functionality consistent
across Python versions.
Ian

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Stuart de M. <stu...@gm...>]

Hello,
I came also across this issue, when using pyopengl 3.0.2 with python 3.3.0
, the following code

Shader = compileShader("""#version 330
in vec4 position;
void main()
{
    gl_Position = position;
}""", GL_VERTEX_SHADER)
    fShader = compileShader("""#version 330

out vec4 outputColor;
void main()
{
   outputColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);
}""",  GL_FRAGMENT_SHADER)

generated the following error:


RuntimeError: ('Shader compile failure (0): b\'Vertex shader failed to
compile with the following errors:\\nERROR: 0:1: error(#132) Syntax error:
"b" parse error\\nERROR: error(#273) 1 compilation errors.  No code
generated\\n\\n\'', [b'#version 330\n\nin vec4 position;\nvoid
main()\n{\n    gl_Position = position;\n}'], GL_VERTEX_SHADER)


this was remedied by commenting out line 217 in shaders.py


def compileShader(source, shaderType):
    """Compile shader source of given type

    source -- GLSL source-code for the shader
    shaderType -- GLenum GL_VERTEX_SHADER, GL_FRAGMENT_SHADER, etc,

    returns GLuint compiled shader reference
    raises RuntimeError when a compilation failure occurs
    """
    if isinstance(source, str):
        source = [ source ]
    #source = [ as_bytes(s) for s in source ]           # offending line

    shader = glCreateShader(shaderType)

Hope this is of use,

Stuart
<http://sourceforge.net/mailarchive/forum.php?thread_name=CAD2qLTBocP8i2RjOcJsRDO48D1Gmi25fVt_T6hgO0gQP7cJhcw%40mail.gmail.com&forum_name=pyopengl-users>

Re: [PyOpenGL-Users] glGenVertexArrays missing with Python 3

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

On 13-05-01 02:36 AM, Tom Goddard wrote:
> I'm using an OpenGL 3.2 context (core profile) on Mac 10.8.3 and I find that bool(OpenGL.GL.glGenVertexArrays) is False when I use Python 3.3.1 and True when I use Python 2.7.4.  Since glGenVertexArrays is core in OpenGL 3.0 there is something wrong when using PyOpenGL with Python 3.3.1.  I observe this using PyOpenGL bzr head source code from April 29, 2013 and am using PyQt4 and Qt 5.0.2.
>
> Some digging reveals that the bug is in PyOpenGL file OpenGL/extensions.py and is caused by the AVAILABLE_GL_EXTENSIONS variable in that file containing a list that includes some extension names as strings and some as Python 3 bytearrays.  The code that checks if glGenVertexArrays is available looks to see if the byte array b"glGenVertexArrays" is in AVAILABLE_GL_EXTENSIONS but it does not find it.  The string "glGenVertexArrays" is in that list but bytearrays are never equal to strings in Python 3.  This bug results in all the extensions listed in VERSION_EXTENSIONS in extensions.py not being found.  A change in one line fixes the bug and is provided in the attached patch.  I hope this can be part of the next PyOpenGL release.
>
> With this patch PyOpenGL is working nicely with a Mac OpenGL 3.2 core profile context and Python 3.3.1 using GLSL version 150 shaders, vertex buffers and vertex array objects showing surfaces, meshes, and textures in a molecular visualization program I am developing (next generation of UCSF Chimera).
Thanks Tom, patch is integrated into bzr head and will show up with the 
next release.

HTH,
Mike

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

[PyOpenGL-Users] glGenVertexArrays missing with Python 3

[Tom G. <go...@so...>]

I'm using an OpenGL 3.2 context (core profile) on Mac 10.8.3 and I find that bool(OpenGL.GL.glGenVertexArrays) is False when I use Python 3.3.1 and True when I use Python 2.7.4.  Since glGenVertexArrays is core in OpenGL 3.0 there is something wrong when using PyOpenGL with Python 3.3.1.  I observe this using PyOpenGL bzr head source code from April 29, 2013 and am using PyQt4 and Qt 5.0.2.

Some digging reveals that the bug is in PyOpenGL file OpenGL/extensions.py and is caused by the AVAILABLE_GL_EXTENSIONS variable in that file containing a list that includes some extension names as strings and some as Python 3 bytearrays.  The code that checks if glGenVertexArrays is available looks to see if the byte array b"glGenVertexArrays" is in AVAILABLE_GL_EXTENSIONS but it does not find it.  The string "glGenVertexArrays" is in that list but bytearrays are never equal to strings in Python 3.  This bug results in all the extensions listed in VERSION_EXTENSIONS in extensions.py not being found.  A change in one line fixes the bug and is provided in the attached patch.  I hope this can be part of the next PyOpenGL release.

With this patch PyOpenGL is working nicely with a Mac OpenGL 3.2 core profile context and Python 3.3.1 using GLSL version 150 shaders, vertex buffers and vertex array objects showing surfaces, meshes, and textures in a molecular visualization program I am developing (next generation of UCSF Chimera).

	Tom Goddard

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Matt W. <li...@mi...>]

On 16 April 2013 03:43, Mike C. Fletcher <mcf...@vr...> wrote:
> The above code (with or without the b) works with Python 2.7, 3.2 and
> 3.3 on Ubuntu 64-bit with fglrx drivers when using bzr head. bzr head
> *also* for the first time, can run test_core.py on all of those
> platforms (when numpy and pygame are installed), however, I don't see
> anything in the changes I made which should have caused the error you saw.
>
> If you can test on bzr head, that would let me know whether we're
> looking at something already fixed, or a continuing bug.

I've just tested it with bzr head and it seems the issue is resolved
there. It appears to compile the shaders without problem.

I also ran test_core.py and it ran fine without any apparent failures.

I am noticing a new and different problem (something ctypes-related I
think) but I'll investigate that a little first and post on the list
if I can't resolve it.

cheers,
Matt Williams