pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] glGetUniformBlockIndex

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

On 14-04-01 01:46 AM, Walter White wrote:
> Hello,
>
> I am not sure if this is an expected behaviour or not yet ported to
> Python 3.x , but when using glGetUniformBlockIndex
...

This was a generic problem with unicode-parameter handling for 
GLcharArray data-types.  There were two issues, the first was that Array 
Data Types were not allowing an extra parameter, the second was that the 
Unicode format handler wasn't correctly calling the Bytes format handler 
once it had converted the value. bzr head should make the code work, but 
I'd like to track down *why* the from_param is getting an extra 
argument, as I don't know why that would be present.

Thanks,
Mike

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

Re: [PyOpenGL-Users] glGetUniformBlockIndex

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

Hi,

If this is what I think it is, I have noticed similar behavior for other
low-level shader-string-affecting calls.

I think doing it this way is probably the Right Thing, as I expect it
avoids needing to do direct string conversion to ASCII text.

Cheers,
Ian

[PyOpenGL-Users] glGetUniformBlockIndex

[Walter W. <hom...@gm...>]

Hello,

I am not sure if this is an expected behaviour or not yet ported to
Python 3.x , but when using glGetUniformBlockIndex

with  uniformBlockName = "mymat" it throws an error:

baseplatform.py", line 385, in __call__
    return self( *args, **named )
ctypes.ArgumentError: argument 2: <class 'TypeError'>: from_param() takes 2
positional arguments but 3 were given

I have to use uniformBlockName = b"mymat" instead.

I guess it it is the same with

window = glutCreateWindow(b"myWindow")

Kind regards,
Walter

Re: [PyOpenGL-Users] Anyone with screenshots they'd like to show off?

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> The PyOpenGL web-site is a bit dry and textual. I'd like to add a 
> rotating set of screenshots so that first-time visitors can see samples 
> of what's been/being doing with PyOpenGL.  If anyone has screenshots 
> they'd like to have displayed, let me know. If you have a description + 
> link to which to send the curious that would be good too.

I have gathered 3 screenshots here:
http://iihm.imag.fr/blanch/temp/pyopengl/

I have put a description in the readme.txt pasted below:

mendelbrot.png
interactive exploration of the mendelbrot set.
rendering is done as a procedural texture computed by the fragment shader.
source:
http://iihm.imag.fr/blanch/teaching/opengl/src/c-shader/02-fragment.py

dots.png
a cube with an animeted partially transparent texture.
illustrates various evolution of the OpenGL pipeline from OpenGL 1.0 to core
profile.
source:
https://bitbucket.org/rndblnch/opengl-programmable/

webmichl_my_camera.png
high fidelity rendering of 2D vector graphics (SVG) using the seagull package.
original file: http://openclipart.org/detail/4524/my-camera-by-webmichl-4524
seagull source:
https://bitbucket.org/rndblnch/seagull/

renaud

Re: [PyOpenGL-Users] PyOpenGL 3.1.0b2 is out

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> Please test to see if you can build accelerate without the environment 
> variable now.

great, works for me here (python2/3, Mac OS X 10.9, XCode 5.1)

renaud

[PyOpenGL-Users] Anyone with screenshots they'd like to show off?

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

The PyOpenGL web-site is a bit dry and textual. I'd like to add a 
rotating set of screenshots so that first-time visitors can see samples 
of what's been/being doing with PyOpenGL.  If anyone has screenshots 
they'd like to have displayed, let me know. If you have a description + 
link to which to send the curious that would be good too.

I've added some rather old screenshots to the OpenGLContext page here:

     http://pyopengl.sourceforge.net/context/index.html

but haven't yet done click-to-investigate or descriptions for those.

Thanks all,
Mike

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

Re: [PyOpenGL-Users] PyOpenGL 3.1.0b2 is out

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

On 03/25/2014 12:34 PM, rndblnch wrote:
> Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:
...
> one thing to note for people attempting to build PyOpenGL_accelerate from
> source and having updated to XCode 5.1 is that you will get on error on
> compilation:

I've put in a hack based on the one PyMongo uses to filter out the 
known-bad parameter that Apple has included in their Python builds. 
Please test to see if you can build accelerate without the environment 
variable now.

Thanks,
Mike

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

Re: [PyOpenGL-Users] Question on glBufferData / glBufferSubData

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

On 03/25/2014 12:54 PM, Walter White wrote:
> Hello Mike,
>
> still no success on the issue.
> I tried two different machines, identical set-up, Win7,64-bit,Python 3.3,
> same problem.
>
> This is the complete error message, maybe you can take a look:
>
> http://bpaste.net/show/2KUuv5TCRPrYbI1OkCa5/
>
> I guess the following calls are identical, right?
>
> glBufferSubData(...,...,..., ADT.voidDataPointer(tmpArray))
> glBufferSubData(...,...,..., tmpArray)

Yes, voidDataPointer is automatically called, no reason to do the call 
yourself.

I see that vispy has encountered the *same* error you are seeing on some 
particular machine:

     https://github.com/vispy/vispy/issues/64

The commit linked there suggests that this is a bug in specific ATI 
drivers. Almar worked around it by redoing the call with glBufferData 
IFF the values happen to cover the whole buffer.

I am *not* seeing the bug on AMD Linux, as noted, but possibly some AMD 
Windows driver has it?  I have to say I'm pretty surprised to see 
something as basic as glBufferSubData have an error like this... this is 
pretty basic/core functionality to have it not work.

Precise hardware/driver information is likely relevant here, the fact 
that the two machines failing are identical lends credence to the 
driver/hardware issue, I suppose.

Thanks,
Mike

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

Re: [PyOpenGL-Users] Python 3 crash when running on optimus card

[Ákos T. <dxm...@gm...>]

Latest release appears to have fixed the issue. Thanks!


On 19 March 2014 06:14, Mike C. Fletcher <mcf...@vr...> wrote:

> On 14-03-05 11:23 AM, Ákos Tóth wrote:
>
>> The Optimus driver is basically a secondary X server with the Nvidia
>> proprietary drivers loaded instead of Mesa (which houses anything the
>> integrated Intel card is capable of running), so I assume the issue might
>> be present when running with the Nvidia drivers regardless of Optimus.
>> Later this week I could do a test where I disable bumblebee altogether and
>> enable Nvidia on the primary X, thus getting around the whole Optimus deal,
>> and see if it still happens.
>>
>
> To attempt to work around this, I've moved all of PyOpenGL to using a
> pattern where entry points are resolved only when they are first used. If
> I'm right about what Optimus is doing, that *should* give us the right
> entry points, as they should be looked up in the context after Optimus has
> swapped them out for its own entry points.
>
> No way to tell without actually testing, though.
>
>
> Thanks,
> Mike
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>

[PyOpenGL-Users] Question on glBufferData / glBufferSubData

[Walter W. <hom...@gm...>]

Hello Mike,

still no success on the issue.
I tried two different machines, identical set-up, Win7,64-bit,Python 3.3,
same problem.

This is the complete error message, maybe you can take a look:

http://bpaste.net/show/2KUuv5TCRPrYbI1OkCa5/

I guess the following calls are identical, right?

glBufferSubData(...,...,..., ADT.voidDataPointer(tmpArray))
glBufferSubData(...,...,..., tmpArray)

Kind regards,
Walter

Re: [PyOpenGL-Users] PyOpenGL 3.1.0b2 is out

[rndblnch <rnd...@gm...>]

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:

> 
> I've just released PyOpenGL 3.1.0b2. Barring any show-stopper bugs this 
> should be the last beta before the final 3.1.0 release.
> Have fun,
> Mike

thanks mike for this beta release.
works for me on both python and python3 on Mac OS X 10.9.

one thing to note for people attempting to build PyOpenGL_accelerate from
source and having updated to XCode 5.1 is that you will get on error on
compilation:

clang: error: unknown argument: '-mno-fused-madd'
[-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning)
in the future

this is due to a documented change on the handling of flags by clang (see
https://developer.apple.com/library/ios/releasenotes/DeveloperTools/
RN-Xcode/xc5_release_notes/xc5_release_notes.html#//apple_ref/doc/
uid/TP40001051-CH2-SW2)
the work-around is also documented by apple: override the new behaviour by
setting this flag:
-Wno-error=unused-command-line-argument-hard-error-in-future e.g. inside the
OpenGL-accelerate folder:

% env
ARCHFLAGS="-Wno-error=unused-command-line-argument-hard-error-in-future"
python3 setup.py bdist
% python3 setup.py install

renaud

[PyOpenGL-Users] PyOpenGL 3.1.0b2 is out

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

I've just released PyOpenGL 3.1.0b2. Barring any show-stopper bugs this 
should be the last beta before the final 3.1.0 release. Changes since 
the last beta:

  * Generation fixes (lots of them)
      o GLES/GL-only extensions should now be generated only in the
        appropriate directories
      o Extensions which are multi-api will show up in each API package
        (note: custom wrappers are still written per-api)
      o Freshly generated wrappers from the khronos API repository
  * Late/lazy binding of all entry points (that is, we do not even
    attempt to resolve any entry point until we try to try to call it)
  * All DLLs are now lazy-loaded, so we can define DLLs and entry points
    without paying for loading them in every script
  * Export the nullFunction method in the OpenGL.platform namespace
  * No longer export DLLs into the OpenGL.platform namespace, these are
    now in OpenGL.platform.PLATFORM (to allow for lazy loading)
  * Setup script fixes for relative filename references
  * Build fixes for cython on OS-X
  * Remove duplicate checking for extension in createFunction()
  * A bit of work on making a GLES2 shader wrapper as in GL
  * Explicitly check for self._noErrorResult in error checkers rather
    than assuming no-error-result is always boolean False
  * Explicitly return self._noErrorResult when error checking is suppressed
  * VBO implementation is now separated out into per-api modules so that
    GLES can eventually get its own implementation
  * OS-X fix for true-core-context with no error checking
  * Refactory the OSMesa context into a platform and a module with the
    extension functions (OpenGL.osmesa)
  * Make most "output" parameters use "orPassIn" flag so that they can
    be *either* generated or passed in
  * Fix for shader log retrieval when using core shader implementation
  * Provide OpenGL and GLES dlls on the EGL and GLX platforms respectively
  * Reinstate intended default for context-checking flag (True)
  * Remove support for extremely old ctypes versions from
    now-unsupported Python versions
  * Accelerate wrappers regenerated with cython 0.20.1

If you have PyOpenGL code, now is the time to test it before the 3.1.0 
release. I still consider the GLES/EGL support to be experimental, so I 
won't treat bugs there as show-stoppers, but if you find GLES or EGL but 
if you find bugs in those I'd love to hear about them (and I'd love to 
have some test code for them as well).

Have fun,
Mike

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

Re: [PyOpenGL-Users] Question on glBufferData / glBufferSubData

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

On 03/24/2014 05:23 AM, Walter White wrote:
...
> Hello,
>
> I have a question about PyOpenGL and hope that you can help me.
>
> While working through the arcsynthesis opengl tutorial I came
> across a problem using glBufferSubData.
>
> My code is here:
>
> http://bpaste.net/show/FAhw0W1Hx4WDW9toa75H/
>
> This works fine:
>
> glBufferData(GL_ARRAY_BUFFER, ADT.arrayByteCount(npData),
>              ADT.voidDataPointer(npData), GL_STATIC_DRAW)
>
> But using
>
> glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData), npData)
>
> or (I guess identical)
>
> glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData), 
> ADT.voidDataPointer(npData))
>
> results in  an OpenGL Error 1281 Invalid Type after a few
> seconds. During the first 1 - 5 seconds the program works as expected.

Your code in the bpaste there works fine on my Kubuntu 13.10 machine, so 
I'm assuming you mean you replace the existing glBufferData call with a 
glBufferSubData call.


I'm surprised it works for the first few seconds with that 
substitution.  If I replace the initial call to glBufferData with a 
glBufferSubData call you should (and my tests show that I do) get an 
INVALID_VALUE error, because the buffer to which we are attempting to 
write currently has 0 size (the docs for glBufferSubData describe this 
condition as well, where offset + size goes beyond the end of the 
reserved space for the buffer).  The first call to glBufferData creates 
the buffer *and sets its size*, only once that is done can you start 
writing with glBufferSubData.

Hope that helps,
Mike

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

[PyOpenGL-Users] Question on glBufferData / glBufferSubData

[Walter W. <hom...@gm...>]

Hello,

I have a question about PyOpenGL and hope that you can help me.

While working through the arcsynthesis opengl tutorial I came
across the following issue.

The example

This works fine:

Hello,

I have a question about PyOpenGL and hope that you can help me.

While working through the arcsynthesis opengl tutorial I came
across a problem using glBufferSubData.

My code is here:

http://bpaste.net/show/FAhw0W1Hx4WDW9toa75H/

This works fine:

glBufferData(GL_ARRAY_BUFFER, ADT.arrayByteCount(npData),
             ADT.voidDataPointer(npData), GL_STATIC_DRAW)

But using

glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData), npData)

or (I guess identical)

glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData),
ADT.voidDataPointer(npData))

results in  an OpenGL Error 1281 Invalid Type after a few
seconds. During the first 1 - 5 seconds the program works as expected.

Can someone tell me what causes the problem?

Kind regards,
Walter

Re: [PyOpenGL-Users] Python 3 crash when running on optimus card

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

On 14-03-05 11:23 AM, Ákos Tóth wrote:
> The Optimus driver is basically a secondary X server with the Nvidia 
> proprietary drivers loaded instead of Mesa (which houses anything the 
> integrated Intel card is capable of running), so I assume the issue 
> might be present when running with the Nvidia drivers regardless of 
> Optimus. Later this week I could do a test where I disable bumblebee 
> altogether and enable Nvidia on the primary X, thus getting around the 
> whole Optimus deal, and see if it still happens.

To attempt to work around this, I've moved all of PyOpenGL to using a 
pattern where entry points are resolved only when they are first used. 
If I'm right about what Optimus is doing, that *should* give us the 
right entry points, as they should be looked up in the context after 
Optimus has swapped them out for its own entry points.

No way to tell without actually testing, though.

Thanks,
Mike

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

Re: [PyOpenGL-Users] bug in upstream version of pyopengl

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

On 14-03-10 02:38 PM, rndblnch wrote:
> hello mike,
>
> i just tested the bleeding edge of pyopengl (rev 740) and found a bug in the
> error handling code:
> the OpenGL.error._ErrorChecker.nullGetError method (used when error checking
> is enabled but not the accelerate module between glBegin/glEnd pairs)
> returns None; but the result of self._currentChecker() is tested against
> self._noErrorResult which is 0.
> so with no accelerate and error checking, glBegin always raises and exception.
I've modified the nullGetError method to return self._noErrorResult.  
Thanks for the bug report.
Mike

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

Re: [PyOpenGL-Users] OpenGL.EGL import error

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

On 14-03-10 02:09 PM, Jan Harms wrote:
> I am trying to install the newest PyOpenGL version but I get an 
> AttributeError when trying to import OpenGL.EGL:
...
> AttributeError: 'GLXPlatform' object has no attribute 'EGL'
>
> I am working on Ubuntu 12.04, Python 2.7.6.
> Any idea why I get this error or how to solve it?

You need to specify the platform at the command line (or in your script, 
by setting the environment variable):

     PYOPENGL_PLATFORM=egl python -c "from OpenGL import EGL"

by default the common platform for the OS is used, which on Linux is 
GLXPlatform, choosing the EGL or OSMesa platforms has to be done explicitly.

HTH,
Mike

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

Re: [PyOpenGL-Users] Question on glBufferData / glBufferSubData

[Walter W. <hom...@gm...>]

Hello,

sorry, I guess I wrote to quickly.
Both methods using glBufferSubData work as expected
for a few seconds but then stop working with

OpenGL.error.GLError: GLError(
	err = 1281,
	description = b'invalid value',
	baseOperation = glBufferSubData,


I found a this bug report
https://bugs.launchpad.net/pygl3display/+bug/1178470
but I am not sure if this is related.

I am using Windows 7 with
PyOpenGL-3.1.0b1.win-amd64-py3.3
PyOpenGL-accelerate-3.1.0b1.win-amd64-py3.3

Kind regards,
Walter


Am 16.03.2014 00:48, schrieb Walter White:
> Hello,
>
> I have a question about PyOpenGL and hope that you can help me.
>
> I am a little bit confused about the follwing.
>
> This works fine:
>
> glBufferData(GL_ARRAY_BUFFER, ADT.arrayByteCount(npData),
>               ADT.voidDataPointer(npData), GL_STATIC_DRAW)
>
> This also works fine:
>
> glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData), npData)
>
> But using this results in OpenGL Error 1281 Invalid Type after a few
> seconds:
>
> glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData),
> ADT.voidDataPointer(npData))
>
> I don't understand why using ADT.voidDataPointer(npData) in the
> latter does not work as the specification states the that
> the type is a void pointer to the data array in both functions:
>
> void glBufferSubData(GLenum target,  GLintptr offset,  GLsizeiptr size,
>   const GLvoid * data);
>
> void glBufferData(GLenum target,  GLsizeiptr size,  const GLvoid * data,
>   GLenum usage);
>
> Kind regards,
> Walter
>

[PyOpenGL-Users] Question on glBufferData / glBufferSubData

[Walter W. <hom...@gm...>]

Hello,

I have a question about PyOpenGL and hope that you can help me.

I am a little bit confused about the follwing.

This works fine:

glBufferData(GL_ARRAY_BUFFER, ADT.arrayByteCount(npData), 	
              ADT.voidDataPointer(npData), GL_STATIC_DRAW)

This also works fine:

glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData), npData)

But using this results in OpenGL Error 1281 Invalid Type after a few
seconds:

glBufferSubData(GL_ARRAY_BUFFER, 0, ADT.arrayByteCount(npData), 
ADT.voidDataPointer(npData))

I don't understand why using ADT.voidDataPointer(npData) in the
latter does not work as the specification states the that
the type is a void pointer to the data array in both functions:

void glBufferSubData(GLenum target,  GLintptr offset,  GLsizeiptr size, 
  const GLvoid * data);

void glBufferData(GLenum target,  GLsizeiptr size,  const GLvoid * data, 
  GLenum usage);

Kind regards,
Walter

[PyOpenGL-Users] Possible issue with glGetQueryiv wrapper?

[Ed P. <edp...@gm...>]

Has anyone come across this before?

Found in 3.0.2 win32

In the following code sequence:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

    glEnable(GL_RASTERIZER_DISCARD)
    glBindTransformFeedback(GL_TRANSFORM_FEEDBACK,TxFB_Buffers)
    glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER,0,TxFB_Buffers)
    glBeginTransformFeedback(GL_TRIANGLES)
    glBeginQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN,TxFB_Query)
    glDrawElementsui(GL_TRIANGLES,IdxArray)
    glEndTransformFeedback()
    glEndQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN)
    glGetQueryiv(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN,GL_CURRENT_QUERY,TxFB_count)
    glDisable(GL_RASTERIZER_DISCARD)
    glBindTransformFeedback(GL_TRANSFORM_FEEDBACK,0)

 The call to glGetQueryiv yields the following error...

glGetQueryiv(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN,GL_CURRENT_QUERY,self.TxFB_count)
File "latebind.pyx", line 32, in
OpenGL_accelerate.latebind.LateBind.*call*(src\latebind.c:667)
File "wrapper.pyx", line 296, in
OpenGL_accelerate.wrapper.Wrapper.*call*(src\wrapper.c:5215)
File "wrapper.pyx", line 148, in
OpenGL_accelerate.wrapper.PyArgCalculator.c_call (src\wrapper.c:3419)
ValueError: glGetQueryiv requires 2 arguments (target, pname), received 3:
(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN, GL_CURRENT_QUERY, c_ulong(0L))

glGetQueryiv function signature is definitely 3 parameters, target, pname
and param.

I did try moving to 3.1.0b1, but had the following issue with
glGenBuffers()...

    buff = glGenBuffers(GLint(1))
  File "latebind.pyx", line 32, in
OpenGL_accelerate.latebind.LateBind.__call__ (src\latebind.c:667)
  File "wrapper.pyx", line 300, in
OpenGL_accelerate.wrapper.Wrapper.__call__ (src\wrapper.c:5257)
  File "wrapper.pyx", line 87, in
OpenGL_accelerate.wrapper.CArgCalculator.c_call (src\wrapper.c:2439)
  File "wrapper.pyx", line 68, in
OpenGL_accelerate.wrapper.CArgCalculatorElement.c_call (src\wrapper.c:2064)
  File "wrapper.pyx", line 63, in
OpenGL_accelerate.wrapper.CArgCalculatorElement.c_call (src\wrapper.c:1942)
  File "arraydatatype.pyx", line 287, in
OpenGL_accelerate.arraydatatype.Output.c_call (src\arraydatatype.c:4827)
  File "arraydatatype.pyx", line 219, in
OpenGL_accelerate.arraydatatype.ArrayDatatype.c_zeros
(src\arraydatatype.c:4005)
  File "arraydatatype.pyx", line 79, in
OpenGL_accelerate.arraydatatype.HandlerRegistry.c_get_output_handler
(src\arraydatatype.c:2080)
RuntimeError: ('Unable to find any output handler at all (not even
ctypes/numpy ones!)', 1, <OpenGL.platform.baseplatform.glGenBuffers object
at 0x02C1C2D8>)


Cheers,

Ed.

Re: [PyOpenGL-Users] Install/version Trouble?

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

On Mon, Mar 10, 2014 at 7:51 PM, Adam Steele <avs...@gm...> wrote:

> On Thu, Mar 6, 2014 at 10:39 PM, Ian Mallett <ia...@ge...> wrote:
>
>> On Thu, Mar 6, 2014 at 8:29 PM, Adam Steele <avs...@gm...> wrote:
>>
>>> PyOpenGL-3.0.2.win-amd64.exe
>>> on a "from OpenGL.GL import *" this gives me error that look like some
>>> conversion from python 2.x didn't take (some exceptions are of the form
>>> "Exception Blah, err:")
>>>
>> You'll have to be more specific than that.
>>
>>
> python 3.3 x64, install PyOpenGL-3.0.2.win-amd64.exe
>


> from OpenGL.GL import *
>


>  Traceback (most recent call last):
>   File
> "C:\Users\ADAM\workspace\oGL_examples\src\PyOpenGL_test\testbed.py", line
> 13, in <module>
>     from OpenGL.GL import *
>   File "C:\Python33\lib\site-packages\OpenGL\GL\__init__.py", line 3, in
> <module>
>     from OpenGL.GL.VERSION.GL_1_1 import *
>   File "C:\Python33\lib\site-packages\OpenGL\GL\VERSION\GL_1_1.py", line
> 10, in <module>
>     from OpenGL import platform, constants, constant, arrays
>   File "C:\Python33\lib\site-packages\OpenGL\platform\__init__.py", line
> 35, in <module>
>     _load()
>   File "C:\Python33\lib\site-packages\OpenGL\platform\__init__.py", line
> 26, in _load
>     plugin_class = plugin.load()
>   File "C:\Python33\lib\site-packages\OpenGL\plugins.py", line 14, in load
>     return importByName( self.import_path )
>   File "C:\Python33\lib\site-packages\OpenGL\plugins.py", line 28, in
> importByName
>     module = __import__( ".".join(moduleName), {}, {}, moduleName)
>   File "C:\Python33\lib\site-packages\OpenGL\platform\win32.py", line 25
>     except OSError, err:
>                   ^
> SyntaxError: invalid syntax
>
I think you're right; this does look like a Python 2/3 issue.

I'd recommend using the latest version of PyOpenGL (or using Python 2, if
for some reason you can't). CC-ed Mike directly, although he's on the list,
in case anything needs to be done.

Once the context is set up, you should be fine calling functions from
either. If you need some test code, my
basecode<http://geometrian.com/programming/tutorials/OpenGL%20Program%20Shell.py.txt>shows
OpenGL 2 usage, and is quite robust.

Ian

Re: [PyOpenGL-Users] Install/version Trouble?

[Adam S. <avs...@gm...>]

On Thu, Mar 6, 2014 at 10:39 PM, Ian Mallett <ia...@ge...> wrote:

> On Thu, Mar 6, 2014 at 8:29 PM, Adam Steele <avs...@gm...> wrote:
>
>> PyOpenGL-3.0.2.win-amd64.exe
>> on a "from OpenGL.GL import *" this gives me error that look like some
>> conversion from python 2.x didn't take (some exceptions are of the form
>> "Exception Blah, err:")
>>
> You'll have to be more specific than that.
>
>
python 3.3 x64, install PyOpenGL-3.0.2.win-amd64.exe
then run file:
------------------------------
from OpenGL.GL import *
if __name__ == '__main__':
    pass
-----------------------
I get error:
-------------------------
Traceback (most recent call last):
  File "C:\Users\ADAM\workspace\oGL_examples\src\PyOpenGL_test\testbed.py",
line 13, in <module>
    from OpenGL.GL import *
  File "C:\Python33\lib\site-packages\OpenGL\GL\__init__.py", line 3, in
<module>
    from OpenGL.GL.VERSION.GL_1_1 import *
  File "C:\Python33\lib\site-packages\OpenGL\GL\VERSION\GL_1_1.py", line
10, in <module>
    from OpenGL import platform, constants, constant, arrays
  File "C:\Python33\lib\site-packages\OpenGL\platform\__init__.py", line
35, in <module>
    _load()
  File "C:\Python33\lib\site-packages\OpenGL\platform\__init__.py", line
26, in _load
    plugin_class = plugin.load()
  File "C:\Python33\lib\site-packages\OpenGL\plugins.py", line 14, in load
    return importByName( self.import_path )
  File "C:\Python33\lib\site-packages\OpenGL\plugins.py", line 28, in
importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "C:\Python33\lib\site-packages\OpenGL\platform\win32.py", line 25
    except OSError, err:
                  ^
SyntaxError: invalid syntax
----------------------------------


 PyOpenGL-3.1.0b1.win-amd64.exe
>> This one installs and lets me do an import, but a simple command like
>> "glGetString(GL_VERSION)" returns "None"
>>
> You'll have to be more specific than that. At a guess (if you only did
> this line), then that's to be expected; OpenGL commands require an OpenGL
> context before they will work.
>
>
>
Thank you for the heads up.  I'm moving over from Pyglet, which evidently
opens a context upon import.
For reference the two file was as below, whre i get the error for the
OpenGL import, this makes sense if you need a context as you say.  Thanks
------------------------------
from OpenGL.GL import *
# or
# from pyglet.gl import *

import ctypes

if __name__ == '__main__':

    ver=glGetString(GL_VERSION)
    print(ctypes.string_at(ver,30))
-------------------------------------------

[PyOpenGL-Users] bug in upstream version of pyopengl

[rndblnch <rnd...@gm...>]

hello mike,

i just tested the bleeding edge of pyopengl (rev 740) and found a bug in the
error handling code:
the OpenGL.error._ErrorChecker.nullGetError method (used when error checking
is enabled but not the accelerate module between glBegin/glEnd pairs)
returns None; but the result of self._currentChecker() is tested against
self._noErrorResult which is 0.
so with no accelerate and error checking, glBegin always raises and exception.

the following patch is a way to fix the issue:

=== modified file 'OpenGL/error.py'
--- OpenGL/error.py	2014-02-24 16:15:39 +0000
+++ OpenGL/error.py	2014-03-10 18:30:25 +0000
@@ -223,7 +223,7 @@
                     should call onBegin and onEnd appropriately.
                 """
                 err = self._currentChecker()
-                if err != self._noErrorResult:
+                if err and err != self._noErrorResult:
                     raise GLError(
                         err,
                         result,


renaud

[PyOpenGL-Users] OpenGL.EGL import error

[Jan H. <jan...@gm...>]

Hi,

I am trying to install the newest PyOpenGL version but I get an
AttributeError when trying to import OpenGL.EGL:


Traceback (most recent call last):
  File "/home/student/miniconda/conda-bld/test-tmp_dir/run_test.py", line
56, in <module>
    import OpenGL.EGL
  File
"/home/student/miniconda/envs/_test/lib/python2.7/site-packages/OpenGL/EGL/__init__.py",
line 2, in <module>
    from OpenGL.raw.EGL._types import *
  File
"/home/student/miniconda/envs/_test/lib/python2.7/site-packages/OpenGL/raw/EGL/_types.py",
line 72, in <module>
    CALLBACK_TYPE = _p.PLATFORM.functionTypeFor( _p.PLATFORM.EGL )
AttributeError: 'GLXPlatform' object has no attribute 'EGL'

I am working on Ubuntu 12.04, Python 2.7.6.
Any idea why I get this error or how to solve it?

Kind regards,

Jan Harms

Re: [PyOpenGL-Users] Install/version Trouble?

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

On Thu, Mar 6, 2014 at 8:29 PM, Adam Steele <avs...@gm...> wrote:

> PyOpenGL-3.0.2.win-amd64.exe
> on a "from OpenGL.GL import *" this gives me error that look like some
> conversion from python 2.x didn't take (some exceptions are of the form
> "Exception Blah, err:")
>
You'll have to be more specific than that.


>  PyOpenGL-3.1.0b1.win-amd64.exe
> This one installs and lets me do an import, but a simple command like
> "glGetString(GL_VERSION)" returns "None"
>
You'll have to be more specific than that. At a guess (if you only did this
line), then that's to be expected; OpenGL commands require an OpenGL
context before they will work.