pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] glReadPixels

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

Ian Mallett wrote:
> Hello,
>
> So, I'm using glReadPixels(...) to get data for a screenshot.  I would
> really like to be able to get data from any framebuffer.  Currently,
> though, I can only get data from the screen framebuffer (or
> GL_COLOR_ATTACHMENT0_EXT).  I looked at glReadBuffer.  I'm using
> PyGame and PyOpenGL, and glGetString(GL_READ_BUFFER) returns None. 
> glReadBuffer(GL_BACK) crashes.
> What's going on?
Don't have your precise code.  Just added a glReadBuffer test to
PyOpenGL's tests modules, seems to work here, though my test code
doesn't do anything particularly interesting:

    def test_glDrawBuffers_list_valid( self ):
        """Test that glDrawBuffers with list argument where value is set"""
        previous = glGetIntegerv( GL_READ_BUFFER )
        fbo = glGenFramebuffersEXT(1)
        glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo)
        try:
            img1,img2 = glGenTextures(2)
            for img in img1,img2:
                glBindTexture( GL_TEXTURE_2D, img )
                glTexImage2D(
                    GL_TEXTURE_2D, 0, GL_RGB8, 
                    300, 300, 0, GL_RGB,
                    GL_INT,
                    None # no data transferred
                )
           

            glFramebufferTexture2DEXT(
                GL_FRAMEBUFFER_EXT,
                GL_COLOR_ATTACHMENT0_EXT,
                GL_TEXTURE_2D, img1, 0
            )
            glFramebufferTexture2DEXT(
                GL_FRAMEBUFFER_EXT,
                GL_COLOR_ATTACHMENT1_EXT,
                GL_TEXTURE_2D, img2, 0
            )
            a_type = constants.GLenum*2
            drawingBuffers = a_type(
                GL_COLOR_ATTACHMENT0_EXT,
                GL_COLOR_ATTACHMENT1_EXT,
            )
            glDrawBuffers(2, drawingBuffers )
            glReadBuffer( GL_COLOR_ATTACHMENT1_EXT )
            pixels = glReadPixels( 0,0, 10,10, GL_RGB, GL_UNSIGNED_BYTE )
            assert len(pixels) == 300, len(pixels)
        finally:
            glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 )
       
        glReadBuffer( previous )

Can you give me a script that shows the failure?

Good luck,
Mike

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

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

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

Joshua Davis wrote:
...
> I now have two versions of my program. The first uses the legacy  
> glVertexPointer() stuff and works perfectly. The second is altered,  
> as little as possible, so that it uses the modern  
> glVertexAttribPointer() stuff instead. It raises no errors but  
> generates no fragments. Here is the glVertexPointer() version of the  
> two crucial functions...
>   
I don't see any obvious problems with the attribute-based version.  I've
done some minimal modifications to create a working full script.  I had
to add some perspective and translation setup (to move the geometry back
from the viewer).  Please consider trying to create this kind of
runnable script when reporting errors, I'm rather short on time to work
on PyOpenGL and recreating scripts takes time I should be putting into
other tasks.

HTH,
Mike

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

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

[Joshua D. <joshuardavis@q.com>]

While hoping for a response to my previous question, I'm trying to  
run the tutorial at

   http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/ 
head:/tests/shader_4.py

as it is written, verbatim. The thing requires OpenGLContext and its  
various dependencies, which are listed at

   http://pyopengl.sourceforge.net/documentation/installation.html

I've installed PyDispatcher, SimpleParse 2.1.1a2, TTFQuery 1.0.1,  
FontTools (for Numpy) 2.1a1, and OpenGLContext 2.1.0a5. Supposedly  
SimpleParse 2.1 provides the VRML97 parser, and the directory  
OpenGLContext/loaders/ contains vrml.py, but I still get this error:

tcsh > python shader_4.py
INFO:OpenGL.acceleratesupport:OpenGL_accelerate module loaded
Traceback (most recent call last):
   File "shader_4.py", line 31, in <module>
     from OpenGLContext import testingcontext
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGLContext/testingcontext.py", line 13, in  
<module>
     from OpenGLContext import context
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGLContext/context.py", line 32, in <module>
     from OpenGLContext import visitor, texturecache,plugins
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGLContext/visitor.py", line 3, in <module>
     from OpenGLContext.scenegraph import nodepath
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGLContext/scenegraph/nodepath.py", line  
3, in <module>
     from vrml.vrml97 import nodepath, nodetypes
ImportError: No module named vrml.vrml97

Josh

[PyOpenGL-Users] glReadPixels

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

Hello,

So, I'm using glReadPixels(...) to get data for a screenshot.  I would
really like to be able to get data from any framebuffer.  Currently, though,
I can only get data from the screen framebuffer (or
GL_COLOR_ATTACHMENT0_EXT).  I looked at glReadBuffer.  I'm using PyGame and
PyOpenGL, and glGetString(GL_READ_BUFFER) returns None.
glReadBuffer(GL_BACK) crashes.

What's going on?

Ian

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

[Joshua D. <joshuardavis@q.com>]

>> This is a bug in the shaders module.  Turns out that  
>> glGetProgramivARB
> and glGetProgramiv have different roles?!  Basically it looks like  
> it's
> glGetObjectParameteriv that's supposed to be used for the  
> glGetProgramiv
> validity check call (at least, if I use that and disable core GL I get
> the correct operation).  Going to have to look into the function
> definitions more to be sure that the alternate declaration works.

Your changes to shaders.py have gotten me past that problem. Thanks  
very much.

I now have two versions of my program. The first uses the legacy  
glVertexPointer() stuff and works perfectly. The second is altered,  
as little as possible, so that it uses the modern  
glVertexAttribPointer() stuff instead. It raises no errors but  
generates no fragments. Here is the glVertexPointer() version of the  
two crucial functions...

def initializeShaders():
     global shaderProgram
     vertexCode = """
     void main()
     {
         gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
         gl_FrontColor = gl_Color;
     }"""
     fragmentCode = """
     void main()
     {
         gl_FragColor = gl_Color;
     }"""
     vertexShader = compileShader(vertexCode, GL_VERTEX_SHADER)
     fragmentShader = compileShader(fragmentCode, GL_FRAGMENT_SHADER)
     shaderProgram = compileProgram(vertexShader, fragmentShader)

def handleDisplayEvent():
     global vertexBufferObject, shaderProgram
     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
     glUseProgram(shaderProgram)
     vertexBufferObject.bind()
     glEnableClientState(GL_VERTEX_ARRAY)
     glEnableClientState(GL_COLOR_ARRAY)
     glVertexPointer(3, GL_FLOAT, 24, vertexBufferObject)
     glColorPointer(3, GL_FLOAT, 24, vertexBufferObject + 12)
     glDrawArrays(GL_TRIANGLES, 0, 9)
     vertexBufferObject.unbind()
     glDisableClientState(GL_VERTEX_ARRAY)
     glDisableClientState(GL_COLOR_ARRAY)
     glUseProgram(0)
     glFlush()
     glutSwapBuffers()

...and here are those same functions, rewritten to use  
glVertexAttribPointer().

def initializeShaders():
     global shaderProgram, positionLocation, colorLocation
     vertexCode = """
     attribute vec3 position;
     attribute vec3 color;
     void main()
     {
         gl_Position = gl_ModelViewProjectionMatrix * vec4(position,  
1.0);
         gl_FrontColor = vec4(color, 1.0);
     }"""
     fragmentCode = """
     void main()
     {
         //gl_FragColor = gl_Color;
         gl_FragColor = vec4(1.0, 0.0, 1.0, 1.0);
     }"""
     vertexShader = compileShader(vertexCode, GL_VERTEX_SHADER)
     fragmentShader = compileShader(fragmentCode, GL_FRAGMENT_SHADER)
     shaderProgram = compileProgram(vertexShader, fragmentShader)
     positionLocation = glGetAttribLocation(shaderProgram, 'position')
     colorLocation = glGetAttribLocation(shaderProgram, 'color')

def handleDisplayEvent():
     global vertexBufferObject, shaderProgram, positionLocation,  
colorLocation
     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
     glUseProgram(shaderProgram)
     vertexBufferObject.bind()
     glEnableVertexAttribArray(positionLocation)
     glEnableVertexAttribArray(colorLocation)
     glVertexAttribPointer(positionLocation, 3, GL_FLOAT, False, 24,  
vertexBufferObject)
     glVertexAttribPointer(colorLocation, 3, GL_FLOAT, False, 24,  
vertexBufferObject + 12)
     glDrawArrays(GL_TRIANGLES, 0, 9)
     vertexBufferObject.unbind()
     glDisableVertexAttribArray(positionLocation)
     glDisableVertexAttribArray(colorLocation)
     glUseProgram(0)
     glFlush()
     glutSwapBuffers()

Am I missing something obvious? Any suggestions on how to debug further?

Josh

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

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

Mike C. Fletcher wrote:
...
> This is a bug in the shaders module.  Turns out that glGetProgramivARB
> and glGetProgramiv have different roles?!  Basically it looks like it's
> glGetObjectParameteriv that's supposed to be used for the glGetProgramiv
> validity check call (at least, if I use that and disable core GL I get
> the correct operation).  Going to have to look into the function
> definitions more to be sure that the alternate declaration works.
>   
I've just uploaded a source release with this fix in it.  SourceForge
seems to be having problems, but it should show up within 15 minutes or so.

HTH,
Mike

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

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

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

Joshua Davis wrote:
> On 2009 Aug 13  , at 11:10 AM, Mike C. Fletcher wrote:
>   
...
> Thanks. I've had some trouble updating PyOpenGL -- probably my  
> incompetence -- but now I'm up to 3.0.1a2 and using the  
> OpenGL.GL.shaders convenience functions. When I try to construct a  
> simple shader program...
>   
...
> OpenGL.error.GLError: GLError(
>          err = 1280,
>          description = 'invalid enumerant',
>          baseOperation = glGetProgramivARB,
>          pyArgs = (3L, GL_VALIDATE_STATUS),
>          cArgs = (3L, GL_VALIDATE_STATUS, array([0])),
>          cArguments = (3L, GL_VALIDATE_STATUS, array([0]))
> )
>
> This never happened with my home-spun shader-building functions. Your  
> continuing help is appreciated.
>   
This is a bug in the shaders module.  Turns out that glGetProgramivARB
and glGetProgramiv have different roles?!  Basically it looks like it's
glGetObjectParameteriv that's supposed to be used for the glGetProgramiv
validity check call (at least, if I use that and disable core GL I get
the correct operation).  Going to have to look into the function
definitions more to be sure that the alternate declaration works.

Good luck,
Mike

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

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

[Joshua D. <joshuardavis@q.com>]

On 2009 Aug 13  , at 11:10 AM, Mike C. Fletcher wrote:

> I'd also *strongly* suggest going for PyOpenGL 3.0.0 final or even a
> PyOpenGL 3.0.1 alpha, as there were quite a number of bug-fixes and
> enhancements.  The latest 3.0.1 alpha has an OpenGL.GL.shaders module
> which provides "alternate" wrapped versions of the shader functions
> which allow for using either core or ARB-provided versions of the
> functions depending on what's available on the final machine.  That
> isn't necessary, but it should make it easier to work with shaders in
> PyOpenGL.

Thanks. I've had some trouble updating PyOpenGL -- probably my  
incompetence -- but now I'm up to 3.0.1a2 and using the  
OpenGL.GL.shaders convenience functions. When I try to construct a  
simple shader program...

vertexCode = """
attribute vec3 position;
attribute vec3 color;
void main()
{
     gl_Position = gl_ModelViewProjectionMatrix * vec4(position, 1.0);
     gl_FrontColor = vec4(color, 1.0);
}"""
fragmentCode = """
void main()
{
     gl_FragColor = gl_Color;
}"""
vertexShader = compileShader(vertexCode, GL_VERTEX_SHADER)
fragmentShader = compileShader(fragmentCode, GL_FRAGMENT_SHADER)
shaderProgram = compileProgram(vertexShader, fragmentShader)

...I get this error:

Traceback (most recent call last):
   File "vbo.py", line 88, in <module>
     shaderProgram = compileProgram(vertexShader, fragmentShader)
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGL/GL/shaders.py", line 105, in  
compileProgram
     validation = glGetProgramiv( program, GL_VALIDATE_STATUS )
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGL/extensions.py", line 95, in __call__
     return self( *args, **named )
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGL/wrapper.py", line 1294, in __call__
     return self.finalise()( *args, **named )
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/OpenGL/wrapper.py", line 572, in wrapperCall
     raise err
OpenGL.error.GLError: GLError(
         err = 1280,
         description = 'invalid enumerant',
         baseOperation = glGetProgramivARB,
         pyArgs = (3L, GL_VALIDATE_STATUS),
         cArgs = (3L, GL_VALIDATE_STATUS, array([0])),
         cArguments = (3L, GL_VALIDATE_STATUS, array([0]))
)

This never happened with my home-spun shader-building functions. Your  
continuing help is appreciated.

Josh

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

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

Ian Mallett wrote:
> On Thu, Aug 13, 2009 at 7:38 AM, Paulo Silva <nit...@gm...
> <mailto:nit...@gm...>> wrote:
>
>     > vertexBufferObject = vbo.VBO(...)
>     > gl.glVertexAttribPointer(positionLocation, 3, GL_FLOAT, False, 24,
>     > vertexBufferObject)
>     >
>     > The second line generates this error:
>     >
>     > ctypes.ArgumentError: argument 6: <type 'exceptions.TypeError'>:
>     > Don't know how to convert parameter 6
>
> You might try this code, adapted from my code, which makes use of
> vertex attributes for normal mapping:
>
> vertex_attrib_vbo.bind()
> glVertexAttribPointer(location,4,GL_FLOAT,GL_FALSE,0,None)
Yup, that should work, even with the raw ctypes APIs.

> The last argument could probably also be 0. 
0 would be interpreted as a 1-element array of integers.  You can (with
a bug-fix introduced for 3.0.1) do ctypes.c_void_p( 0 ) if you want to,
though.

HTH,
Mike

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

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

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

On Thu, Aug 13, 2009 at 7:38 AM, Paulo Silva <nit...@gm...> wrote:

>  > vertexBufferObject = vbo.VBO(...)
> > gl.glVertexAttribPointer(positionLocation, 3, GL_FLOAT, False, 24,
> > vertexBufferObject)
> >
> > The second line generates this error:
> >
> > ctypes.ArgumentError: argument 6: <type 'exceptions.TypeError'>:
> > Don't know how to convert parameter 6
>
> You might try this code, adapted from my code, which makes use of vertex
attributes for normal mapping:

vertex_attrib_vbo.bind()
glVertexAttribPointer(location,4,GL_FLOAT,GL_FALSE,0,None)

The last argument could probably also be 0.

Ian

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

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

Joshua Davis wrote:
> I have some questions that probably boil down to my inexperience with  
> Python. My setup is PyOpenGL-3.0.0c1 on Python 2.5.x on Mac OS X. I'm  
> trying to modernize my OpenGL to use VBOs and vertex attributes,  
> working through the tutorials at http://bazaar.launchpad.net/ 
> ~mcfletch/openglcontext/trunk/annotate/head:/tests/shader_4.py. When  
> I execute code like this:
>
> vertexBufferObject = vbo.VBO(...)
> gl.glVertexAttribPointer(positionLocation, 3, GL_FLOAT, False, 24,  
> vertexBufferObject)
>   
The "gl." should not be necessary, PyOpenGL 3.x includes full access to
the OpenGL 2.x functionality.  The wiki sample you are looking at is
*very* old, unfortunately, the wiki editor seems broken, so I can't
update it without completely hashing the page :( .  The vbo.VBO object
uses PyOpenGL's wrapping functionality to appear as though it is a
data-array pointer, but that behaviour is not available in raw ctypes
wrappers (such as the wiki recipe is creating).

    from OpenGL.GL import *

should get you a copy of glVertexAttribPointer without needing to do
anything else (particularly, without using any ctypes code explicitly). 
If you need the ARB versions, they are available via:

    from OpenGL.GL.ARB.vertex_buffer_object import *

I'd also *strongly* suggest going for PyOpenGL 3.0.0 final or even a
PyOpenGL 3.0.1 alpha, as there were quite a number of bug-fixes and
enhancements.  The latest 3.0.1 alpha has an OpenGL.GL.shaders module
which provides "alternate" wrapped versions of the shader functions
which allow for using either core or ARB-provided versions of the
functions depending on what's available on the final machine.  That
isn't necessary, but it should make it easier to work with shaders in
PyOpenGL.  The tutorials you're following through were written against
PyOpenGL 3.0.1 alpha (actually bzr head), so operations such as
"compileShader()" are not going to be available in your older PyOpenGL
release.  If you're working on a Linux machine where 3.0.0c1 is the
current PyOpenGL package, you may want to set up a "virtualenv"
environment and install the more recent version there (virtualenv
creates a separate Python package namespace where you can work in
isolation from system packages).

I'll update the tutorial introduction page to mention the version of
PyOpenGL that it is written against.

The wiki sample code, rewritten for PyOpenGL 3.0.1's shader convenience
module (which is, via a number of levels of indirection, loosely based
on that wiki recipe, I think) is included below...

HTH,
Mike

#! /usr/bin/env python
from pygame import *
import pygame
from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
from OpenGL.GL.shaders import *

if __name__ == '__main__':
    glutInit(sys.argv)
    width, height = 640, 480
    pygame.init()
    pygame.display.set_mode((width, height), OPENGL | DOUBLEBUF)
 
    program = compileProgram(
        compileShader(
            '''
            // Vertex program
            varying vec3 pos;
            void main() {
                pos = gl_Vertex.xyz;
                gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
            }
            ''',
            GL_VERTEX_SHADER,
        ),
        compileShader(
                '''
            // Fragment program
            varying vec3 pos;
            void main() {
                gl_FragColor.rgb = pos.xyz;
            }
            ''',
            GL_FRAGMENT_SHADER
        ),
    )
 
    glMatrixMode(GL_PROJECTION)
    glLoadIdentity()
    gluPerspective(90.0, width/float(height), 1.0, 100.0)
    glMatrixMode(GL_MODELVIEW)
    glEnable(GL_DEPTH_TEST)
   
    quit = False
    angle = 0
    while not quit:
        for e in pygame.event.get():
            if e.type in (QUIT, KEYDOWN):
                quit = True
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
        glLoadIdentity()
        glTranslate(0.0, 0.0, -2.5)
        glRotate(angle, 0.0, 1.0, 0.0)
        glUseProgram(program)
        glutSolidTeapot(1.0)
        angle += 0.1
        pygame.display.flip()

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

Re: [PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

[Paulo S. <nit...@gm...>]

Joshua Davis from http://www.joshuadavis.com/ :O ? awesome, be welcome! \o/

anyway, i don't know if it is your very first approach on OpenGL using
PyOpenGL - i think i'm even struggling with it way much more than you
- my very first approaches were trying to analyse some pyweek games
like http://pyweek.org/e/GNAG/ , but it uses Pyglet instead (which
also uses OpenGL as well) - in the case you can't fix what you try to
do with PyOpenGL, maybe would be a good idea trying Pyglet also...

cheers!

On 8/13/09, Joshua Davis <joshuardavis@q.com> wrote:
> I have some questions that probably boil down to my inexperience with
> Python. My setup is PyOpenGL-3.0.0c1 on Python 2.5.x on Mac OS X. I'm
> trying to modernize my OpenGL to use VBOs and vertex attributes,
> working through the tutorials at http://bazaar.launchpad.net/
> ~mcfletch/openglcontext/trunk/annotate/head:/tests/shader_4.py. When
> I execute code like this:
>
> vertexBufferObject = vbo.VBO(...)
> gl.glVertexAttribPointer(positionLocation, 3, GL_FLOAT, False, 24,
> vertexBufferObject)
>
> The second line generates this error:
>
> ctypes.ArgumentError: argument 6: <type 'exceptions.TypeError'>:
> Don't know how to convert parameter 6
>
> The following code is what I've been doing to get platform-specific
> (?) PyOpenGL functions. They often seem to require some massaging of
> argument types; is the same thing needed for glVertexAttribPointer()
> above?
>
> # This is adapted from http://www.pygame.org/wiki/GLSLExample.
> try:
>      from OpenGL import platform
>      gl = platform.OpenGL
> except ImportError:
>      try:
>          gl = cdll.LoadLibrary('libGL.so')
>      except OSError:
>          from ctypes.util import find_library
>          path = find_library('OpenGL')
>          gl = cdll.LoadLibrary(path)
> gl.glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), POINTER
> (c_int)]
> gl.glGetShaderiv.argtypes = [c_int, c_int, POINTER(c_int)]
> gl.glGetShaderInfoLog.argtypes = [c_int, c_int, POINTER(c_int),
> c_char_p]
>
> Is there some newer, better way to load these functions? Is there
> some web tutorial that explains what's going on here, so that I can
> debug it myself next time?
>
> Thanks -- Josh
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

[PyOpenGL-Users] glVertexAttribPointer(); loading platform-specific functions

[Joshua D. <joshuardavis@q.com>]

I have some questions that probably boil down to my inexperience with  
Python. My setup is PyOpenGL-3.0.0c1 on Python 2.5.x on Mac OS X. I'm  
trying to modernize my OpenGL to use VBOs and vertex attributes,  
working through the tutorials at http://bazaar.launchpad.net/ 
~mcfletch/openglcontext/trunk/annotate/head:/tests/shader_4.py. When  
I execute code like this:

vertexBufferObject = vbo.VBO(...)
gl.glVertexAttribPointer(positionLocation, 3, GL_FLOAT, False, 24,  
vertexBufferObject)

The second line generates this error:

ctypes.ArgumentError: argument 6: <type 'exceptions.TypeError'>:  
Don't know how to convert parameter 6

The following code is what I've been doing to get platform-specific  
(?) PyOpenGL functions. They often seem to require some massaging of  
argument types; is the same thing needed for glVertexAttribPointer()  
above?

# This is adapted from http://www.pygame.org/wiki/GLSLExample.
try:
     from OpenGL import platform
     gl = platform.OpenGL
except ImportError:
     try:
         gl = cdll.LoadLibrary('libGL.so')
     except OSError:
         from ctypes.util import find_library
         path = find_library('OpenGL')
         gl = cdll.LoadLibrary(path)
gl.glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), POINTER 
(c_int)]
gl.glGetShaderiv.argtypes = [c_int, c_int, POINTER(c_int)]
gl.glGetShaderInfoLog.argtypes = [c_int, c_int, POINTER(c_int),  
c_char_p]

Is there some newer, better way to load these functions? Is there  
some web tutorial that explains what's going on here, so that I can  
debug it myself next time?

Thanks -- Josh

[PyOpenGL-Users] PyOpenGL 3.0.1a2, for the forward-thinking...

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

Second alpha of the 3.0.1 series includes a number of bug-fixes from
PyOpenGL 3.0.1a1, as well as updated extensions (including OpenGL 3.1
core).  The new extensions are currently just auto-generated, so if you
see something that needs special wrapping, feel free to ping me.  The
OpenGL.org extension header now breaks out the deprecated/non-deprecated
functionality, so you will see modules with _DEPRECATED showing up in
the tree, the raw versions are imported into the non _DEPRECATED
versions, so wrapping will continue to be in the root module(s).

I would expect to see only very minor regressions from this release, as
the 3.0.1a1 release seemed to work relatively well in testing and the
only major change is the extensions.  We're not ready for prime-time, so
don't install into live systems, but if you have code that uses
PyOpenGL, you'll want to test with this release and send any bug reports
so that we can fix the bugs before 3.0.1 final.

https://sourceforge.net/projects/pyopengl/files/PyOpenGL/3.0.1a2/

Win32 exe and cross-platform source available.

Enjoy yourselves,
Mike

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

Re: [PyOpenGL-Users] [pygame] opengl from python - drawing wireframe shape colours and contour in the same time

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

Sure :-)

Re: [PyOpenGL-Users] [pygame] opengl from python - drawing wireframe shape colours and contour in the same time

[Paulo S. <nit...@gm...>]

no, my idea is doing simple poly games, a bit like those 3d games from
Amiga time (such as Robocop3 and many others) - very flatcoloured -
but i really wanted so have the meshes wireframed - thanks for all
useful info! :)

On 7/27/09, Ian Mallett <geo...@gm...> wrote:
> Yes, unfortunately.  That may be a problem, especially if the object is high
> poly.  There are more complex methods that use shaders.  One of the better
> ones I've found is:
>
> Render the scene to two textures, one RGB and the other depth
> Apply an edge-detection filter to the depth texture (no edge = white, edge =
> black)
> Multiply the two textures together on a fullscreen quad.
>
> The problem here is you'd need shaders if you want to only have one pass,
> which may be overkill.  (MRT to render to both textures simultaneously or
> storing the depth in the alpha channel of the texture).  If you want to use
> fixed function, you'd need two render-to-textures; one for each texture--and
> so there wouldn't really be an advantage to this method over the original
> one.
>
> There's also normal-based edge detection, which I have tried as well.  It's
> simpler, though you'll probably need a shader here too.  This unfortunately
> suffers from line-thickness, which may or may not be a problem.  You'd only
> need one pass though.
>
> HTH,
> Ian
>

Re: [PyOpenGL-Users] [pygame] opengl from python - drawing wireframe shape colours and contour in the same time

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

Yes, unfortunately.  That may be a problem, especially if the object is high
poly.  There are more complex methods that use shaders.  One of the better
ones I've found is:

Render the scene to two textures, one RGB and the other depth
Apply an edge-detection filter to the depth texture (no edge = white, edge =
black)
Multiply the two textures together on a fullscreen quad.

The problem here is you'd need shaders if you want to only have one pass,
which may be overkill.  (MRT to render to both textures simultaneously or
storing the depth in the alpha channel of the texture).  If you want to use
fixed function, you'd need two render-to-textures; one for each texture--and
so there wouldn't really be an advantage to this method over the original
one.

There's also normal-based edge detection, which I have tried as well.  It's
simpler, though you'll probably need a shader here too.  This unfortunately
suffers from line-thickness, which may or may not be a problem.  You'd only
need one pass though.

HTH,
Ian

Re: [PyOpenGL-Users] [pygame] opengl from python - drawing wireframe shape colours and contour in the same time

[Paulo S. <nit...@gm...>]

thanks! (pressuposed i understood the same object must be drawn twice,
as shape and as wireframe?)

On 7/27/09, Ian Mallett <geo...@gm...> wrote:
> #Draw the object here
> #Disable texturing, lighting, etc. here
> glColor3f(0,0,0)
> glLineWidth(4) #or whatever
> glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)
> #Draw the object here
> glPolygonMode(GL_FRONT_AND_BACK,GL_FILL)
> glLineWidth(1) #also or whatever
> glColor3f(1,1,1)
> #Enable texturing, lighting, etc. here
>

Re: [PyOpenGL-Users] glDeleteBuffers() and arrays.vbo

[Dan H. <Dan...@no...>]

Dan Helfman wrote:
> Mike C. Fletcher wrote:
>> Dan Helfman wrote:
>>> Exception OpenGL.error.NullFunctionError: NullFunctionError('Attempt to 
>>> call an undefined function glDeleteBuffers, check for 
>>> bool(glDeleteBuffers) before calling',) in <function doBufferDeletion at 
>>> 0x0A8892B0> ignored
>>>   
>> This sounds like the VBO is getting deleted after module cleanup?  You
>> should always have a glDeleteBuffers implementation if you have a
>> glGenBuffers implementation.  Basically this code is getting called
>> after the system has done so much cleanup that the functions aren't
>> available any more (at least, that's my interpretation).
> 
> This is happening when a VBO instance is finalized after its containing 
> object goes away. And as far as I can tell, the deleter is only being 
> called once for each VBO. So I'm not sure what else could be doing the 
> cleanup unless it's in the underlying C code. I put some prints in the 
> explicit VBO.delete() call, so I've confirmed that that's not getting 
> called.
> 
> I should mention that this is all with the 3.0.0 release.

Follow-up: Upon further investigation, turns out that this is a 
threading issue. GL and the VBOs were initialized in one thread, and 
then VBO finalization was getting triggered from a different thread. As 
soon as I changed it so that the VBO deleter only got triggered from the 
correct thread, the NullFunctionErrors went away.

Dan

Re: [PyOpenGL-Users] [pygame] opengl from python - drawing wireframe shape colours and contour in the same time

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

#Draw the object here
#Disable texturing, lighting, etc. here
glColor3f(0,0,0)
glLineWidth(4) #or whatever
glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)
#Draw the object here
glPolygonMode(GL_FRONT_AND_BACK,GL_FILL)
glLineWidth(1) #also or whatever
glColor3f(1,1,1)
#Enable texturing, lighting, etc. here

[PyOpenGL-Users] opengl from python - drawing wireframe shape colours and contour in the same time

[Paulo S. <nit...@gm...>]

hi!

do someone know how can we draw opengl shapes with plain colour fill
and outline, with different colours, at same time?
a good example is what were used on the Area 4 of Rez:
http://www.youtube.com/watch?v=aAncDNDsv7s , and some games from Kenta
Cho (which also uses OpenGL)

(sorry posting this message at pygame mailing list as well, maybe
there are good audience can answer, and thanks in advance too)

thanks!

Re: [PyOpenGL-Users] glDeleteBuffers() and arrays.vbo

[Dan H. <Dan...@no...>]

Mike C. Fletcher wrote:
> Dan Helfman wrote:
>> Exception OpenGL.error.NullFunctionError: NullFunctionError('Attempt to 
>> call an undefined function glDeleteBuffers, check for 
>> bool(glDeleteBuffers) before calling',) in <function doBufferDeletion at 
>> 0x0A8892B0> ignored
>>   
> This sounds like the VBO is getting deleted after module cleanup?  You
> should always have a glDeleteBuffers implementation if you have a
> glGenBuffers implementation.  Basically this code is getting called
> after the system has done so much cleanup that the functions aren't
> available any more (at least, that's my interpretation).

This is happening when a VBO instance is finalized after its containing 
object goes away. And as far as I can tell, the deleter is only being 
called once for each VBO. So I'm not sure what else could be doing the 
cleanup unless it's in the underlying C code. I put some prints in the 
explicit VBO.delete() call, so I've confirmed that that's not getting 
called.

I should mention that this is all with the 3.0.0 release.

> That's now fixed in bzr head, will show up in the 3.0.1a2 release.  i.e.
> we catch the NullFunctionError, so you shouldn't see the ignored error
> messages any more.

Great, thanks!

> That said, you *shouldn't* ever need to explicitly call delete on the
> VBO instance unless for some reason you want to "reuse" the VBO object
> but not the GL-side buffer (I can't think of a real use-case for that).

Gotcha.

Dan

Re: [PyOpenGL-Users] glDeleteBuffers() and arrays.vbo

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

Dan Helfman wrote:
> Hi all,
>
> I may have found a bug in PyOpenGL's arrays.vbo module, but it could be 
> a problem with my code or system. When a vertex or other buffer is 
> automatically deleted by PyOpenGL's deleter, here's the error that I get:
>
> Exception OpenGL.error.NullFunctionError: NullFunctionError('Attempt to 
> call an undefined function glDeleteBuffers, check for 
> bool(glDeleteBuffers) before calling',) in <function doBufferDeletion at 
> 0x0A8892B0> ignored
>   
This sounds like the VBO is getting deleted after module cleanup?  You
should always have a glDeleteBuffers implementation if you have a
glGenBuffers implementation.  Basically this code is getting called
after the system has done so much cleanup that the functions aren't
available any more (at least, that's my interpretation).
> To me, that sounds like my OpenGL implementation (from Nvidia) doesn't 
> implement glDeleteBuffers() for whatever reason. The deleter code in 
> vbo.py appears to check for this, but it checks for an AttributeError 
> rather than an OpenGL.error.NullFunctionError, or better yet, doing a 
> protective bool(glDeleteBuffers) before actually calling glDeleteBuffers().
>   
That's now fixed in bzr head, will show up in the 3.0.1a2 release.  i.e.
we catch the NullFunctionError, so you shouldn't see the ignored error
messages any more.
> By the way, is it problematic that when doing a manual VBO.delete(), the 
> automatic deleter is still invoked? Shouldn't VBO.delete() pop the 
> deleter so glDeleteBuffers() isn't called twice for a particular VBO? Or 
> is that not a problem?
>   
The auto-deleter uses the same list (self.buffers of the vbo), so the
delete method's pop() from that list meant there was nothing left in the
auto-deleter.  It shouldn't be possible for the deleter to get called
before the delete method, but just in case I've altered it to also use
pop() to retrieve values (rather than simple iteration).  Calling
glDeleteBuffers() twice for the same buffer would be a problem if, for
instance, another vbo had already been allocated that ID.

That said, you *shouldn't* ever need to explicitly call delete on the
VBO instance unless for some reason you want to "reuse" the VBO object
but not the GL-side buffer (I can't think of a real use-case for that).

Thanks for the bug report,
Mike

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

[PyOpenGL-Users] glDeleteBuffers() and arrays.vbo

[Dan H. <Dan...@no...>]

Hi all,

I may have found a bug in PyOpenGL's arrays.vbo module, but it could be 
a problem with my code or system. When a vertex or other buffer is 
automatically deleted by PyOpenGL's deleter, here's the error that I get:

Exception OpenGL.error.NullFunctionError: NullFunctionError('Attempt to 
call an undefined function glDeleteBuffers, check for 
bool(glDeleteBuffers) before calling',) in <function doBufferDeletion at 
0x0A8892B0> ignored

To me, that sounds like my OpenGL implementation (from Nvidia) doesn't 
implement glDeleteBuffers() for whatever reason. The deleter code in 
vbo.py appears to check for this, but it checks for an AttributeError 
rather than an OpenGL.error.NullFunctionError, or better yet, doing a 
protective bool(glDeleteBuffers) before actually calling glDeleteBuffers().

By the way, is it problematic that when doing a manual VBO.delete(), the 
automatic deleter is still invoked? Shouldn't VBO.delete() pop the 
deleter so glDeleteBuffers() isn't called twice for a particular VBO? Or 
is that not a problem?

Dan

Re: [PyOpenGL-Users] VBOs and gl*Pointer offset parameter

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

renaud blanch wrote:
> On Fri, Jul 17, 2009 at 8:34 PM, Mike C. Fletcher<mcf...@vr...> wrote:
>   
...
> thanks, the patch didn't work against my installed version of
> pyopengl, but 3.0.1a1 did it.
>
> the only thing is that i had to change the order of platform plugin
> declarations so that 'darwin' comes before 'posix'.
> on the mac os.name is 'posix', and thus the GLX platform was found
> first and failed to load.
>   
I've changed the plugin to prefer sys.platform over os.name when doing
resolution.  That should mean that on Linux it is the linux2 plugin
preferred.  I'm presuming that os-x has sys.platform == 'darwin', so the
fix should work there too.

Thanks for the error report(s),
Mike

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