pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] How to use shaders in pyopengl

[Don L. <go...@gm...>]

I'm having a similar problem with shaders in Windows.

I have a WxPython/PyOpenGL app that uses shaders and works fine in
Ubuntu 8.10, but when I try to run it in Windows XP, I get this error:

  File "c:\program
files\python\lib\site-packages\PyOpenGL-3.0.0b6-py2.5.egg\OpenGL\platform\baseplatform.py",
line 280, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function
glCreateProgram, check for bool(glCreateProgram) before calling

If I understand correctly, this is because OpenGL for Windows is stuck
at version 1.1 and needs extensions to use shaders. I'm not exactly
clear on how to use extensions, but judging from your
OpenGL/tests/tests.py file, all you have to do is import the proper
extension. I also found this snippet on your blog and in a tutorial:

from OpenGL.GL import *
from OpenGL.GL.ARB.shader_objects import *
from OpenGL.GL.ARB.fragment_shader import *
from OpenGL.GL.ARB.vertex_shader import *
from OpenGL.extensions import alternate
glCreateShader = alternate( 'glCreateShader', glCreateShader,
glCreateShaderObjectARB )
glShaderSource = alternate( 'glShaderSource', glShaderSource, glShaderSourceARB)
glCompileShader = alternate( 'glCompileShader', glCompileShader,
glCompileShaderARB)
glCreateProgram = alternate( 'glCreateProgram', glCreateProgram,
glCreateProgramObjectARB)
glAttachShader = alternate( 'glAttachShader', glAttachShader,glAttachObjectARB )
glValidateProgram = alternate(
'glValidateProgram',glValidateProgram,glValidateProgramARB )
glLinkProgram = alternate( 'glLinkProgram',glLinkProgram,glLinkProgramARB )
glDeleteShader = alternate( 'glDeleteShader', glDeleteShader,glDeleteObjectARB )
glUseProgram = alternate('glUseProgram',glUseProgram,glUseProgramObjectARB )

But adding this doesn't help. I just get this error instead:

  File "c:\program
files\python\lib\site-packages\PyOpenGL-3.0.0b6-py2.5.egg\OpenGL\extensions.py",
line 65, in __call__
    self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined alterate
function (glCreateProgram, glCreateProgramObjectARB), check for
bool(glCreateProgram) before calling

Do I need to do something first to make the extensions available to
use? To see which extensions are available, I added the following line
to my program just before the glCreateProgram call:

print "\n".join(glGetString(GL_EXTENSIONS).split(' '))

And this is what it says:

GL_WIN_swap_hint
GL_EXT_bgra
GL_EXT_paletted_texture

Do I need to use glewpy or something to get access to the shader
extensions in Windows? I've confirmed that OpenGL shader extensions
work on this computer with OpenGL Extensions Viewer. I've also tried
the release version of PyOpenGL 3.0.0b6 as well as the CVS head
version (but not the bzr version). I'm stumped... The OpenGL red book
states that "OpenGL 1.2 introduces the first ARB-approved extensions."
Is that relevant, considering OpenGL is 1.1 in Windows?

I've attached my program. The OpenGL code is in fft/map/viewer.py. Any
help would be appreciated.

Thanks,
-gomtuu

Re: [PyOpenGL-Users] [Fwd: Re: Vertex Buffer Objects]

[Steven W. <st...@li...>]

Mike C. Fletcher wrote:
> Steven White wrote:
>> After dinner I was able to sit down with some help and remove several 
>> questionable lines of code that had slowly found there way in to the 
>> code as I was stripping down the application during debugging to find 
>> the error.  Unifying the type to GL.GLuint seems to have fixed the 
>> system crash problem, but the VBO will still does not post to the 
>> display.  By removing the index buffer and only using the index data 
>> during the glDrawArrays  call I was able to get what looked like a 
>> bow tie artifact on the screen on my friends fedora 5 machine, but 
>> both of my personal machines render only the clear color.  
> I've attached a version that (with current BZR head of PyOpenGL) 
> renders two squares.  You can comment out the second call to 
> glDrawElements if you want to run it on an older PyOpenGL.  I'm just 
> using the OpenGL.arrays.vbo.VBO implementation, I know, lazy, but oh 
> well.  If you want you can just trace through and see what OpenGL 
> calls are running with the VBO bind/unbind calls.  This version will 
> work with either core or ARB versions of vertex buffer objects.
>
> BTW, if you could just attach runnable files when sending a support 
> request it would help me.  Having to strip off the line numbers uses 
> up time that could be spent on development.
>> I have stripped my application to an exit command and a single 
>> polygon render and attached copied it at the bottom of this message.  
>> I am hopping in the morning someone with more experience in pyOpenGL 
>> can inform me on what may be causing the issue.  As a side note I am 
>> having a rather hard time debugging the application because non of my 
>> profilers seem to be able to intercept the opengl calls.  Does anyone 
>> have a solution for the OpenGL side of an pyOpenGL application like 
>> you would in C.
> You can use the built-in pdb module to debug Python code.  Just do:
>
>    import pdb; pdb.set_trace()
>
> before the call you want to trace into and you can step down to the 
> call that's going into the GL.  Since that call is normally to the 
> system GL directly it's somewhat difficult to trace it below that (you 
> can go into ctypes, but that's seldom useful), since ctypes has 
> stabilized I haven't had to go below that level.
>
> HTH,
> Mike
>
Thanks for the help.  I wasn't sure if the mailing list would allow 
attachments, I will make sure to do so in the future

Steven A White

Re: [PyOpenGL-Users] [Fwd: Re: Vertex Buffer Objects]

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

Steven White wrote:
> After dinner I was able to sit down with some help and remove several 
> questionable lines of code that had slowly found there way in to the 
> code as I was stripping down the application during debugging to find 
> the error.  Unifying the type to GL.GLuint seems to have fixed the 
> system crash problem, but the VBO will still does not post to the 
> display.  By removing the index buffer and only using the index data 
> during the glDrawArrays  call I was able to get what looked like a bow 
> tie artifact on the screen on my friends fedora 5 machine, but both of 
> my personal machines render only the clear color.  
I've attached a version that (with current BZR head of PyOpenGL) renders 
two squares.  You can comment out the second call to glDrawElements if 
you want to run it on an older PyOpenGL.  I'm just using the 
OpenGL.arrays.vbo.VBO implementation, I know, lazy, but oh well.  If you 
want you can just trace through and see what OpenGL calls are running 
with the VBO bind/unbind calls.  This version will work with either core 
or ARB versions of vertex buffer objects.

BTW, if you could just attach runnable files when sending a support 
request it would help me.  Having to strip off the line numbers uses up 
time that could be spent on development.
> I have stripped my application to an exit command and a single polygon 
> render and attached copied it at the bottom of this message.  I am 
> hopping in the morning someone with more experience in pyOpenGL can 
> inform me on what may be causing the issue.  As a side note I am 
> having a rather hard time debugging the application because non of my 
> profilers seem to be able to intercept the opengl calls.  Does anyone 
> have a solution for the OpenGL side of an pyOpenGL application like 
> you would in C.
You can use the built-in pdb module to debug Python code.  Just do:

    import pdb; pdb.set_trace()

before the call you want to trace into and you can step down to the call 
that's going into the GL.  Since that call is normally to the system GL 
directly it's somewhat difficult to trace it below that (you can go into 
ctypes, but that's seldom useful), since ctypes has stabilized I haven't 
had to go below that level.

HTH,
Mike

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

[PyOpenGL-Users] [Fwd: Re: Vertex Buffer Objects]

[Steven W. <st...@Li...>]

[PyOpenGL-Users] Vertex Buffer Objects

[Steven W. <st...@li...>]

I need some advice with creating VBOs in PyOpenGL.  I was writing a demo 
app to use a template for a student assignment and ironically I can not 
seem to create one myself.  I've included some excerpts from the demo 
application and the top of the call stack from the crash log.  I am 
working under the assumption that I just do not know how to pass memory 
address properly in python.  Any advice would  be appreciated.

Test System is a MacBook Pro ATI graphics card.

VertexBuffer = GL.GLuint(0)   
IndexBuffer  = GL.GLuint(0)

def initBuffer
    global VertexBuffer,IndexBuffer
    VertexBuffer = glGenBuffersARB(1)   
    IndexBuffer = glGenBuffersARB(1)

def DrawGLScene():
    """
    Main drawing function
    """

    # Clear The Screen And The Depth Buffer
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
    glLoadIdentity()                 # Reset The View
    glTranslatef( 0.0, 0.0, -25.0)   # Move out a bit to see everything.
 
    global VertexBuffer,IndexData
    glColor3f(1,1,1)
    glDisable(GL_TEXTURE_2D)
    glDisable(GL_LIGHTING)
    glColor3f(1,1,1)
    glBegin(GL_QUADS)   # Create a White Polygon
    glVertex3d(-25,-10,-25);
    glVertex3d( 25,-10,-25);
    glVertex3d( 25,-10, 25);
    glVertex3d(-25,-10, 25);
    glEnd()
    glColor3f(1,0,0)
    indexData=array([0,1,2,3], dtype=int)#Load The VBO With the same 
polygon just a little higher
    vertexCoordData=array([-25, -8, -25, 
                      25, -8, -25,
                      25, -8,  25,
                     -25, -8,  25],dtype=float)
   
   
    glEnableClientState(GL_VERTEX_ARRAY)
    glBindBufferARB(GL_ARRAY_BUFFER_ARB, VertexBuffer);
    glBufferDataARB(GL_ARRAY_BUFFER_ARB, vertexCoordData, 
GL_STREAM_DRAW);        
    glVertexPointer(3,GL_FLOAT,0,None);
   
   
    glEnableClientState(GL_VERTEX_ARRAY)
    glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER, IndexBuffer);
    glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER, indexData, 
GL_STREAM_DRAW);        
    glIndexPointer(GL_INT,0,None);
   
    glDrawElements( GL_QUADS,12, GL_UNSIGNED_INT,indexData);
    glDisableClientState(GL_VERTEX_ARRAY);
   
    glEnable(GL_TEXTURE_2D)
    glEnable(GL_LIGHTING)
    
    # since this is double buffered, swap the buffers to display what 
just got
    # drawn.
    glutSwapBuffers()              


Crash Log
Thread 0 Crashed:
0   libSystem.B.dylib                 0xffff07c2 __memcpy + 34
1   ...pple.ATIRadeonX1000GLDriver    0x131d7ee1 gldAllocVertexBuffer + 
27809
2   GLEngine                          0x130b54ee 
gleDrawArraysOrElements_VBO_Exec + 1950
3   libGL.dylib                       0x93302aa4 glDrawElements + 52
4   _ctypes.so                        0x00abb41d .LCFI1 + 23 (darwin.S:84)
5   _ctypes.so                        0x00abb3be ffi_call + 98 
(ffi_darwin.c:265)
6   _ctypes.so                        0x00ab5e98 _CallProc + 355 
(callproc.c:679)
......

Re: [PyOpenGL-Users] Shading with Interpolated Normals

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

Mike C. Fletcher wrote:
> Chris Finley wrote:
>   

...
>> How do you read the "varying" attribute (pixel normal) that should be
>> passed into the function?
>>   
>>     
> My understanding is that you query for a "uniform" variable (a simple 
> integer) based on the name you use in your program, 
The function to do this, unfortunately, is currently not wrapped 
elegantly.  You'll have to append a "\000" to your program name to avoid 
memory-access failures when you use it...

            result = glGetUniformLocationARB( self.__shaderProgramID, 
variableName+'\000' )

because the array-type conversion will not automatically add the 
null-byte to signal the end of the variable name.  I'll try to get that 
fixed soon.
> then use the 
> glUniform* set of functions with that argument to pass the values into 
> your shader program.  You'll likely need to have the shader in "use" at 
> the time (glUseProgram*).
>   
I've just confirmed this.  You *must* have glUseProgram* called when you 
attempt to call the uniform-related functions, if you don't you'll get 
core-dumps (at least on Linux, with an Nvidia card).  Note that (e.g.) 
calls to glutMainloop() reset the glUseProgram, so you'll likely want to 
"use" the program close to where you do your uniform calls.

HTH,
Mike

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

Re: [PyOpenGL-Users] pointer for vertex index

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

Prashant Saxena wrote:
> Hi,
>
> I am creating a viewer to display Renderman (.rib) using PyOpenGL. 
> I'll be using either vertex arrays or VBO to store and render the data.
>
> A 6 face polygonal cube in .rib format: (5 faces are quad and I 
> purposely divided 4th face into 2 triangles before exporting from 3d 
> application)
>   PointsGeneralPolygons
>     [ 4 4 4 4 3 3 4 ] #number of vertices in face
>     [ 2 3 1 0 4 5 3 2 6 7 5 4 0 1 7 6 3 7
>       1 5 7 3 4 2 0 6 ] #vertex index
>     "vertex point P" [ -4.470358 -4.1476117 3.9099706 4.470358 
> -4.1476117 3.9099706 -4.470358 4.1476117 3.9099706 4.470358 4.1476117 
> 3.9099706
>       -4.470358 4.1476117 -3.9099706 4.470358 4.1476117 -3.9099706 
> -4.470358 -4.1476117 -3.9099706 4.470358 -4.1476117 -3.9099706 ]
>     "facevarying normal N" [ 0 0 1 0 0 1 0 0 1 0 0 1
>       0 1 0 0 1 0 0 1 0 0 1 0
>       0 0 -1 0 0 -1 0 0 -1 0 0 -1
>       0 -1 0 0 -1 0 0 -1 0 0 -1 0
>       1 0 0 1 0 0 1 0 0 1 0 0
>       1 0 0 1 0 0 -1 0 0 -1 0 0
>       -1 0 0 -1 0 0 ]
>     "facevarying float[2] st" [ 0.375 0.75 0.625 0.75 0.625 1 0.375 1 
> 0.375 0.5 0.625 0.5
>       0.625 0.75 0.375 0.75 0.375 0.25 0.625 0.25 0.625 0.5 0.375 0.5
>       0.375 0 0.625 0 0.625 0..25 0.375 0.25 0.625 0.75 0.875 1
>       0.625 1 0.875 0.75 0.875 1 0.625 0.75 0.125 0.75 0.375 0.75
>
> Here normals and "st" (texture coord) are per face basis while 
> vertices are object basis. In OpenGL we have three different pointers 
> to feed this data in:        glVertexPointer, glTexCoordPointer and 
> glNormalPointer.
>
> 1. In above case I would be needing vertices array also per face basis 
> to pass them into glVertexPointer, which I could do by parsing vertex 
> index array and vertices. Do we have something in GL to overcome this 
> problem and creting the mesh using the information as it's already 
> there in the rib.
You generally are going to need equally-indexed arrays AFAIK.  That is, 
you need to be able to say "render vertex X from current arrays".  When 
you have that, you can use e.g. glDrawElements or glDrawRangeElements to 
render the data-set.  Although there might be some extension that allows 
you to use different indices for the various arrays, I don't believe 
anything in core allows you to do so.

In summary: yes, you will likely need to expand your vertex array.
> 2. Secondly we have quads as well as tris in this case. Is it possible 
> to pass an array which contains both of them. For example:
>     [[...],
>      [a,b,c], #three verts of a triangle
>      [a,b,c,d], #four vertices of a quad
You can pass them in in the same array/vbo and then use multiple calls 
to glDrawElements to render the geometry.

HTH,
Mike

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

Re: [PyOpenGL-Users] Shading with Interpolated Normals

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

Chris Finley wrote:
> Greetings,
>
> After Googling and searching the archives, I was unable to find an
> example of fragment shading using interpolated vertex normals, can
> someone point me in the right direction or send some sample code?
>   
Example of a fragment shader using GLSL:

http://bazaar.launchpad.net/~mcfletch/pyopengl-demo/trunk/annotate/2?file_id=shader_test.py-20080923005140-67c17kywpwxa2usj-25
> How do you create the fragment shading function, is there a GLSL Python
> extension? 
>   
PyOpenGL exposes all of the mainline shader-related extensions.  I think 
we've got "friendly" (Pythonic) wrappers for the most commonly used 
shader APIs.
> How do you read the "varying" attribute (pixel normal) that should be
> passed into the function?
>   
My understanding is that you query for a "uniform" variable (a simple 
integer) based on the name you use in your program, then use the 
glUniform* set of functions with that argument to pass the values into 
your shader program.  You'll likely need to have the shader in "use" at 
the time (glUseProgram*).

HTH,
Mike
> This was the closest article that I could find:
> http://www.lighthouse3d.com/opengl/glsl/index.php?toon2
>   

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

[PyOpenGL-Users] Shading with Interpolated Normals

[Chris F. <cfinley@u.washington.edu>]

Greetings,

After Googling and searching the archives, I was unable to find an
example of fragment shading using interpolated vertex normals, can
someone point me in the right direction or send some sample code?

How do you create the fragment shading function, is there a GLSL Python
extension? 
How do you read the "varying" attribute (pixel normal) that should be
passed into the function?

You help and time are greatly appreciated,
Chris

This was the closest article that I could find:
http://www.lighthouse3d.com/opengl/glsl/index.php?toon2

[PyOpenGL-Users] pointer for vertex index

[Prashant S. <ani...@ya...>]

Hi,

I am creating a viewer to display Renderman (.rib) using PyOpenGL. I'll be using either vertex arrays or VBO to store and render the data.

A 6 face polygonal cube in .rib format: (5 faces are quad and I purposely divided 4th face into 2 triangles before exporting from 3d application)
  PointsGeneralPolygons 
    [ 4 4 4 4 3 3 4 ] #number of vertices in face
    [ 2 3 1 0 4 5 3 2 6 7 5 4 0 1 7 6 3 7 
      1 5 7 3 4 2 0 6 ] #vertex index
    "vertex point P" [ -4.470358 -4.1476117 3.9099706 4.470358 -4.1476117 3.9099706 -4.470358 4.1476117 3.9099706 4.470358 4.1476117 3.9099706 
      -4.470358 4.1476117 -3.9099706 4.470358 4.1476117 -3.9099706 -4.470358 -4.1476117 -3.9099706 4.470358 -4.1476117 -3.9099706 ] 
    "facevarying normal N" [ 0 0 1 0 0 1 0 0 1 0 0 1 
      0 1 0 0 1 0 0 1 0 0 1 0 
      0 0 -1 0 0 -1 0 0 -1 0 0 -1 
      0 -1 0 0 -1 0 0 -1 0 0 -1 0 
      1 0 0 1 0 0 1 0 0 1 0 0 
      1 0 0 1 0 0 -1 0 0 -1 0 0 
      -1 0 0 -1 0 0 ] 
    "facevarying float[2] st" [ 0.375 0.75 0.625 0.75 0.625 1 0.375 1 0.375 0.5 0.625 0.5 
      0.625 0.75 0.375 0.75 0.375 0.25 0.625 0.25 0.625 0.5 0.375 0.5 
      0.375 0 0.625 0 0.625 0.25 0.375 0.25 0.625 0.75 0.875 1 
      0.625 1 0.875 0.75 0.875 1 0.625 0.75 0.125 0.75 0.375 0.75 

Here normals and "st" (texture coord) are per face basis while vertices are object basis. In OpenGL we have three different pointers to feed this data in:        glVertexPointer, glTexCoordPointer and glNormalPointer.

1. In above case I would be needing vertices array also per face basis to pass them into glVertexPointer, which I could do by parsing vertex index array and vertices. Do we have something in GL to overcome this problem and creting the mesh using the information as it's already there in the rib.

2. Secondly we have quads as well as tris in this case. Is it possible to pass an array which contains both of them. For example:
    [[...],
     [a,b,c], #three verts of a triangle
     [a,b,c,d], #four vertices of a quad


Thanks

Prashant



      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: [PyOpenGL-Users] pyOpenGL and VBO

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

Prashant Saxena wrote:
> Hi,
>
> Do we have any examples, tutorials of using VBO?
> Mike, I have seen some articles on your blog. I would be interested to 
> test VBO using pyOpenGL. I have already done some tests using display 
> list (~1 million polygons of fluid simulation) and I would like to 
> compare it using VBO.
There's a very simple example in the PyOpenGL/tests/test.py script.  
There's a far more involved example in 
OpenGLContext/scenegraph/arraygeometry.py

HTH,
Mike

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

[PyOpenGL-Users] pyOpenGL and VBO

[Prashant S. <ani...@ya...>]

Hi,

Do we have any examples, tutorials of using VBO?
Mike, I have seen some articles on your blog. I would be interested to test VBO using pyOpenGL. I have already done some tests using display list (~1 million polygons of fluid simulation) and I would like to compare it using VBO. 

Prashant



      Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/

Re: [PyOpenGL-Users] glMultiDrawElements - pointer?

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

Mpi wrote:

I have access to glMultiDrawElementEXT at home.  Now I see the 
difference between your code and the wrapper I'd suggested.  Basically 
the GLvoid ** indices is apparently supposed to be an array of GLvoid 
pointers.  Been trying to get that to work on my machine, but while the 
data-types seem fine just before they pass into C, they're core-ing when 
I actually try them.

Thanks for pointing out the problem,
Mike
...
> # Interface to glMultiDrawElements
> def multiDrawElements(mode, count, gl_type, indices):
>     """
>     """
>     # Set up interface for the call
>     n_count = count.shape[0]
>     libGL.glMultiDrawElements.restype  = ctypes.c_void_p
>     libGL.glMultiDrawElements.argtypes = [ctypes.c_int, 
>                                           ctypes.POINTER(ctypes.c_int),
>                                           ctypes.c_int, 
>                                          
> ctypes.POINTER(ctypes.c_int)*n_count,
>                                           ctypes.c_int, 
>                                           ]
>
>     # Set pointer to data in the count array
>     count_ptr = count.ctypes.data_as(ctypes.POINTER(ctypes.c_int))
>
>     # Set array of pointers to the indices array
>     iptr = ctypes.POINTER(ctypes.c_int)
>     indices_data = (iptr*len(indices))(*[row.ctypes.data_as(iptr) for row in
> indices])
>
>     # Do the actual call to glMultiDrawElements
>     libGL.glMultiDrawElements(int(mode), count_ptr, int(gl_type),
> indices_data, n_count)
>
>
> ________________________________________________________________
> Kommunikation uden grænser - ComX Networks Webmail - 2.7.8p3
>   


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

Re: [PyOpenGL-Users] glMultiDrawElements - pointer?

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

Mpi wrote:
> Suppose I have 
>
> indices = [[0, 4, 1, 5, 2,  6, 3, 7], 
>                        [4, 8, 5, 9, 6, 10, 7, 11]]
> glMultiDrawElements(GL_QUAD_STRIP, 8, GL_UNSIGNED_BYTE, indices, 1)
>
> I get the error
>
> ArgumentError: argument 4: <type 'exceptions.TypeError'>: expected
> LP_c_void_p instance instead of list
>
> Any clues regarding how to set up a pointer to the list of indices and pass
> this to glMultiDrawElements?
>   
There's currently no Pythonic wrapper around the method (I don't have 
any hardware with the functionality to test it).  The wrapper to get it 
working would look something like this:

glMultiDrawElements = wrapper.wrapper( glMultiDrawElements ).setPyConverter(
    'indices', arrays.AsArrayOfType( 'indices', 'type' ),
).setCResolver(
    'indices', arrays.ArrayDatatype.voidDataPointer ,
).setPyConverter(
    'count', arrays.AsArrayTyped( 'count', arrays.GLsizeiArray ),
).setCResolver(
    'count', arrays.ArrayDatatype.voidDataPointer ,
)

put into OpenGL/GL/VERSION/GL_1_4.py

However, it should be noted that it would only work by chance with your 
call, as the "count" parameter is an array.  PyOpenGL supports passing a 
single integer as an array and you have specified 1 as your primcount 
and *happen* to have a uniform multi-dimensional array.  The above 
wrapper is assuming that you normally have a single-dimensional 
data-type for indices and count.  If you happened to have a non-uniform 
indices set (which is AFAICS the whole point of the function) you'd blow 
up trying to convert the indices set.

That is, normally indices would be expected to be a single array of 
index values.  The choices array would then control iteration over that 
array.  The reason I wouldn't likely relax that is that the resulting 
code would have to copy the values from each individual sub-array into a 
contiguous array for passing to the function.

I've added the wrapper shown above to current bzr trunk.  If you're 
willing, please try the wrapper and see if it works for you.

Thanks,
Mike

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

[PyOpenGL-Users] glMultiDrawElements - pointer?

[Mpi <mp...@co...>]

Suppose I have 

indices = [[0, 4, 1, 5, 2,  6, 3, 7], 
                       [4, 8, 5, 9, 6, 10, 7, 11]]
glMultiDrawElements(GL_QUAD_STRIP, 8, GL_UNSIGNED_BYTE, indices, 1)

I get the error

ArgumentError: argument 4: <type 'exceptions.TypeError'>: expected
LP_c_void_p instance instead of list

Any clues regarding how to set up a pointer to the list of indices and pass
this to glMultiDrawElements?

________________________________________________________________
Kommunikation uden grænser - ComX Networks Webmail - 2.7.8p3

Re: [PyOpenGL-Users] How to use shaders in pyopengl

[Dirk R. <di...@li...>]

	Hi Mike,

Mike C. Fletcher wrote:
>
> I found the bug.  Basically there was a wrapper for 
> glShaderSource/glShaderSourceARB which was not passing in the 
> "extension" parameter which was being used to decide whether the 
> function should be available.  Previously we would just try to get the 
> function and check for a NULL pointer, but the Mesa implementation 
> decided to start returning non-null pointers that just print out warning 
> messages when you try to call a non-existent function, so we started 
> checking for the extensions.  Unfortunately, the wrapper didn't get 
> updated, so the test was always coming up false.
> 
> Anyway, with current CVS shaders should work on Win32.  I'll likely be 
> doing some further refactoring of the base platform module to clean it 
> up and see if I can discover the problem on OSX tomorrow.

Thanks for fixing this, works like a charm!

I finally took the time to take a look at PyOpenGLs implementation. Not needing 
a C/C++ part makes the whole system pretty nice, I have to say. It's a little 
painful to write in the first place, but not having to deal with compiling stuff 
everywhere is pretty nice (I'm fighting compiling my boost::python module on 
Windows right now...).

Thanks again

	Dirk

Re: [PyOpenGL-Users] couple of queries

[Greg E. <gre...@ca...>]

Prashant Saxena wrote:

> 1. Which is better (VBO or display list) when you have to show large 
> number of 3d geometrical objects in terms of efficiency and smooth 
> viewport navigation?

There's no general answer to that -- it depends on what you're
doing and what environment you're doing it in.

I have no experience with VBOs, but I've had very good results
using display lists from Python, because they let you draw
arbitrarily large amounts of just about anything using a
single Python call. Since Python function calls are probably
the bottleneck when using OpenGL from Python, this is a
huge win.

You may get similar results using VBOs, but I'd expect that
to be true only if you're drawing a few objects with very
large numbers of vertices each. But as I said, I haven't
tried using VBOs myself, so that's just theorising. The only
way to find out is to try both and see which works better for
you in your situation.

> 2. Method for picking (large number of 3d geometrical objects)
>     a) color based (it'll work only when you draw each objects in 
> wireframe mode and gives unique color to each object. AFAIK)
>     b)Default Selection Mode GL rendering(I am sure it'll be slow)
>     c) Any other?

Personally I prefer to do my own calculations to find picked
objects, and not use OpenGL's picking functions at all.

> 3. If you do have a professional graphic card then performance will be 
> increased using pyOpenGL or no performance gain?

Again, no general answer. Depends on whether GPU activity is
the bottleneck. The only way to find that out is by profiling
your code.

-- 
Greg

[PyOpenGL-Users] couple of queries

[Prashant S. <ani...@ya...>]

Hi,

I am no expert in openGL and need to know about couple of questions using pyOpenGL and large set of 3d geometrical data.

1. Which is better (VBO or display list) when you have to show large number of 3d geometrical objects in terms of efficiency and smooth viewport navigation?

2. Method for picking (large number of 3d geometrical objects)
    a) color based (it'll work only when you draw each objects in wireframe mode and gives unique color to each object. AFAIK)
    b)Default Selection Mode GL rendering(I am sure it'll be slow)
    c) Any other?
    
3. If you do have a professional graphic card then performance will be increased using pyOpenGL or no performance gain?

4. Examples for viewport navigation like 3d commercial applications. 
    a) arcball roration
    b) zoom
    c) pan
    
I did couple of test by loading almost 100 mb of data(.obj format) using display list and so far viewport navigation is satisfactory.
The code that has been used to load the data is slightly modified version of this:
http://www.pygame.org/wiki/OBJFileLoader?parent=CookBook

Regards
    
Prashant     


      Be the first one to try the new Messenger 9 Beta! Go to http://in.messenger.yahoo.com/win/

Re: [PyOpenGL-Users] Nurbs curve Rendering?

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

Prashant Saxena wrote:
> I am trying to create a nurbs curve in 2d (no 'Z') and here is my 
> code. The curve is not getting rendered. There is something wrong with 
> this piece of code:
> Could anybody point me out?
>
> uknots= [0.0, 0.0, 0.0, 0.0, 1.0, 1.0, 1.0, 1.0]
> cntrl = [[25, 50],
>             [25, 75],
>             [75, 75],
>             [75, 50]]
> x = 10, y = 10
> color = (0,0,0)
>            
>         """Create a GL display list to draw a Curve."""
>         nurb = gluNewNurbsRenderer()
>         glNewList(101, GL_COMPILE)
>         glPushMatrix()
>         glLineWidth(1)
>         glTranslate(x, y, 0)
>         glColor(color)
>         glEnable(GLU_MAP1_VERTEX_4)
>         gluBeginCurve(nurb)
>         gluNurbsCurve(nurb, uknots, cntrl, GLU_MAP1_VERTEX_4)
>         gluEndCurve(nurb)
>         glPopMatrix()
>         glEndList()
>
> Prashant
Don't have time to look at the code this morning, just to point out that 
there's a complete nurbs-curve demo just added to the PyOpenGL-Demo 
project's bzr repository:

http://bazaar.launchpad.net/~mcfletch/pyopengl-demo/trunk/files/2?file_id=nurbscurve-20080928050414-wwjmmaza2n95y4h9-7

which might help you.

Good luck,
Mike

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

[PyOpenGL-Users] Nurbs curve Rendering?

[Prashant S. <ani...@ya...>]

I am trying to create a nurbs curve in 2d (no 'Z') and here is my code. The curve is not getting rendered. There is something wrong with this piece of code:
Could anybody point me out?

uknots= [0.0, 0.0, 0.0, 0.0, 1.0, 1.0, 1.0, 1.0]
cntrl = [[25, 50],
            [25, 75],
            [75, 75],
            [75, 50]]
x = 10, y = 10
color = (0,0,0)
            
        """Create a GL display list to draw a Curve."""
        nurb = gluNewNurbsRenderer()
        glNewList(101, GL_COMPILE)
        glPushMatrix()
        glLineWidth(1)
        glTranslate(x, y, 0)
        glColor(color)
        glEnable(GLU_MAP1_VERTEX_4)
        gluBeginCurve(nurb)
        gluNurbsCurve(nurb, uknots, cntrl, GLU_MAP1_VERTEX_4)
        gluEndCurve(nurb)
        glPopMatrix()
        glEndList()

Prashant



      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

Re: [PyOpenGL-Users] glutTimerFunc seems to accumulate garbage

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

Alexandre Lacoste wrote:
> The following code starts by using almost no cpu time and 
> progressively use the complete cpu after like 30 seconds...
> Should I clear some buffer somewhere ?
>
> putting a delay more than 1 will result in the same behavior but will 
> take more time. A delay twice bigger will accumulate twice slower and 
> will have twice more time between calls. Therefore it will take 4 time 
> longer to see the same behavior...
> In my original program, I have 3 timers with period of 20 ms so it 
> takes 1 or 2 minutes to see the behavior starting.
>
> Can someone confirm this ?
Yup, definite leak.  Apparently I got halfway through fixing the problem 
(setting the function to filter it) and got distracted by something 
before I fixed the actual code to remove the callback.
> Should I fill a bug report somewhere ?
I've just fixed it.  If you just want to patch your working version you 
can use this patch:

http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/revision/4

or you can check out the whole package via:

    bzr branch lp:~mcfletch/pyopengl/trunk
    cd trunk
    python setup.py develop

Good luck,
Mike

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

[PyOpenGL-Users] glutTimerFunc seems to accumulate garbage

[Alexandre L. <ale...@gm...>]

The following code starts by using almost no cpu time and progressively use
the complete cpu after like 30 seconds...
Should I clear some buffer somewhere ?

putting a delay more than 1 will result in the same behavior but will take
more time. A delay twice bigger will accumulate twice slower and will have
twice more time between calls. Therefore it will take 4 time longer to see
the same behavior...
In my original program, I have 3 timers with period of 20 ms so it takes 1
or 2 minutes to see the behavior starting.

Can someone confirm this ?
Should I fill a bug report somewhere ?

I've tried it with version 3.0.0b1 and 3.0.0b6.


##############################
# code starts here
##############################
from OpenGL.GLUT import *

glutInit( sys.argv )
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH )
glutInitWindowSize( 100, 100 )
glutCreateWindow( "testtimer" )

delay = 1
count = 0

def timerCallback(value):
    global count
    count += 1
    if count % 2000 == 0: print count
    glutTimerFunc( delay, timerCallback, value+1 )

glutTimerFunc( delay, timerCallback, 0 )

glutMainLoop()

##############################
# code ends here
##############################

some more info:

$ uname -a
Linux xps 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 8.04.1
Release:        8.04
Codename:       hardy



ªŁ€×

Re: [PyOpenGL-Users] get segmentation fault using threading

[Alexandre L. <ale...@gm...>]

yess, yess, yessssss !!!!
it's working :D

And this makes so much sense

Thanks for your time Mike.

P.S.: The tool for searching the mailing list archive (on sourceforge)
doesn't work for me... It always return : "PyOpenGL: Searching mail lists
gives *0* results" even if I type a word that is in some mails.


ªŁ€×


On Sun, Sep 21, 2008 at 10:50 AM, Mike C. Fletcher
<mcf...@vr...>wrote:

> Alexandre Lacoste wrote:
>
>> Hi.
>> First : Many thanks for this great python bindings !!
>>
>> I'm trying to thread my opengl class but it is not working. I get
>> segmentation fault at glutInit or glutInitDisplayMode
>>
>> here is the simplest example I was able to build. It never gets to the :
>> print "end" part.... It seg fault before.
>>
> Most GUI libraries are inherently single-threaded.  You can often get
> around the problem by *first* importing the GUI library in the GUI thread
> (i.e. *not* in the main thread).  That is, the first time GLUT (or wx, or
> Tk, or any GUI lib I've seen recently) is imported needs to be within the
> GUI thread so that it will create its global state inside that thread,
> rather than the main thread.
>
> The attached version of the code runs fine on my machine.  The only change
> is to move *all* imports of GLUT into the background/GUI thread by
> separating it out into a separate module.  You may want to set up a few
> queues to transfer data  in the call to "run" so that your two threads can
> communicate easily.
>
> HTH,
> Mike
>
> --
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>

Re: [PyOpenGL-Users] get segmentation fault using threading

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

Alexandre Lacoste wrote:
> Hi.
> First : Many thanks for this great python bindings !!
>
> I'm trying to thread my opengl class but it is not working. I get 
> segmentation fault at glutInit or glutInitDisplayMode
>
> here is the simplest example I was able to build. It never gets to the 
> : print "end" part.... It seg fault before.
Most GUI libraries are inherently single-threaded.  You can often get 
around the problem by *first* importing the GUI library in the GUI 
thread (i.e. *not* in the main thread).  That is, the first time GLUT 
(or wx, or Tk, or any GUI lib I've seen recently) is imported needs to 
be within the GUI thread so that it will create its global state inside 
that thread, rather than the main thread.

The attached version of the code runs fine on my machine.  The only 
change is to move *all* imports of GLUT into the background/GUI thread 
by separating it out into a separate module.  You may want to set up a 
few queues to transfer data  in the call to "run" so that your two 
threads can communicate easily.

HTH,
Mike

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

[PyOpenGL-Users] get segmentation fault using threading

[Alexandre L. <ale...@gm...>]

Hi.
First : Many thanks for this great python bindings !!

I'm trying to thread my opengl class but it is not working. I get
segmentation fault at glutInit or glutInitDisplayMode

here is the simplest example I was able to build. It never gets to the :
print "end" part.... It seg fault before.

#########################
# code begins here
#########################
from OpenGL.GLUT import *
from threading import *
import time


class GlObject(Thread):

    def __init__(self):
        Thread.__init__(self)

    def run(self):
        print "glutInit"
        glutInit(sys.argv)
        print "initDisplay"
        glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH )
        print "end" # never reach that part...


glObject = GlObject()
print "starting object"
glObject.start()


while True:
    print "waiting"
    time.sleep(1)
##########################

Can any body tell me what I am doing wrong. Is there a way around this ?

I need to get the opengl stuff in a different thread. In my program it is
only a eye candy that print out the state of my algorithm that need to be
running all the time...

please help

thanks all ;)

ªŁ€×