pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Gordon W. <go...@to...>]

Enabling error checking did not change that particular failure.

Are you suggesting that that machine may not have glBindVertexArray? That's
a core function and the driver reports itself as 3.3.0 via glxinfo and lets
me acquire a core 3.3 context via pyopengl glut.

G

On Thu, Nov 10, 2011 at 1:44 PM, Mike C. Fletcher <vrp...@gm...>wrote:

> On 11-11-08 10:38 PM, Gordon Wrigley wrote:
> > On an impulse I tried broke.py on another linux machine I have access
> > to that has Nvidia drivers on it, the result was the same but the
> > details differed. Particularly problems 2, 3 & 4 were replaced by this:
> >
> > Traceback (most recent call last):
> >   File "broke.py", line 145, in <module>
> >     main(sys.argv)
> >   File "broke.py", line 115, in main
> >     glBindVertexArray(vao)
> >   File
> > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
> > line 371, in __call__
> >     if self.load():
> >   File
> > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
> > line 351, in load
> >     if not platform.PLATFORM.checkExtension( self.extension ):
> >   File
> > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
> > line 246, in checkExtension
> >     result = extensions.hasGLExtension( name )
> >   File "/usr/local/lib/python2.7/dist-packages/OpenGL/extensions.py",
> > line 54, in hasGLExtension
> >     AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split()
> > AttributeError: 'NoneType' object has no attribute 'split'
> Hmm, without error checking that will return None if the entry point is
> not provided by the context (i.e. a core/forward-compatible-only
> context).  That definitely will break.
>
> Thanks,
> Mike
>
> --
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Mike C. F. <vrp...@gm...>]

On 11-11-08 10:38 PM, Gordon Wrigley wrote:
> On an impulse I tried broke.py on another linux machine I have access
> to that has Nvidia drivers on it, the result was the same but the
> details differed. Particularly problems 2, 3 & 4 were replaced by this:
>
> Traceback (most recent call last):
>   File "broke.py", line 145, in <module>
>     main(sys.argv)
>   File "broke.py", line 115, in main
>     glBindVertexArray(vao)
>   File
> "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
> line 371, in __call__
>     if self.load():
>   File
> "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
> line 351, in load
>     if not platform.PLATFORM.checkExtension( self.extension ):
>   File
> "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
> line 246, in checkExtension
>     result = extensions.hasGLExtension( name )
>   File "/usr/local/lib/python2.7/dist-packages/OpenGL/extensions.py",
> line 54, in hasGLExtension
>     AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split()
> AttributeError: 'NoneType' object has no attribute 'split'
Hmm, without error checking that will return None if the entry point is
not provided by the context (i.e. a core/forward-compatible-only
context).  That definitely will break.

Thanks,
Mike

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

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Mike C. F. <vrp...@gm...>]

On 11-11-08 06:45 AM, Gordon Wrigley wrote:
> I stripped my program right down to the bare minimum and condensed it
> into a single file, just 150 lines and 5 separate issues.
> The file as attached doesn't run for me.
> There are 5 if statements marked with XXX comments as you toggle each
> one another problem is resolved / worked around.
> After all 5 are toggled it runs and displays a single white triangle.
>
> In order those problems are:
> 1: enabling ERROR_CHECKING after importing OpenGL.GL
> causes glShaderSource to error with "Don't know how to convert
> parameter 3"
Ouch, now I see what you are saying.  Okay, that's actually not
supported, and I would *expect* it to blow up.  All of the config flags
in the top-level OpenGL module are write-once and *must* be written
before any sub-modules are imported.  I need to document that more
clearly and/or make a mechanism that can avoid having a half-configured
system result if the flag is changed after load.  You've got half the
system configured to do error checking and the other half not; that's
definitely going to blow up.
> 2: glGenVertexArrays is not wrapped
Ah, it is lacking a .output call, added to bzr trunk.  Scanning the
source tree there seem to be quite a few other glGen* operations that
likely need some output wrapping, and the output wrappers likely want
some love to make them less cumbersome to write (the lambdas just to
create a tuple are a little silly).
> 3: calling glGenVertexArrays through pyopengl causes a 1280 invalid
> enumerant
I'm pretty sure this is just an error showing up from elsewhere, on my
machine with ERROR_CHECKING turned on I do not see the error.
> 4: which moves to the following glBindVertexArray call when you
> call glGenVertexArrays through ctypes
Again, this seems to be because the error checking is reporting errors
from earlier due to a wrapping failure.
> 5: glVertexAttribPointer will only accept a pointer for the last
> argument not the integer value you pass when using it
> with GL_ARRAY_BUFFER bound.
Yes, this is normally handled by either using GL.arrays.vbo.VBO
instances (where vbo+offset gives you an offset pointer), or by manually
creating a pointer using ctypes.  Probably should look at having a
special array handler type/method which does *not* convert integers into
single-value arrays, but instead passes as a void_p to that address.
> I hope this aids in tracking down and resolving some of these problems.
> And I am by no means a GL expert so it wouldn't surprise me at all if
> one or more of these were my fault.
With the various fixes and changes in trunk, I can run the modified code
(attached) without any errors on my machine, and it displays the
expected triangle.  Note: the changes to use the shaders module and the
vbo.VBO class aren't required, they were just me eliminating sources of
possible errors as I tested.

Thank you very much for the effort and time taken to provide the test
case.  It was most helpful.  Enjoy,
Mike

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

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Gordon W. <go...@to...>]

On an impulse I tried broke.py on another linux machine I have access to
that has Nvidia drivers on it, the result was the same but the details
differed. Particularly problems 2, 3 & 4 were replaced by this:

Traceback (most recent call last):
  File "broke.py", line 145, in <module>
    main(sys.argv)
  File "broke.py", line 115, in main
    glBindVertexArray(vao)
  File
"/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
line 371, in __call__
    if self.load():
  File
"/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
line 351, in load
    if not platform.PLATFORM.checkExtension( self.extension ):
  File
"/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
line 246, in checkExtension
    result = extensions.hasGLExtension( name )
  File "/usr/local/lib/python2.7/dist-packages/OpenGL/extensions.py", line
54, in hasGLExtension
    AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split()
AttributeError: 'NoneType' object has no attribute 'split'

Version stuff for that machine:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL
>>> OpenGL.__version__
'3.0.2a1'

Linux gordonw-laptop 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12
22:21:04 UTC 2011 i686 i686 i386 GNU/Linux

OpenGL renderer string: Quadro NVS 160M/PCI/SSE2
OpenGL version string: 3.3.0 NVIDIA 270.41.06
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

G

On Tue, Nov 8, 2011 at 10:46 PM, Gordon Wrigley <go...@to...> wrote:

> +list
>
> ---------- Forwarded message ----------
> From: Gordon Wrigley <go...@to...>
> Date: Tue, Nov 8, 2011 at 10:45 PM
> Subject: Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid
> enumerant' error.
> To: "Mike C. Fletcher" <vrp...@gm...>
>
>
> I stripped my program right down to the bare minimum and condensed it into
> a single file, just 150 lines and 5 separate issues.
> The file as attached doesn't run for me.
> There are 5 if statements marked with XXX comments as you toggle each one
> another problem is resolved / worked around.
> After all 5 are toggled it runs and displays a single white triangle.
>
> In order those problems are:
> 1: enabling ERROR_CHECKING after importing OpenGL.GL causes glShaderSource
> to error with "Don't know how to convert parameter 3"
> 2: glGenVertexArrays is not wrapped
> 3: calling glGenVertexArrays through pyopengl causes a 1280 invalid
> enumerant
> 4: which moves to the following glBindVertexArray call when you
> call glGenVertexArrays through ctypes
> 5: glVertexAttribPointer will only accept a pointer for the last argument
> not the integer value you pass when using it with GL_ARRAY_BUFFER bound.
>
> I hope this aids in tracking down and resolving some of these problems.
> And I am by no means a GL expert so it wouldn't surprise me at all if one
> or more of these were my fault.
>
> G
>
>
>

[PyOpenGL-Users] Fwd: glGenVertexArrays producing 'invalid enumerant' error.

[Gordon W. <go...@to...>]

+list

---------- Forwarded message ----------
From: Gordon Wrigley <go...@to...>
Date: Tue, Nov 8, 2011 at 10:45 PM
Subject: Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid
enumerant' error.
To: "Mike C. Fletcher" <vrp...@gm...>


I stripped my program right down to the bare minimum and condensed it into
a single file, just 150 lines and 5 separate issues.
The file as attached doesn't run for me.
There are 5 if statements marked with XXX comments as you toggle each one
another problem is resolved / worked around.
After all 5 are toggled it runs and displays a single white triangle.

In order those problems are:
1: enabling ERROR_CHECKING after importing OpenGL.GL causes glShaderSource
to error with "Don't know how to convert parameter 3"
2: glGenVertexArrays is not wrapped
3: calling glGenVertexArrays through pyopengl causes a 1280 invalid
enumerant
4: which moves to the following glBindVertexArray call when you
call glGenVertexArrays through ctypes
5: glVertexAttribPointer will only accept a pointer for the last argument
not the integer value you pass when using it with GL_ARRAY_BUFFER bound.

I hope this aids in tracking down and resolving some of these problems.
And I am by no means a GL expert so it wouldn't surprise me at all if one
or more of these were my fault.

G

Re: [PyOpenGL-Users] Question about developping PyOpenGL

[Mike C. F. <vrp...@gm...>]

On 11-11-04 06:34 PM, Leon W. wrote:
> Hi to all,
> I hope the developer of PyOpenGL read this and answer me.
>
> I want to know if PyOpenGL is developed at the moment.
> Or if the developing stopped.
PyOpenGL is being developed, but fairly slowly, as the developer (me)
doesn't tend to get much time to work on it, nor do I have any code that
actually uses it for anything particularly important (neither
open-source projects nor any paying customers).  bzr head *should*
theoretically support up to OpenGL 4.2, but I have no test code for
anything above about 2.x functionality, so everything beyond that is
pretty much mechanically generated wrappers, and people actually trying
to use e.g. core-only contexts are likely to run into rough spots where
the mechanical wrapping needs to be smoothed out.

HTH,
Mike

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

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Mike C. F. <vrp...@gm...>]

On 11-11-05 03:28 PM, Gordon Wrigley wrote:
> The plot thickens, if I bypass pyopengl and do the glGenVertexArrays
> call direct through ctypes the "invalid enumerant" error moves to the
> subsequent glBindVertexArray call, if I use cytpes for that as well
> then everything starts working.

Sounds like there's an error being hidden in there somewhere, would have
to try to reproduce it to see what it was.  I suspect it's actually the
glGenVertexArrays call, or more likely, the call before it that is
producing the error.  The two uses of direct ctypes are simply ignoring
the error being set, most likely.
>
> On Fri, Nov 4, 2011 at 11:30 PM, Gordon Wrigley <go...@to...
> <mailto:go...@to...>> wrote:
>
>     I just got a chance to get back to this and I've made a little
>     head way, far enough that I have something on screen.
>     Specifying GLUT_COMPATIBILITY_PROFILE instead of GLUT_CORE_PROFILE
>     got round the glGenVertexArrays error.
>     I also had to do ctypes stuff to work around the lack of wrapper
>     for that function.
>     And the function glVertexAttribPointer was getting cast errors on
>     the last argument so I had to ctypes around that as well.
>     I believe that's the only dirty stuff I have so far.
>
>     G
>
You *should* be able to specify core profile, I'd like to get that
working some day.

glVertexAttrib pointer errors seems strange.  I'm pretty sure I use that
in some of my sample code, but maybe something has regressed?

Hopefully will get some time next week to work on it,
Mike
>
>
>
>     On Tue, Oct 25, 2011 at 1:56 AM, Mike C. Fletcher
>     <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>         On 11-10-20 06:41 AM, Gordon Wrigley wrote:
>>         And I attached the wrong log, here's the correct one.
>
>         Hrm, not much to go on there.  The call to createShader() does
>         not appear in the stack, which is a bit weird.  Is this code I
>         could trace through to try to find the error (i.e. not
>         something proprietary?)
>
>         Good luck,
>         Mike
>
>
>>
>>         On Thu, Oct 20, 2011 at 9:39 PM, Gordon Wrigley
>>         <go...@to... <mailto:go...@to...>> wrote:
>>
>>             On Tue, Oct 18, 2011 at 4:56 AM, Mike C. Fletcher
>>             <mcf...@vr... <mailto:mcf...@vr...>>
>>             wrote:
>>
>>                 On 11-10-12 03:34 AM, tolomea wrote:
>>                 > Version stuff:
>>                 > Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
>>                 > [GCC 4.5.2] on linux2
>>                 > Type "help", "copyright", "credits" or "license"
>>                 for more information.
>>                 > import OpenGL
>>                 > OpenGL.__version__
>>                 > '3.0.2a1'
>>                 > I'm using FORWARD_COMPATIBLE_ONLY, context version
>>                 3.3 and GLUT_CORE_PROFILE.
>>                 >
>>                 >
>>                 > I'm porting a working (same machine and environment
>>                 etc) C program to Python,
>>                 > and the glGenVertexArrays function is giving me grief.
>>                 >
>>                 > The pythonic form:
>>                 >     vao = glGenVertexArrays(1)
>>                 > produces "TypeError: this function takes at least 2
>>                 arguments" which I presume
>>                 > means it hasn't been wrapped yet.
>>                 Yes.
>>                 > I've no idea what could be causing that and
>>                 googling hasn't turned up anything
>>                 > useful.
>>                 >
>>                 > Does anyone have any suggestions as to where to look?
>>                 > Are there any known working examples of using
>>                 vertex array objects and pyopengl
>>                 > that I could cross check against?
>>                 My go-to guess with almost any Python-differs-from-C
>>                 problems during
>>                 init is to look at the error-checking code.
>>                  PyOpenGL's biggest
>>                 difference from C code is that it runs error checking
>>                 after every call.
>>                 I'm guessing either your context isn't quite
>>                 ready-to-go and you're
>>                 getting an error from the error checking, or that the
>>                 line before had an
>>                 error and the error checking picked it up a line late.
>>
>>                 import OpenGL
>>                 OpenGL.USE_ACCELERATE = False
>>                 OpenGL.ERROR_CHECKING = False
>>
>>                 at the top of your script should let you quickly
>>                 determine a) where the
>>                 problem is b) whether the problem is with error checking.
>>
>>
>>             If I turn error checking off it dies much earlier on a
>>             glCreateShader call with:
>>
>>             WARNING:OpenGL.errors:Failure on glCreateShader:
>>             Traceback (most recent call last):
>>               File
>>             "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py",
>>             line 74, in __call__
>>                 return function( *args, **named )
>>             ArgumentError: argument 3: <type 'exceptions.TypeError'>:
>>             Don't know how to convert parameter 3
>>
>>             Traceback (most recent call last):
>>               File "main.py", line 237, in <module>
>>                 main(sys.argv)
>>               File "main.py", line 227, in main
>>                 init()
>>               File "main.py", line 147, in init
>>                 init_program()
>>               File "main.py", line 122, in init_program
>>                 vert = gl.VertexShader("data/shaders/basic.vert")
>>               File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py",
>>             line 50, in __init__
>>                 _Shader.__init__(self, fname, VERTEX_SHADER)
>>               File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py",
>>             line 37, in __init__
>>                 self.shader = createShader(shader_type)
>>               File
>>             "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
>>             line 372, in __call__
>>                 return self( *args, **named )
>>               File
>>             "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py",
>>             line 74, in __call__
>>                 return function( *args, **named )
>>             ctypes.ArgumentError: argument 3: <type
>>             'exceptions.TypeError'>: Don't know how to convert
>>             parameter 3
>>
>>
>>             That doesn't seem like progress.
>>
>>             With error checking on calling glGetError right before
>>             the glGenVertexArrays call returns 0.
>>
>>             Toggling use accelerate hasn't made
>>             any noticeable difference.
>>
>>             I don't know if it helps any but I turned on full logging
>>             and attached a dump of the output.
>>
>>             G
>>
>>
>>
>
>
>         -- 
>         ________________________________________________
>           Mike C. Fletcher
>           Designer, VR Plumber, Coder
>           http://www.vrplumber.com
>           http://blog.vrplumber.com
>
>
>


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

Re: [PyOpenGL-Users] glGenBuffers problem

[Mike C. F. <vrp...@gm...>]

On 11-11-06 11:31 AM, Maximiliano Guerra wrote:
> Hi all, this is my first message in this list. Nice to meet you all.
>
> I just started learning Computer Graphics. I'm studying in
> the http://www.arcsynthesis.org/gltut
> It is very good for graphics concepts as well opengl, their code is in
> c++ but I'm wanting to do it with python.
>
> So I'm tring to do the first tutorial (you can find the code
> here: bitbucket.org/alfonse/gltut
> <http://bitbucket.org/alfonse/gltut>) step by step and I ran in some
> problems with glGenBuffers.
>
> In [1]: from OpenGL.GL import *
>
> In [2]: buf = glGenBuffers(1)
> NullFunctionError: Attempt to call an undefined function glGenBuffers,
> check for bool(glGenBuffers) before calling
...

Your code is attempting to call OpenGL-context requiring code without an
OpenGL context (window).  Do the glGenBuffer and similar calls within a
draw callback of your windowing system (e.g. GLUT).  You may also need
to verify that your machine has a reasonably recent video card that
supports modern OpenGL (but most do these days).

HTH,
Mike

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

Re: [PyOpenGL-Users] Texture colour wrapping

[Dirk R. <dir...@gm...>]

	Hi Brice,

On 11/07/2011 01:45 PM, Brice Thurin wrote:
> Thanks a lot for the example. It helps me quite a bit however I am not sure how
> to do what I wish to do. I attached to this email an example of what i would
> like to do.
> On the left hand side is my original phase map data on a polar grid. I want to
> make a polar to cartesian transformation of this phase map so it looks like the
> middle plot in the figure attached, here the phase map is on a cartesian grid.
> For this two first figures the grayscale cover -5 to 25 radians. Finally I want
> to wrap the phase data so the maximum grayscale value is max 6.28 radians.
>
>
> I managed to do the first step (polar to cartesian) using quad strip and texture
> mapping but i am not sure how I can get the vertex value from the middle stage
> map as it is already a texture. I am certainly missing something but I can not
> see what.

ah, that's a different story. If you only have the input data as an image my 
example won't work.

Three options:

1) Do the color mapping on the image. Just create a texture that has the same 
size as your input image, and do a pixel by pixel mapping from your input data 
to whatever output you want. Use the new image instead of the old one. This work 
ok if the data doesn't change.

2) Turn it into geometry. Create your quad strip vertices so that each pixel in 
the input image has a vertex. Assign the input data as a texture coordinate to 
that vertex. Then use my original example to do the mapping.

3) Use a shader. If 1 or 2 are no options, you can use a shader to do the color 
mapping. It would be a fairly simple fragment shader (look at 
PyOpenGL-Demo/proesch/shaderProg/textureShader.py for a basic example how to do 
shaders) that gets the data from the input image and then uses the read data 
value as the texture coordinate for the lookup table.


Hope it helps

	Dirk

[PyOpenGL-Users] glGenBuffers problem

[Maximiliano G. <max...@gm...>]

Hi all, this is my first message in this list. Nice to meet you all.

I just started learning Computer Graphics. I'm studying in the
http://www.arcsynthesis.org/gltut
It is very good for graphics concepts as well opengl, their code is in c++
but I'm wanting to do it with python.

So I'm tring to do the first tutorial (you can find the code here:
bitbucket.org/alfonse/gltut) step by step and I ran in some problems with
glGenBuffers.

In [1]: from OpenGL.GL import *

In [2]: buf = glGenBuffers(1)
NullFunctionError: Attempt to call an undefined function glGenBuffers,
check for bool(glGenBuffers) before calling

In [3]: bool(glGenBuffers)
Out[3]: False

In [4]: glGenBuffers
Out[4]: <OpenGL.platform.baseplatform.glGenBuffers at 0x10313d950>

I googled for solutions, and found another way to use it with:

In [5]: from OpenGL.GL.ARB.vertex_buffer_object import *

In [6]: buf = glGenBuffersARB(1)

But it returns me the very same problems above.

I even tried to use glInitVertexBufferObjectARB() eto check if everything
was ok (as I learned in
http://pyopengl.sourceforge.net/documentation/opengl_diffs.html) but it
gave me an Segmentation Fault

I went ahead and checked the next function I would need to use:
glBindBuffer, and its ARB version, both gave me the same errors of
glGenBuffer.

So there you have it, I'm stuck with this in the first tutorial, any help
is greatly appreciated.
Thanks in advance!

-- 
Maximiliano Guerra de Medeiros

Re: [PyOpenGL-Users] Texture colour wrapping

[Dirk R. <dir...@gm...>]

	Hi Brice,

On 11/05/2011 03:37 PM, Brice Thurin wrote:
> Hi Dirk,
>
> Thanks for your help. So if I understand properly, I first do the geometrical
> mapping to do the polar to cartesian transformation. Then I do the color mapping?

Yes and no. The actual mapping to color is done by the texture, you just need to 
feed your data into it in a way that puts the wraparound point at 0 and 1.

I appended a simple example.

> That's sound pretty neat to me.

It is! :) Its really cool, as you can mess with texture to show specific 
important values or ranges, make it smooth or stepped (like in my example) and 
many other cool tricks.

Hope it helps

	Dirk


#!/usr/bin/python2.4
#
# Use texture for visualizating a data value.
#
# Based on texturedQuad.py by "Peter Roesch" <Pet...@fh...>
#
# This code is licensed under the PyOpenGL License.
# Details are given in the file license.txt included in this distribution.

import sys
import array
import math

try:
   from OpenGL.GLUT import *
   from OpenGL.GL import *
   from OpenGL.GLU import *
except:
   print ''' Error PyOpenGL not installed properly !!'''
   sys.exit(  )

def display(  ):
	"""Glut display function."""
	glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT )
	glColor3f( 1, 1, 1 )

         # Draw a regular grid
         gridres=40
         for y in [y * 1. / gridres - 0.5 for y in range(0, gridres)]:
             glBegin(GL_QUAD_STRIP)

             for x in [x * 1. / gridres - 0.5 for x in range(0, gridres + 1)]:

		# This is where the data value goes...
                 glTexCoord1f( math.sin(x*x + y*y) * 5  )
                 glVertex3f( x, y, 0 )

                 y1 = y + 1. / gridres
                 glTexCoord1f( math.sin(x*x + y1*y1) * 5 )
                 glVertex3f( x, y1, 0 )
   	    glEnd(  )

	glutSwapBuffers (  )

def init(  ):
	"""Glut init function."""

	glClearColor ( 0, 0, 0, 0 )
	glShadeModel( GL_SMOOTH )

         # Build texture. Just a trivial grey step one for now
         # For a real app you would create a nice lookup table
         nsteps = 8

         ns = 256/nsteps
         tmpList = [ int(i/ns)*ns for i in range(0, 256) ]
         texdata = array.array( 'B', tmpList ).tostring( )
         texwidth = 256

	glTexParameterf( GL_TEXTURE_1D, GL_TEXTURE_WRAP_S, GL_REPEAT )
	glTexParameterf( GL_TEXTURE_1D, GL_TEXTURE_MAG_FILTER, GL_LINEAR )
	glTexParameterf( GL_TEXTURE_1D, GL_TEXTURE_MIN_FILTER, GL_LINEAR )

	glTexImage1D( GL_TEXTURE_1D, 0, 3, texwidth, 0,
                       GL_LUMINANCE, GL_UNSIGNED_BYTE, texdata)
	glEnable( GL_TEXTURE_1D )

glutInit( sys.argv )
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB )
glutInitWindowSize( 250, 250 )
glutInitWindowPosition( 100, 100 )
glutCreateWindow( sys.argv[0] )
init(  )
glutDisplayFunc( display )
glutMainLoop(  )

Re: [PyOpenGL-Users] Texture colour wrapping

[Brice T. <bps...@gm...>]

Hi Dirk,

Thanks for your help. So if I understand properly, I first do the
geometrical mapping to do the polar to cartesian transformation. Then I do
the color mapping?

That's sound pretty neat to me.

Thanks
Brice

On 5 November 2011 19:02, Dirk Reiners <dir...@gm...> wrote:

>
>        Hi Brice,
>
> On 11/05/2011 01:46 PM, Brice Thurin wrote:
> > Thanks for both your reply. The range of the input data vary but I could
> fix it
> > if it makes things easier.
> >
> > Note I do not want 2pi and 4pi to both map to the same physical
> location, I want
> > 2pi and 4pi to be displayed with the same gray level or colour.
>
> Ah, ok, I was starting to get confused. You really do want the basic input
> value
> -> color mapping.
>
> That's pretty easy. Define the color map that you want to use as a texture
> (1D
> is fine, 2D works too). Set the texture wrapping mode to REPEAT
> (glTexParameter(GL_TEXTURE_1D, GL_TEXTURE_WRAP_S, GL_REPEAT)). This makes
> OpenGL
> accept any texture coordinate value and just use the fractional part to
> index
> into the texture.  Use your input values (your -15pi to 15pi) as the
> texture
> coordinate for each vertex. The texture coordinates will always be between
> 0 and
> 1, so if you want the texture to repeat after 2pi you will either need to
> divide
> them by 2pi before giving them to OpenGL, or use a texture matrix to
> divide.
>
> Hope it helps
>
>        Dirk
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Gordon W. <go...@to...>]

The plot thickens, if I bypass pyopengl and do the glGenVertexArrays call
direct through ctypes the "invalid enumerant" error moves to the
subsequent glBindVertexArray call, if I use cytpes for that as well then
everything starts working.

G

On Fri, Nov 4, 2011 at 11:30 PM, Gordon Wrigley <go...@to...> wrote:

> I just got a chance to get back to this and I've made a little head way,
> far enough that I have something on screen.
> Specifying GLUT_COMPATIBILITY_PROFILE instead of GLUT_CORE_PROFILE got
> round the glGenVertexArrays error.
> I also had to do ctypes stuff to work around the lack of wrapper for that
> function.
> And the function glVertexAttribPointer was getting cast errors on the last
> argument so I had to ctypes around that as well.
> I believe that's the only dirty stuff I have so far.
>
> G
>
>
> On Tue, Oct 25, 2011 at 1:56 AM, Mike C. Fletcher <mcf...@vr...>wrote:
>
>> **
>> On 11-10-20 06:41 AM, Gordon Wrigley wrote:
>>
>> And I attached the wrong log, here's the correct one.
>>
>>
>> Hrm, not much to go on there.  The call to createShader() does not appear
>> in the stack, which is a bit weird.  Is this code I could trace through to
>> try to find the error (i.e. not something proprietary?)
>>
>> Good luck,
>> Mike
>>
>>
>>
>> On Thu, Oct 20, 2011 at 9:39 PM, Gordon Wrigley <go...@to...>wrote:
>>
>>>   On Tue, Oct 18, 2011 at 4:56 AM, Mike C. Fletcher <
>>> mcf...@vr...> wrote:
>>>
>>>> On 11-10-12 03:34 AM, tolomea wrote:
>>>> > Version stuff:
>>>> > Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
>>>> > [GCC 4.5.2] on linux2
>>>> > Type "help", "copyright", "credits" or "license" for more information.
>>>> > import OpenGL
>>>> > OpenGL.__version__
>>>> > '3.0.2a1'
>>>> > I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and
>>>> GLUT_CORE_PROFILE.
>>>> >
>>>> >
>>>> > I'm porting a working (same machine and environment etc) C program to
>>>> Python,
>>>> > and the glGenVertexArrays function is giving me grief.
>>>> >
>>>> > The pythonic form:
>>>> >     vao = glGenVertexArrays(1)
>>>> > produces "TypeError: this function takes at least 2 arguments" which
>>>> I presume
>>>> > means it hasn't been wrapped yet.
>>>>  Yes.
>>>> > I've no idea what could be causing that and googling hasn't turned up
>>>> anything
>>>> > useful.
>>>> >
>>>> > Does anyone have any suggestions as to where to look?
>>>> > Are there any known working examples of using vertex array objects
>>>> and pyopengl
>>>> > that I could cross check against?
>>>>  My go-to guess with almost any Python-differs-from-C problems during
>>>> init is to look at the error-checking code.  PyOpenGL's biggest
>>>> difference from C code is that it runs error checking after every call.
>>>> I'm guessing either your context isn't quite ready-to-go and you're
>>>> getting an error from the error checking, or that the line before had an
>>>> error and the error checking picked it up a line late.
>>>>
>>>> import OpenGL
>>>> OpenGL.USE_ACCELERATE = False
>>>> OpenGL.ERROR_CHECKING = False
>>>>
>>>> at the top of your script should let you quickly determine a) where the
>>>> problem is b) whether the problem is with error checking.
>>>>
>>>>
>>>   If I turn error checking off it dies much earlier on a glCreateShader
>>> call with:
>>>
>>>  WARNING:OpenGL.errors:Failure on glCreateShader: Traceback (most
>>> recent call last):
>>>   File "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py", line 74,
>>> in __call__
>>>     return function( *args, **named )
>>> ArgumentError: argument 3: <type 'exceptions.TypeError'>: Don't know how
>>> to convert parameter 3
>>>
>>>  Traceback (most recent call last):
>>>    File "main.py", line 237, in <module>
>>>     main(sys.argv)
>>>   File "main.py", line 227, in main
>>>      init()
>>>   File "main.py", line 147, in init
>>>     init_program()
>>>   File "main.py", line 122, in init_program
>>>     vert = gl.VertexShader("data/shaders/basic.vert")
>>>   File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py", line 50, in
>>> __init__
>>>     _Shader.__init__(self, fname, VERTEX_SHADER)
>>>   File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py", line 37, in
>>> __init__
>>>     self.shader = createShader(shader_type)
>>>    File
>>> "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
>>> line 372, in __call__
>>>     return self( *args, **named )
>>>    File "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py", line
>>> 74, in __call__
>>>     return function( *args, **named )
>>> ctypes.ArgumentError: argument 3: <type 'exceptions.TypeError'>: Don't
>>> know how to convert parameter 3
>>>
>>>
>>>  That doesn't seem like progress.
>>>
>>>  With error checking on calling glGetError right before the
>>> glGenVertexArrays call returns 0.
>>>
>>>  Toggling use accelerate hasn't made any noticeable difference.
>>>
>>>  I don't know if it helps any but I turned on full logging and attached
>>> a dump of the output.
>>>
>>>  G
>>>
>>>
>>>
>>
>>
>> --
>> ________________________________________________
>>   Mike C. Fletcher
>>   Designer, VR Plumber, Coder
>>   http://www.vrplumber.com
>>   http://blog.vrplumber.com
>>
>>
>

Re: [PyOpenGL-Users] Texture colour wrapping

[Dirk R. <dir...@gm...>]

	Hi Brice,

On 11/05/2011 01:46 PM, Brice Thurin wrote:
> Thanks for both your reply. The range of the input data vary but I could fix it
> if it makes things easier.
>
> Note I do not want 2pi and 4pi to both map to the same physical location, I want
> 2pi and 4pi to be displayed with the same gray level or colour.

Ah, ok, I was starting to get confused. You really do want the basic input value 
-> color mapping.

That's pretty easy. Define the color map that you want to use as a texture (1D 
is fine, 2D works too). Set the texture wrapping mode to REPEAT 
(glTexParameter(GL_TEXTURE_1D, GL_TEXTURE_WRAP_S, GL_REPEAT)). This makes OpenGL 
accept any texture coordinate value and just use the fractional part to index 
into the texture.  Use your input values (your -15pi to 15pi) as the texture 
coordinate for each vertex. The texture coordinates will always be between 0 and 
1, so if you want the texture to repeat after 2pi you will either need to divide 
them by 2pi before giving them to OpenGL, or use a texture matrix to divide.

Hope it helps

	Dirk

Re: [PyOpenGL-Users] Texture colour wrapping

[Brice T. <bps...@gm...>]

Thanks for both your reply. The range of the input data vary but I could
fix it if it makes things easier.

Note I do not want 2pi and 4pi to both map to the same physical location, I
want 2pi and 4pi to be displayed with the same gray level or colour.

Brice

On 5 November 2011 18:28, Ian Mallett <geo...@gm...> wrote:

> So, the range of the input data is -15pi to 15pi, and you want to map it
> onto a disk, such that the input data maps to the 0-2pi (i.e., phase data
> for 2pi and 4pi both map to the same physical location?)
>
> Ian
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>

Re: [PyOpenGL-Users] Texture colour wrapping

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

So, the range of the input data is -15pi to 15pi, and you want to map it
onto a disk, such that the input data maps to the 0-2pi (i.e., phase data
for 2pi and 4pi both map to the same physical location?)

Ian

Re: [PyOpenGL-Users] Texture colour wrapping

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

On Sat, 2011-11-05 at 12:14 +0000, Brice Thurin wrote:
> I am getting the phase map as 2D numpy array in polar coordinates. And
> i need to display this phase map not as a square but as a disk, which
> i can do with texture mapping. The phase map has type float and i want
> the grayscale to be ranging between 0 and 2ð and not between -15ð and
> 15ð. I have tried to apply the grayscale "wrapping" before the mapping
> but it does not lead to satisfactory result, I believe applying it
> after the polar to cartesian is better. It is how it is currently done
> with the CPU but I am interested to implement it on GPU.

It should be fairly trivial to write a shader to do this, either by
computing it directly or using an indirect texture lookup, since your
phases are well defined to be in the range -15pi to 15pi (that symbol
was meant to be pi right?). Someone more competent that I am could
surely tell you which would be the better option to use in this case
(and I'd be interested to know the answer!).

Cheers,

Henry

Re: [PyOpenGL-Users] Texture colour wrapping

[Brice T. <bps...@gm...>]

Good evening,

Thank you for your reply.I do not mean wrapping geometry.

Basically I have some phase data expressed in radians, which could be
anything between -15ð and +15ð. I want to display this phase wrapped with
min and max value between 2ð.

I am getting the phase map as 2D numpy array in polar coordinates. And i
need to display this phase map not as a square but as a disk, which i can
do with texture mapping. The phase map has type float and i want the
grayscale to be ranging between 0 and 2ð and not between -15ð and 15ð. I
have tried to apply the grayscale "wrapping" before the mapping but it does
not lead to satisfactory result, I believe applying it after the polar to
cartesian is better. It is how it is currently done with the CPU but I am
interested to implement it on GPU.

I hope it is a bit clearer. Please do not hesitate to ask me to clarify
things.

Best

On 4 November 2011 16:51, Ian Mallett <geo...@gm...> wrote:

> What do you mean by wrapping?  Is this like wrapping geometry?  Or
> implicitly wrapping in texture space?  Or doing filtering across texel
> boundaries?
>
> Can you describe basically what you're trying to do?
>
> Ian
>

[PyOpenGL-Users] Question about developping PyOpenGL

[Leon W. <Le...@gm...>]

Hi to all,
I hope the developer of PyOpenGL read this and answer me.

I want to know if PyOpenGL is developed at the moment.
Or if the developing stopped.

Because I want to know if there will come a update which supports OpenGL 4.

Could anyone who know the answer to this question please answer me at my 
E-Mail: Le...@gm...

thanks Leon

Re: [PyOpenGL-Users] Texture colour wrapping

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

What do you mean by wrapping?  Is this like wrapping geometry?  Or
implicitly wrapping in texture space?  Or doing filtering across texel
boundaries?

Can you describe basically what you're trying to do?

Ian

[PyOpenGL-Users] Texture colour wrapping

[Brice T. <bps...@gm...>]

Good Afternoon,

I am new to OpenGL and I was wondering if somebody could tell me if what I
am intending to do is feasible with PyOpenGL.
Here is my problem,

I have data contained in a 2D numpy array of type float. The values in the
array are phase data in polar coordinates. From the array, I am creating a
texture which I mapped using quad strips in order to get the polar to
cartesian conversion.

Once this mapping is done I would like to "wrap" the phase/colour value.
For example, I could have phase value ranging from 0.0 to 6.2 and I want to
ignore the integer par of the value so value(1.3) = value(2.3) =value(3.3)
etc...

I can not do the "colour wrapping" before the mapping (I've tried). The
results is not right an limited by the resolution of the texture.

I was wondering if it would be possible to do such a wrapping, I have been
thinking maybe a lookup table or a shader could be used... This is where I
would appreciate getting some advices.

Thanks in advance.

Regards

Brice

Re: [PyOpenGL-Users] Tutorials and "from foo import *"

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

On 11-10-23 11:11 PM, Derakon wrote:
> I decided it was time to start taking my OpenGL knowledge past the
> textured quads I'd needed for my 2D work, so I looked up tutorials on
> shaders, and found this:
>
> http://pyopengl.sourceforge.net/context/tutorials/shader_1.xhtml
>
> Now, regardless of your opinion on how terse or verbose a language
> should be, I think we can all agree that clarity is vital for
> tutorials. The reader doesn't know what's going on, so the code needs
> to be as explicit as possible; otherwise the reader just ends up
> confused. Terseness is often an anti-virtue here. So it's a bad sign
> when that tutorial leads off by importing * from a bunch of modules.
> The problem with importing * is that you then have no idea where a
> given symbol comes from. Where did compileShader originate?
> glUseProgram? GL_FRAGMENT_SHADER? And so on. The author of the
> tutorial presumably knows, and very likely anyone with any experience
> with PyOpenGL would also know, but those aren't the target audience
> here. The people reading this code will want to be able to adapt it to
> their own needs, and that's harder when
>
> So I'd like to request that someone with the appropriate knowledge and
> access change all of the imports to either import the specific
> components needed (as in "from OpenGL.arrays import vbo" in that
> tutorial) or simply import the module and then refer to it by name
> ("import OpenGLContext; BaseContext =
> OpenGLContext.testingcontext.getInteractive()").
>
> And yes, this extends to all of the things under the OpenGL.GL
> namespace. Reduction to "import OpenGL.GL as GL" is fine, but some
> explicit namespace still needs to be there (or else the "from foo
> import specific items" approach). Yes, it'll result in a lot of
> silly-looking things like "GL.GL_TRIANGLES", but silly is far better
> than obscure when it comes to tutorials.
>
> Otherwise, this looks like it should be a very useful tutorial; my
> thanks to whoever wrote it.
I'd be hesitant to adopt that style for the code, as it is non-idiomatic
wrt general PyOpenGL code.  That said, explicitly referencing the
shaders.* entry points might make sense (they are about the only entry
points which don't follow the "if it starts with gl or GL_ it comes from
OpenGL.GL, if it starts with glu or GLU_ it comes from OpenGL.GLU, if it
starts with glut or GLUT_ it comes from OpenGL.GLUT" rule).  That said,
they are *intended* to override the OpenGL.GL namespace variants on
import to make it easier to use the "core" functions on older hardware.

Further discussion of where entry points are coming from is also quite
possible.  I'll look into adding it.

Have fun,
Mike

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

[PyOpenGL-Users] Tutorials and "from foo import *"

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

I decided it was time to start taking my OpenGL knowledge past the
textured quads I'd needed for my 2D work, so I looked up tutorials on
shaders, and found this:

http://pyopengl.sourceforge.net/context/tutorials/shader_1.xhtml

Now, regardless of your opinion on how terse or verbose a language
should be, I think we can all agree that clarity is vital for
tutorials. The reader doesn't know what's going on, so the code needs
to be as explicit as possible; otherwise the reader just ends up
confused. Terseness is often an anti-virtue here. So it's a bad sign
when that tutorial leads off by importing * from a bunch of modules.
The problem with importing * is that you then have no idea where a
given symbol comes from. Where did compileShader originate?
glUseProgram? GL_FRAGMENT_SHADER? And so on. The author of the
tutorial presumably knows, and very likely anyone with any experience
with PyOpenGL would also know, but those aren't the target audience
here. The people reading this code will want to be able to adapt it to
their own needs, and that's harder when

So I'd like to request that someone with the appropriate knowledge and
access change all of the imports to either import the specific
components needed (as in "from OpenGL.arrays import vbo" in that
tutorial) or simply import the module and then refer to it by name
("import OpenGLContext; BaseContext =
OpenGLContext.testingcontext.getInteractive()").

And yes, this extends to all of the things under the OpenGL.GL
namespace. Reduction to "import OpenGL.GL as GL" is fine, but some
explicit namespace still needs to be there (or else the "from foo
import specific items" approach). Yes, it'll result in a lot of
silly-looking things like "GL.GL_TRIANGLES", but silly is far better
than obscure when it comes to tutorials.

Otherwise, this looks like it should be a very useful tutorial; my
thanks to whoever wrote it.

-Chris

Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

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

On 11-10-12 03:34 AM, tolomea wrote:
> Version stuff:
> Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
> [GCC 4.5.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> import OpenGL
> OpenGL.__version__
> '3.0.2a1'
> I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and GLUT_CORE_PROFILE.
>
>
> I'm porting a working (same machine and environment etc) C program to Python, 
> and the glGenVertexArrays function is giving me grief.
>
> The pythonic form:
>     vao = glGenVertexArrays(1)
> produces "TypeError: this function takes at least 2 arguments" which I presume 
> means it hasn't been wrapped yet.
Yes.
> I've no idea what could be causing that and googling hasn't turned up anything 
> useful.
>
> Does anyone have any suggestions as to where to look?
> Are there any known working examples of using vertex array objects and pyopengl 
> that I could cross check against?
My go-to guess with almost any Python-differs-from-C problems during
init is to look at the error-checking code.  PyOpenGL's biggest
difference from C code is that it runs error checking after every call. 
I'm guessing either your context isn't quite ready-to-go and you're
getting an error from the error checking, or that the line before had an
error and the error checking picked it up a line late.

import OpenGL
OpenGL.USE_ACCELERATE = False
OpenGL.ERROR_CHECKING = False

at the top of your script should let you quickly determine a) where the
problem is b) whether the problem is with error checking.

HTH,
Mike

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

[PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Gordon W. <go...@to...>]

Version stuff:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import OpenGL
OpenGL.__version__
'3.0.2a1'
I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and
GLUT_CORE_PROFILE.


I'm porting a working (same machine and environment etc) C program to
Python,
and the glGenVertexArrays function is giving me grief.

The pythonic form:
    vao = glGenVertexArrays(1)
produces "TypeError: this function takes at least 2 arguments" which I
presume
means it hasn't been wrapped yet.

The ctypes form:
    vao = GLuint()
    glGenVertexArrays(1, ctypes.byref(vao))
produces:
Traceback (most recent call last):
  File "main.py", line 230, in <module>
    main(sys.argv)
  File "main.py", line 221, in main
    init()
  File "main.py", line 155, in init
    glGenVertexArrays(1, ctypes.byref(vao))
  File
"/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py",
line 372, in __call__
    return self( *args, **named )
  File "/usr/local/lib/python2.7/dist-packages/OpenGL/error.py", line 208,
in
glCheckError
    baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1280,
description = 'invalid enumerant',
baseOperation = glGenVertexArrays,
cArguments = (1, <cparam 'P' (0xb74b9b48)>)
)

I've no idea what could be causing that and googling hasn't turned up
anything
useful.

Does anyone have any suggestions as to where to look?
Are there any known working examples of using vertex array objects and
pyopengl
that I could cross check against?

G