pyopengl-devel — Discussion of PyOpenGL development.

[PyOpenGL-Devel] [ pyopengl-Bugs-3127034 ] VBO deletion happening in another thread than Main thread

[SourceForge.net <no...@so...>]

Bugs item #3127034, was opened at 2010-12-03 19:00
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: VBO deletion happening in another thread than Main thread 

Initial Comment:
Hi pyopengl dudes,

I got a bug with VBO. It seem that the deletion of VBO (the one that involve glDeleteBuffers) is happening sometimes inside another thread than Main thread, and lead to a segfault.

I've added a call to threading.currentThread() + traceback.print_stack() just before the call of glDeleteBuffers() in arrays/vbo.py.
And normal case, i got: glDeleteBuffers() <_MainThread(MainThread, started 140737353901824)> + a traceback with last line very weird (like gc call...)
And the segfault case: glDeleteBuffers() <Thread(Thread-6, started daemon 140736902752016)>

Here is both traceback that look different : http://paste.pocoo.org/show/300045/ and http://paste.pocoo.org/show/300047/

It look like the callback of weakref.ref() is called when the object is deleted and finalized... but not in main thread.

Do you confirm this case ? Do you have any tips about how to do ?
I was thinking to use a Queue, and if the deletion happen outside the main thread, queuing the deletion for the next call. (tricky, but since pyopengl don't have clokc of callback from main thread...)

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-12-06 09:21

Message:
?? boggle ??  Okay, *that* is surprising.  AFAIK the weakref code is just
hooked into the DECREF counting so that iff count goes to < 1 then the
weakrefs are called, then the __del__ method.  I suppose somehow one of the
callbacks might allow a thread context switch... but that still seems
pretty exotic.  Don't suppose you have a small test-case that shows this?

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2010-12-05 12:11

Message:
Just to ensure you've understand me, i don't do any deletion of VBO in
another thread than main thread. I've a reference to the VBO in a class,
and when the class is gone, the vbo is gone too. All theses operations are
always executed in a main thread.

That's why i think this bug can happen as soon as you use thread in python
no ? And that's problematic :/

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-12-05 08:49

Message:
The appropriate way to delete a VBO in a multi-threaded situation is to
call .delete() on it in the rendering thread *before* you delete the VBO in
another thread.  The VBO's cleanup will then *not* delete the VBO. 
Anything I do to try to work around this will constrain the design of all
pyopengl applications.

That said, your approach would work fine (moving the deletions to the main
thread) for your application:

# non-render thread
for obj in objs_to_delete:
    remove_from_tree(obj)
    to_delete_queue.push( obj ) # no garbage collection here because of
this reference

# render thread
while: to_delete_queue:
    to_delete_queue.pop() # garbage collected and deleted here...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3127034 ] VBO deletion happening in another thread than Main thread

[SourceForge.net <no...@so...>]

Bugs item #3127034, was opened at 2010-12-04 00:00
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: VBO deletion happening in another thread than Main thread 

Initial Comment:
Hi pyopengl dudes,

I got a bug with VBO. It seem that the deletion of VBO (the one that involve glDeleteBuffers) is happening sometimes inside another thread than Main thread, and lead to a segfault.

I've added a call to threading.currentThread() + traceback.print_stack() just before the call of glDeleteBuffers() in arrays/vbo.py.
And normal case, i got: glDeleteBuffers() <_MainThread(MainThread, started 140737353901824)> + a traceback with last line very weird (like gc call...)
And the segfault case: glDeleteBuffers() <Thread(Thread-6, started daemon 140736902752016)>

Here is both traceback that look different : http://paste.pocoo.org/show/300045/ and http://paste.pocoo.org/show/300047/

It look like the callback of weakref.ref() is called when the object is deleted and finalized... but not in main thread.

Do you confirm this case ? Do you have any tips about how to do ?
I was thinking to use a Queue, and if the deletion happen outside the main thread, queuing the deletion for the next call. (tricky, but since pyopengl don't have clokc of callback from main thread...)

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2010-12-05 17:11

Message:
Just to ensure you've understand me, i don't do any deletion of VBO in
another thread than main thread. I've a reference to the VBO in a class,
and when the class is gone, the vbo is gone too. All theses operations are
always executed in a main thread.

That's why i think this bug can happen as soon as you use thread in python
no ? And that's problematic :/

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-12-05 13:49

Message:
The appropriate way to delete a VBO in a multi-threaded situation is to
call .delete() on it in the rendering thread *before* you delete the VBO in
another thread.  The VBO's cleanup will then *not* delete the VBO. 
Anything I do to try to work around this will constrain the design of all
pyopengl applications.

That said, your approach would work fine (moving the deletions to the main
thread) for your application:

# non-render thread
for obj in objs_to_delete:
    remove_from_tree(obj)
    to_delete_queue.push( obj ) # no garbage collection here because of
this reference

# render thread
while: to_delete_queue:
    to_delete_queue.pop() # garbage collected and deleted here...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3127034 ] VBO deletion happening in another thread than Main thread

[SourceForge.net <no...@so...>]

Bugs item #3127034, was opened at 2010-12-03 19:00
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: VBO deletion happening in another thread than Main thread 

Initial Comment:
Hi pyopengl dudes,

I got a bug with VBO. It seem that the deletion of VBO (the one that involve glDeleteBuffers) is happening sometimes inside another thread than Main thread, and lead to a segfault.

I've added a call to threading.currentThread() + traceback.print_stack() just before the call of glDeleteBuffers() in arrays/vbo.py.
And normal case, i got: glDeleteBuffers() <_MainThread(MainThread, started 140737353901824)> + a traceback with last line very weird (like gc call...)
And the segfault case: glDeleteBuffers() <Thread(Thread-6, started daemon 140736902752016)>

Here is both traceback that look different : http://paste.pocoo.org/show/300045/ and http://paste.pocoo.org/show/300047/

It look like the callback of weakref.ref() is called when the object is deleted and finalized... but not in main thread.

Do you confirm this case ? Do you have any tips about how to do ?
I was thinking to use a Queue, and if the deletion happen outside the main thread, queuing the deletion for the next call. (tricky, but since pyopengl don't have clokc of callback from main thread...)

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-12-05 08:49

Message:
The appropriate way to delete a VBO in a multi-threaded situation is to
call .delete() on it in the rendering thread *before* you delete the VBO in
another thread.  The VBO's cleanup will then *not* delete the VBO. 
Anything I do to try to work around this will constrain the design of all
pyopengl applications.

That said, your approach would work fine (moving the deletions to the main
thread) for your application:

# non-render thread
for obj in objs_to_delete:
    remove_from_tree(obj)
    to_delete_queue.push( obj ) # no garbage collection here because of
this reference

# render thread
while: to_delete_queue:
    to_delete_queue.pop() # garbage collected and deleted here...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3127034 ] VBO deletion happening in another thread than Main thread

[SourceForge.net <no...@so...>]

Bugs item #3127034, was opened at 2010-12-04 00:00
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: VBO deletion happening in another thread than Main thread 

Initial Comment:
Hi pyopengl dudes,

I got a bug with VBO. It seem that the deletion of VBO (the one that involve glDeleteBuffers) is happening sometimes inside another thread than Main thread, and lead to a segfault.

I've added a call to threading.currentThread() + traceback.print_stack() just before the call of glDeleteBuffers() in arrays/vbo.py.
And normal case, i got: glDeleteBuffers() <_MainThread(MainThread, started 140737353901824)> + a traceback with last line very weird (like gc call...)
And the segfault case: glDeleteBuffers() <Thread(Thread-6, started daemon 140736902752016)>

Here is both traceback that look different : http://paste.pocoo.org/show/300045/ and http://paste.pocoo.org/show/300047/

It look like the callback of weakref.ref() is called when the object is deleted and finalized... but not in main thread.

Do you confirm this case ? Do you have any tips about how to do ?
I was thinking to use a Queue, and if the deletion happen outside the main thread, queuing the deletion for the next call. (tricky, but since pyopengl don't have clokc of callback from main thread...)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988

Re: [PyOpenGL-Devel] pyopengl and pypy, one step further

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

i'm back again with some news: shaders are now working, it required a minor fix
of the StringLengths CConverter (in OpenGL/converters.py). the stringArrayForC 
method requires an explicit cast to make pypy ctypes version happy:

     def stringArrayForC( self, strings ):
         """Create a ctypes pointer to char-pointer set"""
         from OpenGL import arrays
         result = (ctypes.c_char_p * len(strings))()
         for i,s in enumerate(strings):
-            result[i] = arrays.GLcharARBArray.dataPointer(s)
+            result[i] = ctypes.cast(arrays.GLcharARBArray.dataPointer(s),
                                     ctypes.c_char_p)
         return result


now, the following programs run fine:
- 05-shader.py (partial shader-based implementation of the fixed pipeline)
- 06-perpixel.py (per-pixel lightening)
- 07-attrib.py (generic vertex attributes rather than pointers)
- 08-pbo.py (using pixel buffer object to read back pixels from framebuffer)

the last one does opengl à la opengles (without any fixed functionality) but
does not work yet.
this time, i think that it's pypy's fault :)

stay tuned,

renaud

Re: [PyOpenGL-Devel] pyopengl and pypy

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

i'm back with some progress.
got some help from pypy-dev:


1) the first issue (missing ctypes.pythonapi) was solved with the help of
pypy-dev. they suggested to replace the c functions by a pure ctype 
implementation (and not worry and the memory layout, since their ctypes module 
does "the right thing"):

PyString_asString can be avoided in OpenGL/array.string.py by using
    def dataPointer(value):
        return ctypes.cast(ctypes.create_string_buffer(value),
                           ctypes.c_void_p).value
or 
    def dataPointer(value):
        return ctypes.cast(ctypes.c_char_p(value), ctypes.c_void_p).value

PyBuffer_FromMemory can be implemented as (not tested though, since it's 
only used in experimental code for vbos):
    def PyBuffer_FromMemory(address, length):
        return buffer((ctypes.c_char * length).from_address(address))

if you want, i can provide a patch for those changes. in my tree of PyOpenGL i
have totally removed the references to ctypes.pythonapi and it uses the ctypes
version even for cpython. you might prefer to keep your implementation and just
add a fallback if ctypes.pythonapi is None.

the whole thread is there for reference:
<http://codespeak.net/pipermail/pypy-dev/2010q4/006452.html>


2) the second issue (missing _CDada_intput) is from pypy. the good news is that 
it has already been fixed by Amaury Forgeot d'Arc in the fast-forward branch 
(aiming at cpython 2.7 compatibility). the patch (requires some adaptation to 
apply on pypy-1.4) can be found there:
<http://codespeak.net/pipermail/pypy-svn/2010-November/045106.html>


so far, i have managed to partially run the programs of my small opengl 
tutorial, i.e. a sample program that use most of the functionalities of the
fixed pipeline and that is evolved step by step into a shader based 
implementation. what runs for the moment (with minor errors):
- 01-direct.py (direct rendering, some geometry + 3d texture)
- 02-displaylist.py
- 03-array.py (use of Vertex/.../NormalPointer)
- 04-vbo.py (idem + VBOs to pass the data)
what does not run: the rest that uses shaders, but i'm pretty confident it's a
minor issue (wrong types in glShaderSource arguments)

the programs are based on pyopengl and can be found here:
<http://bitbucket.org/rndblnch/opengl-programmable/>

Re: [PyOpenGL-Devel] pyopengl and pypy

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

Mike C. Fletcher <mcfletch <at> vrplumber.com> writes:
> I'm definitely interested, but have very little time these days to play
> with PyOpenGL.

ok, thanks for your lights.
i will digg into that/ask some guidance from pypy-dev.
i'll report any progress here.

renaud

Re: [PyOpenGL-Devel] pyopengl and pypy

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

On 10-11-26 07:54 PM, rndblnch wrote:
> hello,
>
> i'm trying to make my pyopengl(3.0.1)-based code run with pypy (1.4).
> i ran into some issues:
> 1) the use of ctypes.pythonapi (for PyString_AsString in arrays/strings.py and
> PyBuffer_FromMemory in arrays/vbo.py)
> 2) an "AttributeError: type object 'ArrayDatatype' has no attribute
> '_CData_input'", trackback:
> ...
>   File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/latebind.py", line
> 45, in __call__
>     return self._finalCall( *args, **named )
>   File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/wrapper.py", line
> 784, in wrapperCall
>     result = self.wrappedOperation( *cArguments )
>   File
> "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/platform/baseplatform.py",
> line 335, in __call__
>     return self( *args, **named )
>   File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 166,
> in __call__
>     argtypes, argsandobjs = self._wrap_args(argtypes, args)
>   File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 281,
> in _wrap_args
>     wrapped = argtype._CData_input(arg)
> AttributeError: type object 'ArrayDatatype' has no attribute '_CData_input'
>
> i guess that for 1) it should be possible to write pure ctypes/python
> replacements for the needed functions (any hints welcome :)
> for 2) i didn't manage to understand enough the relationship between pyopengl
> and ctypes to get any clue about what's going on.
>
> anybody with some experience with/interested by such issues?
>   
I'm definitely interested, but have very little time these days to play
with PyOpenGL.

There's a lot of machinery in PyOpenGL that produces the ctypes
array-wrapper functionality (in the OpenGL/arrays package for the most
part), but in the end, it's just doing standard ctypes calls about 95%
of the time.  Every once in a rare while I had to use an undocumented
implementation feature of ctypes, but I don't think that's the problem
here.  _CData_input looks to be something pypy-specific which would be
the equivalent of the from_param method on CPython ctypes?  I'm guessing
the pypy implementation assumes an inheritance relationship among all
data-types and that _CData_input is a method on their _CData class.  For
whatever reason, the subclasses of ctypes.POINTER( <constant-type> ) are
not picking up that method.

For the first issue, those are going to require some reworking, in
essence those are "C" implemented code that happens to use Python/ctypes
as the implementation language and makes assumptions about the
data-storage for the objects (e.g. that a string is internally a
contiguous series of bytes, which is *not necessarily* true in PyPy). 
We'd need to find a mechanism in PyPy that would give us that direct
memory-pointer access to be able to use it.  Note: a compacting garbage
collector (or anything else that can move memory locations) will cause
problems there, so we may need to find a way to signal PyPy not to move
a given object, and to use contiguous data-arrays for their storage.

HTH,
Mike

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

[PyOpenGL-Devel] pyopengl and pypy

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

hello,

i'm trying to make my pyopengl(3.0.1)-based code run with pypy (1.4).
i ran into some issues:
1) the use of ctypes.pythonapi (for PyString_AsString in arrays/strings.py and
PyBuffer_FromMemory in arrays/vbo.py)
2) an "AttributeError: type object 'ArrayDatatype' has no attribute
'_CData_input'", trackback:
...
  File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/latebind.py", line
45, in __call__
    return self._finalCall( *args, **named )
  File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/wrapper.py", line
784, in wrapperCall
    result = self.wrappedOperation( *cArguments )
  File
"/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/platform/baseplatform.py",
line 335, in __call__
    return self( *args, **named )
  File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 166,
in __call__
    argtypes, argsandobjs = self._wrap_args(argtypes, args)
  File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 281,
in _wrap_args
    wrapped = argtype._CData_input(arg)
AttributeError: type object 'ArrayDatatype' has no attribute '_CData_input'

i guess that for 1) it should be possible to write pure ctypes/python
replacements for the needed functions (any hints welcome :)
for 2) i didn't manage to understand enough the relationship between pyopengl
and ctypes to get any clue about what's going on.

anybody with some experience with/interested by such issues?

thanks for your help,

renaud

[PyOpenGL-Devel] [ pyopengl-Bugs-3042603 ] PyOpenGL Windows installer should be packaged with C Runtime

[SourceForge.net <no...@so...>]

Bugs item #3042603, was opened at 2010-08-10 11:53
Message generated for change (Comment added) made by d_rea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dana Rea (d_rea)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: PyOpenGL Windows installer should be packaged with C Runtime

Initial Comment:
Installation fails on Windows systems that don't include a copy of mscvr71.dll (the C runtime), KB326922 (http://support.microsoft.com/kb/326922) suggests that this file should be packaged with the installer. Can this be included in future versions (precluding any licensing issues)?

----------------------------------------------------------------------

>Comment By: Dana Rea (d_rea)
Date: 2010-10-18 11:17

Message:
I think that you can package vcredist (which installs these components)
without owning the paid version. 

I also wonder if there's a newer version of express that you can compile
with, python includes msvcr90, so at least that will be in the search path
when apps are run with python or pythonw.

If not, a quick note on this problem on the project page would really help
people sort through this.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-10-18 05:19

Message:
Last I looked, you need a paid version of MS Studio to be allowed to
package msvcr71.dll, I only have the free (express) version.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3081957 ] OpenGL.error.NullFunctionError: Attempt to call an undefined

[SourceForge.net <no...@so...>]

Bugs item #3081957, was opened at 2010-10-06 03:11
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GLUT
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined

Initial Comment:
Trying to run this simple example here:
http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html

I get:
C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate
WARNING:context:Python Image Library (PIL) not installed, no Image support available
http://www.pythonware.com/products/pil/index.htm
WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture'
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop
    render = cls( *args, **named)
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling


----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-10-18 08:57

Message:
Then you will need a 64-bit build of GLUT, I'm guessing.  FreeGLUT or
GLUT32 should work.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-10-18 05:31

Message:
This is Windows 7 x64 with 64-bit Python. The PyOpenGL installer does not
work with 64 bit Python (no installers do. see:
http://bugs.python.org/issue6792 )

Instead I did: easy_install pyopengl


----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-10-18 05:27

Message:
You are missing GLUT, though why I can't say, as it is supposed to be
installed with PyOpenGL in the windows installer.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-10-06 03:13

Message:
I installed PIL, but I still get:

C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler
accelerator from OpenGL_accelerate
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 154, in ContextMainLoop
    render = cls( *args, **named)
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File
"C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py",
line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function
glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3081957 ] OpenGL.error.NullFunctionError: Attempt to call an undefined

[SourceForge.net <no...@so...>]

Bugs item #3081957, was opened at 2010-10-06 07:11
Message generated for change (Comment added) made by ghazel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GLUT
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined

Initial Comment:
Trying to run this simple example here:
http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html

I get:
C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate
WARNING:context:Python Image Library (PIL) not installed, no Image support available
http://www.pythonware.com/products/pil/index.htm
WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture'
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop
    render = cls( *args, **named)
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling


----------------------------------------------------------------------

>Comment By: Greg Hazel (ghazel)
Date: 2010-10-18 09:31

Message:
This is Windows 7 x64 with 64-bit Python. The PyOpenGL installer does not
work with 64 bit Python (no installers do. see:
http://bugs.python.org/issue6792 )

Instead I did: easy_install pyopengl


----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-10-18 09:27

Message:
You are missing GLUT, though why I can't say, as it is supposed to be
installed with PyOpenGL in the windows installer.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-10-06 07:13

Message:
I installed PIL, but I still get:

C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler
accelerator from OpenGL_accelerate
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 154, in ContextMainLoop
    render = cls( *args, **named)
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File
"C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py",
line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function
glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3081957 ] OpenGL.error.NullFunctionError: Attempt to call an undefined

[SourceForge.net <no...@so...>]

Bugs item #3081957, was opened at 2010-10-06 03:11
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GLUT
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined

Initial Comment:
Trying to run this simple example here:
http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html

I get:
C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate
WARNING:context:Python Image Library (PIL) not installed, no Image support available
http://www.pythonware.com/products/pil/index.htm
WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture'
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop
    render = cls( *args, **named)
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling


----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-10-18 05:27

Message:
You are missing GLUT, though why I can't say, as it is supposed to be
installed with PyOpenGL in the windows installer.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-10-06 03:13

Message:
I installed PIL, but I still get:

C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler
accelerator from OpenGL_accelerate
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 154, in ContextMainLoop
    render = cls( *args, **named)
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File
"C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py",
line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function
glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3042603 ] PyOpenGL Windows installer should be packaged with C Runtime

[SourceForge.net <no...@so...>]

Bugs item #3042603, was opened at 2010-08-10 11:53
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dana Rea (d_rea)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: PyOpenGL Windows installer should be packaged with C Runtime

Initial Comment:
Installation fails on Windows systems that don't include a copy of mscvr71.dll (the C runtime), KB326922 (http://support.microsoft.com/kb/326922) suggests that this file should be packaged with the installer. Can this be included in future versions (precluding any licensing issues)?

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-10-18 05:19

Message:
Last I looked, you need a paid version of MS Studio to be allowed to
package msvcr71.dll, I only have the free (express) version.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-441873 ] glMultiTexCoord2*ARB failure

[SourceForge.net <no...@so...>]

Bugs item #441873, was opened at 2001-07-16 22:14
Message generated for change (Comment added) made by bourriquet42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=441873&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v2.0
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Tarn Weisner Burton (twburton)
Summary: glMultiTexCoord2*ARB failure

Initial Comment:
glMultiTexCoord2dARB doesn't seem to want to be called 
between glBegin and glEnd, seems as though there might 
be some GL function getting called in the wrapper that 
shouldn't be called there.

See OpenGLContext/tests/multitexture_1.py for testing 
code.  Far as I can see that's properly structured.

----------------------------------------------------------------------

Comment By: bourriquet42 (bourriquet42)
Date: 2010-10-08 08:22

Message:
The new bug has been opened here.
https://sourceforge.net/tracker/?func=detail&aid=2817196&group_id=5988&atid=105988

----------------------------------------------------------------------

Comment By: bourriquet42 (bourriquet42)
Date: 2010-10-07 18:39

Message:
It seems to not work anymore on latest versions.
I tried your code Nehe/lesson6-multi.py with PyOpenGL 3.0.1 and I keep
having the "invalid operation" message.

Jeremy

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-19 22:37

Message:
Logged In: YES 
user_id=21784

glBegin/glEnd extension problem fixed with new extension 
init functions.  Multitexture functionality verified to 
work with NeHe/lesson6-multi.py

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-17 08:56

Message:
Logged In: YES 
user_id=21784

Changed the name of the init function to 
glInitMultitextureARB to maintain naming consistency.

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-17 02:08

Message:
Logged In: YES 
user_id=21784

Initial fix is in CVS.  Only works on glActiveTextureARB 
and glMultiTexCoord2dARB.  Will require a bit more work to 
for rest of the extensions.

New proto added:

GL.ARB.multitexture.init_GL_ARB_multitexture()

which needs to be called to load GL_ARB_multitexture into 
the current context.

Also updated multitexture_1



----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2001-07-17 00:21

Message:
Logged In: YES 
user_id=34901

http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/opengl/hh/opengl/ntopnglr_6yer.asp  Says 
that you only need a lookup table per pixel-format (not 
much better, really).

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-17 00:01

Message:
Logged In: YES 
user_id=21784

This is serious.  WGL docs don't make any mention about 
wglGetProcAddress not being called in between glBegin and 
glEnd.  This is apparently the cause of the "invalid 
operation."  This is confirmed by GLX docs saying that GLX 
calls are not allowed between glBegin and glEnd.  In order 
to get around this I'm going to have to figure out a way to 
call wglGetProcAddress outside of glBegin/glEnd and store 
the address.  Since proc addresses are potentially context 
dependent this probably means I'll have to create a lookup 
table for each context.  Ugh!

Tarn 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=441873&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-2817196 ] regression: multitexturing broken in 3.0.0

[SourceForge.net <no...@so...>]

Bugs item #2817196, was opened at 2009-07-05 19:46
Message generated for change (Comment added) made by bourriquet42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew Straw (astraw)
Assigned to: Nobody/Anonymous (nobody)
Summary: regression: multitexturing broken in 3.0.0

Initial Comment:
I've been trying to track down a regression in multitexturing that happens on Windows with PyOpenGL3. I get the same issue with Python2.5 and Python2.6, and it goes away when I test on Python2.5 with PyOpenGL 2.0.2.01. I don't get this error on Linux.

Running the old NeHe demo "lesson6-multi.py" I found in a local copy of PyOpenGL-2.0.1.09 (in PyOpenGL-2.0.1.09/OpenGL/Demo/NeHe/), I get this traceback:

Z:\test>c:\python25\python lesson6-multi.py
Hit ESC key to quit.
Traceback (most recent call last):
  File "c:\python25\lib\site-packages\OpenGL\GLUT\special.py", line 113, in safe
Call
    return function( *args, **named )
  File "lesson6-multi.py", line 189, in DrawGLScene
    glEnd();                            # Done Drawing The Cube
  File "c:\python25\lib\site-packages\OpenGL\lazywrapper.py", line 9, in __call_
_
    return wrapper( baseFunction, *args, **named )
  File "c:\python25\lib\site-packages\OpenGL\GL\exceptional.py", line 57, in glE
nd
    return baseFunction( )
  File "c:\python25\lib\site-packages\OpenGL\error.py", line 194, in glCheckErro
r
    baseOperation = baseOperation,
GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glEnd,
        cArguments = ()
)
GLUT Idle callback <function DrawGLScene at 0x00D47830> with (),{} failed: retur
ning None GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glEnd,
        cArguments = ()
)


----------------------------------------------------------------------

Comment By: bourriquet42 (bourriquet42)
Date: 2010-10-08 08:20

Message:
Is there anything new about this issue?

----------------------------------------------------------------------

Comment By: Andrew Straw (astraw)
Date: 2010-02-25 13:42

Message:
Thanks for looking into this. I tried, but I got lost in the code. This is
important for the current and past incarnations of the Vision Egg library,
which is useful for vision research experiments. In the future, the VE will
move to shaders, but multi-texturing worked fine for years until PyOpenGL
3. I am happy to test.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-02-25 13:04

Message:
Urgh, *Windows*, sorry.  Guess I need to get over to windows to test this.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-02-25 13:03

Message:
Have just tested with the Demo/NeHe/lesson6-multi.py from PyOpenGL 2.0.1.09
with PyOpenGL 3.0.1 (about to be released).  Works as expected.  We also
have a PyOpenGL-Demo package which includes the updated version of the
demo, which works fine.  We have lots of other scripts that use
multi-texturing, both with the legacy and shader APIs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-441873 ] glMultiTexCoord2*ARB failure

[SourceForge.net <no...@so...>]

Bugs item #441873, was opened at 2001-07-16 22:14
Message generated for change (Comment added) made by bourriquet42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=441873&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v2.0
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Tarn Weisner Burton (twburton)
Summary: glMultiTexCoord2*ARB failure

Initial Comment:
glMultiTexCoord2dARB doesn't seem to want to be called 
between glBegin and glEnd, seems as though there might 
be some GL function getting called in the wrapper that 
shouldn't be called there.

See OpenGLContext/tests/multitexture_1.py for testing 
code.  Far as I can see that's properly structured.

----------------------------------------------------------------------

Comment By: bourriquet42 (bourriquet42)
Date: 2010-10-07 18:39

Message:
It seems to not work anymore on latest versions.
I tried your code Nehe/lesson6-multi.py with PyOpenGL 3.0.1 and I keep
having the "invalid operation" message.

Jeremy

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-19 22:37

Message:
Logged In: YES 
user_id=21784

glBegin/glEnd extension problem fixed with new extension 
init functions.  Multitexture functionality verified to 
work with NeHe/lesson6-multi.py

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-17 08:56

Message:
Logged In: YES 
user_id=21784

Changed the name of the init function to 
glInitMultitextureARB to maintain naming consistency.

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-17 02:08

Message:
Logged In: YES 
user_id=21784

Initial fix is in CVS.  Only works on glActiveTextureARB 
and glMultiTexCoord2dARB.  Will require a bit more work to 
for rest of the extensions.

New proto added:

GL.ARB.multitexture.init_GL_ARB_multitexture()

which needs to be called to load GL_ARB_multitexture into 
the current context.

Also updated multitexture_1



----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2001-07-17 00:21

Message:
Logged In: YES 
user_id=34901

http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/opengl/hh/opengl/ntopnglr_6yer.asp  Says 
that you only need a lookup table per pixel-format (not 
much better, really).

----------------------------------------------------------------------

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-07-17 00:01

Message:
Logged In: YES 
user_id=21784

This is serious.  WGL docs don't make any mention about 
wglGetProcAddress not being called in between glBegin and 
glEnd.  This is apparently the cause of the "invalid 
operation."  This is confirmed by GLX docs saying that GLX 
calls are not allowed between glBegin and glEnd.  In order 
to get around this I'm going to have to figure out a way to 
call wglGetProcAddress outside of glBegin/glEnd and store 
the address.  Since proc addresses are potentially context 
dependent this probably means I'll have to create a lookup 
table for each context.  Ugh!

Tarn 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=441873&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3081957 ] OpenGL.error.NullFunctionError: Attempt to call an undefined

[SourceForge.net <no...@so...>]

Bugs item #3081957, was opened at 2010-10-06 07:11
Message generated for change (Comment added) made by ghazel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GLUT
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined

Initial Comment:
Trying to run this simple example here:
http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html

I get:
C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate
WARNING:context:Python Image Library (PIL) not installed, no Image support available
http://www.pythonware.com/products/pil/index.htm
WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture'
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop
    render = cls( *args, **named)
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling


----------------------------------------------------------------------

>Comment By: Greg Hazel (ghazel)
Date: 2010-10-06 07:13

Message:
I installed PIL, but I still get:

C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler
accelerator from OpenGL_accelerate
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 154, in ContextMainLoop
    render = cls( *args, **named)
  File
"C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py",
line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File
"C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py",
line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function
glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3081957 ] OpenGL.error.NullFunctionError: Attempt to call an undefined

[SourceForge.net <no...@so...>]

Bugs item #3081957, was opened at 2010-10-06 07:11
Message generated for change (Tracker Item Submitted) made by ghazel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GLUT
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined

Initial Comment:
Trying to run this simple example here:
http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html

I get:
C:\Users\Greg\Downloads>shader_sphere.py
WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate
WARNING:context:Python Image Library (PIL) not installed, no Image support available
http://www.pythonware.com/products/pil/index.htm
WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture'
Traceback (most recent call last):
  File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module>
    TestContext.ContextMainLoop()
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop
    render = cls( *args, **named)
  File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__
    glutInitDisplayMode( self.DISPLAYMODE )
  File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3042603 ] PyOpenGL Windows installer should be packaged with C Runtime

[SourceForge.net <no...@so...>]

Bugs item #3042603, was opened at 2010-08-10 11:53
Message generated for change (Settings changed) made by d_rea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dana Rea (d_rea)
Assigned to: Mike C. Fletcher (mcfletch)
>Summary: PyOpenGL Windows installer should be packaged with C Runtime

Initial Comment:
Installation fails on Windows systems that don't include a copy of mscvr71.dll (the C runtime), KB326922 (http://support.microsoft.com/kb/326922) suggests that this file should be packaged with the installer. Can this be included in future versions (precluding any licensing issues)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-3042603 ] yOpenGL Windows installer should be packaged with C Runtime

[SourceForge.net <no...@so...>]

Bugs item #3042603, was opened at 2010-08-10 11:53
Message generated for change (Tracker Item Submitted) made by d_rea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dana Rea (d_rea)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: yOpenGL Windows installer should be packaged with C Runtime

Initial Comment:
Installation fails on Windows systems that don't include a copy of mscvr71.dll (the C runtime), KB326922 (http://support.microsoft.com/kb/326922) suggests that this file should be packaged with the installer. Can this be included in future versions (precluding any licensing issues)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3042603&group_id=5988

Re: [PyOpenGL-Devel] Display lists 30 times faster than VBOs ?

[Eleftherios G. <gar...@gm...>]

Thank you for your replies. Interestingly I tried to do the same with
simulated random lines and the display lists have the same performance with
the vbos. It's only when I try with the real datasets that I get this
problem I am not sure why yet. The function calls take indeed some time but
not much. I need to play with them a bit more though.

On Wed, Jun 30, 2010 at 9:13 AM, Mathieu Virbel <ti...@ba...> wrote:

> At least, remove all dot call in the loop.
> http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Avoidingdots...
> Also, you can cache self.vbo+12, it create a new object each call.
>
> But even that, i doubt you'll gain as much as display list.
>
> * enrike <al...@gm...> [2010-06-30 05:09:42]:
>
> > just an idea.... the bottleneck could be in python and not in opengl,
> > remember that function call is expensive in python
> >
> > az., 2010.eko ekaren 30a 01:33(e)an, Eleftherios Garyfallidis(e)k idatzi
> > zuen:
> > > Hello,
> > >
> > > We are trying to visualize some quite big brain white matter datasets
> > > with PyOpenGL. We have around a quarter of a million of trajectories
> > > where each trajectory consists of up to around 100 line segments. The
> > > goal application is to be able to pick/select and update some or all of
> > > the trajectories in real time in order to help practitioners find their
> > > way through the brain. We had quite a good progress selecting and
> > > picking trajectories using gluUnProject however we are not sure which
> > > design direction we should take from now on as far as vbos are
> > > concernced. According to the Red Book and the community blogs vertex
> > > buffer objects should be more preferable than display lists now and in
> > > the future and display lists have already being tagged as deprecated.
> We
> > > would very much like your thoughts and feedback about this.
> > >
> > > We are testing this software on a Nvidia GeForce GTX 260 and use
> > > PyOpenGL 3.0.1
> > >
> > > The following class shows what we tried to do. The input of the class
> as
> > > shown in __init__() is data which is a list of trajectories where every
> > > trajectory is represented by numpy arrays of shape (N,3) , colors is
> the
> > > similar but a list of arrays of shape (N,4) (where N is different from
> > > trajectory to trajectory) and if the lists parameter is True then we
> use
> > > display lists with vbo eitherwise we use vbos only.
> > >
> > > Surprisingly, when using lists=True we get more than 30fps and when
> > > lists=False we get between 1-2 fps. Any ideas what is the reason for
> > > this dramatic change? Shouldn't vbos be the same or faster than dls?
> > >
> > > class Tracks():
> > >
> > >      def __init__(self,data,colors,line_width=3.,lists=False):
> > >
> > >          Actor.__init__(self)
> > >
> > >          self.data=data
> > >          self.cdata=None
> > >          self.colors=colors
> > >          self.line_width=line_width
> > >          self.list_index = None
> > >          self.vbo = None
> > >          self.lists = lists
> > >
> > >      def init(self):
> > >          self.init_default()
> > >
> > >      def init_default(self):
> > >
> > >          self.counts=[len(d) for d in self.data]
> > >          cdata=np.concatenate(self.data)
> > >          first=np.array(self.counts).cumsum()
> > >          self.first=list(np.hstack((np.array([0]),first[:-1])))
> > >          ccolors=np.concatenate(self.colors)
> > >          self.min=np.min(cdata,axis=0)
> > >          self.max=np.max(cdata,axis=0)
> > >          self.mean=np.mean(cdata,axis=0)
> > >          cdata = cdata - self.mean
> > >          self.cdata = cdata
> > >
> > >          stack=np.hstack((cdata,ccolors))
> > >          stack=stack.astype('float32')
> > >          self.vbo = vbo.VBO(stack,usage='GL_STATIC_DRAW')
> > >          #self.vbo =
> > > vbo.VBO(np.hstack((cdata,ccolors)),usage=gl.GL_DYNAMIC_DRAW)
> > >
> > >          if self.lists:
> > >
> > >              self.list_index = gl.glGenLists(1)
> > >              gl.glNewList( self.list_index,gl.GL_COMPILE)
> > >              self._execute_vbos()
> > >              gl.glEndList()
> > >
> > >
> > >      def _execute_vbos(self):
> > >
> > >          gl.glDisable(gl.GL_LIGHTING)
> > >          gl.glDisable(gl.GL_DEPTH_TEST)
> > >          gl.glEnable(gl.GL_BLEND)
> > >          gl.glBlendFunc(gl.GL_SRC_ALPHA,gl.GL_ONE_MINUS_SRC_ALPHA)
> > >          gl.glLineWidth(self.line_width)
> > >
> > >          self.vbo.bind()
> > >          try:
> > >              gl.glEnableClientState(gl.GL_VERTEX_ARRAY)
> > >              gl.glEnableClientState(gl.GL_COLOR_ARRAY)
> > >              #gl.glVertexPointerf(cdata)
> > >              gl.glVertexPointer(3, gl.GL_FLOAT, 28, self.vbo )
> > >              gl.glColorPointer(4, gl.GL_FLOAT, 28, self.vbo+12 )
> > >              gl.glMultiDrawArrays(gl.GL_LINE_STRIP,\
> > >
> self.first,self.counts,len(self.counts))
> > >          finally:
> > >              self.vbo.unbind()
> > >
> > >          gl.glDisableClientState(gl.GL_COLOR_ARRAY)
> > >          gl.glDisableClientState(gl.GL_VERTEX_ARRAY)
> > >          gl.glDisable(gl.GL_BLEND)
> > >          gl.glEnable(gl.GL_LIGHTING)
> > >          gl.glEnable(gl.GL_DEPTH_TEST)
> > >
> > >
> > >      def display(self):
> > >
> > >          gl.glPushMatrix()
> > >          x,y,z = self.position
> > >          gl.glTranslatef(x,y,z)
> > >
> > >          if self.lists:
> > >              gl.glCallList(self.list_index)
> > >          else:
> > >              self._execute_vbos()
> > >
> > >          gl.glPopMatrix()
> > >
> > >
> > > The Tracks.display function is called from glutDisplayFunc from another
> > > file after the object has been initialized using the init function.  We
> > > would be very happy to hear about your ideas to make this visualization
> > > better and ideas about how to update the datasets using the vbo from
> > > OpenGL.arrays or a different method in a nice efficient way.
> > >
> > > We would be more than happy to continue using PyOpenGL and contribute
> to
> > > the list in the future. PyOpenGL fits very well with a new project we
> > > have created found at nipy.org/dipy <http://nipy.org/dipy> .We are
> more
> > > than eager at the moment to switch from python-vtk or mayavi to
> pyopengl
> > > for all our visualization needs as we think that it can deal better
> with
> > > big datasets.
> > >
> > > Best wishes,
> > > Eleftherios & Ian
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by Sprint
> > > What will you do first with EVO, the first 4G phone?
> > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > >
> > >
> > >
> > > _______________________________________________
> > > PyOpenGL Homepage
> > > http://pyopengl.sourceforge.net
> > > _______________________________________________
> > > PyOpenGL-Devel mailing list
> > > PyO...@li...
> > > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Devel mailing list
> > PyO...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>

Re: [PyOpenGL-Devel] Display lists 30 times faster than VBOs ?

[Mathieu V. <ti...@ba...>]

At least, remove all dot call in the loop.
http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Avoidingdots...
Also, you can cache self.vbo+12, it create a new object each call.

But even that, i doubt you'll gain as much as display list.

* enrike <al...@gm...> [2010-06-30 05:09:42]:

> just an idea.... the bottleneck could be in python and not in opengl, 
> remember that function call is expensive in python
> 
> az., 2010.eko ekaren 30a 01:33(e)an, Eleftherios Garyfallidis(e)k idatzi 
> zuen:
> > Hello,
> >
> > We are trying to visualize some quite big brain white matter datasets
> > with PyOpenGL. We have around a quarter of a million of trajectories
> > where each trajectory consists of up to around 100 line segments. The
> > goal application is to be able to pick/select and update some or all of
> > the trajectories in real time in order to help practitioners find their
> > way through the brain. We had quite a good progress selecting and
> > picking trajectories using gluUnProject however we are not sure which
> > design direction we should take from now on as far as vbos are
> > concernced. According to the Red Book and the community blogs vertex
> > buffer objects should be more preferable than display lists now and in
> > the future and display lists have already being tagged as deprecated. We
> > would very much like your thoughts and feedback about this.
> >
> > We are testing this software on a Nvidia GeForce GTX 260 and use
> > PyOpenGL 3.0.1
> >
> > The following class shows what we tried to do. The input of the class as
> > shown in __init__() is data which is a list of trajectories where every
> > trajectory is represented by numpy arrays of shape (N,3) , colors is the
> > similar but a list of arrays of shape (N,4) (where N is different from
> > trajectory to trajectory) and if the lists parameter is True then we use
> > display lists with vbo eitherwise we use vbos only.
> >
> > Surprisingly, when using lists=True we get more than 30fps and when
> > lists=False we get between 1-2 fps. Any ideas what is the reason for
> > this dramatic change? Shouldn't vbos be the same or faster than dls?
> >
> > class Tracks():
> >
> >      def __init__(self,data,colors,line_width=3.,lists=False):
> >
> >          Actor.__init__(self)
> >
> >          self.data=data
> >          self.cdata=None
> >          self.colors=colors
> >          self.line_width=line_width
> >          self.list_index = None
> >          self.vbo = None
> >          self.lists = lists
> >
> >      def init(self):
> >          self.init_default()
> >
> >      def init_default(self):
> >
> >          self.counts=[len(d) for d in self.data]
> >          cdata=np.concatenate(self.data)
> >          first=np.array(self.counts).cumsum()
> >          self.first=list(np.hstack((np.array([0]),first[:-1])))
> >          ccolors=np.concatenate(self.colors)
> >          self.min=np.min(cdata,axis=0)
> >          self.max=np.max(cdata,axis=0)
> >          self.mean=np.mean(cdata,axis=0)
> >          cdata = cdata - self.mean
> >          self.cdata = cdata
> >
> >          stack=np.hstack((cdata,ccolors))
> >          stack=stack.astype('float32')
> >          self.vbo = vbo.VBO(stack,usage='GL_STATIC_DRAW')
> >          #self.vbo =
> > vbo.VBO(np.hstack((cdata,ccolors)),usage=gl.GL_DYNAMIC_DRAW)
> >
> >          if self.lists:
> >
> >              self.list_index = gl.glGenLists(1)
> >              gl.glNewList( self.list_index,gl.GL_COMPILE)
> >              self._execute_vbos()
> >              gl.glEndList()
> >
> >
> >      def _execute_vbos(self):
> >
> >          gl.glDisable(gl.GL_LIGHTING)
> >          gl.glDisable(gl.GL_DEPTH_TEST)
> >          gl.glEnable(gl.GL_BLEND)
> >          gl.glBlendFunc(gl.GL_SRC_ALPHA,gl.GL_ONE_MINUS_SRC_ALPHA)
> >          gl.glLineWidth(self.line_width)
> >
> >          self.vbo.bind()
> >          try:
> >              gl.glEnableClientState(gl.GL_VERTEX_ARRAY)
> >              gl.glEnableClientState(gl.GL_COLOR_ARRAY)
> >              #gl.glVertexPointerf(cdata)
> >              gl.glVertexPointer(3, gl.GL_FLOAT, 28, self.vbo )
> >              gl.glColorPointer(4, gl.GL_FLOAT, 28, self.vbo+12 )
> >              gl.glMultiDrawArrays(gl.GL_LINE_STRIP,\
> >                                   self.first,self.counts,len(self.counts))
> >          finally:
> >              self.vbo.unbind()
> >
> >          gl.glDisableClientState(gl.GL_COLOR_ARRAY)
> >          gl.glDisableClientState(gl.GL_VERTEX_ARRAY)
> >          gl.glDisable(gl.GL_BLEND)
> >          gl.glEnable(gl.GL_LIGHTING)
> >          gl.glEnable(gl.GL_DEPTH_TEST)
> >
> >
> >      def display(self):
> >
> >          gl.glPushMatrix()
> >          x,y,z = self.position
> >          gl.glTranslatef(x,y,z)
> >
> >          if self.lists:
> >              gl.glCallList(self.list_index)
> >          else:
> >              self._execute_vbos()
> >
> >          gl.glPopMatrix()
> >
> >
> > The Tracks.display function is called from glutDisplayFunc from another
> > file after the object has been initialized using the init function.  We
> > would be very happy to hear about your ideas to make this visualization
> > better and ideas about how to update the datasets using the vbo from
> > OpenGL.arrays or a different method in a nice efficient way.
> >
> > We would be more than happy to continue using PyOpenGL and contribute to
> > the list in the future. PyOpenGL fits very well with a new project we
> > have created found at nipy.org/dipy <http://nipy.org/dipy> .We are more
> > than eager at the moment to switch from python-vtk or mayavi to pyopengl
> > for all our visualization needs as we think that it can deal better with
> > big datasets.
> >
> > Best wishes,
> > Eleftherios & Ian
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> >
> >
> >
> > _______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Devel mailing list
> > PyO...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel

Re: [PyOpenGL-Devel] Display lists 30 times faster than VBOs ?

[enrike <al...@gm...>]

just an idea.... the bottleneck could be in python and not in opengl, 
remember that function call is expensive in python

az., 2010.eko ekaren 30a 01:33(e)an, Eleftherios Garyfallidis(e)k idatzi 
zuen:
> Hello,
>
> We are trying to visualize some quite big brain white matter datasets
> with PyOpenGL. We have around a quarter of a million of trajectories
> where each trajectory consists of up to around 100 line segments. The
> goal application is to be able to pick/select and update some or all of
> the trajectories in real time in order to help practitioners find their
> way through the brain. We had quite a good progress selecting and
> picking trajectories using gluUnProject however we are not sure which
> design direction we should take from now on as far as vbos are
> concernced. According to the Red Book and the community blogs vertex
> buffer objects should be more preferable than display lists now and in
> the future and display lists have already being tagged as deprecated. We
> would very much like your thoughts and feedback about this.
>
> We are testing this software on a Nvidia GeForce GTX 260 and use
> PyOpenGL 3.0.1
>
> The following class shows what we tried to do. The input of the class as
> shown in __init__() is data which is a list of trajectories where every
> trajectory is represented by numpy arrays of shape (N,3) , colors is the
> similar but a list of arrays of shape (N,4) (where N is different from
> trajectory to trajectory) and if the lists parameter is True then we use
> display lists with vbo eitherwise we use vbos only.
>
> Surprisingly, when using lists=True we get more than 30fps and when
> lists=False we get between 1-2 fps. Any ideas what is the reason for
> this dramatic change? Shouldn't vbos be the same or faster than dls?
>
> class Tracks():
>
>      def __init__(self,data,colors,line_width=3.,lists=False):
>
>          Actor.__init__(self)
>
>          self.data=data
>          self.cdata=None
>          self.colors=colors
>          self.line_width=line_width
>          self.list_index = None
>          self.vbo = None
>          self.lists = lists
>
>      def init(self):
>          self.init_default()
>
>      def init_default(self):
>
>          self.counts=[len(d) for d in self.data]
>          cdata=np.concatenate(self.data)
>          first=np.array(self.counts).cumsum()
>          self.first=list(np.hstack((np.array([0]),first[:-1])))
>          ccolors=np.concatenate(self.colors)
>          self.min=np.min(cdata,axis=0)
>          self.max=np.max(cdata,axis=0)
>          self.mean=np.mean(cdata,axis=0)
>          cdata = cdata - self.mean
>          self.cdata = cdata
>
>          stack=np.hstack((cdata,ccolors))
>          stack=stack.astype('float32')
>          self.vbo = vbo.VBO(stack,usage='GL_STATIC_DRAW')
>          #self.vbo =
> vbo.VBO(np.hstack((cdata,ccolors)),usage=gl.GL_DYNAMIC_DRAW)
>
>          if self.lists:
>
>              self.list_index = gl.glGenLists(1)
>              gl.glNewList( self.list_index,gl.GL_COMPILE)
>              self._execute_vbos()
>              gl.glEndList()
>
>
>      def _execute_vbos(self):
>
>          gl.glDisable(gl.GL_LIGHTING)
>          gl.glDisable(gl.GL_DEPTH_TEST)
>          gl.glEnable(gl.GL_BLEND)
>          gl.glBlendFunc(gl.GL_SRC_ALPHA,gl.GL_ONE_MINUS_SRC_ALPHA)
>          gl.glLineWidth(self.line_width)
>
>          self.vbo.bind()
>          try:
>              gl.glEnableClientState(gl.GL_VERTEX_ARRAY)
>              gl.glEnableClientState(gl.GL_COLOR_ARRAY)
>              #gl.glVertexPointerf(cdata)
>              gl.glVertexPointer(3, gl.GL_FLOAT, 28, self.vbo )
>              gl.glColorPointer(4, gl.GL_FLOAT, 28, self.vbo+12 )
>              gl.glMultiDrawArrays(gl.GL_LINE_STRIP,\
>                                   self.first,self.counts,len(self.counts))
>          finally:
>              self.vbo.unbind()
>
>          gl.glDisableClientState(gl.GL_COLOR_ARRAY)
>          gl.glDisableClientState(gl.GL_VERTEX_ARRAY)
>          gl.glDisable(gl.GL_BLEND)
>          gl.glEnable(gl.GL_LIGHTING)
>          gl.glEnable(gl.GL_DEPTH_TEST)
>
>
>      def display(self):
>
>          gl.glPushMatrix()
>          x,y,z = self.position
>          gl.glTranslatef(x,y,z)
>
>          if self.lists:
>              gl.glCallList(self.list_index)
>          else:
>              self._execute_vbos()
>
>          gl.glPopMatrix()
>
>
> The Tracks.display function is called from glutDisplayFunc from another
> file after the object has been initialized using the init function.  We
> would be very happy to hear about your ideas to make this visualization
> better and ideas about how to update the datasets using the vbo from
> OpenGL.arrays or a different method in a nice efficient way.
>
> We would be more than happy to continue using PyOpenGL and contribute to
> the list in the future. PyOpenGL fits very well with a new project we
> have created found at nipy.org/dipy <http://nipy.org/dipy> .We are more
> than eager at the moment to switch from python-vtk or mayavi to pyopengl
> for all our visualization needs as we think that it can deal better with
> big datasets.
>
> Best wishes,
> Eleftherios & Ian
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel

[PyOpenGL-Devel] Display lists 30 times faster than VBOs ?

[Eleftherios G. <gar...@gm...>]

Hello,

We are trying to visualize some quite big brain white matter datasets with
PyOpenGL. We have around a quarter of a million of trajectories where each
trajectory consists of up to around 100 line segments. The goal application
is to be able to pick/select and update some or all of the trajectories in
real time in order to help practitioners find their way through the brain.
We had quite a good progress selecting and picking trajectories using
gluUnProject however we are not sure which design direction we should take
from now on as far as vbos are concernced. According to the Red Book and the
community blogs vertex buffer objects should be more preferable than display
lists now and in the future and display lists have already being tagged as
deprecated. We would very much like your thoughts and feedback about this.

We are testing this software on a Nvidia GeForce GTX 260 and use PyOpenGL
3.0.1

The following class shows what we tried to do. The input of the class as
shown in __init__() is data which is a list of trajectories where every
trajectory is represented by numpy arrays of shape (N,3) , colors is the
similar but a list of arrays of shape (N,4) (where N is different from
trajectory to trajectory) and if the lists parameter is True then we use
display lists with vbo eitherwise we use vbos only.

Surprisingly, when using lists=True we get more than 30fps and when
lists=False we get between 1-2 fps. Any ideas what is the reason for this
dramatic change? Shouldn't vbos be the same or faster than dls?

class Tracks():

    def __init__(self,data,colors,line_width=3.,lists=False):

        Actor.__init__(self)

        self.data=data
        self.cdata=None
        self.colors=colors
        self.line_width=line_width
        self.list_index = None
        self.vbo = None
        self.lists = lists

    def init(self):
        self.init_default()

    def init_default(self):

        self.counts=[len(d) for d in self.data]
        cdata=np.concatenate(self.data)
        first=np.array(self.counts).cumsum()
        self.first=list(np.hstack((np.array([0]),first[:-1])))
        ccolors=np.concatenate(self.colors)
        self.min=np.min(cdata,axis=0)
        self.max=np.max(cdata,axis=0)
        self.mean=np.mean(cdata,axis=0)
        cdata = cdata - self.mean
        self.cdata = cdata

        stack=np.hstack((cdata,ccolors))
        stack=stack.astype('float32')
        self.vbo = vbo.VBO(stack,usage='GL_STATIC_DRAW')
        #self.vbo =
vbo.VBO(np.hstack((cdata,ccolors)),usage=gl.GL_DYNAMIC_DRAW)

        if self.lists:

            self.list_index = gl.glGenLists(1)
            gl.glNewList( self.list_index,gl.GL_COMPILE)
            self._execute_vbos()
            gl.glEndList()


    def _execute_vbos(self):

        gl.glDisable(gl.GL_LIGHTING)
        gl.glDisable(gl.GL_DEPTH_TEST)
        gl.glEnable(gl.GL_BLEND)
        gl.glBlendFunc(gl.GL_SRC_ALPHA,gl.GL_ONE_MINUS_SRC_ALPHA)
        gl.glLineWidth(self.line_width)

        self.vbo.bind()
        try:
            gl.glEnableClientState(gl.GL_VERTEX_ARRAY)
            gl.glEnableClientState(gl.GL_COLOR_ARRAY)
            #gl.glVertexPointerf(cdata)
            gl.glVertexPointer(3, gl.GL_FLOAT, 28, self.vbo )
            gl.glColorPointer(4, gl.GL_FLOAT, 28, self.vbo+12 )
            gl.glMultiDrawArrays(gl.GL_LINE_STRIP,\
                                 self.first,self.counts,len(self.counts))
        finally:
            self.vbo.unbind()

        gl.glDisableClientState(gl.GL_COLOR_ARRAY)
        gl.glDisableClientState(gl.GL_VERTEX_ARRAY)
        gl.glDisable(gl.GL_BLEND)
        gl.glEnable(gl.GL_LIGHTING)
        gl.glEnable(gl.GL_DEPTH_TEST)


    def display(self):

        gl.glPushMatrix()
        x,y,z = self.position
        gl.glTranslatef(x,y,z)

        if self.lists:
            gl.glCallList(self.list_index)
        else:
            self._execute_vbos()

        gl.glPopMatrix()


The Tracks.display function is called from glutDisplayFunc from another file
after the object has been initialized using the init function.  We would be
very happy to hear about your ideas to make this visualization better and
ideas about how to update the datasets using the vbo from OpenGL.arrays or a
different method in a nice efficient way.

We would be more than happy to continue using PyOpenGL and contribute to the
list in the future. PyOpenGL fits very well with a new project we have
created found at nipy.org/dipy .We are more than eager at the moment to
switch from python-vtk or mayavi to pyopengl for all our visualization needs
as we think that it can deal better with big datasets.

Best wishes,
Eleftherios & Ian