pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] Support for py3k?

[Almar K. <alm...@gm...>]

Hi all,

I'm using PyOpenGl as a basis for my visualization toolkit (
http://code.google.com/p/visvis/). Thanks for the great package.

Since Numpy is now py3k-ready, I'm starting to think about supporting
Python3. Any idea when PyOpenGL is going to run on Python 3 too?

I did see a branch of PyOpenGL that is supposed to run on Py3k, but it said
"untested".

Regards,
  Almar

Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

[Belzile Marc-A. <ma...@ho...>]

These 'NoneType is not callable" errors are probably related to a bad installation. I used PyQt as well and got the same error. 

-mab

From: as...@gm...
Date: Tue, 5 Jul 2011 23:32:22 -0300
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
To: ma...@ho...
CC: pyo...@li...

Hello Mab,
I am currently using PyOpenGL on a Windows 7 x64 machine and I haven't run into these issues. I am not using GLUT though, I create my OpenGL context using Qt.


Those "NoneType is not callable" errors lead me to believe that for some reason the OpenGL functions are not being linked into your program. This should happen automagically when you create an OpenGL context (at least this is the case for me using Qt on a NVIDIA driver).


Have you tried using a different mechanism to create your window? pygame is really simple, just call pygame.display.set_mode((w,h), pygame.OPENGL | pygame.DOUBLEBUF).
Alejandro.-



On Tue, Jul 5, 2011 at 10:49 PM, Belzile Marc-André <ma...@ho...> wrote:







Hi,
anyone knows what's going on ? I supsect my pyopengl installation is not adequate. So here are the instructions I used to install pyopengl 3.0.1:
python.exe setup.py build

python.exe setup.py install
However this doesn't seem to do the job:
C:\Users\mab\Downloads\PyOpenGL-3.0.1 (1)\PyOpenGL-3.0.1\tests>python test_glutinit.py

Traceback (most recent call last):  File "test_glutinit.py", line 18, in <module>    glutInit([])  File "c:\Python27\lib\site-packages\OpenGL\GLUT\special.py", line 323, in glutInit

    _base_glutInit( ctypes.byref(count), holder )TypeError: 'NoneType' object is not callable
I'm sure I'm missing something obvious. Is there any more magic involved for installing pyopengl on win64 ?


I was able to install the win64 package available here http://www.lfd.uci.edu/~gohlke/pythonlibs/ but I still get the error for GL_MAX_TEXTURE_BUFFER_SIZE_ARB .


thanks for your help
-mab


From: ma...@ho...


To: as...@gm...
Date: Tue, 5 Jul 2011 09:55:04 -0400
CC: pyo...@li...


Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB








Hi,
yes I did. Here's the full code I'm using:
"""Log opengl info for this machine"""

from OpenGL.GL import *

from OpenGL.GLUT import *from OpenGL.GL.ARB.texture_buffer_object import *



def InitGL(Width, Height):	glClearColor(0.0, 0.0, 0.0, 0.0)

	glMatrixMode(GL_PROJECTION)

	glLoadIdentity()	glMatrixMode(GL_MODELVIEW)

  

def log_opengl_info(): 	ver = glGetString( GL_VERSION )

 	ven = glGetString( GL_VENDOR )

 	ren = glGetString( GL_RENDERER )
 	
 	print 'vendor: %s\nopenl version: %s\nrenderer: %s\nsupported extensions:' % (ven,ver,ren)

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

	print 'OpenGL.GL.ARB.texture_buffer_object %d\n' % glInitTextureBufferObjectARB()

	print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )

def render():

	glClear(GL_COLOR_BUFFER_BIT)

	glLoadIdentity()	log_opengl_info()

window = None	

def main():	global window

	glutInit(sys.argv)

	glutInitDisplayMode(GLUT_RGBA)

	glutInitWindowSize(10, 10)

	glutInitWindowPosition(0, 0)

	window = glutCreateWindow('log opengl info')

	glutDisplayFunc(render)

	# Initialize our window. 

	InitGL(10, 10)

	# Start Event Processing Engine    

	glutMainLoop()



if __name__ == "__main__":    main()



From: as...@gm...
Date: Tue, 5 Jul 2011 10:14:14 -0300
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
To: ma...@ho...


CC: pyo...@li...

Hi Mab,





Hi,



using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an error 




Have you tried creating a window with an OpenGL context before trying to call glGetIntegerv?
Alejandro.- --  http://alejandrosegovia.net




 		 	   		  

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users 		 	   		  


-- 
http://alejandrosegovia.net

 		 	   		  

Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

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

Hello Mab,

I am currently using PyOpenGL on a Windows 7 x64 machine and I haven't run
into these issues. I am not using GLUT though, I create my OpenGL context
using Qt.

Those "NoneType is not callable" errors lead me to believe that for some
reason the OpenGL functions are not being linked into your program. This
should happen automagically when you create an OpenGL context (at least this
is the case for me using Qt on a NVIDIA driver).

Have you tried using a different mechanism to create your window? pygame is
really simple, just call pygame.display.set_mode((w,h), pygame.OPENGL |
pygame.DOUBLEBUF).

Alejandro.-

On Tue, Jul 5, 2011 at 10:49 PM, Belzile Marc-André <ma...@ho...>wrote:

>  Hi,
>
> anyone knows what's going on ? I supsect my pyopengl installation is not
> adequate. So here are the instructions I used to install pyopengl 3.0.1:
>
> python.exe setup.py build
> python.exe setup.py install
>
> However this doesn't seem to do the job:
>
> C:\Users\mab\Downloads\PyOpenGL-3.0.1 (1)\PyOpenGL-3.0.1\tests>python
> test_glutinit.py
> Traceback (most recent call last):
>   File "test_glutinit.py", line 18, in <module>
>     glutInit([])
>   File "c:\Python27\lib\site-packages\OpenGL\GLUT\special.py", line 323, in
> glutInit
>     _base_glutInit( ctypes.byref(count), holder )
> TypeError: 'NoneType' object is not callable
>
> I'm sure I'm missing something obvious. Is there any more magic involved
> for installing pyopengl on win64 ?
>
> I was able to install the win64 package available here
> http://www.lfd.uci.edu/~gohlke/pythonlibs/ but I still get the error for GL_MAX_TEXTURE_BUFFER_SIZE_ARB
> .
>
> thanks for your help
>
> -mab
>
>
> ------------------------------
> From: ma...@ho...
> To: as...@gm...
> Date: Tue, 5 Jul 2011 09:55:04 -0400
>
> CC: pyo...@li...
> Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
>
>  Hi,
>
> yes I did. Here's the full code I'm using:
>
> """Log opengl info for this machine"""
>
> from OpenGL.GL import *
> from OpenGL.GLUT import *
> from OpenGL.GL.ARB.texture_buffer_object import *
>
>
> def InitGL(Width, Height):
> glClearColor(0.0, 0.0, 0.0, 0.0)
>  glMatrixMode(GL_PROJECTION)
>  glLoadIdentity()
> glMatrixMode(GL_MODELVIEW)
>
>
> def log_opengl_info():
>   ver = glGetString( GL_VERSION )
>   ven = glGetString( GL_VENDOR )
>   ren = glGetString( GL_RENDERER )
>
>   print 'vendor: %s\nopenl version: %s\nrenderer: %s\nsupported
> extensions:' % (ven,ver,ren)
>   #print '\n'.join( glGetString( GL_EXTENSIONS ).split(' ') )
>
> print 'OpenGL.GL.ARB.texture_buffer_object %d\n' %
> glInitTextureBufferObjectARB()
>  print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )
>
> def render():
>  glClear(GL_COLOR_BUFFER_BIT)
>  glLoadIdentity()
> log_opengl_info()
>
> window = None
> def main():
> global window
>  glutInit(sys.argv)
>  glutInitDisplayMode(GLUT_RGBA)
>
>  glutInitWindowSize(10, 10)
>
> glutInitWindowPosition(0, 0)
>
> window = glutCreateWindow('log opengl info')
>
> glutDisplayFunc(render)
>
> # Initialize our window.
>  InitGL(10, 10)
>
> # Start Event Processing Engine
>  glutMainLoop()
>
>
> if __name__ == "__main__":
>     main()
>
>
> ------------------------------
> From: as...@gm...
> Date: Tue, 5 Jul 2011 10:14:14 -0300
> Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
> To: ma...@ho...
> CC: pyo...@li...
>
> Hi Mab,
>
>  Hi,
>
> using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an error
>
>
>
> Have you tried creating a window with an OpenGL context before trying to
> call glGetIntegerv?
>
> Alejandro.-
>
> --
> http://alejandrosegovia.net
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________ PyOpenGL Homepage
> http://pyopengl.sourceforge.net_______________________________________________ PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>



-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

[Belzile Marc-A. <ma...@ho...>]

Hi,
anyone knows what's going on ? I supsect my pyopengl installation is not adequate. So here are the instructions I used to install pyopengl 3.0.1:
python.exe setup.py buildpython.exe setup.py install
However this doesn't seem to do the job:
C:\Users\mab\Downloads\PyOpenGL-3.0.1 (1)\PyOpenGL-3.0.1\tests>python test_glutinit.pyTraceback (most recent call last):  File "test_glutinit.py", line 18, in <module>    glutInit([])  File "c:\Python27\lib\site-packages\OpenGL\GLUT\special.py", line 323, in glutInit    _base_glutInit( ctypes.byref(count), holder )TypeError: 'NoneType' object is not callable
I'm sure I'm missing something obvious. Is there any more magic involved for installing pyopengl on win64 ?
I was able to install the win64 package available here http://www.lfd.uci.edu/~gohlke/pythonlibs/ but I still get the error for GL_MAX_TEXTURE_BUFFER_SIZE_ARB .
thanks for your help
-mab


From: ma...@ho...
To: as...@gm...
Date: Tue, 5 Jul 2011 09:55:04 -0400
CC: pyo...@li...
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB








Hi,
yes I did. Here's the full code I'm using:
"""Log opengl info for this machine"""from OpenGL.GL import *from OpenGL.GLUT import *from OpenGL.GL.ARB.texture_buffer_object import *def InitGL(Width, Height):	glClearColor(0.0, 0.0, 0.0, 0.0)	glMatrixMode(GL_PROJECTION)	glLoadIdentity()	glMatrixMode(GL_MODELVIEW)  def log_opengl_info(): 	ver = glGetString( GL_VERSION ) 	ven = glGetString( GL_VENDOR ) 	ren = glGetString( GL_RENDERER ) 	 	print 'vendor: %s\nopenl version: %s\nrenderer: %s\nsupported extensions:' % (ven,ver,ren) 	#print '\n'.join( glGetString( GL_EXTENSIONS ).split(' ') )	print 'OpenGL.GL.ARB.texture_buffer_object %d\n' % glInitTextureBufferObjectARB()	print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )def render():	glClear(GL_COLOR_BUFFER_BIT)	glLoadIdentity()	log_opengl_info()window = None	def main():	global window	glutInit(sys.argv)	glutInitDisplayMode(GLUT_RGBA)	glutInitWindowSize(10, 10)	glutInitWindowPosition(0, 0)	window = glutCreateWindow('log opengl info')	glutDisplayFunc(render)	# Initialize our window. 	InitGL(10, 10)	# Start Event Processing Engine    	glutMainLoop()if __name__ == "__main__":    main()

From: as...@gm...
Date: Tue, 5 Jul 2011 10:14:14 -0300
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
To: ma...@ho...
CC: pyo...@li...

Hi Mab,



Hi,

using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an error 


Have you tried creating a window with an OpenGL context before trying to call glGetIntegerv?
Alejandro.- --  http://alejandrosegovia.net


 		 	   		  

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users 		 	   		  

Re: [PyOpenGL-Users] PyOpenGL on Windows

[Chris B. <Chr...@no...>]

On 7/5/11 9:54 AM, Alejandro Segovia wrote:
>     As a rule, it is easiest, and maybe necessary, to build python
>     extensions on Windows with the same version of the MS compiler used to
>     build the python binary. AFAIK, it's CRT issues.

> I'm using Python 2.7 on Windows 7 x64. It is the python.org
> <http://python.org> build.

then I am surprised that there aren't issues with that older CRT.

> If you haven't run across this issue, it might be because you have
> MSVCRT7.1.dll in your system.

probably do -- it's pretty darn common. I've generally not bothered to 
distribute it with py2exe projects, as most people have it. (or did -- 
it maybe getting less common with Win7 systems, etc)

> I do understand you point, however.
> Perhaps providing a gle32.dll linked against MSVCRT90 could be a problem
> for people running older versions of Python (2.4 and 2.5).

it might, yes - certainly testing would be in order.

> I have noticed other Python projects usually keep different binary
> downloads for different versions of Python.

yes -- that's generally required -- as a rule, the different versions of 
python are not binary compatible, so you need to do that, CRT issues 
aside. I guess if you use ctypes as your only interface, you avoid that.

> This is all assuming gle32 is at all needed as a part of PyOpenGL. If
> it's not used internally, maybe it shouldn't come with PyOpenGL, as the
> whole linking issue seems to be confusing enough for at least one person :)

indeed -- that would simplify things.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

Hi Chris,

On Tue, Jul 5, 2011 at 1:21 PM, Chris Barker <Chr...@no...> wrote:

> On 7/4/11 7:58 AM, Alejandro Segovia wrote:
> > It seems the binary installer available at the PyOpenGL website is
> > dynamically linked against the Visual C++ 7.1 runtime. This library,
> > available as the Visual C++ redistributable 2003, is very outdated and
> > is kinda hard to obtain nowadays.
>
>
> from further posts, is seem there may be some PyOpenGL-specific issues
> here, but:
>
> As a rule, it is easiest, and maybe necessary, to build python
> extensions on Windows with the same version of the MS compiler used to
> build the python binary. AFAIK, it's CRT issues.
>
> The binaries on python.org are built with (I think, you'd probably want
> to make sure rather than trust my memory)
>
> Python 2.4 -- MSVS 2003
> Python 2.5 -- MSVS 2003
> Python 2.6 -- MSVS 2008
> Python 2.9 -- MSVS 2008
>
> What version of Python (and is it the python.org build?) are you using?
>

I'm using Python 2.7 on Windows 7 x64. It is the python.org build.


> If newer versions of the PyOpenGL binary are built with the 2003 CRT,
> then I'm surprised I haven't run into any of these issues yet -- I guess
> we've just have that old CRT kicking around on all our machines. Though
> aside from having the dll, I wonder if there might be issues with mixing
> CRTs in the same binary. I suppose it depends on what you are calling in
> the CRT
>

If you haven't run across this issue, it might be because you have
MSVCRT7.1.dll in your system. I do understand you point, however. Perhaps
providing a gle32.dll linked against MSVCRT90 could be a problem for people
running older versions of Python (2.4 and 2.5).

I have noticed other Python projects usually keep different binary downloads
for different versions of Python. Something like that could be adopted for
PyOpenGL, where there's a download for Python versions 2.3 and 2.4 with
gle32.dll linked against MSVCRT7.1 and another download for newer Python
versions, with gle32.dll linked against MSVCRT90.

This is all assuming gle32 is at all needed as a part of PyOpenGL. If it's
not used internally, maybe it shouldn't come with PyOpenGL, as the whole
linking issue seems to be confusing enough for at least one person :)

Best,
Alejandro.-


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] PyOpenGL on Windows

[Chris B. <Chr...@no...>]

On 7/4/11 7:58 AM, Alejandro Segovia wrote:
> It seems the binary installer available at the PyOpenGL website is
> dynamically linked against the Visual C++ 7.1 runtime. This library,
> available as the Visual C++ redistributable 2003, is very outdated and
> is kinda hard to obtain nowadays.


from further posts, is seem there may be some PyOpenGL-specific issues 
here, but:

As a rule, it is easiest, and maybe necessary, to build python 
extensions on Windows with the same version of the MS compiler used to 
build the python binary. AFAIK, it's CRT issues.

The binaries on python.org are built with (I think, you'd probably want 
to make sure rather than trust my memory)

Python 2.4 -- MSVS 2003
Python 2.5 -- MSVS 2003
Python 2.6 -- MSVS 2008
Python 2.9 -- MSVS 2008

What version of Python (and is it the python.org build?) are you using?

If newer versions of the PyOpenGL binary are built with the 2003 CRT, 
then I'm surprised I haven't run into any of these issues yet -- I guess 
we've just have that old CRT kicking around on all our machines. Though 
aside from having the dll, I wonder if there might be issues with mixing 
CRTs in the same binary. I suppose it depends on what you are calling in 
the CRT

HTH,

-Chris





  I tried building PyOpenGL from source
> and the produced package seems to depend on the 7.1 runtime as well.
>
> As a consequence, I have two questions someone might be able to help me
> with:
>
> 1. Why is the Visual C++ 7.1 runtime a dependency even when I build from
> source and I don't have the VC7.1 compiler?
>
> 2. I have a VS10 compiler available, would anyone be interested in me
> building a more recent binary release for Windows? I can do it, but I'm
> going to need some help regarding how to get rid of the old 7.1 runtime.
>
> Thanks in advance.
>
> Best regards,
> Alejandro.-
>
> --
> http://alejandrosegovia.net
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

[Belzile Marc-A. <ma...@ho...>]

Hi,
yes I did. Here's the full code I'm using:
"""Log opengl info for this machine"""from OpenGL.GL import *from OpenGL.GLUT import *from OpenGL.GL.ARB.texture_buffer_object import *def InitGL(Width, Height):	glClearColor(0.0, 0.0, 0.0, 0.0)	glMatrixMode(GL_PROJECTION)	glLoadIdentity()	glMatrixMode(GL_MODELVIEW)  def log_opengl_info(): 	ver = glGetString( GL_VERSION ) 	ven = glGetString( GL_VENDOR ) 	ren = glGetString( GL_RENDERER ) 	 	print 'vendor: %s\nopenl version: %s\nrenderer: %s\nsupported extensions:' % (ven,ver,ren) 	#print '\n'.join( glGetString( GL_EXTENSIONS ).split(' ') )	print 'OpenGL.GL.ARB.texture_buffer_object %d\n' % glInitTextureBufferObjectARB()	print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )def render():	glClear(GL_COLOR_BUFFER_BIT)	glLoadIdentity()	log_opengl_info()window = None	def main():	global window	glutInit(sys.argv)	glutInitDisplayMode(GLUT_RGBA)	glutInitWindowSize(10, 10)	glutInitWindowPosition(0, 0)	window = glutCreateWindow('log opengl info')	glutDisplayFunc(render)	# Initialize our window. 	InitGL(10, 10)	# Start Event Processing Engine    	glutMainLoop()if __name__ == "__main__":    main()

From: as...@gm...
Date: Tue, 5 Jul 2011 10:14:14 -0300
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
To: ma...@ho...
CC: pyo...@li...

Hi Mab,



Hi,

using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an error 


Have you tried creating a window with an OpenGL context before trying to call glGetIntegerv?
Alejandro.- --  http://alejandrosegovia.net


 		 	   		  

Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

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

Hi Mab,

Hi,
>
> using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an error
>
>

Have you tried creating a window with an OpenGL context before trying to
call glGetIntegerv?

Alejandro.-

--
http://alejandrosegovia.net

[PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

[Belzile Marc-A. <ma...@ho...>]

Hi,using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an errorfrom OpenGL.GL.ARB.texture_buffer_object import *ver = glGetString( GL_VERSION )ven = glGetString( GL_VENDOR )print 'vendor: %s\nversion: %s\nExtensions supported:\n' % (ven,ver)print 'OpenGL.GL.ARB.texture_buffer_object %d\n' % glInitTextureBufferObjectARB()print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )output:vendor: NVIDIA Corporationversion: 4.0.0Extensions supported:OpenGL.GL.ARB.texture_buffer_object 1Traceback (most recent call last):  File "c:\Python27\lib\site-packages\OpenGL\GLUT\special.py", line 120, in safeCall    return function( *args, **named )  File "lesson3.py", line 95, in DrawGLScene    log_opengl_info()  File "lesson3.py", line 63, in log_opengl_info    print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )  File "c:\Python27\lib\site-packages\OpenGL\latebind.py", line 45, in __call__    return self._finalCall( *args, **named )  File "c:\Python27\lib\site-packages\OpenGL\wrapper.py", line 570, in wrapperCall    cArgs = tuple(calculate_cArgs( pyArgs ))  File "c:\Python27\lib\site-packages\OpenGL\wrapper.py", line 373, in calculate_cArgs    yield converter( pyArgs, index, self )  File "c:\Python27\lib\site-packages\OpenGL\converters.py", line 194, in __call__    return self.arrayType.zeros( self.getSize(pyArgs) )  File "c:\Python27\lib\site-packages\OpenGL\converters.py", line 233, in getSize    raise KeyError( """Unknown specifier %s"""%( specifier ))KeyError: ('Unknown specifier GL_MAX_TEXTURE_BUFFER_SIZE_ARB (35883)', 'Failure in cConverter <OpenGL.converters.SizedOutput objectat 0x0000000002BE71C8>', (GL_MAX_TEXTURE_BUFFER_SIZE_ARB,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x0000000002E9C288>)GLUT Idle callback <function DrawGLScene at 0x0000000003645D68> with (),{} failed: returning None ('Unknown specifier GL_MAX_TEXTURE_BUFFER_SIZE_ARB (35883)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x0000000002BE71C8>', (GL_MAX_TEXTURE_BUFFER_SIZE_ARB,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x0000000002E9C288>)What is wrong here?thanks-mab 		 	   		  

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

Okay guys, I managed to get the GLE source code. It was found laying in a
SourceForge project.

http://sourceforge.net/projects/gle/

By default it builds as a static library. I ported the project to Visual C++
9 (so it links against MSVCRT9.0) and tweaked it to build into a DLL file.

I've replaced the old and busted gle32.dll with this new DLL and my
application no longer complains about missing the MSVCRT7.1 runtime.

Mike, would you agree on replacing the old DLL in the PyOpenGL source bundle
with this one?

Best,
Alejandro.-


On Mon, Jul 4, 2011 at 3:15 PM, Alejandro Segovia <as...@gm...> wrote:

> Hi Henry,
>
> Thanks for all the help. The CRT versioning discussion was a great read.
>
>  >> It seems that the gle32.dll packaged with PyOpenGL has this
>> >> dependency, so its this library that needs to be recompiled.
>>
>> It also seems to be a fairly minimal change to remove the GLE
>> functionality entirely under Windows. Certainly, I won't be needing it.
>>
>
> Yes, I think I'll go this way too. I'll try to find whatever code requests
> this DLL to be loaded and nuke it. I just hope nothing breaks.
>
> It would still be nice being able to recompile this library and patch
> PyOpenGL. I found this other page using Google:
> http://brightideassoftware.com/GLE32Downloads.aspx but the source code is
> incomplete and I can't build it.
>
> If anyone has the GLE32 code, please drop me a line.
>
> Best,
> Alejandro.-
>
>
> --
> http://alejandrosegovia.net
>
>


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

Hi Henry,

Thanks for all the help. The CRT versioning discussion was a great read.

>> It seems that the gle32.dll packaged with PyOpenGL has this
> >> dependency, so its this library that needs to be recompiled.
>
> It also seems to be a fairly minimal change to remove the GLE
> functionality entirely under Windows. Certainly, I won't be needing it.
>

Yes, I think I'll go this way too. I'll try to find whatever code requests
this DLL to be loaded and nuke it. I just hope nothing breaks.

It would still be nice being able to recompile this library and patch
PyOpenGL. I found this other page using Google:
http://brightideassoftware.com/GLE32Downloads.aspx but the source code is
incomplete and I can't build it.

If anyone has the GLE32 code, please drop me a line.

Best,
Alejandro.-


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

On Mon, 2011-07-04 at 18:32 +0100, Henry Gomersall wrote:
> It seems that the gle32.dll packaged with PyOpenGL has this
> dependency,
> so its this library that needs to be recompiled. 

It also seems to be a fairly minimal change to remove the GLE
functionality entirely under Windows. Certainly, I won't be needing it.

Cheers,
Henry

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

On Mon, 2011-07-04 at 18:32 +0100, Henry Gomersall wrote:
> On Mon, 2011-07-04 at 13:43 -0300, Alejandro Segovia wrote:
> > I can confirm that after getting the MSVCRT7.1.dll not found error
> > message every time I lunch my application, it happens to run fine,
> > with all OpenGL code working.
> 
> It seems that the gle32.dll packaged with PyOpenGL has this
> dependency,
> so its this library that needs to be recompiled. 

My naive fiddling seems to suggest a fairly minimal dependency on
MSVCR71.dll. winedump shows the following symbols. Most of those look
like they won't have changed much (although some look like they might
have!)...

  offset 0001e1dc MSVCR71.dll
  Hint/Name Table: 0001E23C
  TimeDateStamp:   00000000 (Thu Jan  1 01:00:00 1970)
  ForwarderChain:  00000000
  First thunk RVA: 0001E024
  Ordn  Name
   766  sin 1e3dc
   241  _except_handler3 1e456
    76  __CppXcptFilter 1e444
   187  _adjust_fdiv 1e434
   319  _initterm 1e428
   440  _onexit 1e412
   107  __dllonexit 1e404
   648  atan2 1e3fc
   757  realloc 1e3f2
   644  acos 1e3ea
   769  sqrt 1e3bc
   684  free 1e3c4
   735  malloc 1e3cc
   658  cos 1e3d6
   665  fabs 1e3e2

Interesting discussion here on CRT versioning...

http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

Cheers,
Henry

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

On Mon, 2011-07-04 at 13:43 -0300, Alejandro Segovia wrote:
> I can confirm that after getting the MSVCRT7.1.dll not found error
> message every time I lunch my application, it happens to run fine,
> with all OpenGL code working.

It seems that the gle32.dll packaged with PyOpenGL has this dependency,
so its this library that needs to be recompiled.

I've just spent a little while trying to hunt the source down for that
library, and the best I get to is here:
http://linas.org/mirrors/www.quiknet.com/2001.04.09/~moriarty/downloads.htm

but the source link (look inside the html) is dead. If you try to go to
that quicknet page, it redirects to surewest.com. Someone must have the
source somewhere! (it's GPL according to the license file).

cheers,
Henry

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

It seems this issue has been brought up before, although on a slightly
different form.

There was an email thread at [1] and there even seems to be an open ticket
regarding this at [2].

I can confirm that after getting the MSVCRT7.1.dll not found error message
every time I lunch my application, it happens to run fine, with all OpenGL
code working.

I guess the two questions stand though, does anyone know why we might be
getting this message?

Alejandro.-

References:

[1] -
http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimctcemkdkY4U4JyX9EibLj01ERgNhBXPbrC-Rq%40mail.gmail.com&forum_name=pyopengl-users

[2] -
http://sourceforge.net/tracker/index.php?func=detail&aid=3177110&group_id=5988&atid=105988

On Mon, Jul 4, 2011 at 12:04 PM, Henry Gomersall <he...@ca...> wrote:

> On Mon, 2011-07-04 at 11:58 -0300, Alejandro Segovia wrote:
> > today I'm attempting to use PyOpenGL on Windows for the very first
> > time in my life
>
> I, too, am very interested in doing this shortly, so I second the
> questions!
>
> Cheers,
>
> Henry
>
>


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

On Mon, 2011-07-04 at 11:58 -0300, Alejandro Segovia wrote:
> today I'm attempting to use PyOpenGL on Windows for the very first
> time in my life

I, too, am very interested in doing this shortly, so I second the
questions!

Cheers,

Henry

[PyOpenGL-Users] PyOpenGL on Windows

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

Hello all,

As some of you might know, I've been a PyOpenGL user since 2006, however,
today I'm attempting to use PyOpenGL on Windows for the very first time in
my life and I'm experiencing a dependencies issue.

It seems the binary installer available at the PyOpenGL website is
dynamically linked against the Visual C++ 7.1 runtime. This library,
available as the Visual C++ redistributable 2003, is very outdated and is
kinda hard to obtain nowadays. I tried building PyOpenGL from source and the
produced package seems to depend on the 7.1 runtime as well.

As a consequence, I have two questions someone might be able to help me
with:

1. Why is the Visual C++ 7.1 runtime a dependency even when I build from
source and I don't have the VC7.1 compiler?

2. I have a VS10 compiler available, would anyone be interested in me
building a more recent binary release for Windows? I can do it, but I'm
going to need some help regarding how to get rid of the old 7.1 runtime.

Thanks in advance.

Best regards,
Alejandro.-

-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] VBO question

[Jason H. <Jas...@vo...>]

Sure thing.  Here is basically everything I changed to get this to work.  I'm not an expert in OGL, so I could be doing some things wrong.


from ctypes import c_void_p
from OpenGL.GL import *
from OpenGL.GL.ARB.vertex_buffer_object import *
import OpenGL.arrays.arraydatatype
import numpy


## Right after OGL is initialized ##
if glInitVertexBufferObjectARB():
        # build meshes
        # compile shaders


## When a mesh is being built ##
ADT = OpenGL.arrays.arraydatatype.ArrayDatatype

# iterate over each face and build up vertices
vertices.append( [ x, y, z, r, g, b, a ] )

# convert vertices to a numpy array

# send vertices to the GPU
vb_name = glGenBuffersARB( 1 )
glBindBufferARB( GL_ARRAY_BUFFER_ARB, vb_name )
glBufferDataARB( GL_ARRAY_BUFFER_ARB, ADT.arrayByteCount( vertices ), ADT.voidDataPointer( vertices ), GL_STATIC_DRAW_ARB )


## In the mesh bind function ##
glBindBufferARB( GL_ARRAY_BUFFER_ARB, vb_name )

# bind vertex
id = getGetAttribLocation( shader, "position" )
glEnableVertexAttribArray( id )
glVertexAttribPointer( id, 3, GL_FLOAT, GL_FALSE, sizeof( vertex ), None )

# bind color
id = getGetAttribLocation( shader, "color" )
glEnableVertexAttribArray( id )
glVertexAttribPointer( id, 4, GL_FLOAT, GL_FALSE, sizeof( vertex ), c_void_p( OFFSET_VERTEX_COLOR ) )


## In my main render loop ##
glUseProgramObjectARB( shader )
mesh.bind( )
glDrawArrays( GL_TRIANGLES, 0, mesh.num_raw_verts )
mesh.unbind( )
glUseProgramObjectARB( shader )


-Jason

-----Original Message-----
From: W.H. Gomersall [mailto:wh...@he...] On Behalf Of Henry Gomersall
Sent: Tuesday, June 21, 2011 3:20 AM
To: Jason Hayes
Cc: pyo...@li...
Subject: RE: [PyOpenGL-Users] VBO question

On Mon, 2011-06-20 at 18:29 -0700, Jason Hayes wrote:
> Thanks for the reply Henry.  After a lot of trial and error, I finally
> figured out what the real problem is.  I'm on OpenGL 3.3 and
> glVertexPointer and the others have been deprecated since 3.0, but
> PyOpenGL tries to maintain backwards compatability I guess.  So I
> figured out the correct method and switched to glVertexAttribPointer
> and wrote a GLSL shader, now everything works great.

For my benefit as much as others, would you share the code snippet that loads the vertex array?

Thanks,

Henry


This message, including any attachments, may contain privileged and/or confidential information. Any distribution or use of this email by anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you.

Re: [PyOpenGL-Users] VBO question

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

On Mon, 2011-06-20 at 18:29 -0700, Jason Hayes wrote:
> Thanks for the reply Henry.  After a lot of trial and error, I finally
> figured out what the real problem is.  I'm on OpenGL 3.3 and
> glVertexPointer and the others have been deprecated since 3.0, but
> PyOpenGL tries to maintain backwards compatability I guess.  So I
> figured out the correct method and switched to glVertexAttribPointer
> and wrote a GLSL shader, now everything works great.

For my benefit as much as others, would you share the code snippet that
loads the vertex array?

Thanks,

Henry

Re: [PyOpenGL-Users] VBO question

[Jason H. <Jas...@vo...>]

Thanks for the reply Henry.  After a lot of trial and error, I finally figured out what the real problem is.  I'm on OpenGL 3.3 and glVertexPointer and the others have been deprecated since 3.0, but PyOpenGL tries to maintain backwards compatability I guess.  So I figured out the correct method and switched to glVertexAttribPointer and wrote a GLSL shader, now everything works great.

-Jason

________________________________________
From: Henry Gomersall [he...@ca...]
Sent: Monday, June 20, 2011 3:02 PM
To: pyo...@li...
Subject: Re: [PyOpenGL-Users] VBO question

On Mon, 2011-06-20 at 12:20 -0700, Jason Hayes wrote:
> # send vertices over to the GPU self.vbo_name = glGenBuffersARB( 1 )
> glBindBufferARB( GL_ARRAY_BUFFER_ARB, self.vbo_name )
> glBufferDataARB( GL_ARRAY_BUFFER_ARB, vertices, GL_STATIC_DRAW_ARB )

I'm not an expert, but don't you still need to copy the data to the
buffer. I'm not quite sure how you've managed with 3 arguments there
though. The docs all suggest you need 4.

After that I think you need to do something like (modified from my pbo
code, which is all in terms of numpy arrays, which are well laid out in
memory):

        # Map the buffer object to a pointer
        vbo_pointer = ctypes.cast(\
                GL.glMapBuffer(GL.GL_ARRAY_BUFFER, GL.GL_WRITE_ONLY),
                ctypes.POINTER(ctypes.c_ubyte))

        # Turn that pointer into a numpy array that spans
        # the whole block.(buffer size is the size of your buffer)
        vbo_array = numpy.ctypeslib.as_array(vbo_pointer,
                    (buffer_size,))

        vbo_array[0:data_size_to_copy] = \
                    data.view(dtype='uint8').ravel()

        # Unmap the buffer.
        GL.glUnmapBuffer(GL.GL_ARRAY_BUFFER)

Hope that helps.

cheers,

Henry


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users

This message, including any attachments, may contain privileged and/or confidential information. Any distribution or use of this email by anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you.

Re: [PyOpenGL-Users] VBO question

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

On Mon, 2011-06-20 at 12:20 -0700, Jason Hayes wrote:
> # send vertices over to the GPU self.vbo_name = glGenBuffersARB( 1 )
> glBindBufferARB( GL_ARRAY_BUFFER_ARB, self.vbo_name )
> glBufferDataARB( GL_ARRAY_BUFFER_ARB, vertices, GL_STATIC_DRAW_ARB ) 

I'm not an expert, but don't you still need to copy the data to the
buffer. I'm not quite sure how you've managed with 3 arguments there
though. The docs all suggest you need 4.

After that I think you need to do something like (modified from my pbo
code, which is all in terms of numpy arrays, which are well laid out in
memory):

        # Map the buffer object to a pointer
        vbo_pointer = ctypes.cast(\
                GL.glMapBuffer(GL.GL_ARRAY_BUFFER, GL.GL_WRITE_ONLY),
                ctypes.POINTER(ctypes.c_ubyte))
        
        # Turn that pointer into a numpy array that spans
        # the whole block.(buffer size is the size of your buffer)
        vbo_array = numpy.ctypeslib.as_array(vbo_pointer,
                    (buffer_size,))
        
        vbo_array[0:data_size_to_copy] = \
                    data.view(dtype='uint8').ravel()

        # Unmap the buffer.
        GL.glUnmapBuffer(GL.GL_ARRAY_BUFFER) 

Hope that helps.

cheers,

Henry

[PyOpenGL-Users] VBO question

[Jason H. <Jas...@vo...>]

Hello,

I am trying to get VBO's to work using OpenGL.GL.ARB.vertex_buffer_object and am running into issues getting this to work.  It basically renders nothing, and I have no clue why it wouldn't.

Here is the spirit of what I'm doing.

# in my mesh class
def  build(self):
#iterate over faces and build up an array of vertices with interleaved color info
vertices.append( [ x, y, z, r, g, b, a ] )

# convert vertices to numpy array

# send vertices over to the GPU
self.vbo_name = glGenBuffersARB( 1 )
glBindBufferARB( GL_ARRAY_BUFFER_ARB, self.vbo_name )
glBufferDataARB( GL_ARRAY_BUFFER_ARB, vertices, GL_STATIC_DRAW_ARB )


# in my main render loop

glEnableClientState( GL_VERTEX_ARRAY )
glEnableClientState( GL_COLOR_ARRAY )

glBindBufferARB( GL_ARRAY_BUFFER_ARB, mesh.vbo_name )
glVertexPointer( 3, GL_FLOAT, 28, 0 )
glColorPointer( 4, GL_FLOAT, 28, 16 )

glDrawArrays( GL_TRIANGLES, 0, mesh.num_raw_vertices )

glDisableClientState( GL_VERTEX_ARRAY )
glDisableClientState( GL_COLOR_ARRAY )


Any help as to what I could possibly be doing wrong here would be really appreciated.  Thanks!

-Jason



  ________________________________
This message, including any attachments, may contain privileged and/or confidential information. Any distribution or use of this email by anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you.

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

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

>In *theory* all the entry points are
>there, but I expect there will be broken wrappers somewhere.

Unfortunately, not all functions are declared in extensions. (checked
that in gl3.h, and others).
So there is need to parse at least also gl3.h and gl3ext.h, to get full OGL 4.1.

I'll have some free time in near future so ill play a bit.

I'm writing to both mailing-lists but in future ill write only to devel list.

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

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

On 11-06-09 02:53 PM, Przemysław Lib wrote:
> Thx, for replay!
> I'll try to play with bazar pyopengl branch.
>
> BTW I have opengl 4.1 hwd (amd 5730M), and a bit of time (after
> 25.06.2011) so I think i can help in testing
> and/or development (under Lin and Win).
Sounds great.  Probably the best way to help is to try to use 4.x
features and report any bugs.  In *theory* all the entry points are
there, but I expect there will be broken wrappers somewhere.  If you can
do your experiments/tests in a public repository so that they can be
used as sample code for others, that would be a bonus.

Enjoy,
Mike

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