pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Any OS-X users able to do some testing with bzr head?

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

rndblnch <rndblnch <at> gmail.com> writes:

> 
> Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:
> 
> > I have no OS-X machine on which to test the changes, so I'm wondering if 
> > someone who *does* have OS-X could check out bzr-head and run 
> > tests/test_core.py as a smoke test.
> 
> I do not have pygame installed, however, I have got a bunch of opengl code
> to test.
> With revision 639, my code segfault at startup.

more precisely:

	blanch% python
	Python 2.7.2 (default, Oct 11 2012, 20:14:37) 
	[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
	Type "help", "copyright", "credits" or "license" for more information.
	>>> from OpenGL import GL
	Segmentation fault

and the crash log:

	Process:         Python [3980]
	Path:           /System/Library/Frameworks/Python.framework/Versions/2.7/
	                 Resources/Python.app/Contents/MacOS/Python
	Identifier:      Python
	Version:         2.7.2 (2.7.2)
	Code Type:       X86-64 (Native)
	Parent Process:  tcsh [3968]
	User ID:         501

	Date/Time:       2014-01-15 22:37:56.714 +0100
	OS Version:      Mac OS X 10.8.5 (12F45)
	Report Version:  10

	Interval Since Last Report:          1753025 sec
	Crashes Since Last Report:           67
	Per-App Crashes Since Last Report:   40
	Anonymous UUID:                      65705B44-CC97-1F2B-712E-DE99C82E4CFA

	Crashed Thread:  0  Dispatch queue: com.apple.main-thread

	Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
	Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000003b0

	VM Regions Near 0x3b0:
	--> 
	    __TEXT                 000000010461e000-000000010461f000 [    4K]
	r-x/rwx SM=COW /System/Library/Frameworks/Python.framework/Versions/2.7/
	Resources/Python.app/Contents/MacOS/Python

	Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
	0   libGL.dylib                   	0x000000010590b8b5 glGetString + 15
	1   libffi.dylib                  	0x0000000104b12de4 ffi_call_unix64 + 76
	2   libffi.dylib                  	0x0000000104b13619 ffi_call + 853
	3   _ctypes.so                    	0x0000000105770ffc 
		_ctypes_callproc + 785
	4   _ctypes.so                    	0x000000010576b06a 0x105768000 + 12394
	5   org.python.python             	0x00000001046326c6 PyObject_Call + 97
	6   org.python.python             	0x000000010463c78d 
		PyEval_EvalFrameEx + 9728
	7   org.python.python             	0x0000000104640869 0x104623000 + 120937

	...

	69  org.python.python             	0x00000001046399b3 PyEval_EvalCode + 54
	70  org.python.python             	0x0000000104675c70 0x104623000 + 339056
	71  org.python.python             	0x0000000104675ae9 
		PyRun_InteractiveOneFlags + 518
	72  org.python.python            	0x0000000104675578
		PyRun_InteractiveLoopFlags + 206
	73  org.python.python             	0x0000000104675414
		PyRun_AnyFileExFlags + 63
	74  org.python.python             	0x0000000104699e27 Py_Main + 2715
	75  libdyld.dylib                 	0x0000000104b7a7e1 start + 1

hope this helps
renaud

[PyOpenGL-Users] glGenVertexArrays present with python/absent with python3

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

Hello,

I am experimenting with OpenGL 3.2 core using PyOpenGL 3.0.2
I am experiencing something strange: a function (glGenVertexArrays) that is
present when I use python 2.7 is absent when I use python 3.3.
Maybe the automatic conversion from 2to3 breaks something?
I have a lot of PyOpenGL code that run on both python/python3, and it is the
first time I am experiencing something like that.

Any hint?

Below a quick transcript to show the problem (the "core" in the glut init
display string is a hack of mine to get apple's glut supporting opengl 3.2
core):

python 2.7:

	blanch% python
	Python 2.7.2 (default, Oct 11 2012, 20:14:37) 
	[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
	Type "help", "copyright", "credits" or "license" for more information.
	>>> from OpenGL import GL
	>>> from OpenGL import GLUT
	>>> GLUT.glutInit(["test"])
	['test']
	>>> GLUT.glutInitDisplayString(b"rgba double depth core")
	>>> GLUT.glutCreateWindow(b"titi")
	1
	>>> bool(GL.glGenVertexArrays)
	True
	>>> GL
	<module 'OpenGL.GL' from '/Library/Python/2.7/site-packages/
	PyOpenGL-3.0.2-py2.7.egg/OpenGL/GL/__init__.pyc'>
	>>> GL.glGetString(GL.GL_VERSION)
	'3.2 NVIDIA-8.16.74 310.40.00.10f02'
	>>> GL.glGetString(GL.GL_SHADING_LANGUAGE_VERSION)
	'1.50'
	>>> ^D

python 3.3:

	blanch% python3
	Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
	[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
	Type "help", "copyright", "credits" or "license" for more information.
	>>> from OpenGL import GL
	>>> from OpenGL import GLUT
	>>> GLUT.glutInit(["test"])
	["b'test'"]
	>>> GLUT.glutInitDisplayString(b"rgba double depth core")
	>>> GLUT.glutCreateWindow(b"titi")
	1
	>>> bool(GL.glGenVertexArrays)
	False
	>>> GL
	<module 'OpenGL.GL' from '/Library/Frameworks/Python.framework/Versions/
	3.3/lib/python3.3/site-packages/
	PyOpenGL-3.0.2-py3.3.egg/OpenGL/GL/__init__.py'>
	>>> GL.glGetString(GL.GL_VERSION)
	b'3.2 NVIDIA-8.16.74 310.40.00.10f02'
	>>> GL.glGetString(GL.GL_SHADING_LANGUAGE_VERSION)
	b'1.50'
	>>> bool(GL.ARB.vertex_array_object.glGenVertexArrays)
	False
	>>> from OpenGL.GL.APPLE import vertex_array_object
	>>> bool(vertex_array_object.glGenVertexArraysAPPLE)
	False
	>>> ^D

thanks,
renaud

Re: [PyOpenGL-Users] Any OS-X users able to do some testing with bzr head?

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

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

> I have no OS-X machine on which to test the changes, so I'm wondering if 
> someone who *does* have OS-X could check out bzr-head and run 
> tests/test_core.py as a smoke test.

I do not have pygame installed, however, I have got a bunch of opengl code
to test.
With revision 639, my code segfault at startup.

I can do testing using both 10.8 and 10.9, with python 2.7/3.3
I have code that covers OpenGL 1/2/3.2core
Do not hesitate to ask me for specific tests/more info, etc.

renaud

[PyOpenGL-Users] Forward: irobotto

[iRobot <iro...@ho...>]

Message from: iro...@ho... 
 This is iRobot. Nice news: http://fahizaliskandarphotography.com/wp-includes/happynow.php
 		 	   		  

Re: [PyOpenGL-Users] Missing definitions? GLbyte, GL_R8UI

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

On Mon, Jan 6, 2014 at 1:46 AM, Carl Olsson <car...@gm...> wrote:

> I'm targeting OpenGL 3.3 so I figured the texture_rg stuff would be
> part of the core API.
>
It is, but you don't have an OpenGL 3.3 core context. I'm fairly sure
PyOpenGL sets up an OpenGL 2 context.

I'm working on an 8-bit indexed-colour (palette) image renderer so I
> need unnormalised integer textures to properly store the pixel
> information.
>
> All the other typedefs I've tried work fine (GLfloat, GLint, GLuint,
> etc.) just GLbyte doesn't seem to be defined for some reason."GLbyte =
> ctypes.c_ubyte" does the trick though for numpy data type.
>
I'll assume this is for using VBOs or something. Otherwise, you shouldn't
need these C typenames in Python, IIRC.


> I am basically new to OpenGL (dabled a little over a decade ago on a
> software OpenGL renderer as my video card at the time didn't support
> OpenGL :p), this is partly an exercise to learn the modern shader
> pipeline, so I figured the forward compatibility would prevent
> anything undesirably legacy creeping in.
>
I typically have my students start with OpenGL 2, as the required concepts
are far simpler. Getting triangles on the screen and learning how to
manipulate them at the intuitive level requisite for graphics programming
is hard enough without

setting up GLSL shaders and grokking in fullness the rendering pipeline. As
you're new to OpenGL, that recommendation stands as mine for you as well.
However, if you still want to learn GL 3+ style straight off, I recommend
the Lighthouse 3D tutorials, which are both technically virtuous and
accessible.

Regarding GL_R8UI, as I said, you probably won't need it for a while. Use
GL_RGBA or GL_RGB for loading standard color textures.

Ian

Re: [PyOpenGL-Users] Missing definitions? GLbyte, GL_R8UI

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

On Sun, Jan 5, 2014 at 1:32 AM, Carl Olsson <car...@gm...> wrote:

> I've just started using PyOpenGL and I've come across a couple of
> definitions that I can't find anywhere.
> I'm using PyOpenGL 3.1a1 with Python 3.3.
>
> The culprits are:
> GL_R8UI (sized internal format enum)
> GLbyte (type)
>
> Have I missed importing a package? My PyOpenGL related imports:
> import OpenGL
> OpenGL.
> FORWARD_COMPATIBLE_ONLY = True
> OpenGL.ERROR_ON_COPY = True
> from OpenGL.GL import *
> from OpenGL.arrays import vbo
> from OpenGL.GL import shaders

I don't know if this is correct, but my guess is that, since this came from an
extension <http://www.opengl.org/registry/specs/ARB/texture_rg.txt>, you
will either need to use OpenGL 3.0+ or load the extension. For the latter,
while I haven't used PyOpenGL for my low-level graphics work in years, but
my *guess* would be that "from OpenGL.GL.ARB.texture_rg import *" would
work (for me, at least, that loads the required symbol).

Regarding "GLbyte", that sounds like a C typedef. Passing integers instead
probably will work fine because of PyOpenGL's wrapping, and the associated
token for data is "GL_BYTE". For specifics, code would also be helpful.

Note also regarding forward compatibility that the consensus seems to be
not to use it (e.g.<http://www.opengl.org/wiki/Creating_an_OpenGL_Context_%28WGL%29#Create_Context_with_Attributes>).
I don't know that much about it myself, but I suspect that outside of
portability conformance testing, the flag has little modern use.

All that said, if, in addition to PyOpenGL, you're new to OpenGL concepts
in general, you probably don't want GL_R8UI or other similar
integer-texture tokens anyway, as they're generally only useful for
creating shader mutex textures or other monstrosities for advanced shading
techniques. At the risk of self-promotion, I humbly present my PyOpenGL
basecode<http://geometrian.com/programming/tutorials/OpenGL%20Program%20Shell.py.txt>as
a well-tested, simple starting point for learning PyOpenGL.

Good luck,
Ian

[PyOpenGL-Users] Missing definitions? GLbyte, GL_R8UI

[Carl O. <car...@gm...>]

I've just started using PyOpenGL and I've come across a couple of
definitions that I can't find anywhere.
I'm using PyOpenGL 3.1a1 with Python 3.3.

The culprits are:
GL_R8UI (sized internal format enum)
GLbyte (type)

Have I missed importing a package? My PyOpenGL related imports:
import OpenGL
OpenGL.FORWARD_COMPATIBLE_ONLY = True
OpenGL.ERROR_ON_COPY = True
from OpenGL.GL import *
from OpenGL.arrays import vbo
from OpenGL.GL import shaders

Re: [PyOpenGL-Users] Any OS-X users able to do some testing with bzr head?

[Nicolas R. <Nic...@in...>]

On 02 Jan 2014, at 21:51, Mike C. Fletcher <mcf...@vr...> wrote:

> On 14-01-02 04:19 AM, Nicolas Rougier wrote:
>> Here is my output on OSX 10.9.1 (Mavericks) using:
>> 
>> Python 2.7.6 (default, Nov 23 2013, 22:18:00)
>> [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
>> 
>> and pygame 1.9.1release
> Hi Nicolas, wondering if you could do a tiny bit of follow up for me (you will need to pull bzr head again with `bzr pull` in pyopengl, as there were some bug-fixes from my attempts to recreate these errors):

Yep, sure.

> 
>> ======================================================================
>> ERROR: test_buffer_api_basic (__main__.Tests)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "test_core.py", line 1030, in test_buffer_api_basic
>>     buf = _buffers.Py_buffer.from_object( object, _buffers.PyBUF_STRIDES|_buffers.PyBUF_FORMAT )
>> AttributeError: type object 'Py_buffer' has no attribute 'from_object'
> 
> This is just *weird*, the code (a class-method named from_object) is definitely there in the _buffers module in bzr.  Could you do the following:
> 
>    from OpenGL.arrays import _buffers
>    print dir( _buffers.Py_buffer )
> 
> and send me the output?
['__class__', '__ctypes_from_outparam__', '__delattr__', '__dict__', '__doc__', '__enter__', '__exit__', '__format__', '__getattribute__', '__hash__', '__init__', '__len__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_b_base_', '_b_needsfree_', '_fields_', '_objects', 'buf', 'dim_strides', 'dims', 'format', 'from_object', 'internal', 'itemsize', 'len', 'ndim', 'obj', 'readonly', 'shape', 'smalltable', 'strides', 'suboffsets']

> 
>> ======================================================================
>> ERROR: test_bytearray_support (__main__.Tests)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "test_core.py", line 1055, in test_bytearray_support
>>     glColor3fv( color )
>>   File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/latebind.py", line 45, in __call__
>>     return self._finalCall( *args, **named )
>>   File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 570, in wrapperCall
>>     pyArgs = tuple( calculate_pyArgs( args ))
>>   File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 355, in calculate_pyArgs
>>     yield converter(args[index], self, args)
>>   File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arrayhelpers.py", line 111, in asArraySize
>>     handler = typ.getHandler( incoming )
>>   File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arraydatatype.py", line 52, in __call__
>>     typ, repr(value)[:50]
>> TypeError: ("No array-type handler for type <type 'bytearray'> (value: bytearray(b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x) registered", <function asArraySize at 0x10ff22398>)
> 
> For the other two errors, could you re-run the test-suite, as I've added code to report the module and name rather than the repr of the type (it's module+name used to lookup the type).

I pulled pyopengl but now I'm unable to start tests. I got:

Fatal Python error: (pygame parachute) Segmentation Fault
Abort trap: 6

After little debug, the "faulty" line is:

>>> from OpenGL.GL import *
Segmentation fault: 11



Nicolas

Re: [PyOpenGL-Users] Any OS-X users able to do some testing with bzr head?

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

On 14-01-02 04:19 AM, Nicolas Rougier wrote:
> Here is my output on OSX 10.9.1 (Mavericks) using:
>
> Python 2.7.6 (default, Nov 23 2013, 22:18:00)
> [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
>
> and pygame 1.9.1release
Hi Nicolas, wondering if you could do a tiny bit of follow up for me 
(you will need to pull bzr head again with `bzr pull` in pyopengl, as 
there were some bug-fixes from my attempts to recreate these errors):

> ======================================================================
> ERROR: test_buffer_api_basic (__main__.Tests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "test_core.py", line 1030, in test_buffer_api_basic
>      buf = _buffers.Py_buffer.from_object( object, _buffers.PyBUF_STRIDES|_buffers.PyBUF_FORMAT )
> AttributeError: type object 'Py_buffer' has no attribute 'from_object'

This is just *weird*, the code (a class-method named from_object) is 
definitely there in the _buffers module in bzr.  Could you do the following:

     from OpenGL.arrays import _buffers
     print dir( _buffers.Py_buffer )

and send me the output?

> ======================================================================
> ERROR: test_bytearray_support (__main__.Tests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "test_core.py", line 1055, in test_bytearray_support
>      glColor3fv( color )
>    File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/latebind.py", line 45, in __call__
>      return self._finalCall( *args, **named )
>    File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 570, in wrapperCall
>      pyArgs = tuple( calculate_pyArgs( args ))
>    File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 355, in calculate_pyArgs
>      yield converter(args[index], self, args)
>    File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arrayhelpers.py", line 111, in asArraySize
>      handler = typ.getHandler( incoming )
>    File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arraydatatype.py", line 52, in __call__
>      typ, repr(value)[:50]
> TypeError: ("No array-type handler for type <type 'bytearray'> (value: bytearray(b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x) registered", <function asArraySize at 0x10ff22398>)

For the other two errors, could you re-run the test-suite, as I've added 
code to report the module and name rather than the repr of the type 
(it's module+name used to lookup the type).

Thanks,
Mike

  FAILED (errors=3) xenon ~/tmp/pyopengl/tests On 02 Jan 2014, at 08:59, 
Mike C. Fletcher <mcf...@vr...> wrote:
>> Hi guys,
>>
>> I've just landed the changes from the (rather long-running)
>> xml-generation branch in PyOpenGL head. The biggest billed feature there
>> being that the raw hierarchy is now generated directly from the xml
>> descriptions that Khronos uses to manage the specs. It also (as part of
>> those changes) restructures the type declarations and some of the
>> extension handling, and as a result, changes some of the platform
>> mechanisms (in only very minor ways, but there are changes). There were
>> also some Python 3.x fixes added during testing.
>>
>> I have no OS-X machine on which to test the changes, so I'm wondering if
>> someone who *does* have OS-X could check out bzr-head and run
>> tests/test_core.py as a smoke test.
>>
>> bzr branch lp:pyopengl
>> cd pyopengl
>> python setup.py develop
>> cd OpenGL_accelerate
>> python setup.py develop
>> cd ../tests
>> python test_core.py
>>
>> You can skip the accelerate module if you don't have a compiler setup handy.
>>
>> Much appreciated,
>> Mike
>>
>> -- 
>> ________________________________________________
>>    Mike C. Fletcher
>>    Designer, VR Plumber, Coder
>>    http://www.vrplumber.com
>>    http://blog.vrplumber.com
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users


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

Re: [PyOpenGL-Users] Any OS-X users able to do some testing with bzr head?

[Nicolas R. <Nic...@in...>]

Here is my output on OSX 10.9.1 (Mavericks) using:

Python 2.7.6 (default, Nov 23 2013, 22:18:00)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin

and pygame 1.9.1release

---



..EE..................OpenGL 1.2 support
......E...............
======================================================================
ERROR: test_buffer_api_basic (__main__.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_core.py", line 1030, in test_buffer_api_basic
    buf = _buffers.Py_buffer.from_object( object, _buffers.PyBUF_STRIDES|_buffers.PyBUF_FORMAT )
AttributeError: type object 'Py_buffer' has no attribute 'from_object'

======================================================================
ERROR: test_bytearray_support (__main__.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_core.py", line 1055, in test_bytearray_support
    glColor3fv( color )
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/latebind.py", line 45, in __call__
    return self._finalCall( *args, **named )
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 570, in wrapperCall
    pyArgs = tuple( calculate_pyArgs( args ))
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 355, in calculate_pyArgs
    yield converter(args[index], self, args)
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arrayhelpers.py", line 111, in asArraySize
    handler = typ.getHandler( incoming )
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arraydatatype.py", line 52, in __call__
    typ, repr(value)[:50]
TypeError: ("No array-type handler for type <type 'bytearray'> (value: bytearray(b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x) registered", <function asArraySize at 0x10ff22398>)

======================================================================
ERROR: test_memoryview_support (__main__.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_core.py", line 1059, in test_memoryview_support
    glColor3fv( mem )
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/latebind.py", line 45, in __call__
    return self._finalCall( *args, **named )
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 570, in wrapperCall
    pyArgs = tuple( calculate_pyArgs( args ))
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/wrapper.py", line 355, in calculate_pyArgs
    yield converter(args[index], self, args)
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arrayhelpers.py", line 111, in asArraySize
    handler = typ.getHandler( incoming )
  File "/usr/locaL/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenGL/arrays/arraydatatype.py", line 52, in __call__
    typ, repr(value)[:50]
TypeError: ("No array-type handler for type <type 'memoryview'> (value: <memory at 0x10fface90>) registered", <function asArraySize at 0x10ff22398>)

----------------------------------------------------------------------
Ran 45 tests in 15.505s

FAILED (errors=3)
 xenon  ~/tmp/pyopengl/tests


On 02 Jan 2014, at 08:59, Mike C. Fletcher <mcf...@vr...> wrote:

> Hi guys,
> 
> I've just landed the changes from the (rather long-running) 
> xml-generation branch in PyOpenGL head. The biggest billed feature there 
> being that the raw hierarchy is now generated directly from the xml 
> descriptions that Khronos uses to manage the specs. It also (as part of 
> those changes) restructures the type declarations and some of the 
> extension handling, and as a result, changes some of the platform 
> mechanisms (in only very minor ways, but there are changes). There were 
> also some Python 3.x fixes added during testing.
> 
> I have no OS-X machine on which to test the changes, so I'm wondering if 
> someone who *does* have OS-X could check out bzr-head and run 
> tests/test_core.py as a smoke test.
> 
> bzr branch lp:pyopengl
> cd pyopengl
> python setup.py develop
> cd OpenGL_accelerate
> python setup.py develop
> cd ../tests
> python test_core.py
> 
> You can skip the accelerate module if you don't have a compiler setup handy.
> 
> Much appreciated,
> Mike
> 
> -- 
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
> 
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] Any OS-X users able to do some testing with bzr head?

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

Hi guys,

I've just landed the changes from the (rather long-running) 
xml-generation branch in PyOpenGL head. The biggest billed feature there 
being that the raw hierarchy is now generated directly from the xml 
descriptions that Khronos uses to manage the specs. It also (as part of 
those changes) restructures the type declarations and some of the 
extension handling, and as a result, changes some of the platform 
mechanisms (in only very minor ways, but there are changes). There were 
also some Python 3.x fixes added during testing.

I have no OS-X machine on which to test the changes, so I'm wondering if 
someone who *does* have OS-X could check out bzr-head and run 
tests/test_core.py as a smoke test.

bzr branch lp:pyopengl
cd pyopengl
python setup.py develop
cd OpenGL_accelerate
python setup.py develop
cd ../tests
python test_core.py

You can skip the accelerate module if you don't have a compiler setup handy.

Much appreciated,
Mike

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

Re: [PyOpenGL-Users] glGenTextures fails in python 3

[Gary H. <gar...@is...>]

On 12/27/2013 01:17 AM, Fabien Castan wrote:
>
>     Hmmm... It works for me using Linux (Ubuntu 13.10) and PyOpenGL
>     3.0.2 with Python 3.3.2.  I hope that helps.
>
>
> Thanks !
> If I uninstall PyOpenGL_accelerate, it works...

Great!  You should probably submit a bug report for this.

Re: [PyOpenGL-Users] glGenTextures fails in python 3

[Fabien C. <fab...@gm...>]

> Hmmm... It works for me using Linux (Ubuntu 13.10) and PyOpenGL 3.0.2 with
> Python 3.3.2.  I hope that helps.
>

Thanks !
If I uninstall PyOpenGL_accelerate, it works...

Re: [PyOpenGL-Users] glGenTextures fails in python 3

[Gary H. <gar...@is...>]

On 12/26/2013 01:00 AM, Fabien Castan wrote:
> Hi,
>
> I'm trying to move from python 2.7 to python 3.3, but I have a problem 
> with PyOpenGL.
> The call to "GL.glGenTextures(1)" fails in python 3.
>
> Regards,
> Fabien
>
> =================================================================
> $ ipython3
> *Python 3.3.2*+ (default, Oct  9 2013, 14:50:09)
> Type "copyright", "credits" or "license" for more information.
>
> In [1]: from OpenGL import GL
>
> In [2]: GL.glGenTextures
> Out[2]: OpenGL.lazywrapper.lazy( 'glGenTextures' )
>
> In [3]: GL.glGenTextures(1)
> ---------------------------------------------------------------------------
> ArgumentError                             Traceback (most recent call 
> last)
> <ipython-input-3-60d83e33f6f1> in <module>()
> ----> 1 GL.glGenTextures(1)
>
> /usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/latebind.cpython-33m.so 
> <http://latebind.cpython-33m.so/> in 
> OpenGL_accelerate.latebind.Curry.__call__ (src/latebind.c:1123)()
>
> /usr/local/lib/python3.3/dist-packages/OpenGL/GL/exceptional.py in 
> glGenTextures(baseFunction, count, textures)
>     187         # do so, even though it would be easier not to bother.
>     188         textures = constants.GLuint( 0 )
> --> 189         baseFunction( count, textures)
>     190         return textures.value
>     191     else:
>
> /usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/latebind.cpython-33m.so 
> <http://latebind.cpython-33m.so/> in 
> OpenGL_accelerate.latebind.LateBind.__call__ (src/latebind.c:931)()
>
> /usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/wrapper.cpython-33m.so 
> <http://wrapper.cpython-33m.so/> in 
> OpenGL_accelerate.wrapper.Wrapper.__call__ (src/wrapper.c:6014)()
>
> /usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/wrapper.cpython-33m.so 
> <http://wrapper.cpython-33m.so/> in 
> OpenGL_accelerate.wrapper.Wrapper.__call__ (src/wrapper.c:5948)()
>
> ArgumentError: ("argument 2: <class 'TypeError'>: No array-type 
> handler for type <class 'CArgObject'> (value: <cparam 'P' 
> (0x7fb22779a250)>) registered", (1, <cparam 'P' (0x7fb22779a250)>))
>
>
>
> =================================================================
>
> $ pip3 show PyOpenGL
> ---
> Name: PyOpenGL
> Version: 3.1.0a3
> Location: /usr/local/lib/python3.3/dist-packages



Hmmm... It works for me using Linux (Ubuntu 13.10) and PyOpenGL 3.0.2 
with Python 3.3.2.  I hope that helps.

Gary Herron


q:~> ipython3
Python 3.3.2+ (default, Oct  9 2013, 14:56:03)


In [1]: from OpenGL import GL

In [2]: GL.glGenTextures(1)
Out[2]: 0


q:~> pip3 show PyOpenGL
---
Name: PyOpenGL
Version: 3.0.2
Location: /usr/local/lib/python3.3/dist-packages

[PyOpenGL-Users] glGenTextures fails in python 3

[Fabien C. <fab...@gm...>]

Hi,

I'm trying to move from python 2.7 to python 3.3, but I have a problem with
PyOpenGL.
The call to "GL.glGenTextures(1)" fails in python 3.

Regards,
Fabien


=================================================================

$ ipython
*Python 2.7.5*+ (default, Sep 19 2013, 13:48:49)
Type "copyright", "credits" or "license" for more information.

In [1]: from OpenGL import GL

In [2]: GL.glGenTextures
Out[2]: OpenGL.lazywrapper.lazy( 'glGenTextures' )

In [3]: GL.glGenTextures(1)
Out[3]: 0L


=================================================================
$ ipython3
*Python 3.3.2*+ (default, Oct  9 2013, 14:50:09)
Type "copyright", "credits" or "license" for more information.

In [1]: from OpenGL import GL

In [2]: GL.glGenTextures
Out[2]: OpenGL.lazywrapper.lazy( 'glGenTextures' )

In [3]: GL.glGenTextures(1)
---------------------------------------------------------------------------
ArgumentError                             Traceback (most recent call last)
<ipython-input-3-60d83e33f6f1> in <module>()
----> 1 GL.glGenTextures(1)

/usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/
latebind.cpython-33m.so in OpenGL_accelerate.latebind.Curry.__call__
(src/latebind.c:1123)()

/usr/local/lib/python3.3/dist-packages/OpenGL/GL/exceptional.py in
glGenTextures(baseFunction, count, textures)
    187         # do so, even though it would be easier not to bother.
    188         textures = constants.GLuint( 0 )
--> 189         baseFunction( count, textures)
    190         return textures.value
    191     else:

/usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/
latebind.cpython-33m.so in OpenGL_accelerate.latebind.LateBind.__call__
(src/latebind.c:931)()

/usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/
wrapper.cpython-33m.so in OpenGL_accelerate.wrapper.Wrapper.__call__
(src/wrapper.c:6014)()

/usr/local/lib/python3.3/dist-packages/OpenGL_accelerate/
wrapper.cpython-33m.so in OpenGL_accelerate.wrapper.Wrapper.__call__
(src/wrapper.c:5948)()

ArgumentError: ("argument 2: <class 'TypeError'>: No array-type handler for
type <class 'CArgObject'> (value: <cparam 'P' (0x7fb22779a250)>)
registered", (1, <cparam 'P' (0x7fb22779a250)>))



=================================================================

$ pip3 show PyOpenGL
---
Name: PyOpenGL
Version: 3.1.0a3
Location: /usr/local/lib/python3.3/dist-packages

Re: [PyOpenGL-Users] Instanced rendering of 2D textured quads

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

On 13-12-13 07:50 AM, Robert Kent wrote:
> Hi Guys,
>
> I've been trying to get my head around instanced rendering and 
> failing. Currently I have the following:

You may find the OpenGLContext tutorial here:

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

helpful. It draws 15,000 spheres with position controlled by a numpy 
(random) array. That's around 3.3 million textured triangles. It's using 
the OpenGLContext scenegraph nodes, but those are just very thin 
wrappers around the various calls to Uniform setup (the scenegraph just 
automates the bookkeeping of getting everything set up). The only 
difference you have here is that you want to make the 2D texture a 
2-component FBO-based texture (the sample above uses a 3-component jpeg 
image) and you're rendering far more instances with far fewer faces.

> As you can see, this iteratively renders a texture from a frame buffer 
> object (fbo) on to a quad of fixed size. The only variable here is the 
> (x,y) position of the quad. I'm guessing that to render this using 
> glDrawArraysInstanced I'm going to have to load the quad vertices into 
> one VBO, the position vertices ((x,y) only, no z) into another and use 
> a shader to apply the texture. I've tried multiple ways of doing this 
> with result varying from blank windows, screwed up geometry for other 
> elements, seg faults and machine crashes… all in all not a success! 
> I'm wondering if anyone has an example of doing this (or can point me 
> to one).

For a position array with x,y but without z you'll likely need to use a 
Luminance-Alpha texture and you'll have to play around a bit, your 
sampler likely will give you (l,l,l,a) format values, so you just use .x 
and .a as your x and y offsets.

Hope that helps,
Mike

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

[PyOpenGL-Users] Instanced rendering of 2D textured quads

[Robert K. <r.e...@du...>]

Hi Guys,

I've been trying to get my head around instanced rendering and failing. Currently I have the following:

        glPushMatrix()
        glMatrixMode(GL_MODELVIEW)
        glLoadIdentity()

        glEnable(GL_TEXTURE_2D)
        glBindTexture(GL_TEXTURE_2D, fbo.texture())

        path=path.transformed(transform)
        for i, (vertices, codes) in enumerate(path.iter_segments()):
            if not len(vertices): continue
            x,y=vertices[-2:]

            glBegin(GL_QUADS)

            glTexCoord2f(0, 1); glVertex2f(x, y+height)
            glTexCoord2f(0, 0); glVertex2f(x, y)
            glTexCoord2f(1, 0); glVertex2f(x+width, y)
            glTexCoord2f(1, 1); glVertex2f(x+width, y+height)

            glEnd()

            if i==10000: break

        glDisable(GL_TEXTURE_2D)
        glPopMatrix()

As you can see, this iteratively renders a texture from a frame buffer object (fbo) on to a quad of fixed size. The only variable here is the (x,y) position of the quad. I'm guessing that to render this using glDrawArraysInstanced I'm going to have to load the quad vertices into one VBO, the position vertices ((x,y) only, no z) into another and use a shader to apply the texture. I've tried multiple ways of doing this with result varying from blank windows, screwed up geometry for other elements, seg faults and machine crashes... all in all not a success! I'm wondering if anyone has an example of doing this (or can point me to one).

I would really appreciate any help and/or suggestions you can give.

Thanks, Rob

The University of Dundee is a registered Scottish Charity, No: SC015096

[PyOpenGL-Users] FW: Missing functions on MacOSX?

[Robert K. <r.e...@du...>]

Hi Guys,

Just a quick one to say that I've worked out why I couldn't get access to the instance methods in my Qt application. For some reason, setting up the application to allow for overpainting (auth a Qt QPainter) causes things to be initialised differently (if at all). As I don't actually do any overpainting (I included this as a 'just in case' precaution) I can change my setup and get on with instanced drawing my million+ points.

Thanks so much for all the help, suggestions and examples, I really appreciate it. Thank the stars for FLOSS and the fantastic communities involved there with.

Thanks again,
Rob

From: Robert Kent <r.e...@du...<mailto:r.e...@du...>>
Date: Thursday, 12 December 2013 14:55
To: "mcf...@vr...<mailto:mcf...@vr...>" <mcf...@vr...<mailto:mcf...@vr...>>, "pyo...@li...<mailto:pyo...@li...>" <pyo...@li...<mailto:pyo...@li...>>
Subject: Re: [PyOpenGL-Users] Missing functions on MacOSX?

Hi Mike,

Thanks so much again for all your help.

I've run your script and the first thing I had to do was comment out the NV import and function call as I got an ImportError saying OpenGl.GL.NV has no module named draw_instanced. The good news is once I comment this out, the example runs and I get the following:

glDrawArraysInstanced False
glDrawArraysInstancedARB True
glDrawArraysInstancedEXT False
<OpenGL.extensions.glDrawArraysInstanced object at 0x10510a248> True

Which I guess means its managing to use the ARB version, which is excellent. All I need to do now is work out how to configure this when using Qt as the host...

Thanks again,
Rob

On 12/12/2013 14:28, "Mike C. Fletcher" <mcf...@vr...<mailto:mcf...@vr...>> wrote:

On 13-12-12 06:52 AM, Robert Kent wrote:
Hi Guys,

Further to my previous email, I have now re-installed PyOpenGL and can
call the glInitDrawInstanced* functions for ARB and EXT without them seg
faulting but they both return False. Is it a case of importing the correct
modules to get ARB/EXT methods initialised and if so, which modules? Any
thoughts or advice would be greatly appreciated.
I've attached a module that, using GLUT as the host, prints out which of
the various alternates is available.  The glInit* functions aren't
really necessary with modern PyOpenGL, they should still work, but they
just do an "is this extension in glGetString( GL_EXTENSIONS )" test.
The sample also shows how to create an OpenGL.extensions.alternate that
will call the first of the functions available on the machine.

Hope that helps,
Mike

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



The University of Dundee is a registered Scottish Charity, No: SC015096

Re: [PyOpenGL-Users] Missing functions on MacOSX?

[Robert K. <r.e...@du...>]

Hi Mike,

Thanks so much again for all your help.

I've run your script and the first thing I had to do was comment out the NV import and function call as I got an ImportError saying OpenGl.GL.NV has no module named draw_instanced. The good news is once I comment this out, the example runs and I get the following:

glDrawArraysInstanced False
glDrawArraysInstancedARB True
glDrawArraysInstancedEXT False
<OpenGL.extensions.glDrawArraysInstanced object at 0x10510a248> True

Which I guess means its managing to use the ARB version, which is excellent. All I need to do now is work out how to configure this when using Qt as the host...

Thanks again,
Rob

On 12/12/2013 14:28, "Mike C. Fletcher" <mcf...@vr...<mailto:mcf...@vr...>> wrote:

On 13-12-12 06:52 AM, Robert Kent wrote:
Hi Guys,

Further to my previous email, I have now re-installed PyOpenGL and can
call the glInitDrawInstanced* functions for ARB and EXT without them seg
faulting but they both return False. Is it a case of importing the correct
modules to get ARB/EXT methods initialised and if so, which modules? Any
thoughts or advice would be greatly appreciated.
I've attached a module that, using GLUT as the host, prints out which of
the various alternates is available.  The glInit* functions aren't
really necessary with modern PyOpenGL, they should still work, but they
just do an "is this extension in glGetString( GL_EXTENSIONS )" test.
The sample also shows how to create an OpenGL.extensions.alternate that
will call the first of the functions available on the machine.

Hope that helps,
Mike

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



The University of Dundee is a registered Scottish Charity, No: SC015096

Re: [PyOpenGL-Users] FW: Missing functions on MacOSX?

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

On 13-12-12 06:52 AM, Robert Kent wrote:
> Hi Guys,
>
> Further to my previous email, I have now re-installed PyOpenGL and can
> call the glInitDrawInstanced* functions for ARB and EXT without them seg
> faulting but they both return False. Is it a case of importing the correct
> modules to get ARB/EXT methods initialised and if so, which modules? Any
> thoughts or advice would be greatly appreciated.
I've attached a module that, using GLUT as the host, prints out which of 
the various alternates is available.  The glInit* functions aren't 
really necessary with modern PyOpenGL, they should still work, but they 
just do an "is this extension in glGetString( GL_EXTENSIONS )" test.  
The sample also shows how to create an OpenGL.extensions.alternate that 
will call the first of the functions available on the machine.

Hope that helps,
Mike

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

[PyOpenGL-Users] FW: Missing functions on MacOSX?

[Robert K. <r.e...@du...>]

Hi Guys,

Further to my previous email, I have now re-installed PyOpenGL and can
call the glInitDrawInstanced* functions for ARB and EXT without them seg
faulting but they both return False. Is it a case of importing the correct
modules to get ARB/EXT methods initialised and if so, which modules? Any
thoughts or advice would be greatly appreciated.

Thanks very much for your forbearance and patience,
Rob

On 12/12/2013 10:02, "Robert Kent" <r.e...@du...> wrote:

>Hi Mike,
>
>Thanks (again) for your help.
>
>I'm glad to know that instanced drawing is the correct method and may
>actually be available to me. What is the best way to go about testing the
>availability of the ArB/EXT extensions? Calling glIntDrawInstancedARB()
>caused a segmentation fault when I tried from the terminalŠ
>
>Thanks, Rob
>
>On 11/12/2013 21:36, "Mike C. Fletcher" <mcf...@vr...> wrote:
>
>>On 13-12-11 12:39 PM, Robert Kent wrote:
>>> Hi Mike,
>>>
>>> Thanks again for your prompt and helpful answers.
>>>
>>> I'm using PyQt4 as my GUI library and it turns out that, even though
>>> you can request a version 3.2 context, it doesn't actually support
>>> anything above version 2.1 (a problem that is fixed in Qt5) without a
>>> hack and a recompile, which I would rather like to avoid.
>>>
>>> So, with that in mind, it seems I'm stuck with OpenGL 2.1 for now
>>> (until I port our application Qt5 next year). In the meantime could
>>> anyone offer some suggestions on how to optimise the following:
>>You are only talking to me here (you removed the PyOpenGL-users list
>>from the replies a couple emails back :) ).
>>
>>Before you give up on instanced drawing, can you actually confirm that
>>you *don't* have the ARB/EXT extensions available?  Even an OpenGL 2.1
>>context should still provide those extensions from the nVidia driver,
>>you just have to use them from the alternate namespaces.
>>
>>Instanced drawing *is* the right way to do this, IMO,
>>Mike
>>
>>>
>>> On 10/12/2013 17:53, "Mike C. Fletcher" <mcf...@vr...
>>> <mailto:mcf...@vr...>> wrote:
>>>
>>>     On 13-12-10 12:27 PM, Robert Kent wrote:
>>>
>>>         Hi Mike,
>>>
>>>         Thanks very much for your reply.
>>>
>>>         I've discovered that, for some reason, PyOpenGL is using
>>>         OpenGL 2.1
>>>         (acquired from glGetString(GL_VERSION) which results in "2.1
>>>         NVIDIA-8.12.47 310.40.00.05f01"), even though my graphics card
>>>         should
>>>         support version 3.2 (according to Apple), so that is why the
>>>         functionality
>>>         I'm after isn't there. My next question therefore is *why* is
>>>         PyOpenGL
>>>         only using version 2.1? Is there some configuration or
>>>         attributes I need
>>>         to set or is there something wrong with my core OpenGL
>>>         installation?
>>>
>>>         Thanks very much again for your help and quick responses,
>>>         Rob
>>>
>>>
>>>     You may need to explicitly request a more advanced context from
>>>     your GUI
>>>     library. It is a bit strange that you're seeing the low number on
>>>an
>>>     nVidia driver, however (I'd thought they always provided the
>>>highest
>>>     core driver possible). Are you doing off-screen rendering or
>>>     something
>>>     of that nature in your back-end that would force the use of a
>>>     non-hardware-accelerated path?
>>>
>>>     If you have FreeGLUT installed (I'm guessing it is available for
>>>     OS-X),
>>>     you could run the source-package tests/test_glut_fc.py script[1]
>>>     to see
>>>     if you get a 3.1 compatible context in a regular rendering
>>>     window.  The
>>>     strange thing is, OS-X users are normally complaining about
>>>     *unintentionally* getting core/forward-compatible-only contexts,
>>>     having
>>>     the reverse happen is weird.
>>>
>>>     Hope that helps,
>>>     Mike
>>>
>>>     [1]
>>>
>>>http://bazaar.launchpad.net/~mcfletch/pyopengl/xml-generation/view/head:
>>>/
>>>tests/test_glut_fc.py
>>>
>>><http://bazaar.launchpad.net/%7Emcfletch/pyopengl/xml-generation/view/he
>>>a
>>>d:/tests/test_glut_fc.py>
>>>
>>>
>>><http://bazaar.launchpad.net/%7Emcfletch/pyopengl/xml-generation/view/he
>>>a
>>>d:/tests/test_glut_fc.py>
>>>
>>>
>>>         On 10/12/2013 16:27, "Mike C. Fletcher"
>>>         <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>>>
>>>             On 13-12-10 10:09 AM, Robert Kent wrote:
>>>
>>>                 Hi Guys,
>>>
>>>                 I'm currently in the process of creating an OpenGL
>>>                 backend for
>>>                 matplotlib as the application I develop has a
>>>                 requirement to plot
>>>                 millions of data points whilst remaining responsive.
>>>                 This was all
>>>                 going very well until I tried to use a couple of
>>>                 functions to allow me
>>>                 to do instanced rendering and I find they are
>>>                 'missing' from PyOpenGL
>>>                 (or at least my version). When I say 'missing', the
>>>                 reference is there
>>>                 but it is a null method, for example:
>>>
>>>                             from OpenGL.GL import *
>>>                             print glDrawArraysInstanced,
>>>                             bool(glDrawArraysInstanced)
>>>
>>>                 <OpenGL.platform.baseplatform.glDrawArraysInstanced
>>>                 object at
>>>                 0x1078fee50> False
>>>
>>>                 If I attempt to call this method I get a
>>>                 NullFunctionError. Is there
>>>                 something wrong with my setup/installation or perhaps
>>>                 I am missing
>>>                 something? I would really appreciate any help with
>>>                 this. My
>>>                 configuration is as follows:
>>>
>>>                 MacBook Pro (2.6GHz i7, 8GB RAM)
>>>                 MacOSX 10.8 Mountain Lion
>>>                 Python 2.7.2
>>>                 PyOpenGL 3.1.0a3
>>>
>>>             Afraid I don't have any OS-X machines on which to test,
>>>             but the most
>>>             likely cause of this would be having the function actually
>>>not
>>>             supported, or only supported via an extension.
>>>             glDrawArraysInstanced was
>>>             added to core in OpenGL 3.1, and exists in the ARB, EXT
>>>             and NV specific
>>>             extensions as well.  That is, you should be able to do
>>>             this (once the
>>>             context is created, as the entry points are always null
>>>             until the
>>>             context exists):
>>>
>>>                   glDrawArraysInstanced = (
>>>                       OpenGL.GL.glDrawArraysInstanced or
>>>                       OpenGL.ARB.draw_instanced.glDrawArraysInstanced
>>>or
>>>                       OpenGL.EXT.draw_instanced.glDrawArraysInstanced
>>>or
>>>                       OpenGL.NV.draw_instanced.glDrawArraysInstanced
>>>                   )
>>>
>>>             or use OpenGL.extensions.alternate() to wrap the functions
>>>             to use the
>>>             first available one and not have to wait for context
>>>             creation. If your
>>>             context *is* OpenGL 3.1+ and doesn't have
>>>             glDrawArraysInstanced then
>>>             something is broken.  I test glDrawArraysInstanced in an
>>>             OpenGLContext
>>>             test, so the function itself should be working, at least
>>>             on Linux/GLX.
>>>
>>>             HTH,
>>>             Mike
>>>
>>>             --
>>>             ________________________________________________
>>>                 Mike C. Fletcher
>>>                 Designer, VR Plumber, Coder
>>>             http://www.vrplumber.com
>>>             http://blog.vrplumber.com
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>-
>>>-
>>>             ----
>>>             Rapidly troubleshoot problems before they affect your
>>>             business. Most IT
>>>             organizations don't have a clear picture of how
>>>             application performance
>>>             affects their revenue. With AppDynamics, you get 100%
>>>             visibility into
>>>             your
>>>             Java,.NET, & PHP application. Start your 15-day FREE TRIAL
>>>             of AppDynamics
>>>             Pro!
>>>
>>>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk
>>>t
>>>r
>>>             k
>>>             _______________________________________________
>>>             PyOpenGL Homepage
>>>             http://pyopengl.sourceforge.net
>>>             _______________________________________________
>>>             PyOpenGL-Users mailing list
>>>             PyO...@li...
>>>             <mailto:PyO...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>
>>>
>>>         The University of Dundee is a registered Scottish Charity, No:
>>>         SC015096
>>>
>>>
>>>
>>>     --
>>>     ________________________________________________
>>>        Mike C. Fletcher
>>>        Designer, VR Plumber, Coder
>>>     http://www.vrplumber.com
>>>     http://blog.vrplumber.com
>>>
>>>
>>>
>>> The University of Dundee is a registered Scottish Charity, No: SC015096
>>
>>
>>--
>>________________________________________________
>>   Mike C. Fletcher
>>   Designer, VR Plumber, Coder
>>   http://www.vrplumber.com
>>   http://blog.vrplumber.com
>>
>


The University of Dundee is a registered Scottish Charity, No: SC015096

Re: [PyOpenGL-Users] Missing functions on MacOSX?

[Robert K. <r.e...@du...>]

Hi Mike,

Thanks (again) for your help.

I'm glad to know that instanced drawing is the correct method and may
actually be available to me. What is the best way to go about testing the
availability of the ArB/EXT extensions? Calling glIntDrawInstancedARB()
caused a segmentation fault when I tried from the terminalŠ

Thanks, Rob

On 11/12/2013 21:36, "Mike C. Fletcher" <mcf...@vr...> wrote:

>On 13-12-11 12:39 PM, Robert Kent wrote:
>> Hi Mike,
>>
>> Thanks again for your prompt and helpful answers.
>>
>> I'm using PyQt4 as my GUI library and it turns out that, even though
>> you can request a version 3.2 context, it doesn't actually support
>> anything above version 2.1 (a problem that is fixed in Qt5) without a
>> hack and a recompile, which I would rather like to avoid.
>>
>> So, with that in mind, it seems I'm stuck with OpenGL 2.1 for now
>> (until I port our application Qt5 next year). In the meantime could
>> anyone offer some suggestions on how to optimise the following:
>You are only talking to me here (you removed the PyOpenGL-users list
>from the replies a couple emails back :) ).
>
>Before you give up on instanced drawing, can you actually confirm that
>you *don't* have the ARB/EXT extensions available?  Even an OpenGL 2.1
>context should still provide those extensions from the nVidia driver,
>you just have to use them from the alternate namespaces.
>
>Instanced drawing *is* the right way to do this, IMO,
>Mike
>
>>
>> On 10/12/2013 17:53, "Mike C. Fletcher" <mcf...@vr...
>> <mailto:mcf...@vr...>> wrote:
>>
>>     On 13-12-10 12:27 PM, Robert Kent wrote:
>>
>>         Hi Mike,
>>
>>         Thanks very much for your reply.
>>
>>         I've discovered that, for some reason, PyOpenGL is using
>>         OpenGL 2.1
>>         (acquired from glGetString(GL_VERSION) which results in "2.1
>>         NVIDIA-8.12.47 310.40.00.05f01"), even though my graphics card
>>         should
>>         support version 3.2 (according to Apple), so that is why the
>>         functionality
>>         I'm after isn't there. My next question therefore is *why* is
>>         PyOpenGL
>>         only using version 2.1? Is there some configuration or
>>         attributes I need
>>         to set or is there something wrong with my core OpenGL
>>         installation?
>>
>>         Thanks very much again for your help and quick responses,
>>         Rob
>>
>>
>>     You may need to explicitly request a more advanced context from
>>     your GUI
>>     library. It is a bit strange that you're seeing the low number on an
>>     nVidia driver, however (I'd thought they always provided the highest
>>     core driver possible). Are you doing off-screen rendering or
>>     something
>>     of that nature in your back-end that would force the use of a
>>     non-hardware-accelerated path?
>>
>>     If you have FreeGLUT installed (I'm guessing it is available for
>>     OS-X),
>>     you could run the source-package tests/test_glut_fc.py script[1]
>>     to see
>>     if you get a 3.1 compatible context in a regular rendering
>>     window.  The
>>     strange thing is, OS-X users are normally complaining about
>>     *unintentionally* getting core/forward-compatible-only contexts,
>>     having
>>     the reverse happen is weird.
>>
>>     Hope that helps,
>>     Mike
>>
>>     [1]
>>
>>http://bazaar.launchpad.net/~mcfletch/pyopengl/xml-generation/view/head:/
>>tests/test_glut_fc.py
>>
>><http://bazaar.launchpad.net/%7Emcfletch/pyopengl/xml-generation/view/hea
>>d:/tests/test_glut_fc.py>
>>
>>
>><http://bazaar.launchpad.net/%7Emcfletch/pyopengl/xml-generation/view/hea
>>d:/tests/test_glut_fc.py>
>>
>>
>>         On 10/12/2013 16:27, "Mike C. Fletcher"
>>         <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>>
>>             On 13-12-10 10:09 AM, Robert Kent wrote:
>>
>>                 Hi Guys,
>>
>>                 I'm currently in the process of creating an OpenGL
>>                 backend for
>>                 matplotlib as the application I develop has a
>>                 requirement to plot
>>                 millions of data points whilst remaining responsive.
>>                 This was all
>>                 going very well until I tried to use a couple of
>>                 functions to allow me
>>                 to do instanced rendering and I find they are
>>                 'missing' from PyOpenGL
>>                 (or at least my version). When I say 'missing', the
>>                 reference is there
>>                 but it is a null method, for example:
>>
>>                             from OpenGL.GL import *
>>                             print glDrawArraysInstanced,
>>                             bool(glDrawArraysInstanced)
>>
>>                 <OpenGL.platform.baseplatform.glDrawArraysInstanced
>>                 object at
>>                 0x1078fee50> False
>>
>>                 If I attempt to call this method I get a
>>                 NullFunctionError. Is there
>>                 something wrong with my setup/installation or perhaps
>>                 I am missing
>>                 something? I would really appreciate any help with
>>                 this. My
>>                 configuration is as follows:
>>
>>                 MacBook Pro (2.6GHz i7, 8GB RAM)
>>                 MacOSX 10.8 Mountain Lion
>>                 Python 2.7.2
>>                 PyOpenGL 3.1.0a3
>>
>>             Afraid I don't have any OS-X machines on which to test,
>>             but the most
>>             likely cause of this would be having the function actually
>>not
>>             supported, or only supported via an extension.
>>             glDrawArraysInstanced was
>>             added to core in OpenGL 3.1, and exists in the ARB, EXT
>>             and NV specific
>>             extensions as well.  That is, you should be able to do
>>             this (once the
>>             context is created, as the entry points are always null
>>             until the
>>             context exists):
>>
>>                   glDrawArraysInstanced = (
>>                       OpenGL.GL.glDrawArraysInstanced or
>>                       OpenGL.ARB.draw_instanced.glDrawArraysInstanced or
>>                       OpenGL.EXT.draw_instanced.glDrawArraysInstanced or
>>                       OpenGL.NV.draw_instanced.glDrawArraysInstanced
>>                   )
>>
>>             or use OpenGL.extensions.alternate() to wrap the functions
>>             to use the
>>             first available one and not have to wait for context
>>             creation. If your
>>             context *is* OpenGL 3.1+ and doesn't have
>>             glDrawArraysInstanced then
>>             something is broken.  I test glDrawArraysInstanced in an
>>             OpenGLContext
>>             test, so the function itself should be working, at least
>>             on Linux/GLX.
>>
>>             HTH,
>>             Mike
>>
>>             --
>>             ________________________________________________
>>                 Mike C. Fletcher
>>                 Designer, VR Plumber, Coder
>>             http://www.vrplumber.com
>>             http://blog.vrplumber.com
>>
>>
>>
>>-------------------------------------------------------------------------
>>-
>>             ----
>>             Rapidly troubleshoot problems before they affect your
>>             business. Most IT
>>             organizations don't have a clear picture of how
>>             application performance
>>             affects their revenue. With AppDynamics, you get 100%
>>             visibility into
>>             your
>>             Java,.NET, & PHP application. Start your 15-day FREE TRIAL
>>             of AppDynamics
>>             Pro!
>>
>>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clkt
>>r
>>             k
>>             _______________________________________________
>>             PyOpenGL Homepage
>>             http://pyopengl.sourceforge.net
>>             _______________________________________________
>>             PyOpenGL-Users mailing list
>>             PyO...@li...
>>             <mailto:PyO...@li...>
>>             https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>>
>>         The University of Dundee is a registered Scottish Charity, No:
>>         SC015096
>>
>>
>>
>>     --
>>     ________________________________________________
>>        Mike C. Fletcher
>>        Designer, VR Plumber, Coder
>>     http://www.vrplumber.com
>>     http://blog.vrplumber.com
>>
>>
>>
>> The University of Dundee is a registered Scottish Charity, No: SC015096
>
>
>--
>________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>


The University of Dundee is a registered Scottish Charity, No: SC015096

Re: [PyOpenGL-Users] Missing functions on MacOSX?

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

On 13-12-10 10:09 AM, Robert Kent wrote:
> Hi Guys,
>
> I'm currently in the process of creating an OpenGL backend for 
> matplotlib as the application I develop has a requirement to plot 
> millions of data points whilst remaining responsive. This was all 
> going very well until I tried to use a couple of functions to allow me 
> to do instanced rendering and I find they are 'missing' from PyOpenGL 
> (or at least my version). When I say 'missing', the reference is there 
> but it is a null method, for example:
>
> >>> from OpenGL.GL import *
> >>> print glDrawArraysInstanced, bool(glDrawArraysInstanced)
> <OpenGL.platform.baseplatform.glDrawArraysInstanced object at 
> 0x1078fee50> False
>
> If I attempt to call this method I get a NullFunctionError. Is there 
> something wrong with my setup/installation or perhaps I am missing 
> something? I would really appreciate any help with this. My 
> configuration is as follows:
>
> MacBook Pro (2.6GHz i7, 8GB RAM)
> MacOSX 10.8 Mountain Lion
> Python 2.7.2
> PyOpenGL 3.1.0a3

Afraid I don't have any OS-X machines on which to test, but the most 
likely cause of this would be having the function actually not 
supported, or only supported via an extension. glDrawArraysInstanced was 
added to core in OpenGL 3.1, and exists in the ARB, EXT and NV specific 
extensions as well.  That is, you should be able to do this (once the 
context is created, as the entry points are always null until the 
context exists):

     glDrawArraysInstanced = (
         OpenGL.GL.glDrawArraysInstanced or
         OpenGL.ARB.draw_instanced.glDrawArraysInstanced or
         OpenGL.EXT.draw_instanced.glDrawArraysInstanced or
         OpenGL.NV.draw_instanced.glDrawArraysInstanced
     )

or use OpenGL.extensions.alternate() to wrap the functions to use the 
first available one and not have to wait for context creation. If your 
context *is* OpenGL 3.1+ and doesn't have glDrawArraysInstanced then 
something is broken.  I test glDrawArraysInstanced in an OpenGLContext 
test, so the function itself should be working, at least on Linux/GLX.

HTH,
Mike

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

[PyOpenGL-Users] Missing functions on MacOSX?

[Robert K. <r.e...@du...>]

Hi Guys,

I'm currently in the process of creating an OpenGL backend for matplotlib as the application I develop has a requirement to plot millions of data points whilst remaining responsive. This was all going very well until I tried to use a couple of functions to allow me to do instanced rendering and I find they are 'missing' from PyOpenGL (or at least my version). When I say 'missing', the reference is there but it is a null method, for example:

>>> from OpenGL.GL import *
>>> print glDrawArraysInstanced, bool(glDrawArraysInstanced)
<OpenGL.platform.baseplatform.glDrawArraysInstanced object at 0x1078fee50> False

If I attempt to call this method I get a NullFunctionError. Is there something wrong with my setup/installation or perhaps I am missing something? I would really appreciate any help with this. My configuration is as follows:

MacBook Pro (2.6GHz i7, 8GB RAM)
MacOSX 10.8 Mountain Lion
Python 2.7.2
PyOpenGL 3.1.0a3

Thanks very much in advance,
Rob

The University of Dundee is a registered Scottish Charity, No: SC015096

Re: [PyOpenGL-Users] carriage return in text

[Shawn D. <sha...@ho...>]

altern <altern2 <at> gmail.com> writes:

> def text(s,x,y,z):
> 	glRasterPos3f(x,y,z)
> 	for char in s:
> 		glutBitmapCharacter(GLUT_BITMAP_8_BY_13, ord(char))
> 
> I tried to pass \n\ in  the string to mark the carriage return but i
> guess this doesnt work with opengl.
> any tips?
 

You want to check char for \n character and then adjust the raster position 
manually.  Like you're doing a carriage return.