pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] glReadPixels not working in thread

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

​It's not entirely clear to me your setup. It looks like you're trying to
use a subprocess? A few things:

- Threads in Python add parallelism, but not performance, due to the global
interpreter lock. They may even be pure software threads.
- OpenGL contexts are not threadsafe. It is usually considered an error to
use OpenGL from multiple threads, although in-principle it can be done if
the parallel executions correspond to a serial execution, with no overlaps
(through, e.g., tons of mutexes).
- Subprocesses definitely will suffer at least that problem. IDR exactly,
but it may be an error to attempt to share a GL context across
subprocesses, regardless of any synchronization.

Recommendation: keep all GL calls in one thread, and don't use threads in
Python anyway unless you need asynchronous operations. If profiling shows
that OpenGL *command overhead* really is the bottleneck *and* this is worth
investing effort fixing, move to C++. If you still don't have enough
performance, move from OpenGL to Vulkan (which unlike GL will allow you to
build and issue command lists in parallel).

Ian

[PyOpenGL-Users] glReadPixels not working in thread

[Shir G. <shi...@gm...>]

Hi,

My code works just fine without threading, but I’m trying to make it faster by processing the OpenGL data in another thread.

class Cube(app.Canvas):
*
*
*
	def finish(self):
    		im = gl.glReadPixels(0, 0, self.canvas_size[0], self.canvas_size[1], gl.GL_RGB, gl.GL_FLOAT)
    		rgb = np.copy(np.frombuffer(im, np.float32)).reshape(self.canvas_size + (3,))[::-1, :]  # Read buffer and flip Y
    		im = gl.glReadPixels(0, 0, self.canvas_size[0], self.canvas_size[1], gl.GL_DEPTH_COMPONENT, gl.GL_FLOAT)
    		dep = np.copy(np.frombuffer(im, np.float32)).reshape(self.canvas_size + (1,))[::-1, :]  # Read buffer and flip Y

    		# Convert z-buffer to depth map
    		mult = (self.clip_near * self.clip_far) / (self.clip_near - self.clip_far)
    		addi = self.clip_far / (self.clip_near - self.clip_far)
    		bg = dep == 1
    		dep = mult / (dep + addi)
    		dep[bg] = 0
    		return rgb, np.squeeze(dep)

	def next_batch(self, size):
		**** something
       		self.draw()
        	col, dep = self.finish()
		**** something

def load_data(o, size, q):
    while True:
        q.put(o.next_batch(size))

cube = Cube()
data_q = Queue()
p = Process(target=load_data, args=(cube, args.nof_load, data_q,))
p.start()
qg = data_q.get()

BUT when it reaches this line:
im = gl.glReadPixels(0, 0, self.canvas_size[0], self.canvas_size[1], gl.GL_RGB, gl.GL_FLOAT)
The program get stuck

Any idea why this happens when i use threading?

Thanks
Shir

[PyOpenGL-Users] PyOpenGL / togl with python3 - minor tweaks needed?

[Jonathan W. <wr...@es...>]

Hello,

Trying to port some old togl code to python3.6 there was a glitch from 
PyOpenGL:

http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/view/head:/OpenGL/Tk/__init__.py
     line 101:   "sys.maxint"     needs to be renamed to "sys.maxsize"

For installing togl from src/togl.py there were a couple of issues:
     sys.maxint (line 7, also delete "L"?? )
     urls in lines 20-21: "sys.platform" of "linux2" becomes "linux" for 
python3.6

With those changes it seems to be working for me (admittedly a very 
small test) on linux.

Nevertheless, I guess this is a dead end for windows-64 bit anyway...?

Best,

Jon

Re: [PyOpenGL-Users] "Attempt to retrieve context when no valid context" when calling glVertexAttribPointer in GL ES 2

[JP L. <jpl...@gm...>]

I've now tried a few other things, like setting
OpenGL.CONTEXT_CHECKING=True and forcing an ES 2.0 context specifically,
and experimenting with SDL_GL_CONTEXT_FLAGS, but nothing seems to work.
Debug contexts don't seem supported, they're only core as of 4.3.

Searching this mailing list for "raspberry" returns only this thread so it
seems reasonable to assume that PyOpenGL has never worked on the Pi without
significant modifications; guess I should have searched this list before I
started.

On Wed, Jan 3, 2018 at 12:00 AM, Ian Mallett <ia...@ge...> wrote:

> On Tue, Jan 2, 2018 at 10:44 PM, JP LeBreton <jpl...@gm...> wrote:
>
>> PySDL2 and PyOpenGL have been working fine together for this application
>> on x86[_64] Linux, macOS, and Windows, on Intel and Nvidia GPUs, but I
>> realize the Pi is a fairly different environment and drivers play a large
>> role.
>>
> It is distressingly common (less so, today, but still) to get an
> application that works perfectly on a variety of (arch/PCI, GPU, OS,
> driver) tuples, but is actually incorrect. It is also possible to have
> bugs, usually in the driver (I have, for example, several outstanding ones
> reported on various Linux graphics drivers) making perfect programs break.
>
>
>> I'll read up on debugging with glGetError...
>>
> ​Shortly after I sent my email, I remembered that PyOpenGL does some
> amount of its own checking, which IIRC includes implicit `glGetError(...)`.
> Perhaps creating a debug context
> <https://www.khronos.org/opengl/wiki/Debug_Output> would enable more
> checks, assuming the Pi supports it (which IDR offhand). I might also
> suggest some kind of graphics debugger, like RenderDoc.
>
> Although . . . the error does seem to indicate at least the basic nature
> of the problem rather clearly. Perhaps the context exists, but is invalid
> for some reason (Unsupported flags? Invalid version? Invalid size?).
>
> Ian
>

Re: [PyOpenGL-Users] "Attempt to retrieve context when no valid context" when calling glVertexAttribPointer in GL ES 2

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

On Tue, Jan 2, 2018 at 10:44 PM, JP LeBreton <jpl...@gm...> wrote:

> PySDL2 and PyOpenGL have been working fine together for this application
> on x86[_64] Linux, macOS, and Windows, on Intel and Nvidia GPUs, but I
> realize the Pi is a fairly different environment and drivers play a large
> role.
>
It is distressingly common (less so, today, but still) to get an
application that works perfectly on a variety of (arch/PCI, GPU, OS,
driver) tuples, but is actually incorrect. It is also possible to have
bugs, usually in the driver (I have, for example, several outstanding ones
reported on various Linux graphics drivers) making perfect programs break.


> I'll read up on debugging with glGetError...
>
​Shortly after I sent my email, I remembered that PyOpenGL does some amount
of its own checking, which IIRC includes implicit `glGetError(...)`.
Perhaps creating a debug context
<https://www.khronos.org/opengl/wiki/Debug_Output> would enable more
checks, assuming the Pi supports it (which IDR offhand). I might also
suggest some kind of graphics debugger, like RenderDoc.

Although . . . the error does seem to indicate at least the basic nature of
the problem rather clearly. Perhaps the context exists, but is invalid for
some reason (Unsupported flags? Invalid version? Invalid size?).

Ian

Re: [PyOpenGL-Users] "Attempt to retrieve context when no valid context" when calling glVertexAttribPointer in GL ES 2

[JP L. <jpl...@gm...>]

Thanks for the reply. The context does seem to be the window's current one,
SDL_GL_MakeCurrent didn't change anything. I'm running it from the Raspbian
Pixel desktop and made sure there are no other SDL2 windows nor OpenGL
contexts active on the system, just in case that was a factor.

Correct, I did have a few local uncommitted changes - as of about 15
minutes ago the current state of the repo should reproduce the error on a
Pi 3.

PySDL2 and PyOpenGL have been working fine together for this application on
x86[_64] Linux, macOS, and Windows, on Intel and Nvidia GPUs, but I realize
the Pi is a fairly different environment and drivers play a large role.
I'll read up on debugging with glGetError...

On Tue, Jan 2, 2018 at 7:37 PM, Ian Mallett <ia...@ge...> wrote:

> On Tue, Jan 2, 2018 at 12:33 AM, JP LeBreton <jpl...@gm...> wrote:
>
>> I have a program (http://vectorpoem.com/playscii) that's been running
>> nicely with PyOpenGL on x86 Linux, macOS, and Windows for a few years now,
>> and I'm now attempting to get it running on a Raspberry Pi 3 (using the
>> Raspbian OpenGL driver). Until now this process was pretty straightforward,
>> tweaking shaders and providing a render path for non-VAO hardware, but I've
>> now hit a crash I don't understand and can't figure out how to debug.
>>
>> Deep into program initialization, I'm setting up some vertex buffers, and
>> get a crash whose final line is "OpenGL.error.Error: Attempt to retrieve
>> context when no valid context" when calling glVertexAttribPointer. See the
>> full log here; my program first logs info about the hardware and the OpenGL
>> context it creates (via PySDL2), followed by the crash:
>>
>> https://gist.github.com/JPLeBreton/782b92872380ee6ab3b11b3954ca56cd
>>
>> The OpenGL render context is definitely present; I tried logging stuff
>> about it just before the glVertexAttribPointer call and as far as I can
>> tell it's valid right up until that point. For what it's worth that call
>> does appear to be the first (of many) in the program's execution.
>>
>
> ​It's not enough for the context to be present; it must also be "current"
> on the thread and window from which the GL command is issued. I'm not
> especially familiar with SDL2 and its requirements, but I should think
> `SDL_GL_MakeCurrent(...)` after creating your window and before calling any
> GL commands would do it.
>
> If this turns out not to be the issue, I'd suggest some well-placed
> `glGetError(...)`s. I don't know if mixing PyOpenGL with PySDL2 is okay,
> either—in C++, at least, SDL provides its own GL binding . . . but Mike
> would know. Also your repo <https://bitbucket.org/JPLeBreton/playscii>
> doesn't seem to match the error perfectly; I assume you made a few changes
> since.
>
> GL context creation is ludicrously fraught, even in the more-modern API
> revisions—and I've found it to be particularly buggy on *nix graphics
> drivers, especially Debian-based Linuxes. So.
>
> Ian
>

Re: [PyOpenGL-Users] "Attempt to retrieve context when no valid context" when calling glVertexAttribPointer in GL ES 2

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

On Tue, Jan 2, 2018 at 12:33 AM, JP LeBreton <jpl...@gm...> wrote:

> I have a program (http://vectorpoem.com/playscii) that's been running
> nicely with PyOpenGL on x86 Linux, macOS, and Windows for a few years now,
> and I'm now attempting to get it running on a Raspberry Pi 3 (using the
> Raspbian OpenGL driver). Until now this process was pretty straightforward,
> tweaking shaders and providing a render path for non-VAO hardware, but I've
> now hit a crash I don't understand and can't figure out how to debug.
>
> Deep into program initialization, I'm setting up some vertex buffers, and
> get a crash whose final line is "OpenGL.error.Error: Attempt to retrieve
> context when no valid context" when calling glVertexAttribPointer. See the
> full log here; my program first logs info about the hardware and the OpenGL
> context it creates (via PySDL2), followed by the crash:
>
> https://gist.github.com/JPLeBreton/782b92872380ee6ab3b11b3954ca56cd
>
> The OpenGL render context is definitely present; I tried logging stuff
> about it just before the glVertexAttribPointer call and as far as I can
> tell it's valid right up until that point. For what it's worth that call
> does appear to be the first (of many) in the program's execution.
>

​It's not enough for the context to be present; it must also be "current"
on the thread and window from which the GL command is issued. I'm not
especially familiar with SDL2 and its requirements, but I should think
`SDL_GL_MakeCurrent(...)` after creating your window and before calling any
GL commands would do it.

If this turns out not to be the issue, I'd suggest some well-placed
`glGetError(...)`s. I don't know if mixing PyOpenGL with PySDL2 is okay,
either—in C++, at least, SDL provides its own GL binding . . . but Mike
would know. Also your repo <https://bitbucket.org/JPLeBreton/playscii>
doesn't seem to match the error perfectly; I assume you made a few changes
since.

GL context creation is ludicrously fraught, even in the more-modern API
revisions—and I've found it to be particularly buggy on *nix graphics
drivers, especially Debian-based Linuxes. So.

Ian

[PyOpenGL-Users] "Attempt to retrieve context when no valid context" when calling glVertexAttribPointer in GL ES 2

[JP L. <jpl...@gm...>]

I have a program (http://vectorpoem.com/playscii) that's been running
nicely with PyOpenGL on x86 Linux, macOS, and Windows for a few years now,
and I'm now attempting to get it running on a Raspberry Pi 3 (using the
Raspbian OpenGL driver). Until now this process was pretty straightforward,
tweaking shaders and providing a render path for non-VAO hardware, but I've
now hit a crash I don't understand and can't figure out how to debug.

Deep into program initialization, I'm setting up some vertex buffers, and
get a crash whose final line is "OpenGL.error.Error: Attempt to retrieve
context when no valid context" when calling glVertexAttribPointer. See the
full log here; my program first logs info about the hardware and the OpenGL
context it creates (via PySDL2), followed by the crash:

https://gist.github.com/JPLeBreton/782b92872380ee6ab3b11b3954ca56cd

The OpenGL render context is definitely present; I tried logging stuff
about it just before the glVertexAttribPointer call and as far as I can
tell it's valid right up until that point. For what it's worth that call
does appear to be the first (of many) in the program's execution.

Happy to provide more info as needed. Thanks.

Re: [PyOpenGL-Users] WGL Extension Querier broken (Python 3)

[Peter K. <kl...@gm...>]

Found a way to make it work, had to adjust Win32Platform as well.

Cheers,
Peter


On Fri, Oct 27, 2017 at 3:39 PM, Peter Klosowski <kl...@gm...> wrote:

> Hi,
>
> The WGL extensions seem very broken on Python 3. I fixed the "TypeError:
> startswith first arg must be bytes or a tuple of bytes, not str" (see
> attached).
>
> However, the following still returns False, although I am pretty confident
> it should be True:
>
> extensions.hasExtension("WGL_ARB_extensions_string")
>
> Any comments/advice?
>
> Cheers,
> Peter
>
>
>

[PyOpenGL-Users] WGL Extension Querier broken (Python 3)

[Peter K. <kl...@gm...>]

Hi,

The WGL extensions seem very broken on Python 3. I fixed the "TypeError:
startswith first arg must be bytes or a tuple of bytes, not str" (see
attached).

However, the following still returns False, although I am pretty confident
it should be True:

extensions.hasExtension("WGL_ARB_extensions_string")

Any comments/advice?

Cheers,
Peter

[PyOpenGL-Users] glGetMultisample returns a single float

[Nicolas R. <Nic...@in...>]

Hi all,


I’m trying to retrieve the position of the samples when using multisampling (GL 3.2) and I use:

z = glGetMultisamplefv(gl.GL_SAMPLE_POSITION, 0)

but the return value is a single float while I was expecting a tuple of 2 floats (2d coordinates of the sample)
Did I miss something ?



Nicolas

Re: [PyOpenGL-Users] Bug? Importing WGL crashes glReadPixel call with "wrong argument type" exception

[Matti K. <mat...@gm...>]

Consider using Mesa's software renderer, if your requirements allow it:

$ sudo apt-get install python-opengl libosmesa # maybe libosmesa6?
$ PYOPENGL_PLATFORM=osmesa python your_app.py
$ cat your_app.py
...
   from OpenGL import GL, arrays, platform
   ctx = platform.OSMesaCreateContext(GL.GL_RGBA, None) # requires PYOPENGL_PLATFORM=osmesa
   buf = arrays.GLubyteArray.zeros((height, width, 4))
   p = arrays.ArrayDatatype.dataPointer(buf)
   assert(platform.OSMesaMakeCurrent(ctx, p, GL.GL_UNSIGNED_BYTE, width, height))
   assert(platform.CurrentContextIsValid())
...
   platform.OSMesaDestroyContext(ctx)
...

I understand that you're on Windows. There may be an easy way to install 
Mesa for use with PyOpenGL on your setup, but I'm afraid I'm not 
familiar with the Windows platform so you'll have to do some digging first.

On 9/2/17 2:31 PM, Anton Ovsyannikov wrote:
> Hello.
>
> I am trying to use PyOpengGL for off-screen rendering, so I need WGL 
> to create gl context and then glReadPixels to retrieve data
>
> First I wrote simple app with GLUT, but right after I import 
> OpenGL.WGL (just import, no more), the glReadPixels starts to crash with
>
> ctypes.ArgumentError: argument 7: <type 'exceptions.TypeError'>: wrong 
> type
>
> The app, OpenGL version and stack trace are below. Now some of my 
> investigations
>
> =======================================================
> The crash starts in \OpenGL\GL\images.py line 369
>
> GL_1_1.glReadPixels(
>     x,y,width,height,
>     format,type,
>     imageData
> )
>
> imageData in both cases is completely the same
>
> The only difference in further workflow happens in 
> \OpenGL\platform\baseplatform.py line 125
>
> def finalArgType( self, typ ):
>     """Retrieve a final type for arg-type"""
>     if typ == ctypes.POINTER( None ) and not getattr( typ, 'final',False):
>         from OpenGL.arrays import ArrayDatatype
>         return ArrayDatatype
>     else:
>         return typ
>
> With no WGL the 7th argument (while typ is <class 'ctypes.c_void_p'>) 
> have no "final" attribute set, so final type becomes ArrayDatatype and 
> everything works fine
>
> But if to import WGL "final" flag is set, so <class 'ctypes.c_void_p'> 
> returned leading to "wrong type" exception in GL_1_1.glReadPixels call
>
> I searched for "final" in WGL and found the following in 
> \OpenGL\raw\WGL\_types.py line 72
>
> HANDLE = POINTER(None) # /home/mcfletch/pylive/OpenGL-ctypes/src/wgl.h:60
> # TODO: figure out how to make the handle not appear as a void_p 
> within the code...
> HANDLE.final = True
>
> So we found who set up "final" flag for <class 'ctypes.c_void_p'>
>
> But then I stuck up completely, have no single idea how to solve this 
> type conflict, suppose it's some issue in design
>
> Have any idea how to solve it?
>
>
> =======================================================
> PyOpenGL package is
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl 
> <http://www.lfd.uci.edu/%7Egohlke/pythonlibs/#pyopengl>
> PyOpenGL‑3.1.1‑cp27‑cp27m‑win_amd64.whl
>
> OpenGL.__version__
> 3.1.1
> =======================================================
>
> =======================================================
> The App
> =======================================================
> # -*- coding: utf-8 -*-
>
> # Just uncomment following line to reproduce the bug!
> #import OpenGL.WGL
>
> from OpenGL.GL import *
> from OpenGL.GLU import *
> from OpenGL.GLUT import *
>
> from PIL import Image
> import sys
>
> width, height = 300, 300
>
> def init():
>     glClearColor(0.5, 0.5, 0.5, 1.0)
>     glColor(0.0, 1.0, 0.0)
>     gluOrtho2D(-1.0, 1.0, -1.0, 1.0)
>     glViewport(0, 0, width, height)
>
> def render():
>
>     glClear(GL_COLOR_BUFFER_BIT)
>
>     glBegin(GL_LINES)
>     glVertex2d(-0.5, -0.5)
>     glVertex2d(0.5, 0.5)
>     glEnd()
>
>     glFlush()
>
> def draw():
>     render()
>     glutSwapBuffers()
>
> def main():
>     glutInit(sys.argv)
>
>     glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB)
>     glutInitWindowSize(300, 300)
>     glutCreateWindow(b"OpenGL vs WGL")
>
>     init()
>     render()
>
>     glPixelStorei(GL_PACK_ALIGNMENT, 1)
>     data = glReadPixels(0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE)
>     image = Image.frombytes("RGBA", (width, height), data)
>     image.save('output.png', 'PNG')
>
>     glutDisplayFunc(draw)
>     glutMainLoop()
>
> main()
> =======================================================
>
>
> =======================================================
> Stack trace with import WGL uncommented
> =======================================================
>
> Traceback (most recent call last):
>   File 
> "C:/Users/Anton/Documents/Dev/PycharmProjects/OpenGL/OpenGLTest.py", 
> line 54, in <module>
>     main()
>   File 
> "C:/Users/Anton/Documents/Dev/PycharmProjects/OpenGL/OpenGLTest.py", 
> line 47, in main
>     data = glReadPixels(0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE)
>   File 
> "C:\ProgramData\Anaconda2\lib\site-packages\OpenGL\GL\images.py", line 
> 372, in glReadPixels
>     imageData
>   File 
> "C:\ProgramData\Anaconda2\lib\site-packages\OpenGL\platform\baseplatform.py", 
> line 402, in __call__
>     return self( *args, **named )
> ctypes.ArgumentError: argument 7: <type 'exceptions.TypeError'>: wrong 
> type
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] Bug? Importing WGL crashes glReadPixel call with "wrong argument type" exception

[Anton O. <ant...@gm...>]

Hello.

I am trying to use PyOpengGL for off-screen rendering, so I need WGL to
create gl context and then glReadPixels to retrieve data

First I wrote simple app with GLUT, but right after I import OpenGL.WGL
(just import, no more), the glReadPixels starts to crash with

ctypes.ArgumentError: argument 7: <type 'exceptions.TypeError'>: wrong type

The app, OpenGL version and stack trace are below. Now some of my
investigations

=======================================================
The crash starts in \OpenGL\GL\images.py line 369

GL_1_1.glReadPixels(
    x,y,width,height,
    format,type,
    imageData
)

imageData in both cases is completely the same

The only difference in further workflow happens in
\OpenGL\platform\baseplatform.py line 125

def finalArgType( self, typ ):
    """Retrieve a final type for arg-type"""
    if typ == ctypes.POINTER( None ) and not getattr( typ, 'final',False):
        from OpenGL.arrays import ArrayDatatype
        return ArrayDatatype
    else:
        return typ

With no WGL the 7th argument (while typ is <class 'ctypes.c_void_p'>) have
no "final" attribute set, so final type becomes ArrayDatatype and
everything works fine

But if to import WGL "final" flag is set, so <class 'ctypes.c_void_p'>
returned leading to "wrong type" exception in GL_1_1.glReadPixels call

I searched for "final" in WGL and found the following in
\OpenGL\raw\WGL\_types.py line 72

HANDLE = POINTER(None) # /home/mcfletch/pylive/OpenGL-ctypes/src/wgl.h:60
# TODO: figure out how to make the handle not appear as a void_p within the
code...
HANDLE.final = True

So we found who set up "final" flag for <class 'ctypes.c_void_p'>

But then I stuck up completely, have no single idea how to solve this type
conflict, suppose it's some issue in design

Have any idea how to solve it?


=======================================================
PyOpenGL package is
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl
PyOpenGL‑3.1.1‑cp27‑cp27m‑win_amd64.whl

OpenGL.__version__
3.1.1
=======================================================

=======================================================
The App
=======================================================
# -*- coding: utf-8 -*-

# Just uncomment following line to reproduce the bug!
#import OpenGL.WGL

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

from PIL import Image
import sys

width, height = 300, 300

def init():
    glClearColor(0.5, 0.5, 0.5, 1.0)
    glColor(0.0, 1.0, 0.0)
    gluOrtho2D(-1.0, 1.0, -1.0, 1.0)
    glViewport(0, 0, width, height)

def render():

    glClear(GL_COLOR_BUFFER_BIT)

    glBegin(GL_LINES)
    glVertex2d(-0.5, -0.5)
    glVertex2d(0.5, 0.5)
    glEnd()

    glFlush()

def draw():
    render()
    glutSwapBuffers()

def main():
    glutInit(sys.argv)

    glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB)
    glutInitWindowSize(300, 300)
    glutCreateWindow(b"OpenGL vs WGL")

    init()
    render()

    glPixelStorei(GL_PACK_ALIGNMENT, 1)
    data = glReadPixels(0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE)
    image = Image.frombytes("RGBA", (width, height), data)
    image.save('output.png', 'PNG')

    glutDisplayFunc(draw)
    glutMainLoop()

main()
=======================================================


=======================================================
Stack trace with import WGL uncommented
=======================================================

Traceback (most recent call last):
  File "C:/Users/Anton/Documents/Dev/PycharmProjects/OpenGL/OpenGLTest.py",
line 54, in <module>
    main()
  File "C:/Users/Anton/Documents/Dev/PycharmProjects/OpenGL/OpenGLTest.py",
line 47, in main
    data = glReadPixels(0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE)
  File "C:\ProgramData\Anaconda2\lib\site-packages\OpenGL\GL\images.py",
line 372, in glReadPixels
    imageData
  File
"C:\ProgramData\Anaconda2\lib\site-packages\OpenGL\platform\baseplatform.py",
line 402, in __call__
    return self( *args, **named )
ctypes.ArgumentError: argument 7: <type 'exceptions.TypeError'>: wrong type

Re: [PyOpenGL-Users] High Order glMap2 Error

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

On Tue, Aug 8, 2017 at 7:39 AM, Shuai Jiang (Marshall) <
mar...@gm...> wrote:

> ​Oh goodness, yeah the max value is 8. Thanks for the input! It seems from
> a cursory search that this value is pretty much hardwired into the OpenGL
> implementation, and there's no way to increase it.
>
​That's correct.


> ​
> When you say converting to a newer pipeline, do you mean moving to
> tessellation instead to plot my patches? Sorry if this is a silly question,
> I'm not very familiar with OpenGL.
>
​It is a bit of a silly question, but you sortof have the right idea ;)

OpenGL for a long time was GL 1 / GL 2 ("old-style GL"). These were
developed gradually and slowly, maintaining backward compatibility when
possible. Many (most, still?) online resources target the GL 2 API,
in-particular.

However, as the technology has developed, it became increasingly clear that
the old-style API could not adequately represent the power of modern GPUs.
Consequently, GL 3 was introduced, followed rapidly by GL 4 ("new-style
GL"). The new-style API removes (at least in 4) much of the old
functionality (such as e.g. `glVertex*(...)`), replacing it with new API
calls that map better to the underlying hardware.

The new-style API is usually more complex to use, particularly for
beginners, but it's forward compatible and much faster. It also gives you
complete flexibility, which is why I mentioned it. In particular, for
handling patches, you'd draw with a primitive type of GL_PATCHES
(GL_MAX_PATCH_VERTICES is required to be at least 32). The patch would then
be subdivided by tessellation shaders to whatever degree and subdivision
level you want (because you write those shaders yourself). So, flexibility,
but it's a whole lot of learning/work if you don't know GL 4 pipelines yet.

If this intrigues you, you may also want to check out Vulkan. Vulkan is a
new graphics API written from the ground up, and provides the ultimate in
flexibility and power. The downside is that it is (necessarily) extremely
complex to use.

Ian​

Re: [PyOpenGL-Users] High Order glMap2 Error

[Shuai J. (Marshall) <mar...@gm...>]

Oh goodness, yeah the max value is 8. Thanks for the input! It seems from a
cursory search that this value is pretty much hardwired into the OpenGL
implementation, and there's no way to increase it.

When you say converting to a newer pipeline, do you mean moving to
tessellation instead to plot my patches? Sorry if this is a silly question,
I'm not very familiar with OpenGL.

Best,

Marshall

On Mon, Aug 7, 2017 at 6:11 PM, Ian Mallett <ia...@ge...> wrote:

> ​According to the docs:
>
> GL_INVALID_VALUE is generated if either uorder or vorder is less than 1 or
> greater than the return value of GL_MAX_EVAL_ORDER.
>
> So . . . what value do you have when querying "GL_MAX_EVAL_ORDER"?
>
> ---
>
> It might also be worth converting to a GL 3/GL 4 pipeline, for fully
> flexibility.
>
> Ian
>

Re: [PyOpenGL-Users] High Order glMap2 Error

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

​According to the docs:

GL_INVALID_VALUE is generated if either uorder or vorder is less than 1 or
greater than the return value of GL_MAX_EVAL_ORDER.

So . . . what value do you have when querying "GL_MAX_EVAL_ORDER"?

---

It might also be worth converting to a GL 3/GL 4 pipeline, for fully
flexibility.

Ian

[PyOpenGL-Users] High Order glMap2 Error

[Shuai J. (Marshall) <mar...@gm...>]

Hi all,

I have some high order Bezier patches generated by Python that I want to
use OpenGL to draw. Unfortunately, it seems that PyOpenGl seems to only
handle orders up to 7 but I can plot Bezier patches in C codes of higher
order than that.

I posted a self-contained code:
https://gist.github.com/runiteking1/b0946026d2cad966db1e52c0a28a86c6

To see the error, comment out the second definition of one_patch (i.e.
lines 103 to 166). The error I get is

OpenGL.error.GLError: GLError(
err = 1281,
description = 'invalid value',
baseOperation = glMap2d,
pyArgs = (
GL_MAP2_VERTEX_3,
0,
1,
27,
9,
0,
1,
3,
9,
<OpenGL.arrays.lists.c_double_Array_3_Array_9_Array_9 object at
0x7fa4ecbbff80>,
),
cArgs = (
GL_MAP2_VERTEX_3,
0,
1,
27,
9,
0,
1,
3,
9,
<OpenGL.arrays.lists.c_double_Array_3_Array_9_Array_9 object at
0x7fa4ecbbff80>,
),
cArguments = (
GL_MAP2_VERTEX_3,
0,
1,
27,
9,
0,
1,
3,
9,
<OpenGL.arrays.lists.c_double_Array_3_Array_9_Array_9 object at
0x7fa4ecbbff80>,
)
)

Does anybody know workarounds?

Best,

Marshall

Re: [PyOpenGL-Users] Using PyopenGL with GLArea

[Oliver M. <ol...@di...>]

fantastic thanks for spending the time on that Matti, it works perfectly on
my system I will play around and adapt it to my own program and try out
your suggestions and see what i come up with :)

On Sat, Mar 11, 2017 at 5:15 PM Matti Kariluoma <mat...@gm...>
wrote:

> I forked your gist:
> https://gist.github.com/matti-kariluoma/7786a620abe87deb54c6012b07ded884
>
> I added error-checking to work around the errors I encountered, and placed
> a print-statement to show how to check which PyOpenGL Platform is loaded at
> runtime.
>
> When I tried to run either gist on my Nvidia+Debian laptop (pyopengl
> 3.0.2), the program crashed immediately with an error similar to:
> http://askubuntu.com/questions/175744/x-error-of-failed-request-badrequest-invalid-request-code-or-no-such-operation
> When I tried to run your gist on my Intel+Ubuntu 16.10 machine, your gist
> gives the errors you described. After making my changes, my gist displayed
> a red triangle with platforms "linux2" and "posix".
>
> ==
>
>
> > I just dont 100% get why i need to prefix I would not want to tell a
> user they need todo that
>
> PYOPENGL_PLATFORM allows one codebase to support osx, windows, and various
> linux flavors. A platform is selected at runtime to simplify the
> distribution of PyOpenGL. Some platforms implement things differently-
> there will always be bugs or missing functionality when running on
> different platforms. Avoid the use of `from X import *' to make your code
> more likely to run on a different platform. Instead of:
>   from OpenGL.GLUT import *
>   glutInit([])
> ...try:
>   from OpenGL import GLUT as glut
>   glut.glutInit([])
> ... you'd be surprised how much this helps platform portability.
>
> Each of the platforms has various dependencies that are not installed when
> you get pyopengl from source or pip, however the system package manager
> (apt) will download the dependencies automatically (e.g. freeglut3, etc.)
> for your system's recommended platform. Some of the "optional" platforms
> (osmesa, egl) do not have packages in apt, so you'll need to install the
> dependencies yourself. This becomes very complicated when you use external
> PPAs, or build your own drivers and libraries!
>
> Hint: Use strace to see which drivers/libraries are being used by your
> process, to ensure you are using the drivers/libraries you intend:
>   $ strace python glutexample.py 2>&1 | grep open
> ==
>
>
> >is there a way i can detect the profiles and select the best on startup ?
>
> You can choose between PyOpenGL platforms at runtime by setting
> `os.environ' in your code:
>   import os
>   os.environ['PYOPENGL_PLATFORM'] = 'posix'
>   import OpenGL
>
> ...you /should/ be able to use the `reload' function (
> http://stackoverflow.com/questions/437589/how-do-i-unload-reload-a-python-module)
> to choose a different platform at runtime:
>   import os
>   os.environ['PYOPENGL_PLATFORM'] = 'posix'
>   import OpenGL
>   # check if we have the features we want, if not...
>   if reload_opengl_platform:
>     os.environ['PYOPENGL_PLATFORM'] = 'osmesa'
>     reload(OpenGL)
>
> I did not test the`reload' code above, your results may vary.
>
>
> On 3/9/17 1:57 PM, Oliver Marks wrote:
>
> I am not sure if this is an issue now there are a few things I have
> noticed it occurs when using osmesa on x11 and wayland.
>
> I can now run it on both with x11 it just works in wayland if i prefix
> PYOPENGL_PLATFORM = "EGL" then it works.
>
> I am using ubuntu 16.10 and python-gobject 3.22.0-1 from the repository.
>
>
> PYOPENGL_PLATFORM = "EGL"
>
> I have a gi gtkglarea example on stack overflow
> http://stackoverflow.com/questions/42185728/why-is-glgenvertexarrays-undefined-in-pyopengl-when-using-gtkglarea
> .
>
>
> Tried to use Glut which i have never used before but that seems to be a
> world of pain and brings up new errors :/
>
> - using EGL NotImplementedError: Platform does not define a GLUT font
> retrieval function
> - using osmesa gives me TypeError: unhashable type contextdata.py", line
> 106, in getValue
> - using glx gives me glGenVertexArrays(1) this function takes at least 2
> arguments (1 given)
>
> This is where i got to with the code but it could be completely wrong as
> you don't seem to manage context in the same way but i did not find many
> glut examples most see to use pygame.
>
> https://gist.github.com/olymk2/b156f7490e3f5662e2fa0cf42b8c7c63
>
>
> Anyway my code kind of works I just dont 100% get why i need to prefix I
> would not want to tell a user they need todo that, so is there a way i can
> detect the profiles and select the best on startup
>
>
>
>
>
>
>
>
> On Wed, Mar 8, 2017 at 3:25 PM Matti Kariluoma <mat...@gm...>
> wrote:
>
> I will take a look on Saturday.
>
> 1) In the meantime, could you create a minimal example that demonstrates
> the problem?
>
> Its always very interesting to see simple-looking code that works on some
> platforms but doesn't work on others; we just had an example of such two
> weeks ago from another user.
>
> Ideally your minimal example would not involve the use of the `gi' module,
> or at the very least, include instructions to bring a fresh installation up
> with that package installed, i.e. "sudo apt-get install ..."
>
> 2) Does your problem require `gi' for this error to show?
>
> 3) Is the error reproducible under GLUT or GLFW?
>
> 4) If (2), what steps are needed to install `gi', and what version of `gi'?
> On 3/5/17 12:49 PM, Oly wrote:
>
> Just another thing of note,
>
> using PYOPENGL_PLATFORM = "osmesa" with x11 causes the same issue, so it
> would appear related to the mesa drivers.
>
> What other options can that take, can i enforce nvidia or intel instead of
> osmesa ?
>
> perhaps wayland is defaulting to mesa and x11 is using something else.
>
> feels like i am getting nearer to a solution, or at least a work around.
>
>
>
> On Sun, 5 Mar 2017 at 17:29 Oly <ol...@gm...> wrote:
>
> Also because it maybe useful, i have this being reported by gtk / opengl.
>
>
> Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
> OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
> OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
> Shader Language version 4.50
>
> so it looks like things should be new enough to support that feature under
> wayland.
>
>
> On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...> wrote:
>
> Thanks for the offer not sure how i missed your reply.
>
> Anyway i made some progress, yes my issue is with linux and gtk
> specifically I have also found out it has something todo with wayland.
>
> Running the example i can get it to work with my intel and nvidia graphics
> (optimus card) on x11 but if i am using wayland then i get the error above.
>
> Not sure why wayland would effect what available to me anyone seen
> anything similar ?
>
> Seems it i graphics card related.
>
> I did not know about this trick PYOPENGL_PLATFORM="osmesa" so thats useful
> to know but it does not help unfortunately.
>
>
> On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma <mat...@gm...>
> wrote:
>
> I tried to have a look at your code, but I don't have the `gi' package
> on my machine, and `pip install gi' can't find it either.
>
> 1) Would you accept help in the form of a program that starts with
> `from OpenGL import GLUT' , or does your problem require gi?
>
> As for the error you posted, looking at https://mesamatrix.net/ I see
> that glGenVertexArrays is a part of OpenGL 3.0, extension
> GL_ARB_vertex_array_object which seems to have broad support.
>
> 2) Maybe your graphics device (or its driver) is ancient?
>
> Since your gist seems to indicate you are using GTK, I assume you are
> running this under Linux. You may want to look into running PyOpenGL
> under mesa, using one of their software renderers if for whatever
> reason you don't have OpenGL3.0 support.
>
> Using the mesa CPU renderer under Linux:
>
> http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>
> >From: Oliver Marks <oly@di...> <oly@di...> - 2017-02-11 22:40:09
> >
> >Thought i would have a stab at trying to make this work, I cant find any
> >existing working examples.
> >
> >I have linked a gist if any one want to try.
> >
> >currently I am getting this error.
> >
> >OpenGL.error.NullFunctionError: Attempt to call an undefined function
> >glGenVertexArrays, check for bool(glGenVertexArrays) before calling
> >
> >Which to me sounds like its not available to the context, GLArea is
> >supplying the context so i am unsure why this would be ?
> >
> >Any ideas or can anyone give me some pointers ?
> >
> >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using PyopenGL with GLArea

[Matti K. <mat...@gm...>]

I forked your gist: 
https://gist.github.com/matti-kariluoma/7786a620abe87deb54c6012b07ded884

I added error-checking to work around the errors I encountered, and 
placed a print-statement to show how to check which PyOpenGL Platform is 
loaded at runtime.

When I tried to run either gist on my Nvidia+Debian laptop (pyopengl 
3.0.2), the program crashed immediately with an error similar to: 
http://askubuntu.com/questions/175744/x-error-of-failed-request-badrequest-invalid-request-code-or-no-such-operation

When I tried to run your gist on my Intel+Ubuntu 16.10 machine, your 
gist gives the errors you described. After making my changes, my gist 
displayed a red triangle with platforms "linux2" and "posix".

==

 > I just dont 100% get why i need to prefix I would not want to tell a 
user they need todo that

PYOPENGL_PLATFORM allows one codebase to support osx, windows, and 
various linux flavors. A platform is selected at runtime to simplify the 
distribution of PyOpenGL. Some platforms implement things differently- 
there will always be bugs or missing functionality when running on 
different platforms. Avoid the use of `from X import *' to make your 
code more likely to run on a different platform. Instead of:
   from OpenGL.GLUT import *
   glutInit([])
...try:
   from OpenGL import GLUT as glut
   glut.glutInit([])
... you'd be surprised how much this helps platform portability.

Each of the platforms has various dependencies that are not installed 
when you get pyopengl from source or pip, however the system package 
manager (apt) will download the dependencies automatically (e.g. 
freeglut3, etc.) for your system's recommended platform. Some of the 
"optional" platforms (osmesa, egl) do not have packages in apt, so 
you'll need to install the dependencies yourself. This becomes very 
complicated when you use external PPAs, or build your own drivers and 
libraries!

Hint: Use strace to see which drivers/libraries are being used by your 
process, to ensure you are using the drivers/libraries you intend:
   $ strace python glutexample.py 2>&1 | grep open
==

 >is there a way i can detect the profiles and select the best on startup ?

You can choose between PyOpenGL platforms at runtime by setting 
`os.environ' in your code:
   import os
   os.environ['PYOPENGL_PLATFORM'] = 'posix'
   import OpenGL

...you /should/ be able to use the `reload' function 
(http://stackoverflow.com/questions/437589/how-do-i-unload-reload-a-python-module) 
to choose a different platform at runtime:
   import os
   os.environ['PYOPENGL_PLATFORM'] = 'posix'
   import OpenGL
   # check if we have the features we want, if not...
   if reload_opengl_platform:
     os.environ['PYOPENGL_PLATFORM'] = 'osmesa'
     reload(OpenGL)

I did not test the`reload' code above, your results may vary.

On 3/9/17 1:57 PM, Oliver Marks wrote:
> I am not sure if this is an issue now there are a few things I have 
> noticed it occurs when using osmesa on x11 and wayland.
>
> I can now run it on both with x11 it just works in wayland if i prefix 
> PYOPENGL_PLATFORM = "EGL" then it works.
>
> I am using ubuntu 16.10 and python-gobject 3.22.0-1 from the repository.
>
>
> PYOPENGL_PLATFORM = "EGL"
>
> I have a gi gtkglarea example on stack overflow 
> http://stackoverflow.com/questions/42185728/why-is-glgenvertexarrays-undefined-in-pyopengl-when-using-gtkglarea.
>
>
> Tried to use Glut which i have never used before but that seems to be 
> a world of pain and brings up new errors :/
>
> - using EGL NotImplementedError: Platform does not define a GLUT font 
> retrieval function
> - using osmesa gives me TypeError: unhashable type contextdata.py", 
> line 106, in getValue
> - using glx gives me glGenVertexArrays(1) this function takes at least 
> 2 arguments (1 given)
>
> This is where i got to with the code but it could be completely wrong 
> as you don't seem to manage context in the same way but i did not find 
> many glut examples most see to use pygame.
>
> https://gist.github.com/olymk2/b156f7490e3f5662e2fa0cf42b8c7c63
>
>
> Anyway my code kind of works I just dont 100% get why i need to prefix 
> I would not want to tell a user they need todo that, so is there a way 
> i can detect the profiles and select the best on startup
>
>
>
>
>
>
>
>
> On Wed, Mar 8, 2017 at 3:25 PM Matti Kariluoma 
> <mat...@gm... <mailto:mat...@gm...>> wrote:
>
>     I will take a look on Saturday.
>
>     1) In the meantime, could you create a minimal example that
>     demonstrates the problem?
>
>     Its always very interesting to see simple-looking code that works
>     on some platforms but doesn't work on others; we just had an
>     example of such two weeks ago from another user.
>
>     Ideally your minimal example would not involve the use of the `gi'
>     module, or at the very least, include instructions to bring a
>     fresh installation up with that package installed, i.e. "sudo
>     apt-get install ..."
>
>     2) Does your problem require `gi' for this error to show?
>
>     3) Is the error reproducible under GLUT or GLFW?
>
>     4) If (2), what steps are needed to install `gi', and what version
>     of `gi'?
>
>     On 3/5/17 12:49 PM, Oly wrote:
>>     Just another thing of note,
>>
>>     using PYOPENGL_PLATFORM = "osmesa" with x11 causes the same
>>     issue, so it would appear related to the mesa drivers.
>>
>>     What other options can that take, can i enforce nvidia or intel
>>     instead of osmesa ?
>>
>>     perhaps wayland is defaulting to mesa and x11 is using something
>>     else.
>>
>>     feels like i am getting nearer to a solution, or at least a work
>>     around.
>>
>>
>>
>>     On Sun, 5 Mar 2017 at 17:29 Oly <ol...@gm...
>>     <mailto:ol...@gm...>> wrote:
>>
>>         Also because it maybe useful, i have this being reported by
>>         gtk / opengl.
>>
>>         Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
>>         OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
>>         OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
>>         Shader Language version 4.50
>>
>>         so it looks like things should be new enough to support that
>>         feature under wayland.
>>
>>
>>         On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...
>>         <mailto:ol...@gm...>> wrote:
>>
>>             Thanks for the offer not sure how i missed your reply.
>>
>>             Anyway i made some progress, yes my issue is with linux
>>             and gtk specifically I have also found out it has
>>             something todo with wayland.
>>
>>             Running the example i can get it to work with my intel
>>             and nvidia graphics (optimus card) on x11 but if i am
>>             using wayland then i get the error above.
>>
>>             Not sure why wayland would effect what available to me
>>             anyone seen anything similar ?
>>
>>             Seems it i graphics card related.
>>
>>             I did not know about this trick
>>             PYOPENGL_PLATFORM="osmesa" so thats useful to know but it
>>             does not help unfortunately.
>>
>>
>>             On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma
>>             <mat...@gm...
>>             <mailto:mat...@gm...>> wrote:
>>
>>                 I tried to have a look at your code, but I don't have
>>                 the `gi' package
>>                 on my machine, and `pip install gi' can't find it either.
>>
>>                 1) Would you accept help in the form of a program
>>                 that starts with
>>                 `from OpenGL import GLUT' , or does your problem
>>                 require gi?
>>
>>                 As for the error you posted, looking at
>>                 https://mesamatrix.net/ I see
>>                 that glGenVertexArrays is a part of OpenGL 3.0, extension
>>                 GL_ARB_vertex_array_object which seems to have broad
>>                 support.
>>
>>                 2) Maybe your graphics device (or its driver) is ancient?
>>
>>                 Since your gist seems to indicate you are using GTK,
>>                 I assume you are
>>                 running this under Linux. You may want to look into
>>                 running PyOpenGL
>>                 under mesa, using one of their software renderers if
>>                 for whatever
>>                 reason you don't have OpenGL3.0 support.
>>
>>                 Using the mesa CPU renderer under Linux:
>>                 http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>>
>>                 >From: Oliver Marks <oly@di...> <mailto:oly@di...> -
>>                 2017-02-11 22:40:09
>>                 >
>>                 >Thought i would have a stab at trying to make this
>>                 work, I cant find any
>>                 >existing working examples.
>>                 >
>>                 >I have linked a gist if any one want to try.
>>                 >
>>                 >currently I am getting this error.
>>                 >
>>                 >OpenGL.error.NullFunctionError: Attempt to call an
>>                 undefined function
>>                 >glGenVertexArrays, check for bool(glGenVertexArrays)
>>                 before calling
>>                 >
>>                 >Which to me sounds like its not available to the
>>                 context, GLArea is
>>                 >supplying the context so i am unsure why this would be ?
>>                 >
>>                 >Any ideas or can anyone give me some pointers ?
>>                 >
>>                 >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
>>                 >
>>
>>                 ------------------------------------------------------------------------------
>>                 Check out the vibrant tech community on one of the
>>                 world's most
>>                 engaging tech sites, SlashDot.org!
>>                 http://sdm.link/slashdot
>>                 _______________________________________________
>>                 PyOpenGL Homepage
>>                 http://pyopengl.sourceforge.net
>>                 _______________________________________________
>>                 PyOpenGL-Users mailing list
>>                 PyO...@li...
>>                 <mailto:PyO...@li...>
>>                 https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>
>     ------------------------------------------------------------------------------
>     Announcing the Oxford Dictionaries API! The API offers world-renowned
>     dictionary content that is easy and intuitive to access. Sign up
>     for an
>     account today to start using our lexical data to power your apps and
>     projects. Get started today and enter our developer competition.
>     http://sdm.link/oxford_______________________________________________
>     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] Using PyopenGL with GLArea

[Oliver M. <ol...@di...>]

I am not sure if this is an issue now there are a few things I have noticed
it occurs when using osmesa on x11 and wayland.

I can now run it on both with x11 it just works in wayland if i prefix
PYOPENGL_PLATFORM = "EGL" then it works.

I am using ubuntu 16.10 and python-gobject 3.22.0-1 from the repository.


PYOPENGL_PLATFORM = "EGL"

I have a gi gtkglarea example on stack overflow
http://stackoverflow.com/questions/42185728/why-is-glgenvertexarrays-undefined-in-pyopengl-when-using-gtkglarea
.


Tried to use Glut which i have never used before but that seems to be a
world of pain and brings up new errors :/

- using EGL NotImplementedError: Platform does not define a GLUT font
retrieval function
- using osmesa gives me TypeError: unhashable type contextdata.py", line
106, in getValue
- using glx gives me glGenVertexArrays(1) this function takes at least 2
arguments (1 given)

This is where i got to with the code but it could be completely wrong as
you don't seem to manage context in the same way but i did not find many
glut examples most see to use pygame.

https://gist.github.com/olymk2/b156f7490e3f5662e2fa0cf42b8c7c63


Anyway my code kind of works I just dont 100% get why i need to prefix I
would not want to tell a user they need todo that, so is there a way i can
detect the profiles and select the best on startup ?








On Wed, Mar 8, 2017 at 3:25 PM Matti Kariluoma <mat...@gm...>
wrote:

> I will take a look on Saturday.
>
> 1) In the meantime, could you create a minimal example that demonstrates
> the problem?
>
> Its always very interesting to see simple-looking code that works on some
> platforms but doesn't work on others; we just had an example of such two
> weeks ago from another user.
>
> Ideally your minimal example would not involve the use of the `gi' module,
> or at the very least, include instructions to bring a fresh installation up
> with that package installed, i.e. "sudo apt-get install ..."
>
> 2) Does your problem require `gi' for this error to show?
>
> 3) Is the error reproducible under GLUT or GLFW?
>
> 4) If (2), what steps are needed to install `gi', and what version of `gi'?
> On 3/5/17 12:49 PM, Oly wrote:
>
> Just another thing of note,
>
> using PYOPENGL_PLATFORM = "osmesa" with x11 causes the same issue, so it
> would appear related to the mesa drivers.
>
> What other options can that take, can i enforce nvidia or intel instead of
> osmesa ?
>
> perhaps wayland is defaulting to mesa and x11 is using something else.
>
> feels like i am getting nearer to a solution, or at least a work around.
>
>
>
> On Sun, 5 Mar 2017 at 17:29 Oly <ol...@gm...> wrote:
>
> Also because it maybe useful, i have this being reported by gtk / opengl.
>
>
> Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
> OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
> OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
> Shader Language version 4.50
>
> so it looks like things should be new enough to support that feature under
> wayland.
>
>
> On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...> wrote:
>
> Thanks for the offer not sure how i missed your reply.
>
> Anyway i made some progress, yes my issue is with linux and gtk
> specifically I have also found out it has something todo with wayland.
>
> Running the example i can get it to work with my intel and nvidia graphics
> (optimus card) on x11 but if i am using wayland then i get the error above.
>
> Not sure why wayland would effect what available to me anyone seen
> anything similar ?
>
> Seems it i graphics card related.
>
> I did not know about this trick PYOPENGL_PLATFORM="osmesa" so thats useful
> to know but it does not help unfortunately.
>
>
> On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma <mat...@gm...>
> wrote:
>
> I tried to have a look at your code, but I don't have the `gi' package
> on my machine, and `pip install gi' can't find it either.
>
> 1) Would you accept help in the form of a program that starts with
> `from OpenGL import GLUT' , or does your problem require gi?
>
> As for the error you posted, looking at https://mesamatrix.net/ I see
> that glGenVertexArrays is a part of OpenGL 3.0, extension
> GL_ARB_vertex_array_object which seems to have broad support.
>
> 2) Maybe your graphics device (or its driver) is ancient?
>
> Since your gist seems to indicate you are using GTK, I assume you are
> running this under Linux. You may want to look into running PyOpenGL
> under mesa, using one of their software renderers if for whatever
> reason you don't have OpenGL3.0 support.
>
> Using the mesa CPU renderer under Linux:
>
> http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>
> >From: Oliver Marks <oly@di...> <oly@di...> - 2017-02-11 22:40:09
> >
> >Thought i would have a stab at trying to make this work, I cant find any
> >existing working examples.
> >
> >I have linked a gist if any one want to try.
> >
> >currently I am getting this error.
> >
> >OpenGL.error.NullFunctionError: Attempt to call an undefined function
> >glGenVertexArrays, check for bool(glGenVertexArrays) before calling
> >
> >Which to me sounds like its not available to the context, GLArea is
> >supplying the context so i am unsure why this would be ?
> >
> >Any ideas or can anyone give me some pointers ?
> >
> >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using PyopenGL with GLArea

[Stuart A. <st...@ya...>]

Hi,  Just a note on 'gi'.   These are the 'Gobject' (Gtk) bindings for python, and give you access to all the different 'GLib/GObject/Gtk' APIs.
https://wiki.gnome.org/Projects/PyGObject


How you install it, depends on your platform.
If you are on Linux, then your system python will already have it, if you have installed something like python-gi or python3-gi.
If you are on a mac then, homebrew and other methods work, Windows is the most difficult to get working, but is possible.


If you want to use pytho-gi from within a virtualenv you can install 'vext.gi'* from pypi.  Vext lets the python in the virtualenv access these modules in the system python.

*Disclaimer - I am the author of vext + made it to make using virtualenv + Gtk easier. https://pypi.python.org/pypi/vext.gi



S++ 

    On Wednesday, March 8, 2017 3:25 PM, Matti Kariluoma <mat...@gm...> wrote:
 

  I will take a look on Saturday. 1) In the meantime, could you create a minimal example that demonstrates the problem? 
  Its always very interesting to see simple-looking code that works on some platforms but doesn't work on others; we just had an example of such two weeks ago from another user.
  Ideally your minimal example would not involve the use of the `gi' module, or at the very least, include instructions to bring a fresh installation up with that package installed, i.e. "sudo apt-get install ..." 
  2) Does your problem require `gi' for this error to show? 
  3) Is the error reproducible under GLUT or GLFW?
  4) If (2), what steps are needed to install `gi', and what version of `gi'?
  On 3/5/17 12:49 PM, Oly wrote:
  
 Just another thing of note,
 
 using PYOPENGL_PLATFORM = "osmesa" with x11 causes the same issue, so it would appear related to the mesa drivers.
 
 What other options can that take, can i enforce nvidia or intel instead of osmesa ? 
 
 perhaps wayland is defaulting to mesa and x11 is using something else.
 
 feels like i am getting nearer to a solution, or at least a work around.
 
 
   
  On Sun, 5 Mar 2017 at 17:29 Oly <ol...@gm...> wrote:
  
  Also because it maybe useful, i have this being reported by gtk / opengl.
 
Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
 OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
 OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
 Shader Language version 4.50
 
  so it looks like things should be new enough to support that feature under wayland.
 
   
  On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...> wrote:
  
      Thanks for the offer not sure how i missed your reply.
 
  Anyway i made some progress, yes my issue is with linux and gtk specifically I have also found out it has something todo with wayland.
 
  Running the example i can get it to work with my intel and nvidia graphics (optimus card) on x11 but if i am using wayland then i get the error above.
 
  Not sure why wayland would effect what available to me anyone seen anything similar ?
 
  Seems it i graphics card related.
 
  I did not know about this trick PYOPENGL_PLATFORM="osmesa" so thats useful to know but it does not help unfortunately.
    
      
  On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma <mat...@gm...> wrote:
  
I tried to have a look at your code, but I don't have the `gi' package
 on my machine, and `pip install gi' can't find it either.
 
 1) Would you accept help in the form of a program that starts with
 `from OpenGL import GLUT' , or does your problem require gi?
 
 As for the error you posted, looking at https://mesamatrix.net/ I see
 that glGenVertexArrays is a part of OpenGL 3.0, extension
 GL_ARB_vertex_array_object which seems to have broad support.
 
 2) Maybe your graphics device (or its driver) is ancient?
 
 Since your gist seems to indicate you are using GTK, I assume you are
 running this under Linux. You may want to look into running PyOpenGL
 under mesa, using one of their software renderers if for whatever
 reason you don't have OpenGL3.0 support.
 
 Using the mesa CPU renderer under Linux:
 http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
 
 >From: Oliver Marks <oly@di...> - 2017-02-11 22:40:09
 >
 >Thought i would have a stab at trying to make this work, I cant find any
 >existing working examples.
 >
 >I have linked a gist if any one want to try.
 >
 >currently I am getting this error.
 >
 >OpenGL.error.NullFunctionError: Attempt to call an undefined function
 >glGenVertexArrays, check for bool(glGenVertexArrays) before calling
 >
 >Which to me sounds like its not available to the context, GLArea is
 >supplying the context so i am unsure why this would be ?
 >
 >Any ideas or can anyone give me some pointers ?
 >
 >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
 >
 
------------------------------------------------------------------------------
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, SlashDot.org! http://sdm.link/slashdot
 _______________________________________________
 PyOpenGL Homepage
 http://pyopengl.sourceforge.net
 _______________________________________________
 PyOpenGL-Users mailing list
 PyO...@li...
 https://lists.sourceforge.net/lists/listinfo/pyopengl-users
 
  
  
  
 
 ------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users


   

Re: [PyOpenGL-Users] Using PyopenGL with GLArea

[Matti K. <mat...@gm...>]

I will take a look on Saturday.

1) In the meantime, could you create a minimal example that demonstrates 
the problem?

Its always very interesting to see simple-looking code that works on 
some platforms but doesn't work on others; we just had an example of 
such two weeks ago from another user.

Ideally your minimal example would not involve the use of the `gi' 
module, or at the very least, include instructions to bring a fresh 
installation up with that package installed, i.e. "sudo apt-get install 
..."

2) Does your problem require `gi' for this error to show?

3) Is the error reproducible under GLUT or GLFW?

4) If (2), what steps are needed to install `gi', and what version of `gi'?

On 3/5/17 12:49 PM, Oly wrote:
> Just another thing of note,
>
> using PYOPENGL_PLATFORM = "osmesa" with x11 causes the same issue, so 
> it would appear related to the mesa drivers.
>
> What other options can that take, can i enforce nvidia or intel 
> instead of osmesa ?
>
> perhaps wayland is defaulting to mesa and x11 is using something else.
>
> feels like i am getting nearer to a solution, or at least a work around.
>
>
>
> On Sun, 5 Mar 2017 at 17:29 Oly <ol...@gm... 
> <mailto:ol...@gm...>> wrote:
>
>     Also because it maybe useful, i have this being reported by gtk /
>     opengl.
>
>     Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
>     OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
>     OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
>     Shader Language version 4.50
>
>     so it looks like things should be new enough to support that
>     feature under wayland.
>
>
>     On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...
>     <mailto:ol...@gm...>> wrote:
>
>         Thanks for the offer not sure how i missed your reply.
>
>         Anyway i made some progress, yes my issue is with linux and
>         gtk specifically I have also found out it has something todo
>         with wayland.
>
>         Running the example i can get it to work with my intel and
>         nvidia graphics (optimus card) on x11 but if i am using
>         wayland then i get the error above.
>
>         Not sure why wayland would effect what available to me anyone
>         seen anything similar ?
>
>         Seems it i graphics card related.
>
>         I did not know about this trick PYOPENGL_PLATFORM="osmesa" so
>         thats useful to know but it does not help unfortunately.
>
>
>         On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma
>         <mat...@gm... <mailto:mat...@gm...>>
>         wrote:
>
>             I tried to have a look at your code, but I don't have the
>             `gi' package
>             on my machine, and `pip install gi' can't find it either.
>
>             1) Would you accept help in the form of a program that
>             starts with
>             `from OpenGL import GLUT' , or does your problem require gi?
>
>             As for the error you posted, looking at
>             https://mesamatrix.net/ I see
>             that glGenVertexArrays is a part of OpenGL 3.0, extension
>             GL_ARB_vertex_array_object which seems to have broad support.
>
>             2) Maybe your graphics device (or its driver) is ancient?
>
>             Since your gist seems to indicate you are using GTK, I
>             assume you are
>             running this under Linux. You may want to look into
>             running PyOpenGL
>             under mesa, using one of their software renderers if for
>             whatever
>             reason you don't have OpenGL3.0 support.
>
>             Using the mesa CPU renderer under Linux:
>             http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>
>             >From: Oliver Marks <oly@di...> - 2017-02-11 22:40:09
>             >
>             >Thought i would have a stab at trying to make this work,
>             I cant find any
>             >existing working examples.
>             >
>             >I have linked a gist if any one want to try.
>             >
>             >currently I am getting this error.
>             >
>             >OpenGL.error.NullFunctionError: Attempt to call an
>             undefined function
>             >glGenVertexArrays, check for bool(glGenVertexArrays)
>             before calling
>             >
>             >Which to me sounds like its not available to the context,
>             GLArea is
>             >supplying the context so i am unsure why this would be ?
>             >
>             >Any ideas or can anyone give me some pointers ?
>             >
>             >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
>             >
>
>             ------------------------------------------------------------------------------
>             Check out the vibrant tech community on one of the world's
>             most
>             engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>             _______________________________________________
>             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] Using PyopenGL with GLArea

[Oly <ol...@gm...>]

Just another thing of note,

using PYOPENGL_PLATFORM = "osmesa" with x11 causes the same issue, so it
would appear related to the mesa drivers.

What other options can that take, can i enforce nvidia or intel instead of
osmesa ?

perhaps wayland is defaulting to mesa and x11 is using something else.

feels like i am getting nearer to a solution, or at least a work around.




On Sun, 5 Mar 2017 at 17:29 Oly <ol...@gm...> wrote:

> Also because it maybe useful, i have this being reported by gtk / opengl.
>
>
> Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
> OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
> OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
> Shader Language version 4.50
>
> so it looks like things should be new enough to support that feature under
> wayland.
>
>
> On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...> wrote:
>
> Thanks for the offer not sure how i missed your reply.
>
> Anyway i made some progress, yes my issue is with linux and gtk
> specifically I have also found out it has something todo with wayland.
>
> Running the example i can get it to work with my intel and nvidia graphics
> (optimus card) on x11 but if i am using wayland then i get the error above.
>
> Not sure why wayland would effect what available to me anyone seen
> anything similar ?
>
> Seems it i graphics card related.
>
> I did not know about this trick PYOPENGL_PLATFORM="osmesa" so thats useful
> to know but it does not help unfortunately.
>
>
> On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma <mat...@gm...>
> wrote:
>
> I tried to have a look at your code, but I don't have the `gi' package
> on my machine, and `pip install gi' can't find it either.
>
> 1) Would you accept help in the form of a program that starts with
> `from OpenGL import GLUT' , or does your problem require gi?
>
> As for the error you posted, looking at https://mesamatrix.net/ I see
> that glGenVertexArrays is a part of OpenGL 3.0, extension
> GL_ARB_vertex_array_object which seems to have broad support.
>
> 2) Maybe your graphics device (or its driver) is ancient?
>
> Since your gist seems to indicate you are using GTK, I assume you are
> running this under Linux. You may want to look into running PyOpenGL
> under mesa, using one of their software renderers if for whatever
> reason you don't have OpenGL3.0 support.
>
> Using the mesa CPU renderer under Linux:
>
> http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>
> >From: Oliver Marks <oly@di...> - 2017-02-11 22:40:09
> >
> >Thought i would have a stab at trying to make this work, I cant find any
> >existing working examples.
> >
> >I have linked a gist if any one want to try.
> >
> >currently I am getting this error.
> >
> >OpenGL.error.NullFunctionError: Attempt to call an undefined function
> >glGenVertexArrays, check for bool(glGenVertexArrays) before calling
> >
> >Which to me sounds like its not available to the context, GLArea is
> >supplying the context so i am unsure why this would be ?
> >
> >Any ideas or can anyone give me some pointers ?
> >
> >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>

Re: [PyOpenGL-Users] Using PyopenGL with GLArea

[Oly <ol...@gm...>]

Also because it maybe useful, i have this being reported by gtk / opengl.

Intel_Open_Source_Technology_Center_4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA_Mesa_DRI_Intel(R)_Kabylake_GT2__4.50
OpenGL Version 4.5_(Core_Profile)_Mesa_17.0.0_-_padoka_PPA
OpenGL Renderer Mesa_DRI_Intel(R)_Kabylake_GT2_
Shader Language version 4.50

so it looks like things should be new enough to support that feature under
wayland.


On Sun, 5 Mar 2017 at 17:28 Oly <ol...@gm...> wrote:

> Thanks for the offer not sure how i missed your reply.
>
> Anyway i made some progress, yes my issue is with linux and gtk
> specifically I have also found out it has something todo with wayland.
>
> Running the example i can get it to work with my intel and nvidia graphics
> (optimus card) on x11 but if i am using wayland then i get the error above.
>
> Not sure why wayland would effect what available to me anyone seen
> anything similar ?
>
> Seems it i graphics card related.
>
> I did not know about this trick PYOPENGL_PLATFORM="osmesa" so thats useful
> to know but it does not help unfortunately.
>
>
> On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma <mat...@gm...>
> wrote:
>
> I tried to have a look at your code, but I don't have the `gi' package
> on my machine, and `pip install gi' can't find it either.
>
> 1) Would you accept help in the form of a program that starts with
> `from OpenGL import GLUT' , or does your problem require gi?
>
> As for the error you posted, looking at https://mesamatrix.net/ I see
> that glGenVertexArrays is a part of OpenGL 3.0, extension
> GL_ARB_vertex_array_object which seems to have broad support.
>
> 2) Maybe your graphics device (or its driver) is ancient?
>
> Since your gist seems to indicate you are using GTK, I assume you are
> running this under Linux. You may want to look into running PyOpenGL
> under mesa, using one of their software renderers if for whatever
> reason you don't have OpenGL3.0 support.
>
> Using the mesa CPU renderer under Linux:
>
> http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>
> >From: Oliver Marks <oly@di...> - 2017-02-11 22:40:09
> >
> >Thought i would have a stab at trying to make this work, I cant find any
> >existing working examples.
> >
> >I have linked a gist if any one want to try.
> >
> >currently I am getting this error.
> >
> >OpenGL.error.NullFunctionError: Attempt to call an undefined function
> >glGenVertexArrays, check for bool(glGenVertexArrays) before calling
> >
> >Which to me sounds like its not available to the context, GLArea is
> >supplying the context so i am unsure why this would be ?
> >
> >Any ideas or can anyone give me some pointers ?
> >
> >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>

Re: [PyOpenGL-Users] Using PyopenGL with GLArea

[Oly <ol...@gm...>]

Thanks for the offer not sure how i missed your reply.

Anyway i made some progress, yes my issue is with linux and gtk
specifically I have also found out it has something todo with wayland.

Running the example i can get it to work with my intel and nvidia graphics
(optimus card) on x11 but if i am using wayland then i get the error above.

Not sure why wayland would effect what available to me anyone seen anything
similar ?

Seems it i graphics card related.

I did not know about this trick PYOPENGL_PLATFORM="osmesa" so thats useful
to know but it does not help unfortunately.


On Sun, 12 Feb 2017 at 20:20 Matti Kariluoma <mat...@gm...>
wrote:

> I tried to have a look at your code, but I don't have the `gi' package
> on my machine, and `pip install gi' can't find it either.
>
> 1) Would you accept help in the form of a program that starts with
> `from OpenGL import GLUT' , or does your problem require gi?
>
> As for the error you posted, looking at https://mesamatrix.net/ I see
> that glGenVertexArrays is a part of OpenGL 3.0, extension
> GL_ARB_vertex_array_object which seems to have broad support.
>
> 2) Maybe your graphics device (or its driver) is ancient?
>
> Since your gist seems to indicate you are using GTK, I assume you are
> running this under Linux. You may want to look into running PyOpenGL
> under mesa, using one of their software renderers if for whatever
> reason you don't have OpenGL3.0 support.
>
> Using the mesa CPU renderer under Linux:
>
> http://www.mattikariluoma.com/blog/Headless%20Rendered%20OpenGL%20Scenes.html
>
> >From: Oliver Marks <oly@di...> - 2017-02-11 22:40:09
> >
> >Thought i would have a stab at trying to make this work, I cant find any
> >existing working examples.
> >
> >I have linked a gist if any one want to try.
> >
> >currently I am getting this error.
> >
> >OpenGL.error.NullFunctionError: Attempt to call an undefined function
> >glGenVertexArrays, check for bool(glGenVertexArrays) before calling
> >
> >Which to me sounds like its not available to the context, GLArea is
> >supplying the context so i am unsure why this would be ?
> >
> >Any ideas or can anyone give me some pointers ?
> >
> >https://gist.github.com/olymk2/5b3e49ac83130e580bd9983f2e5d49c3
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>