pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] using glGetSynciv

[Henry G. <he...@ca...>]

On Tue, 2011-05-24 at 10:09 -0400, Mike C. Fletcher wrote:
> It doesn't attempt to create a higher-level abstraction, just makes
> the
> function easier to call from Python code by providing an alias that
> auto-allocates the buffers for you.
> 

I've been meaning to reply to this thread for a while now. The previous
problems were in trying to get a texture streaming object working well
within python. To this end, I've written a TextureStream2D object with
accompanying python GL sync object.

Its all on my github repository at:
https://github.com/hgomersall/Blog-Code/tree/master/opengl_utils

try it out by running demo.py (after applying the described patch as per
previous emails in this thread).

I hope it might be useful to somebody.

Cheers,

Henry

Re: [PyOpenGL-Users] Difference in transformation matrices

[Derakon <de...@gm...>]

Never mind, problem solved! The issue was that my second translation
was getting rotated, which was undesirable. In fact what I wanted was
to do this:

glTranslated(dx + cx, dy + cy)
glRotated(-angle, 0, 0, 1)
glTranslated(-cx, -cy, 0)

I'd tried the line swap that Ian suggested earlier, and it didn't work
(as noted in the last paragraph of my previous message), but this
appears to get me what I want.

-Chris

On Thu, Jun 9, 2011 at 1:24 PM, Derakon <de...@gm...> wrote:
> I have a program that displays 3D arrays of pixel data that have been
> transformed (by XYZ translation, rotation about the Z axis, and
> uniform scaling in X and Y -- so five parameters). When possible (i.e.
> Z offset is 0) I use OpenGL to show the transformation since this is
> fast. however, when there is a Z transform, I manually construct a
> transformation matrix with Numpy, invert it, and use it to map display
> coordinates into the data to determine what needs to be shown. That
> is, I have a bunch of XY coordinates, one for each pixel I want to
> display (e.g. from [0, 0] to [512, 512]), I reverse-transform them,
> this gives me a location in the dataset, and that gets me the value to
> display.
>
> There's a problem here: the two approaches generate different results.
> For example, here's my flat 512x512 test image (disregarding the Z
> dimension), untransformed (the grey lines are for reference and are
> not part of the image):
> http://derakon.dyndns.org/~chriswei/temp2/1.png
>
> Here's the image rotated 45° and translated 20 pixels in X, in OpenGL:
> http://derakon.dyndns.org/~chriswei/temp2/2.png
>
> (Ignore the grey triangles; they're just a display artifact)
>
> And here's that same image with the transformation applied via Numpy:
> http://derakon.dyndns.org/~chriswei/temp2/3.png
>
> The last example is the behavior I actually want -- rotation should be
> about the center of the image, and applied before translation occurs.
> However that's not what I'm getting from my OpenGL transformation
> code. I've put up a paste comparing the two approaches and what I get
> when I print their transformation matrices, here:
> http://pastebin.com/j31iLGbT
>
> Any ideas what I'm doing wrong here? I note that if I swap the order
> of the glRotated and glTranslated calls, then I get OpenGL matrices
> that look more like what I'm getting from Numpy, but of course the
> rotation is no longer about the center of the image, so the results
> are even more off.
>
> -Chris
>

Re: [PyOpenGL-Users] Difference in transformation matrices

[Ian M. <geo...@gm...>]

On Thu, Jun 9, 2011 at 1:24 PM, Derakon <de...@gm...> wrote:

> I have a program that displays 3D arrays of pixel data that have been
> transformed (by XYZ translation, rotation about the Z axis, and
> uniform scaling in X and Y -- so five parameters). When possible (i.e.
> Z offset is 0) I use OpenGL to show the transformation since this is
> fast. however, when there is a Z transform, I manually construct a
> transformation matrix with Numpy, invert it, and use it to map display
> coordinates into the data to determine what needs to be shown. That
> is, I have a bunch of XY coordinates, one for each pixel I want to
> display (e.g. from [0, 0] to [512, 512]), I reverse-transform them,
> this gives me a location in the dataset, and that gets me the value to
> display.
>
> There's a problem here: the two approaches generate different results.
> For example, here's my flat 512x512 test image (disregarding the Z
> dimension), untransformed (the grey lines are for reference and are
> not part of the image):
> http://derakon.dyndns.org/~chriswei/temp2/1.png
>
> Here's the image rotated 45° and translated 20 pixels in X, in OpenGL:
> http://derakon.dyndns.org/~chriswei/temp2/2.png
>
> (Ignore the grey triangles; they're just a display artifact)
>
> And here's that same image with the transformation applied via Numpy:
> http://derakon.dyndns.org/~chriswei/temp2/3.png
>
> The last example is the behavior I actually want -- rotation should be
> about the center of the image, and applied before translation occurs.
> However that's not what I'm getting from my OpenGL transformation
> code. I've put up a paste comparing the two approaches and what I get
> when I print their transformation matrices, here:
> http://pastebin.com/j31iLGbT
>
> Any ideas what I'm doing wrong here? I note that if I swap the order
> of the glRotated and glTranslated calls, then I get OpenGL matrices
> that look more like what I'm getting from Numpy, but of course the
> rotation is no longer about the center of the image, so the results
> are even more off.
>
Switch lines 11 and 12.

[PyOpenGL-Users] Difference in transformation matrices

[Derakon <de...@gm...>]

I have a program that displays 3D arrays of pixel data that have been
transformed (by XYZ translation, rotation about the Z axis, and
uniform scaling in X and Y -- so five parameters). When possible (i.e.
Z offset is 0) I use OpenGL to show the transformation since this is
fast. however, when there is a Z transform, I manually construct a
transformation matrix with Numpy, invert it, and use it to map display
coordinates into the data to determine what needs to be shown. That
is, I have a bunch of XY coordinates, one for each pixel I want to
display (e.g. from [0, 0] to [512, 512]), I reverse-transform them,
this gives me a location in the dataset, and that gets me the value to
display.

There's a problem here: the two approaches generate different results.
For example, here's my flat 512x512 test image (disregarding the Z
dimension), untransformed (the grey lines are for reference and are
not part of the image):
http://derakon.dyndns.org/~chriswei/temp2/1.png

Here's the image rotated 45° and translated 20 pixels in X, in OpenGL:
http://derakon.dyndns.org/~chriswei/temp2/2.png

(Ignore the grey triangles; they're just a display artifact)

And here's that same image with the transformation applied via Numpy:
http://derakon.dyndns.org/~chriswei/temp2/3.png

The last example is the behavior I actually want -- rotation should be
about the center of the image, and applied before translation occurs.
However that's not what I'm getting from my OpenGL transformation
code. I've put up a paste comparing the two approaches and what I get
when I print their transformation matrices, here:
http://pastebin.com/j31iLGbT

Any ideas what I'm doing wrong here? I note that if I swap the order
of the glRotated and glTranslated calls, then I get OpenGL matrices
that look more like what I'm getting from Numpy, but of course the
rotation is no longer about the center of the image, so the results
are even more off.

-Chris

Re: [PyOpenGL-Users] How to get OpenGL4 using PyOpenGL

[Przemysław L. <an....@gm...>]

Thx, for replay!
I'll try to play with bazar pyopengl branch.

BTW I have opengl 4.1 hwd (amd 5730M), and a bit of time (after
25.06.2011) so I think i can help in testing
and/or development (under Lin and Win).

>From: Mike C. Fletcher <mcfletch@vr...> - 2011-05-14 17:16

>On 11-05-13 05:13 AM, Przemysław Lib wrote:
>> Can I get OpenGL 4 (core profile) with PyOpenGL? (can live with
>> manually loading needed extensions one by one, but need to know if
>> they all are in PyOpenGL)
>I believe that current bzr head has all of the current extensions, they
>are auto-generated from the extension registry header files, however,
>nothing has been tested above OpenGL 3.x, as I don't have any 4.x
>hardware available on which to test/debug/develop. I also don't have a
>*lot* of 3.x code to run to test that behaviour is as expected, most of
>my test code was written back in the 1.x and 2.x days.
>> What is state of PyOpenGL development? Main site claim compatibility
>> only with OGL 3.2.
>PyOpenGL is still being developed, but it is one of a dozen of Open
>Source projects I work on in my spare time, I figure it gets about 1-2
>half-days/month. My current hardware has a 3.3 context, so I should,
>when I get the time, be able to get robust support up to 3.3 level.

Re: [PyOpenGL-Users] Tracking down an invalid operation

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

On 11-06-02 04:35 PM, Derakon wrote:
> I have an OpenGL-related crash that's giving me fits trying to trace
> it. This is gonna take a bit to describe, unfortunately.
...
> So far, so good...except that when I ramp up the rate at which the
> cameras collect images, I get irregular crashes. OpenGL reports an
> invalid operation in glDeleteTextures, though I've no idea why; I'm
> certainly not double-deleting textures, and I've put locks around
> everything remotely sensitive so it shouldn't be e.g. trying to create
> a texture in one thread while rendering in another. In fact, I
> probably have too many locks, but there's no deadlocks, so oh well.
The docs for glDeleteTextures say that the point at which it will
generate invalid operation is when called between glBegin and glEnd, you
may wish to guard that segment of render() with your self.lock. 
However, given that there should only be a single wxPython thread, you
should only have one thread rendering at a time.

As far as I recall, wx.PostEvent should do the "correct" thing in
scheduling the call in the GUI thread.  Note, however, that your C++
code is likely not GIL-locked, so unlike Python code, it can be running
between op-codes and the like.  I don't know that that would be the
problem, but it is a likely difference between the broken and working
versions.

Afraid I don't have much else to suggest off the top of my head.  I
expect you are somehow seeing interference between the C++ rendering
loop and the wxPython rendering loop, but without knowing what that C++
code is doing (i.e. is it in a thread, is it posting events to wx to do
its own rendering, etc), I can't really guess what in particular is
going wrong.

Good luck,
Mike

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

Re: [PyOpenGL-Users] Tracking down an invalid operation

[Ian M. <geo...@gm...>]

On Thu, Jun 2, 2011 at 2:35 PM, Derakon <de...@gm...> wrote:

> I should have clarified: I'm not reading the texture data out, I'm
> reading the array of brightness values that was used to generate the
> texture. Basically the camera sends us a bunch of bytes, then one of
> our viewers reads from those bytes to generate a texture. Now I'm
> adding a second viewer to read from the same set of bytes.
>
> As for multiple contexts, I may have mis-stated or maybe I am in fact
> using multiple contexts; I'm not that boned up on OpenGL. I'd assumed
> each non-overlaid camera display was its own context, since each one
> has the same texture ID of 1, and I'd assume that in a single context
> no two textures could have the same texture ID. Is this inaccurate?
>
> This app has many wxGLCanvases all over the place and I've never run
> into trouble before. This window should work just like the other
> canvases in the app. According to this:
>
> http://wiki.wxwidgets.org/WxGLCanvas#Sharing_wxGLCanvas_context
>
> it should be possible to share the OpenGL context across canvases, but
> we aren't doing that right now. Of course none of the canvases are
> trying to share resources either.
>
> It sounds like you're suggesting that in the middle of my viewer's
> paint logic, another context is barging in and confusing OpenGL. I
> take that to mean that when I make an OpenGL API call, my context
> isn't implicitly passed along? But then why wouldn't my other canvases
> ever get screwed up? Assuming that is the problem, theoretically I
> could fix that by creating one canvas, getting its context, and then
> storing that globally and using it whenever I create any other
> canvases. Does that sound about right?
>
Not sure exactly.  I just know that having one application and several
contexts gets dicey quickly.  Personally, I'd go with the single context, as
that should fix any problems therein.

It seems to me that you can minimize any problems by making one texture for
each context, and then just updating that texture with the given bytes
(glCopyTex[Sub]Image2D(...), though you might already be doing that.

Ian

Re: [PyOpenGL-Users] Tracking down an invalid operation

[Derakon <de...@gm...>]

On Thu, Jun 2, 2011 at 2:23 PM, Ian Mallett <geo...@gm...> wrote:
> On Thu, Jun 2, 2011 at 1:35 PM, Derakon <de...@gm...> wrote:
>>
>> I have an OpenGL-related crash that's giving me fits trying to trace
>> it. This is gonna take a bit to describe, unfortunately.
>>
>> We have a computerized microscope with four cameras which each image
>> different wavelength bands (colors) of the sample as 512x512 pixel
>> arrays. These are displayed as OpenGL textures by some C++ code. I've
>> made an overlaid view as a separate window, which runs in Python --
>> our C++ code is old and crufty and every time I touch it I'm worried
>> it'll collapse into dust, but the Python "half" (more like 80%) of the
>> program is more up-to-date. Basically, each time a camera receives new
>> image, an event is generated on the C++ side, which is picked up by
>> the Python side. The Python side makes a request to the C++ side for
>> the image data, converts that into its own texture, and displays it.
>> Ideally I'd just re-use the same textures the normal camera displays
>> use, but they're in separate OpenGL contexts so, as far as I'm aware,
>> that's not possible.
>
> Hi,
>
> Generally, having multiple contexts in OpenGL is a very very very bad idea.
> If you're doing a readback of the texture data from one context, and then
> trying to use that data in another, it may not work properly, because OpenGL
> works asynchronously.
>

I should have clarified: I'm not reading the texture data out, I'm
reading the array of brightness values that was used to generate the
texture. Basically the camera sends us a bunch of bytes, then one of
our viewers reads from those bytes to generate a texture. Now I'm
adding a second viewer to read from the same set of bytes.

As for multiple contexts, I may have mis-stated or maybe I am in fact
using multiple contexts; I'm not that boned up on OpenGL. I'd assumed
each non-overlaid camera display was its own context, since each one
has the same texture ID of 1, and I'd assume that in a single context
no two textures could have the same texture ID. Is this inaccurate?

This app has many wxGLCanvases all over the place and I've never run
into trouble before. This window should work just like the other
canvases in the app. According to this:

http://wiki.wxwidgets.org/WxGLCanvas#Sharing_wxGLCanvas_context

it should be possible to share the OpenGL context across canvases, but
we aren't doing that right now. Of course none of the canvases are
trying to share resources either.

It sounds like you're suggesting that in the middle of my viewer's
paint logic, another context is barging in and confusing OpenGL. I
take that to mean that when I make an OpenGL API call, my context
isn't implicitly passed along? But then why wouldn't my other canvases
ever get screwed up? Assuming that is the problem, theoretically I
could fix that by creating one canvas, getting its context, and then
storing that globally and using it whenever I create any other
canvases. Does that sound about right?

-Chris

Re: [PyOpenGL-Users] Tracking down an invalid operation

[Ian M. <geo...@gm...>]

On Thu, Jun 2, 2011 at 1:35 PM, Derakon <de...@gm...> wrote:

> I have an OpenGL-related crash that's giving me fits trying to trace
> it. This is gonna take a bit to describe, unfortunately.
>
> We have a computerized microscope with four cameras which each image
> different wavelength bands (colors) of the sample as 512x512 pixel
> arrays. These are displayed as OpenGL textures by some C++ code. I've
> made an overlaid view as a separate window, which runs in Python --
> our C++ code is old and crufty and every time I touch it I'm worried
> it'll collapse into dust, but the Python "half" (more like 80%) of the
> program is more up-to-date. Basically, each time a camera receives new
> image, an event is generated on the C++ side, which is picked up by
> the Python side. The Python side makes a request to the C++ side for
> the image data, converts that into its own texture, and displays it.
> Ideally I'd just re-use the same textures the normal camera displays
> use, but they're in separate OpenGL contexts so, as far as I'm aware,
> that's not possible.
>
Hi,

Generally, having multiple contexts in OpenGL is a very very very bad idea.
If you're doing a readback of the texture data from one context, and then
trying to use that data in another, it may not work properly, because OpenGL
works asynchronously.

In a single context, OpenGL calls will execute in order--but some won't
block while they do the underlying work.  In the context isn't managed, the
context will get confused.  If the work done by one context isn't done
(e.g., copy this texture) and another context gets a function call in
edge-wise, you'll have problems.

Ian

[PyOpenGL-Users] Tracking down an invalid operation

[Derakon <de...@gm...>]

I have an OpenGL-related crash that's giving me fits trying to trace
it. This is gonna take a bit to describe, unfortunately.

We have a computerized microscope with four cameras which each image
different wavelength bands (colors) of the sample as 512x512 pixel
arrays. These are displayed as OpenGL textures by some C++ code. I've
made an overlaid view as a separate window, which runs in Python --
our C++ code is old and crufty and every time I touch it I'm worried
it'll collapse into dust, but the Python "half" (more like 80%) of the
program is more up-to-date. Basically, each time a camera receives new
image, an event is generated on the C++ side, which is picked up by
the Python side. The Python side makes a request to the C++ side for
the image data, converts that into its own texture, and displays it.
Ideally I'd just re-use the same textures the normal camera displays
use, but they're in separate OpenGL contexts so, as far as I'm aware,
that's not possible.

So far, so good...except that when I ramp up the rate at which the
cameras collect images, I get irregular crashes. OpenGL reports an
invalid operation in glDeleteTextures, though I've no idea why; I'm
certainly not double-deleting textures, and I've put locks around
everything remotely sensitive so it shouldn't be e.g. trying to create
a texture in one thread while rendering in another. In fact, I
probably have too many locks, but there's no deadlocks, so oh well.

I made a standalone application. It doesn't crash. I copied the
standalone app's code back into the main program and hooked it back
in. It crashes. I severed the code that retrieves the image array from
the C++ side in favor of displaying a randomly-generated pixel array.
It still crashes. At this point the only connection this system has to
the rest of the program is the event notification.

Here's the standalone, non-crashy version of the program:
http://pastebin.com/p2QtTSZf
(requires PyOpenGL, wxPython, numpy)

The only difference between this version and the version running in
the actual app is the source of the events that trigger
onNewImageReady (and that the in-app version doesn't make its own
wxApp, of course).

Any ideas? I'm completely stumped.

Also, I've noticed a secondary issue: when this version is running in
the main app and hasn't crashed yet, other OpenGL canvases that use
FTGL to draw text will sometimes instead draw solid blocks of color
(or once, I saw black with random green lines across it) where the
text should be. I don't know if this is related. How is display in one
window affecting display in another?

-Chris

Re: [PyOpenGL-Users] using glGetSynciv

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

On 11-05-24 05:33 AM, Henry Gomersall wrote:
> On Mon, 2011-05-23 at 22:55 -0400, Mike C. Fletcher wrote:
>> Okay, I constructed my own test case so I could see what the problem
>> is.  There was a bug in the declaration of GLsync, which was declared
>> to
>> be a c_void_p, it should have been declared as a ctypes.POINTER(
>> structure ).  I had thought c_void_p would create an opaque pointer
>> type
>> as a return-type, but apparently ctypes short-circuits it to return an
>> integer.
>>
>> I've checked a fix into bzr, and that should appear in the next
>> release
>> of PyOpenGL.  In the meantime, you can patch your copy of PyOpenGL
>> with
>> this: 
> Yeah, that fixes it - thank you. I've got the fence test code working as
> follows now:
>
> from OpenGL.GL.ARB import sync as GL_sync
> ...
> my_sync = \
> 	GL_sync.glFenceSync(GL_sync.GL_SYNC_GPU_COMMANDS_COMPLETE, 0)
>         
> fence_status = GL.GLint(0)
> GL_sync.glGetSynciv(my_sync,
> GL_sync.GL_SYNC_STATUS, GL.GLint(1), GL.GLint(0), fence_status)
>         
> print GL_sync.GL_UNSIGNALED == fence_status.value
>
> A couple of things come to light with this code. Firstly, as it is
> fence_status can only return a single argument. I couldn't work out how
> to instantiate GLintArray (it allows raises the following exception:
> TypeError: Cannot create instance: has no _type_ ). This isn't a problem
> as it stands because all the parameters will only return a single value.
>>> from OpenGL.arrays import GLintArray
>>> GLintArray.zeros( (2,3) )
array([[0, 0, 0],
       [0, 0, 0]], dtype=int32)
> Secondly, its pretty unpythonic as it stands. I understand that the
> PyOpenGL is a pretty thin shim around OpenGL, but this seems like a good
> opportunity for a little more logic on the python side, returning a
> datatype that is more conducive to being tested, or even better, a whole
> wrapper around the sync object.
>
> Is there any movement by anyone to make the whole OpenGL experience more
> pythonic? It strikes me that its starting to make a lot of sense with
> the buffers and shaders paradigm. I guess there is something towards
> this end with Qt and PySide/PyQt. Do any of the various game engines
> offer similar?
I'm torn on the issue.  Historically every time we (or I) have pulled
higher-level wrapper functionality into the core package, we have wound
up regretting it as the march of years means the APIs become obsolete or
broken (or just need to be maintained).  That said, I've recently added
the VBO and GL.shaders wrappers, mostly because it was so painful
working with the low-level APIs that I couldn't get demos/tests written
without them.

The problem seems to be finding a balance between making it easy to
code, and getting so radically far from the underlying API that we've
created a new intermediate API.  A truly usable/pythonic 3D API should
likely be a separate package with PyOpenGL (or just raw OpenGL) as a
dependency (i.e. a rendering engine).  At least, that's how I feel about
it this morning, before I have my coffee :) .

The ARB.sync module does appear rather awkward right now, as it appears
the ARB is planning for lots more features than are currently
available.  It would likely be reasonable to provide a glGetsynciv
wrapper that creates the arrays for you if you pass None.  For
reference, here's what my test code looks like:

http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/arbsync.py
<http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/arbsync.py>

And here's the convenience wrapper I've just added:

http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/view/head:/OpenGL/GL/ARB/sync.py
<http://bazaar.launchpad.net/%7Emcfletch/pyopengl/trunk/view/head:/OpenGL/GL/ARB/sync.py>

It doesn't attempt to create a higher-level abstraction, just makes the
function easier to call from Python code by providing an alias that
auto-allocates the buffers for you.

Enjoy,
Mike

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

Re: [PyOpenGL-Users] using glGetSynciv

[Henry G. <he...@ca...>]

On Mon, 2011-05-23 at 22:55 -0400, Mike C. Fletcher wrote:
> Okay, I constructed my own test case so I could see what the problem
> is.  There was a bug in the declaration of GLsync, which was declared
> to
> be a c_void_p, it should have been declared as a ctypes.POINTER(
> structure ).  I had thought c_void_p would create an opaque pointer
> type
> as a return-type, but apparently ctypes short-circuits it to return an
> integer.
> 
> I've checked a fix into bzr, and that should appear in the next
> release
> of PyOpenGL.  In the meantime, you can patch your copy of PyOpenGL
> with
> this: 

Yeah, that fixes it - thank you. I've got the fence test code working as
follows now:

from OpenGL.GL.ARB import sync as GL_sync
...
my_sync = \
	GL_sync.glFenceSync(GL_sync.GL_SYNC_GPU_COMMANDS_COMPLETE, 0)
        
fence_status = GL.GLint(0)
GL_sync.glGetSynciv(my_sync,
GL_sync.GL_SYNC_STATUS, GL.GLint(1), GL.GLint(0), fence_status)
        
print GL_sync.GL_UNSIGNALED == fence_status.value

A couple of things come to light with this code. Firstly, as it is
fence_status can only return a single argument. I couldn't work out how
to instantiate GLintArray (it allows raises the following exception:
TypeError: Cannot create instance: has no _type_ ). This isn't a problem
as it stands because all the parameters will only return a single value.

Secondly, its pretty unpythonic as it stands. I understand that the
PyOpenGL is a pretty thin shim around OpenGL, but this seems like a good
opportunity for a little more logic on the python side, returning a
datatype that is more conducive to being tested, or even better, a whole
wrapper around the sync object.

Is there any movement by anyone to make the whole OpenGL experience more
pythonic? It strikes me that its starting to make a lot of sense with
the buffers and shaders paradigm. I guess there is something towards
this end with Qt and PySide/PyQt. Do any of the various game engines
offer similar?

Cheers,
HEnry

Re: [PyOpenGL-Users] using glGetSynciv

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

On 11-05-23 05:44 PM, Henry Gomersall wrote:
...
> That didn't seem to be the problem.
>
> I've had a bit more of a play. Its seems that the problem is *actually*
> the first argument: my_sync is an integer. I can't find the type that it
> actually needs as the argument though. I've not idea what GLsync
> actually is.
>
> Cheers,
>
> Henry
Okay, I constructed my own test case so I could see what the problem
is.  There was a bug in the declaration of GLsync, which was declared to
be a c_void_p, it should have been declared as a ctypes.POINTER(
structure ).  I had thought c_void_p would create an opaque pointer type
as a return-type, but apparently ctypes short-circuits it to return an
integer.

I've checked a fix into bzr, and that should appear in the next release
of PyOpenGL.  In the meantime, you can patch your copy of PyOpenGL with
this:

=== modified file 'OpenGL/constants.py'
--- OpenGL/constants.py 2011-04-12 19:23:44 +0000
+++ OpenGL/constants.py 2011-05-24 02:47:52 +0000
@@ -103,7 +103,9 @@
 # GL.ARB.sync extension, GLsync is an opaque pointer to a struct
 # in the extensions header, basically just a "token" that can be
 # passed to the various operations...
-GLsync = ctypes.c_void_p
+class _GLsync( ctypes.Structure ):
+    """Opaque structure definition to fool ctypes into treating us as a
real structure"""
+GLsync = ctypes.POINTER( _GLsync ) # ctypes.c_void_p does *not* work as
a return type...
 GLvoidp = ctypes.c_void_p
 
 ARRAY_TYPE_TO_CONSTANT = [

HTH,
Mike

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

Re: [PyOpenGL-Users] Code readability

[SAn <gri...@gm...>]

On Mon, May 23, 2011 at 16:34, Mike C. Fletcher <mcf...@vr...> wrote:
> On 11-05-21 11:47 AM, SAn wrote:
>> Hi! I am trying to understand pyopengl VBO implementation, well, the
>> whole OpenGL.array package.
>>
>> Is there a reason why the code is written so "anti-pep8/python zen"
>> way? Like that there isn't a new line between class methods, etc.
>> Maybe because of consistence with the automatic generator?
> Mostly because it is written by one crusty old pythonista who pre-dates
> PEP-8 (heck, PEPs entirely) by a significant period, and who looks at
> PEP-8 conformance as something those young whippersnappers do ;) :D .
> Be happy I finally gave in and started using spaces instead of tabs :)
> .  It took a plea directly from Pete Shinners (or maybe it was René?
> been a while) to get that to happen, and I felt dirty for months after.

> I'm fine with accepting a pep-8 patch, but keep in mind that APIs should
> not change, and I'm really not all that worried about keeping the
> code-base PEP-8-ified moving forward... that is, I can't guarantee I
> won't edit the files at some point and make them match my personal
> preference again :) .  If I start seeing people contributing code
> frequently I might revisit that opinion, but if it's still basically
> just me, I'll likely just do as comes naturally.

Ohh i see! I understand you.

I will be pep-8ing the code that have to read and eventually send you a patch.

Thanks for the reply!
SAn

Re: [PyOpenGL-Users] using glGetSynciv

[Henry G. <he...@ca...>]

On Mon, 2011-05-23 at 15:08 -0400, Mike C. Fletcher wrote:
> > my_sync = GL_sync.glFenceSync(GL_sync.GL_SYNC_GPU_COMMANDS_COMPLETE,
> 0)
> >         
> > a = numpy.zeros(10, dtype='uint32')
> > foo = GL_sync.glGetSynciv(my_sync,
> >                 GL_sync.GL_SYNC_STATUS,
> >                 10, None, a)
> >
> > Running it returns the following error that I am having trouble
> parsing:
> >
> > ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>:
> > ("byref() argument must be a ctypes instance, not 'int'", ' If you
> have
> > ERROR_ON_COPY enabled, remember to pass in an array to
> array-requiring
> > functions.')
> >
> > The trouble is that I'm not sure to which argument it is referring.
> I am
> > not sufficiently familiar with the PyOpenGL interface.
> It's a little obtuse there, I believe the problem is the None, it
> should
> be a GL.GLsizei() instance (or a single-integer numpy array).  It will
> have its .value set to the number of records written into a.
> 

That didn't seem to be the problem.

I've had a bit more of a play. Its seems that the problem is *actually*
the first argument: my_sync is an integer. I can't find the type that it
actually needs as the argument though. I've not idea what GLsync
actually is.

Cheers,

Henry

[PyOpenGL-Users] Fwd: Works on OSX, fails on Linux

[Alejandro S. <as...@gm...>]

Forwarding to PyOpenGL Users on behalf of Derakon ;)

Alejandro.-

---------- Forwarded message ----------
From: Derakon <de...@gm...>
Date: Mon, May 23, 2011 at 4:30 PM
Subject: Re: [PyOpenGL-Users] Works on OSX, fails on Linux
To: Alejandro Segovia <as...@gm...>


On Mon, May 23, 2011 at 12:22 PM, Alejandro Segovia <as...@gm...>
wrote:
> Hi Derakon,
> On Mon, May 23, 2011 at 4:04 PM, Mike C. Fletcher <mcf...@vr...>
> wrote:
>>
>> I'm pretty sure the problem is that you haven't properly bound your
>> texture for the refresh and as a result you are seeing an error due to
>> e.g. alignment or similar issues pushing your image parameters into
>> invalid territory.
>
> I subscribe to Mike's comments. In line 159 you are forgetting to call
> image.bindTexture() before calling image.refresh(). This might not be what
> you intended.

Yeah, this was the fix. Thanks, guys!

I found that the the assertion errors I was getting earlier had
something to do with my multithreaded viewer-update code. In normal
use the program has three separate windows showing different views of
a dataset; when the dataset updates I have to update all three
viewers, which I was doing in three separate threads. I guess
something about that isn't quite threadsafe, since while it worked
fine on OSX I had to revert to a sequential update for the Linux port.

Anyway, it's working now!

-Chris



-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] Code readability

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

On 11-05-21 11:47 AM, SAn wrote:
> Hi! I am trying to understand pyopengl VBO implementation, well, the
> whole OpenGL.array package.
>
> Is there a reason why the code is written so "anti-pep8/python zen"
> way? Like that there isn't a new line between class methods, etc.
> Maybe because of consistence with the automatic generator?
Mostly because it is written by one crusty old pythonista who pre-dates
PEP-8 (heck, PEPs entirely) by a significant period, and who looks at
PEP-8 conformance as something those young whippersnappers do ;) :D . 
Be happy I finally gave in and started using spaces instead of tabs :)
.  It took a plea directly from Pete Shinners (or maybe it was René?
been a while) to get that to happen, and I felt dirty for months after.

I'm fine with accepting a pep-8 patch, but keep in mind that APIs should
not change, and I'm really not all that worried about keeping the
code-base PEP-8-ified moving forward... that is, I can't guarantee I
won't edit the files at some point and make them match my personal
preference again :) .  If I start seeing people contributing code
frequently I might revisit that opinion, but if it's still basically
just me, I'll likely just do as comes naturally.

Have fun,
Mike

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

Re: [PyOpenGL-Users] Works on OSX, fails on Linux

[Alejandro S. <as...@gm...>]

Hi Derakon,

On Mon, May 23, 2011 at 4:04 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> I'm pretty sure the problem is that you haven't properly bound your
> texture for the refresh and as a result you are seeing an error due to
> e.g. alignment or similar issues pushing your image parameters into
> invalid territory.


I subscribe to Mike's comments. In line 159 you are forgetting to call
image.bindTexture() before calling image.refresh(). This might not be what
you intended.

Good luck,

Alejandro.-



-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] using glGetSynciv

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

On 11-05-23 04:57 AM, Henry Gomersall wrote:
> I'm trying to query the status of a fence I've created using
> glFenceSync, using the following snippet:
>
> my_sync = GL_sync.glFenceSync(GL_sync.GL_SYNC_GPU_COMMANDS_COMPLETE, 0)
>         
> a = numpy.zeros(10, dtype='uint32')
> foo = GL_sync.glGetSynciv(my_sync,
>                 GL_sync.GL_SYNC_STATUS,
>                 10, None, a)
>
> Running it returns the following error that I am having trouble parsing:
>
> ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>:
> ("byref() argument must be a ctypes instance, not 'int'", ' If you have
> ERROR_ON_COPY enabled, remember to pass in an array to array-requiring
> functions.')
>
> The trouble is that I'm not sure to which argument it is referring. I am
> not sufficiently familiar with the PyOpenGL interface.
It's a little obtuse there, I believe the problem is the None, it should
be a GL.GLsizei() instance (or a single-integer numpy array).  It will
have its .value set to the number of records written into a.

HTH,
Mike

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

Re: [PyOpenGL-Users] Works on OSX, fails on Linux

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

On 11-05-23 02:41 PM, Derakon wrote:
> I'm trying to port a program from OSX to Linux, so it can be run over
> an SSH tunnel. I'm getting "invalid operation" errors when I call
> glTexSubImage2D, though. I've trimmed the program down to a
> more-or-less minimal program (still almost 200 lines) which still
> exhibits the failure:
I'm pretty sure the problem is that you haven't properly bound your
texture for the refresh and as a result you are seeing an error due to
e.g. alignment or similar issues pushing your image parameters into
invalid territory.  I come to that conclusion by adding a
self.bindtexture() to your image class' refresh method, which eliminates
the errors and displays some gradients.  This kind of thing is common in
cross-platform OpenGL, one implementation happens to allow it, another
is more strict about the order of operations.  Linux, in particular, has
become far more stringent in recent years as to order of operations.

HTH,
Mike

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

[PyOpenGL-Users] Works on OSX, fails on Linux

[Derakon <de...@gm...>]

I'm trying to port a program from OSX to Linux, so it can be run over
an SSH tunnel. I'm getting "invalid operation" errors when I call
glTexSubImage2D, though. I've trimmed the program down to a
more-or-less minimal program (still almost 200 lines) which still
exhibits the failure:

http://paste.ubuntu.com/611982/

Dependencies are PyOpenGL, numpy, and wx. I apologize for the very
inconsistent code style/formatting; this is a bit of a hodgepodge and
I'm cleaning it up as I get the chance.

I've pasted the error I'm getting at the end of this message. It's
occurring in some PyOpenGL-accelerate code. From my understanding,
this package isn't actually necessary; it just makes certain
operations faster. Is it possible to uninstall it? Googling around
doesn't show it being particularly straightforward to uninstall Python
packages, but perhaps this one's more self-contained?

Could it be that running over ssh -Y is what's giving me trouble? I'm
not really familiar with SSH tunneling in general and what it does to
the display. Before I started trimming down the program to make the
"minimal" version, I was actually semi-randomly getting assertion
errors in /usr/lib/libxcb-xlib.so (and when the assertions didn't show
up the app would just hang with nothing displayed).

Anyway, here's the error. Any advice would be appreciated. Thanks!

Traceback (most recent call last):
  File "editor.py", line 159, in OnPaint
    image.refresh()
  File "editor.py", line 52, in refresh
    GL.GL_LUMINANCE, GL.GL_SHORT, imgString)
  File "latebind.pyx", line 32, in
OpenGL_accelerate.latebind.LateBind.__call__ (src/latebind.c:559)
  File "wrapper.pyx", line 315, in
OpenGL_accelerate.wrapper.Wrapper.__call__ (src/wrapper.c:5196)
OpenGL.error.GLError: GLError(
	err = 1282,
	description = 'invalid operation',
	baseOperation = glTexSubImage2D,
	pyArgs = (
		GL_TEXTURE_2D,
		0,
		0,
		0,
		512,
		512,
		GL_LUMINANCE,
		GL_SHORT,
		'\x00\x00\x01\x00\x02\x00\x03\x00\x04...,
	),
	cArgs = (
		GL_TEXTURE_2D,
		0,
		0,
		0,
		512,
		512,
		GL_LUMINANCE,
		GL_SHORT,
		'\x00\x00\x01\x00\x02\x00\x03\x00\x04...,
	),
	cArguments = (
		GL_TEXTURE_2D,
		0,
		0,
		0,
		512,
		512,
		GL_LUMINANCE,
		GL_SHORT,
		'\x00\x00\x01\x00\x02\x00\x03\x00\x04...,
	)
)

[PyOpenGL-Users] using glGetSynciv

[Henry G. <he...@ca...>]

I'm trying to query the status of a fence I've created using
glFenceSync, using the following snippet:

my_sync = GL_sync.glFenceSync(GL_sync.GL_SYNC_GPU_COMMANDS_COMPLETE, 0)
        
a = numpy.zeros(10, dtype='uint32')
foo = GL_sync.glGetSynciv(my_sync,
                GL_sync.GL_SYNC_STATUS,
                10, None, a)

Running it returns the following error that I am having trouble parsing:

ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>:
("byref() argument must be a ctypes instance, not 'int'", ' If you have
ERROR_ON_COPY enabled, remember to pass in an array to array-requiring
functions.')

The trouble is that I'm not sure to which argument it is referring. I am
not sufficiently familiar with the PyOpenGL interface.

Any assistance would be much appreciated.

Thanks,

Henry Gomersall

[PyOpenGL-Users] Code readability

[SAn <gri...@gm...>]

Hi! I am trying to understand pyopengl VBO implementation, well, the
whole OpenGL.array package.

Is there a reason why the code is written so "anti-pep8/python zen"
way? Like that there isn't a new line between class methods, etc.
Maybe because of consistence with the automatic generator?

I am editing the files manualy so i could read and undestand them,
from bzr. I could send you a patch, and maybe to the generator too!

thanks,
SAn

Re: [PyOpenGL-Users] Getting Started With PyOpenGL and OpenGL 3.2

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

On 11-05-13 05:24 AM, Przemysław Lib wrote:
> Hi!
>
> OpenGL 3 needs separate context. This means that you will get OpenGL 2
> as default.
> Use:
>
> glutInit(&argc, argv);
> glutInitContextVersion(3, 2);
> glutInitContextFlags(GLUT_FORWARD_COMPATIBLE);
> glutInitContextProfile(GLUT_CORE_PROFILE);
>
> That's C code that will get you OpenGL 3.2 core profile context (if
> your hwd/drivers support it).
> Do not know PyOpenGL equivalents but should be similar.
Those appear to be new freeglut extensions. I've just added the entry
points to the freeglut wrappers in bzr head, along with the various
constants that have been added. With that (on an Ubuntu machine), the
following seems to properly initialize a 3.2 forward-compatible context:

glutInit([])
glutInitContextVersion(3, 2)
glutInitContextFlags(GLUT_FORWARD_COMPATIBLE)
glutInitContextProfile(GLUT_CORE_PROFILE)
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH)

glutInitWindowSize(resX, resY)

glutInitWindowPosition(0, 0)
window = glutCreateWindow("hello")
glutDisplayFunc(display)
glutMainLoop()

BTW, thanks for the very helpful request; given C code that should work
it is generally very easy for me to get the Python wrappers written to
support the functionality.

HTH,
Mike

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

Re: [PyOpenGL-Users] How to get OpenGL4 using PyOpenGL

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

On 11-05-13 05:13 AM, Przemysław Lib wrote:
> Can I get OpenGL 4 (core profile) with PyOpenGL? (can live with
> manually loading needed extensions one by one, but need to know if
> they all are in PyOpenGL)
I believe that current bzr head has all of the current extensions, they
are auto-generated from the extension registry header files, however,
nothing has been tested above OpenGL 3.x, as I don't have any 4.x
hardware available on which to test/debug/develop. I also don't have a
*lot* of 3.x code to run to test that behaviour is as expected, most of
my test code was written back in the 1.x and 2.x days.
> What is state of PyOpenGL development? Main site claim compatibility
> only with OGL 3.2.
PyOpenGL is still being developed, but it is one of a dozen of Open
Source projects I work on in my spare time, I figure it gets about 1-2
half-days/month. My current hardware has a 3.3 context, so I should,
when I get the time, be able to get robust support up to 3.3 level.

HTH,
Mike

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