pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] difficulties installing pyOpenGL on Linux

[Miriam E. <mi...@mi...>]

Okay, so long story short, I found ctypes on the net (it is new to 
python2.5 so I don't really understand why it is needed for python2.4). 
I downloaded and installed it and PyOpenGL works!

...kinda...

The dots.py demo works, but I still have problems.

Firstly when I ran some demos that use PIL I got the error
"The _imaging C module is not installed"

Upshot: I re-installed PIL. Now I get a bewildering array of error 
messages for various of the PyOpenGL programs (they all work fine on 
Win32). None of the GLE demos work or any other demos using textures. 
Many things give AttributeError: pixel_access.

Many other things have other errors, like dek/MandelImage.py which says
Numeric.ravel(xx+yy[:,Numeric.NewAxis]) doesn't have NewAxis attribute. 
I installed Numeric recently. I'm sure MandelImage is older than 
Numeric... but waaaiit... I tried an old version of MandelImage and the 
error disappears (now we have the PIL pixel_access error).

texturesurf.py and tile.py say tkinter can't find togl. Huh? I never 
needed togl on Win32. I guess I need to find and install it. [sigh]

How can this be so damn hard?

Oh well... at least dots.py is working, and a few other things like the 
GLUT demos (but not conesave.py -- it spits the dummy when given the 
wrong number type... in a dynamically type-converting language?), and a 
few of the more primitive NeHe demos work, and the redbook examples.

Time to put this aside and get back to other things.


I may, at times, spend days getting things to work, coming back again 
and again to try more after being thwarted. If I do this with PyOpenGL 
and still am unable to get it working cleanly, what are the chances that 
this can get any sort of wide acceptance?

I really, really want this to work, but I'm starting to get a 
desperately strong impression of a structure built upon shifting sands. 
How can I recommend this to anyone else? How can I hope to build usable 
worlds?

I still intend to get this to work. I consider python the best hope in 
many ways. And I don't mean to be critical. I realise the incredible 
amount of time and brillance put into this. It's just... these things 
worry me greatly.

Cheers,

	- Miriam
-- 
---------=---------=---------=---------=---------=---------=------
A life! Cool! Where can I download one of those from?
---------=---------=---------=---------=---------=---------=------
Website: http://miriam-english.org
Blog: http://www.livejournal.com/users/miriam_e/

[PyOpenGL-Users] difficulties installing pyOpenGL on Linux

[Miriam E. <mi...@mi...>]

Hi folks,

I've run pyOpenGL on Win32 for a year or two now, but over that period 
have been gradually migrating to Linux -- specifically Puppy Linux. This 
has probably made installing pyOpenGL (and a few other things) harder 
than it needs to be because Puppy is a fairly young distribution. Its 
great advantages are its small size and its speed. Most modern Linuxes 
are going a similar bloated route to MSWindows.

Anyway... I have got python working fine with pygame, and can run all 
the demos except the glcube.py example. It prints "The GLCUBE example 
requires PyOpenGL". No problem, thought I. That's next on my list to 
install.

So I go to sourceforge and... ummm... an egg??? OK, so I read up about 
them (seems a little like making things more complicated to make them 
easier), download the required tools and install them, then install 
PyOpenGL-3.0.0a6. Everything seems to go fine.

I now try the glcube example again and it gives the same message:
"The GLCUBE example requires PyOpenGL"
Very odd...

I decide to try another example, just in case it is something related to 
that particular file. I select the dots.py example from the 
PyOpenGL_Demo-3.0.0a6 collection. This time the error I get is:

Traceback (most recent call last):
   File "dots.py", line 24, in ?
     from OpenGL.GL import *
   File 
"/usr/lib/python2.4/site-packages/PyOpenGL_Demo-3.0.0a6-py2.4.egg/PyOpenGL-Demo/da/__init__.py", 
line 2, in ?

   File 
"/usr/lib/python2.4/site-packages/PyOpenGL_Demo-3.0.0a6-py2.4.egg/PyOpenGL-Demo/da/__init__.py", 
line 6, in ?

   File "build/bdist.linux-i686/egg/OpenGL/raw/GL/constants.py", line 6, 
in ?
ImportError: No module named ctypes

It is true I have no module named ctypes, but I haven't needed it 
previously when using Win32 and I can't find mention of it in the 
python2.4 documentation. Does anybody know what this means?

I was going to uninstall PyOpenGL-3.0.0a6 so that I could install an 
older version, but I can't find any mechanism for this. Previously I 
would just delete the folder in site-packages and the PyOpenGL.pth file, 
but they aren't there anymore -- there is a PyOpenGL-3.0.0a6-py2.4.egg 
file and an easy-install.pth file, but I'm a little reluctant to tamper 
with automated install systems in case I screw up info that they need 
...but I do it anyway (actually I move them to a safe place so I can 
restore them later if I want.

I try running python setup.py install on the PyOpenGL-2.0.2.01 source 
and after thousands of warnings scroll by it ends with
error: command 'gcc' failed with exit status 1
I've had no problems compiling the SDL libs and various other things, so 
I wonder if it doesn't know where to find some source files. Wouldn't 
they accompany PyOpenGL? I don't know. I definitely have OpebGL 
installed and working and can run many binary OpenGL demos. And I 
installed the nVidia driver for my card, which put a number of gl*.h 
files in /usr/include/GL/ which, I guess could be the wrong place... but 
I have no idea how to find that out.

Now I try a binary installable made for Fedora (shaky, I know, but I've 
had some success installing binaries for RedHat and Debian before). But 
this gives no joy at all. Running dots.py (or any other PyOpenGL demo) 
results in
Traceback (most recent call last):
   File "dots.py", line 24, in ?
     from OpenGL.GL import *
   File "/usr/lib/python2.4/site-packages/OpenGL/__init__.py", line 26, in ?
     from GL._GL__init__ import __numeric_present__, __numeric_support__
   File "/usr/lib/python2.4/site-packages/OpenGL/GL/__init__.py", line 
2, in ?
     from GL__init__ import *
   File "/usr/lib/python2.4/site-packages/OpenGL/GL/GL__init__.py", line 
5, in ?
     import _GL__init__
ImportError: /lib/libc.so.6: version `GLIBC_2.4' not found (required by 
/usr/lib/python2.4/site-packages/OpenGL/GL/_GL__init__.so)

On my machine /lib/libc.so.6 does exist, but is a link to libc-2.3.5.s0
So does that mean I need a newer version of libc? And if so, why did the 
setuptools installer not balk at it? If it is a dependency then 
shouldn't it be included? or listed as a dependency? Or is it a result 
of me blythely dropping in an incompatible version?

Sheesh. Lucky I'm a ridiculously patient person. I've tried a few other 
times to install PyOpenGL on Puppy and run out of time after spending a 
day or so at it. This time I've finally decided to turn to the list...

Help!!! :)

Cheers,

	- Miriam

-- 
---------=---------=---------=---------=---------=---------=------
A life! Cool! Where can I download one of those from?
---------=---------=---------=---------=---------=---------=------
Website: http://miriam-english.org
Blog: http://www.livejournal.com/users/miriam_e/

[PyOpenGL-Users] glDrawPixels

[Jason W. <ny...@gm...>]

Hi I am trying to call glDrawPixels but it doesn't seem to be working.
I say:
from numpy import arange
pixels = arange( float( 1024*768*3 ))
for j in range(1024*768*3):
      pixels[j]=float(1)

#Normal opengl setup code etc
glDrawPixels(1024,768,GL_RGB,GL_FLOAT,pixels)

# I am using a 1D array that will be organised in the right fashion, but
IDLE keeps crashing with this line of code

Re: [PyOpenGL-Users] Aliasing changes when I have a white background

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

Rick Muller wrote:
> The basic way I'm updating my screen is:
> 
>         #anti-aliasing code
>         glEnable(GL_BLEND)
>         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
>         glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE)

You're turning on smoothing for lines here, but your
images look like they're made up of filled polygons.
Line smoothing has no effect on polygon rendering.

So I think you're not getting any anti-aliasing at
all, and the black/white difference is just because
the eye doesn't notice it so much against a black
background.

There is an option for smoothing polygons, but using
it correctly is viciously difficult. Unless you're
pushing the limits of rendering speed, FSAA is by
far the better way to go.

--
Greg

Re: [PyOpenGL-Users] Aliasing changes when I have a white background

[Rick M. <rpm...@gm...>]

This is indeed what it looks like, which is why I think I'm doing
something wrong. I thought I was drawing the image on white, but
perhaps I'm not doing what I think I'm doing. Could double buffering
be messing me up here?

The basic way I'm updating my screen is:

        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

        #anti-aliasing code
        glEnable(GL_BLEND)
        glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
        glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE)

        glPushMatrix()
        glCallList(self.dlist)
        glPopMatrix()

        self.SwapBuffers()

However, I only set the color when I setup the canvas, so maybe I'm
not updating it in the second buffer. Does anyone have any thoughts on
this?

On 8/11/07, vwf <vw...@vu...> wrote:
> On Fri, Aug 10, 2007 at 02:38:21PM -0600, Rick Muller wrote:
> > http://farm2.static.flickr.com/1037/1074160261_a963714943_o.png
> > If this isn't publication quality, it's close enough that I don't care
> > about the difference.
> > However, when I draw a molecule with a white background, the aliasing looks bad:
> > http://farm2.static.flickr.com/1314/1074160459_5baa206cc4_o.png
> > I'm not a real OpenGL expert, so I'm probably doing something wrong.
>
> I am not an OpenGL anti-aliasing expert either, but did you really draw
> the second image on white? It looks like you drew it on black, and
> placed it on a white background afterwards.
>
>


-- 
Rick Muller
rpm...@gm...

Re: [PyOpenGL-Users] Aliasing changes when I have a white background

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

Rick Muller wrote:
> However, when I draw a molecule with a white background, the aliasing looks bad:

You could try turning on FSAA (Full Scene
Anti-Aliasing). There will be an option for this
when you create the OpenGL context, although the
details are platform-dependent.

This causes the scene to be rendered at a higher
resolution and then smoothed. It takes longer to
render, but if you're not trying to get enormous
frame rates, that probably won't be a problem.

--
Greg

[PyOpenGL-Users] Aliasing changes when I have a white background

[Rick M. <rpm...@gm...>]

I maintain a chemical graphics program called Vimes
(http://vimes.sf.net) that uses PyOpenGL for it's OpenGL rendering.
I've been very happy with how well PyOpenGL has worked for me over the
years, and I'm particularly thrilled with how easy the new
installation in version 3 is.

I have a more basic problem, though. When I draw a molecule on a black
background, everything looks great:
http://farm2.static.flickr.com/1037/1074160261_a963714943_o.png
If this isn't publication quality, it's close enough that I don't care
about the difference.

However, when I draw a molecule with a white background, the aliasing looks bad:
http://farm2.static.flickr.com/1314/1074160459_5baa206cc4_o.png
I'm not a real OpenGL expert, so I'm probably doing something wrong.
One of the great things about PyOpenGL is that it makes OpenGL
possible for people like me.

Can anyone give me pointers to making this look better? Thanks in advance,

-- 
Rick Muller
rpm...@gm...

Re: [PyOpenGL-Users] glut import error bug state

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

Mike C. Fletcher(e)k dio:
> altern wrote:
>> hi
>>
>> just upgraded to python 2.5 and pyopengl 3.0.0a6 under XP. Any 
>> solutions to this problem?
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=464D0AF5.2080303%40vrplumber.com 
>>
>>
>> I double checked and glut32.dll was installed in c:\windows\system32
>>   
> It *should* work on Win32 with the current cvs, but we haven't had any 
> Win32 testers yet, so it's quite possible there's still a bug there.  As 
> for not finding your glut32, that's a new bug, likely.
> 
> Can you check out the CVS version, run setup.py develop and then trace 
> through the code in platform/win32.py to see where it's failing (not 
> sure of your level of Python comfort, there's a module called "pdb" that 
> allows for tracing through python code).  If you can trace down into the 
> ctypes code to see why it isn't finding your library I can probably 
> figure out how to fix it.

ok, i am not sure if i will have time to do this before i go on 
holidays. Otherwise i will try after.
thanks!

enrike

> Enjoy yourself,
> Mike
> 

Re: [PyOpenGL-Users] glut import error bug state

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

altern wrote:
> hi
>
> just upgraded to python 2.5 and pyopengl 3.0.0a6 under XP. Any solutions 
> to this problem?
>
> http://sourceforge.net/mailarchive/message.php?msg_id=464D0AF5.2080303%40vrplumber.com
>
> I double checked and glut32.dll was installed in c:\windows\system32
>   
It *should* work on Win32 with the current cvs, but we haven't had any 
Win32 testers yet, so it's quite possible there's still a bug there.  As 
for not finding your glut32, that's a new bug, likely.

Can you check out the CVS version, run setup.py develop and then trace 
through the code in platform/win32.py to see where it's failing (not 
sure of your level of Python comfort, there's a module called "pdb" that 
allows for tracing through python code).  If you can trace down into the 
ctypes code to see why it isn't finding your library I can probably 
figure out how to fix it.

Enjoy yourself,
Mike

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

[PyOpenGL-Users] Begginer's question: how to bind key press in OpenGK.Tk

[<bus...@si...>]

Hi,

I just started to play around with PyOpenGL. I'm using the OpenGK.Tk 
package, and I have a problem binding keyboard input to my application.

I attach a very simple code I wrote. Although I've done the 
bind("<KeyPress>"), it does not work.

Any help will be really appreciated.

Thanks!

CODE:

from OpenGL.Tk import *

################################################################3
#
def redraw(o):
    glClearColor(0.5, 0.5, 0.5, 0)
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
    glOrtho(0,1,0,1,0,1)

    glBegin(GL_QUADS)
    glVertex3f(0,0,0)
    glVertex3f(1,0,0)
    glVertex3f(1,1,0)
    glVertex3f(0,1,0)
    glEnd()
   
################################################################3
#
def keyDown(event):
    print repr(event.char)

################################################################3
#

o = Opengl(width = 300, height = 300, double = 1)
o.redraw = redraw
o.pack(side = 'top', expand = 1, fill = 'both')
o.bind("<KeyPress>",keyDown)

o.mainloop()
------------------------------------------------------------------------
Abans d'imprimir aquest correu electrònic pensa si és necessari fer-ho: 
el medi ambient és cosa de tots.

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

Re: [PyOpenGL-Users] glut import error bug state

[Brian J. <bri...@gm...>]

I get the same error message with opengl32.dll and glut32.dll in
C:\Windows\system32\ and C:\python25.

On 7/31/07, altern <al...@gm...> wrote:
>
> hi
>
> just upgraded to python 2.5 and pyopengl 3.0.0a6 under XP. Any solutions
> to this problem?
>
>
> http://sourceforge.net/mailarchive/message.php?msg_id=464D0AF5.2080303%40vrplumber.com
>
> I double checked and glut32.dll was installed in c:\windows\system32
>
> thanks
>
> enrike
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

[PyOpenGL-Users] glut import error bug state

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

hi

just upgraded to python 2.5 and pyopengl 3.0.0a6 under XP. Any solutions 
to this problem?

http://sourceforge.net/mailarchive/message.php?msg_id=464D0AF5.2080303%40vrplumber.com

I double checked and glut32.dll was installed in c:\windows\system32

thanks

enrike

Re: [PyOpenGL-Users] OpenGL and py2exe

[Neil Y. <yag...@gm...>]

UPDATE: There is a package called bbfreeze for creating standalone
executables that supports eggs. It isn't as mature as py2exe, but
works well with PyOpenGL eggs.

Neil

On 25/05/07, Neil Yager <yag...@gm...> wrote:
> I understand that this issue has been covered before, and the discussion
> rightly belongs to a py2exe list, but I'm hoping for a little luck here -
> some of you have had, and apparently worked around, this specific problem.
>
> The py2exeeggs trick isn't working for me.  I am excluding OpenGL from my
> py2exe build, and copying the EGG into the dist directory manually.  The
> py2exeeggs (which is the first module imported) correctly finds the EGG and
> adds it to the system path.  However, the entry-points don't seem to be
> registered (my error is  "No array-type handler for type <type 'list'>").
> I've tried explicitly calling dist.activate() as well...
>
> Has anyone got py2exeeggs working with Python 2.4? Can I explicitly register
> the entry-points in the code?  Any ideas or suggestions would be
> appreciated.
>
> Thanks,
> Neil
>

Re: [PyOpenGL-Users] Python OpenGL

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

Ben Sizer wrote:
...
> Ok, thanks. How much work is left to be done to get it out of alpha?
http://blog.vrplumber.com/1883 is the latest status update.  Everything 
there is still basically valid.
> Is it something the wider community can help with?
Any of the issues there are reasonable for the community to help with.

Biggest help, however, would probably be testing and/or writing 
demonstrations with the more advanced features we now provide.  We now 
have OpenGL 2.1 support (in CVS, 2.0 in the a6 release), but we don't 
have any 2.1 tests or demos.  Similarly, the more advanced extensions 
are often just an automated wrapper, so we don't have any convenience 
operations in the modules.  And really, we could use lots more 
testing/porting for exotic architectures and OSs, such as Windows (all 
flavours), Mac OS9, the various non-Linux Unix architectures, that kind 
of thing.

All of that is pretty easy to work on in the new code base, just cvs co 
OpenGL-ctypes, setup.py develop, then hack and submit the CVS diff when 
you have an improvement.

Enjoy yourself,
Mike

(CC'ing PyOpenGL users list in case anyone else would like to do some 
work on getting the package released sooner rather than later)

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

[PyOpenGL-Users] Could someone with Win32 and/or OS-X test latest CVS

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

I've been eliminating the hard-coded platform implementation restriction 
(i.e. allowing people to write plug-ins for supporting other 
platforms).  In doing so I've had to rewrite the platform 
implementations.  I don't have a real Win32 or OS-X environment on which 
to test, however.

Anyway, if someone could check out the code from CVS on those platforms, 
run setup.py develop, and then test to see if we have working 
extensions, GLUT, GLE and the like, that would be helpful.

There's also an experimental script in the src directory for 
downloading/installing the GLUT and GLE dlls automatically on Win32 in 
case someone wants to try that.  I've also made it possible to 
completely disable error checking by setting a flag before you import 
the various modules (OpenGL.ERROR_CHECKING).

Have fun all,
Mike

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

Re: [PyOpenGL-Users] Problems with glReadPixels

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

	
	Hi Mike,

Mike C. Fletcher wrote:
>
> It's a bug, I didn't realise that numpy had added unsigned versions of 
> the int types so the code was doing the same as it did for Numeric.  
> I've added support for them on my local machine, will push it out on the 
> next alpha release.

OK, great.

> You're getting all three colours in a single integer IIUC, that is, 
> you're seeing an integer with bits 0-8 with colour 1, 1-16 with colour 
> two etceteras.

I understand that, and I'm not saying it's a bad thing (actually, that's 
EXACTLY what we need right now ;), but it's not quite consistent with 
the regular OpenGL behavior and therefore somewhat unexpected. Would it 
make sense to have a different entry point for this behavior?

Nonetheless, for the float I'm not sure how to use it. How would I split 
a single float into 4 pieces?

Thanks for your help!

	Dirk

Re: [PyOpenGL-Users] Problems with glReadPixels

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

Dirk Reiners wrote:
...
> But now I have some other questions concerning glReadPixels: I'm a little 
> confused about the return types. Adding the following to cube.py:display
>
>     data = glReadPixelsub(0, 0, 1, 1, GL_RGB)
>     print data, type(data[0][0][0])
>     data = glReadPixelsb(0, 0, 1, 1, GL_RGB)
>     print data, type(data[0][0][0])
>     data = glReadPixelsui(0, 0, 1, 1, GL_RGB)
>     print data, type(data[0][0])
>     data = glReadPixelsi(0, 0, 1, 1, GL_RGB)
>     print data, type(data[0][0])
>     data = glReadPixelsf(0, 0, 1, 1, GL_RGB)
>     print data, type(data[0][0])
>
> gives me
>
> [[[0 0 0]]] <type 'numpy.int8'>
> [[[0 0 0]]] <type 'numpy.int8'>
> [[0]] <type 'numpy.int32'>
> [[0]] <type 'numpy.int32'>
> [[ 0.]] <type 'numpy.float32'>
>
> Why do I get signed integers in each case? I would have expected unsigneds for 
> the ub/ui cases.
>   
It's a bug, I didn't realise that numpy had added unsigned versions of 
the int types so the code was doing the same as it did for Numeric.  
I've added support for them on my local machine, will push it out on the 
next alpha release.
> Why do I get only a 2D array for the i/ui/f cases? I would have expected the 
> usual RGB triple.
>   
You're getting all three colours in a single integer IIUC, that is, 
you're seeing an integer with bits 0-8 with colour 1, 1-16 with colour 
two etceteras.
> P.S.: Can you please close our bug? No clue why it showed up 5 times.
>   
Will do so when I sit down to work on the project.

Take care,
Mike

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

Re: [PyOpenGL-Users] Problems with glReadPixels

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

	Hi Mike,

thanks for the quick response.

Mike C. Fletcher wrote:
>
> I don't have any code that uses the un-decorated version.  
> glReadPixelsub seems to work fine (at least, the 
> OpenGLContext/tests/saveimage.py test works fine on my CVS-based version 
> of PyOpenGL).  That's on an AMD64 Gentoo machine.  Code looks identical 
> for the two versions of the function (other than a type being specified 
> by default).
> 
> If you have failing code I could pdb through it might be easier to track 
> down the issue.  One other thing, what versions of ctypes and numpy are 
> you using?

Gah! As it turns out Qt doesn't export the event's position as variables but as 
accessors, so the event.x and event.y that we passed in ReadPixels were 
functions, not positions. Fixing that fixed the error. Not exactly an intuitive 
failure mode, but that's Python for you. ;)

But now I have some other questions concerning glReadPixels: I'm a little 
confused about the return types. Adding the following to cube.py:display

    data = glReadPixelsub(0, 0, 1, 1, GL_RGB)
    print data, type(data[0][0][0])
    data = glReadPixelsb(0, 0, 1, 1, GL_RGB)
    print data, type(data[0][0][0])
    data = glReadPixelsui(0, 0, 1, 1, GL_RGB)
    print data, type(data[0][0])
    data = glReadPixelsi(0, 0, 1, 1, GL_RGB)
    print data, type(data[0][0])
    data = glReadPixelsf(0, 0, 1, 1, GL_RGB)
    print data, type(data[0][0])

gives me

[[[0 0 0]]] <type 'numpy.int8'>
[[[0 0 0]]] <type 'numpy.int8'>
[[0]] <type 'numpy.int32'>
[[0]] <type 'numpy.int32'>
[[ 0.]] <type 'numpy.float32'>

Why do I get signed integers in each case? I would have expected unsigneds for 
the ub/ui cases.
Why do I get only a 2D array for the i/ui/f cases? I would have expected the 
usual RGB triple.

None of these are showstoppers, but they surprised me a bit.

Thanks

	Dirk

P.S.: Can you please close our bug? No clue why it showed up 5 times.

Re: [PyOpenGL-Users] Problems with glReadPixels

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

Dirk Reiners wrote:
> 	Hi everybody,
>
> we're trying to use glReadPixels with PyOpenGL, but we're running into exceptions:
>
> Traceback (most recent call last):
> File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py",
> line 155, in mousePressEvent
>
> index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
> File
> "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line
> 279, in glReadPixels
> ctypes.c_void_p( arrayType.dataPointer(array))
> ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong
> type
>   
...
> This is using 3.0.0a6 on an x86_64 (RHEL) system.
>
> Is anybody using glReadPixels successfully? What are we missing?
>   
I don't have any code that uses the un-decorated version.  
glReadPixelsub seems to work fine (at least, the 
OpenGLContext/tests/saveimage.py test works fine on my CVS-based version 
of PyOpenGL).  That's on an AMD64 Gentoo machine.  Code looks identical 
for the two versions of the function (other than a type being specified 
by default).

If you have failing code I could pdb through it might be easier to track 
down the issue.  One other thing, what versions of ctypes and numpy are 
you using?

Good luck,
Mike

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

[PyOpenGL-Users] Problems with glReadPixels

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

	Hi everybody,

we're trying to use glReadPixels with PyOpenGL, but we're running into exceptions:

Traceback (most recent call last):
File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py",
line 155, in mousePressEvent

index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
File
"/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line
279, in glReadPixels
ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong
type

Adding a few prints to see the types of the involved variables they seem to
be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type
'_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

Is anybody using glReadPixels successfully? What are we missing?

Thanks

	Dirk

[PyOpenGL-Users] Problems with glReadPixels

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

	Hi everybody,

we're trying to use glReadPixels with PyOpenGL, but we're running into exceptions:

Traceback (most recent call last):
File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py",
line 155, in mousePressEvent

index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
File
"/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line
279, in glReadPixels
ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong
type

Adding a few prints to see the types of the involved variables they seem to
be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type
'_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

Is anybody using glReadPixels successfully? What are we missing?

Thanks

	Dirk

Re: [PyOpenGL-Users] I'm incapable of mapping a texture, in my small test.

[Black <py...@bl...>]

Well, textures certainly do work in PyOpenGL, so it isn't just the  
call to glGenTextures() that is the problem. It would be helpful to  
see more of the code that is failing, but my suspicion is that you  
are calling glGenTextures() before the OpenGL context has been  
initialized...



On Jun 21, 2007, at 2:09 PM, Laurence Penney wrote:

> I cannot get textures to work in PyOpenGL (Mac OS 10.4 with PyObjC).
>
> I think the problem is bogus results from glGenTextures(), as in this
> example:
>
> IDs = glGenTextures(10)
> print IDs
>
> (3356347L, 0L, 3343296L, 249236L, 25816960L, 25817200L, 25816660L,
> 0L, 3263844L, 0L)
>
> I previously wrote an OpenGL program in Objective C. There  
> requesting 10
> values reliably gives me the nice sequence:
>
> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
>
> I believe all the values returned in PyOpenGL, including 0, are bogus.
> Duplicate results don't make sense either. Certainly they don't  
> work, and
> nor do textures work if you force a bind to 1 or 2, etc.
>
> -- Laurence
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] I'm incapable of mapping a texture, in my small test.

[Laurence P. <lau...@gm...>]

I cannot get textures to work in PyOpenGL (Mac OS 10.4 with PyObjC).

I think the problem is bogus results from glGenTextures(), as in this 
example:

IDs = glGenTextures(10)
print IDs

(3356347L, 0L, 3343296L, 249236L, 25816960L, 25817200L, 25816660L, 
0L, 3263844L, 0L)

I previously wrote an OpenGL program in Objective C. There requesting 10
values reliably gives me the nice sequence:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

I believe all the values returned in PyOpenGL, including 0, are bogus. 
Duplicate results don't make sense either. Certainly they don't work, and
nor do textures work if you force a bind to 1 or 2, etc.

-- Laurence

Re: [PyOpenGL-Users] Perl vs. Python OpenGL bindings benchmarks

[Aleksandar B. S. <asa...@gm...>]

On 6/5/07, Mike C. Fletcher <mcf...@vr...> wrote:
> Here's what a cProfile run of their "benchmark" method shows (they had a
> .tar.gz on the site, I'd thought it was just the one file, it includes
> the whole suite):
>
>    [ snip ]
>

Mike,

Thanks for running cProfile on this benchmark, and for providing
results.  Everything is as expected, I'd say - overhead regarding
using Python arrays is not that big after all, error checking is
indeed taking lots of running time, and most of running time is spent
in actually awaiting OpenGL to complete drawing (which is very
interesting in itself, because it shows that wrappers are probably not
a bottleneck at all).  So overall, I think we're good, I'll try to
work with POGL guys to have PyOpenGL based benchmark properly run on
their machines, so that they could eventually confirm what I'm seeing
on my machine (that both wrappers are approximately of same
performance), and update results on their site.

As for passing arrays to glVertexPointer: so what would be your
suggestion on best approach to accomplish this (if we're talking about
large arrays, and if we put aside that we should be doing all of this
in C instead of Python)?  I tried to replace using ctypes arrays with
using numpy arrays in trislam_pyopengl_ctp.py, and then to use
glVertexPointer() (with 4 arguments) instead of glVertexPointerf()
(with 1 argument); diff is attached (against trislam_pyopengl_ctp.py
from POGL site) and benchmark results are practically unchanged...

Regards,
Alex

------------
[alex@r51 trislam]$ diff trislam_pyopengl_ctp.py trislam_pyopengl_num.py
24c24
< import ctypes
---
> import numpy
88c88
<     data = (ctypes.c_float * 2 * (count * count * 4))()
---
>     data = numpy.empty((count * count * 4, 2), numpy.float32)
104c104
<     data = (ctypes.c_float * 2 * (count * (count + 1) * 2))()
---
>     data = numpy.empty((count * (count + 1) * 2, 2), numpy.float32)
116c116
<     data = (ctypes.c_float * 2 * (count * count * 6))()
---
>     data = numpy.empty((count * count * 6, 2), numpy.float32)
137c137
<     data = (ctypes.c_float * 2 * (count * (count + 1) * 2))()
---
>     data = numpy.empty((count * (count + 1) * 2, 2), numpy.float32)
171c171
<     glVertexPointerf(va)
---
>     glVertexPointer(2, GL_FLOAT, 0, va)
198c198
<     glVertexPointerf(va)
---
>     glVertexPointer(2, GL_FLOAT, 0, va)
213c213
<     glVertexPointerf(va)
---
>     glVertexPointer(2, GL_FLOAT, 0, va)
245c245
<     glVertexPointerf(va)
---
>     glVertexPointer(2, GL_FLOAT, 0, va)
273c273
<     glVertexPointerf(va)
---
>     glVertexPointer(2, GL_FLOAT, 0, va)
288c288
<     glVertexPointerf(va)
---
>     glVertexPointer(2, GL_FLOAT, 0, va)

Re: [PyOpenGL-Users] Perl vs. Python OpenGL bindings benchmarks

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

Aleksandar B. Samardzic wrote:
> On 6/4/07, Mike C. Fletcher <mcf...@vr...> wrote:
>   
...
>> PyOpenGL does a lot more than just wrap the C call.  In particular, it
>> adds a glGetError call after *every* call to provide Python-like
>> exception-on-error semantics instead of requiring explicit error checks
>> in the code.  The current 3.0.0a6 version also does a logging-enabling
>> call for every function (I'm thinking of making that feature default to
>> off, though it would mean less informative error messages).
>>     
...
> Take a look say into benchmark() function in trislam_pyopengl_ctp.py -
>  benchmark consist of same drawing sequence rendered either 100 times
> or for 10 seconds, whatever takes less.  For vertex arrays (for
> example, draw_quads_va() function), drawing sequence consists
> practically of glVertexPointer() and glDrawArrays() calls; further,
> array of vertex coordinates that is passed to glVertexPointer() is
> prepared beforehand (before benchmark() function loop entered).  Now I
> guess you, as PyOpenGL primary developer, may know better, but if
> array of vertex coordinates is already ctypes based array (and I sent
> some tiny patches, so trislam_pyopengl_ctp.py is benchmark version
> that is ctypes based now), then from what I can see in PyOpenGL code,
> overhead has to be negligible...
>
> On the other side, I do think that alike benchmark could be very
> useful in pointing to performance bottlenecks of a wrapper; thus,
> while it is indeed very simple benchmark, I guess PyOpenGL could only
> benefit if you find some time, sometimes, to play with trislam.
>   
Here's what a cProfile run of their "benchmark" method shows (they had a 
.tar.gz on the site, I'd thought it was just the one file, it includes 
the whole suite):

    * In ~400s, 66s are taken up with the error-checking functionality,
      most of that time is in the individual-vertex versions (array
      versions amortize the cost of the operation over the size of the
      array)
    * 24.1s is due to overhead from the wrapper objects
          o 6.5s is due to direct overhead from the "wrapper" objects
            (mostly bookkeeping (e.g. temporary list creation) and
            function-call overhead)
          o Array conversion overhead
                + 8.4s is due to overhead in determining size of ctypes
                  arrays automatically
                + 7.9s is due to overhead in determining the "stride
                  size" of ctypes arrays automatically

The ctypes arrays are spending so much time in those two functions 
because they don't have a "dims" member, as seen in numpy arrays, so 
they have a little while loop that adds up the length of the 
sub-component arrays, producing lots of intermediate objects as a result.

Making the error-checking an optional C module would be doable, but it's 
still going to be a fairly large part of total run-time (we would see a 
maximum of 16% speedup).  Similarly, we might get a 1.5% speedup by 
writing the wrapper function in C.  We might get that to 6% if we were 
to write the whole of the wrapping system in C (which I really do *not* 
want to do).  Altogether we could get maybe 25% from the lower-hanging 
fruit of optimisation.

We also seem to spend 7.9s (2%) in the time.time function and almost 
207s (52% of time) waiting for glFlush calls to complete.  That would 
suggest to me that we're seeing synchronization issues skewing results 
at least part of the time.  I'm running all of this on Python 2.5 on a 
Gentoo Linux box, by the way.

Anyway, hope that helps somewhat,
Mike

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      338    0.237    0.001    0.242    0.001 PyBench.py:311(fade_to_white)
   369465    1.329    0.000    1.826    0.000 
arraydatatype.py:17(getHandler)
   123155    0.557    0.000    1.278    0.000 
arraydatatype.py:45(dataPointer)
   123155    0.542    0.000    1.820    0.000 
arraydatatype.py:55(voidDataPointer)
   123155    0.797    0.000    1.649    0.000 arraydatatype.py:59(asArray)
   123155    0.636    0.000    7.987    0.000 arraydatatype.py:71(unitSize)
   123155    0.452    0.000    1.941    0.000 arrayhelpers.py:52(__call__)
   123155    0.449    0.000    8.436    0.000 
arrayhelpers.py:78(arraySizeOfFirst)
   123155    0.348    0.000    0.348    0.000 contextdata.py:22(getContext)
   123155    0.815    0.000    1.489    0.000 contextdata.py:35(setValue)
   123155    0.449    0.000    2.097    0.000 converters.py:111(__call__)
   123155    0.185    0.000    0.185    0.000 converters.py:155(__call__)
   123155    0.192    0.000    0.192    0.000 converters.py:169(__call__)
   492620    1.779    0.000    2.866    0.000 ctypesarrays.py:55(types)
   369465    1.727    0.000    5.339    0.000 ctypesarrays.py:63(dims)
   123155    0.169    0.000    0.169    0.000 ctypesarrays.py:69(asArray)
   123155    1.441    0.000    6.781    0.000 ctypesarrays.py:72(unitSize)
 17225384   48.363    0.000   66.352    0.000 error.py:162(glCheckError)
 14887425   17.989    0.000   17.989    0.000 error.py:191(nullGetError)
   125123    0.217    0.000    0.217    0.000 error.py:209(onBegin)
   125123    0.208    0.000    0.208    0.000 error.py:212(onEnd)
   125123    0.875    0.000    1.632    0.000 exceptional.py:44(glBegin)
   125123    1.020    0.000    1.552    0.000 exceptional.py:48(glEnd)
       49    0.000    0.000    0.000    0.000 
formathandler.py:90(registerEquivalent)
    49176    0.058    0.000    0.058    0.000 
trislam_pyopengl_ctp.py:156(draw_empty)
       26    0.000    0.000    0.000    0.000 
trislam_pyopengl_ctp.py:159(stats_empty)
     5583   17.723    0.003   34.072    0.006 
trislam_pyopengl_ctp.py:162(draw_quads)
    20661    2.306    0.000    6.676    0.000 
trislam_pyopengl_ctp.py:173(draw_quads_va)
       52    0.000    0.000    0.000    0.000 
trislam_pyopengl_ctp.py:181(stats_quads)
     6829   12.125    0.002   24.593    0.004 
trislam_pyopengl_ctp.py:189(draw_qs)
    18933    4.886    0.000   10.204    0.001 
trislam_pyopengl_ctp.py:198(draw_qs_va)
    24497    0.351    0.000    0.409    0.000 
trislam_pyopengl_ctp.py:210(draw_qs_dl)
    22370    0.540    0.000    4.787    0.000 
trislam_pyopengl_ctp.py:214(draw_qs_va_dl)
      104    0.000    0.000    0.000    0.000 
trislam_pyopengl_ctp.py:224(stats_qs)
     4010   22.822    0.006   44.041    0.011 
trislam_pyopengl_ctp.py:232(draw_tris)
    20307    2.815    0.000    7.291    0.000 
trislam_pyopengl_ctp.py:246(draw_tris_va)
       52    0.000    0.000    0.000    0.000 
trislam_pyopengl_ctp.py:256(stats_tris)
     9041   12.119    0.001   24.633    0.003 
trislam_pyopengl_ctp.py:264(draw_ts)
    20087    4.529    0.000    9.986    0.000 
trislam_pyopengl_ctp.py:273(draw_ts_va)
    29773    0.335    0.000    0.405    0.000 
trislam_pyopengl_ctp.py:285(draw_ts_dl)
    20797    0.501    0.000    4.496    0.000 
trislam_pyopengl_ctp.py:289(draw_ts_va_dl)
      104    0.000    0.000    0.000    0.000 
trislam_pyopengl_ctp.py:299(stats_ts)
   252064    2.706    0.000    3.402    0.000 
trislam_pyopengl_ctp.py:699(start_frame)
   252064  205.511    0.001  207.370    0.001 
trislam_pyopengl_ctp.py:703(end_frame)
      339    7.990    0.024  398.633    1.176 
trislam_pyopengl_ctp.py:707(benchmark)
   123155    6.467    0.000   24.188    0.000 wrapper.py:294(wrapperCall)
   123155    0.148    0.000    0.148    0.000 {_ctypes.addressof}
   492620    0.552    0.000    0.552    0.000 {callable}
   738930    1.246    0.000    1.246    0.000 {getattr}
       49    0.000    0.000    0.000    0.000 {hasattr}
   369465    0.587    0.000    0.587    0.000 {isinstance}
   247663    0.325    0.000    0.325    0.000 {len}
  1108733    1.279    0.000    1.279    0.000 {method 'append' of 'list' 
objects}
      339    0.001    0.000    0.001    0.000 {method 'disable' of 
'_lsprof.Profiler' objects}
   615775    0.823    0.000    0.823    0.000 {method 'get' of 'dict' 
objects}
       98    0.000    0.000    0.000    0.000 {method 'has_key' of 
'dict' objects}
      338    0.001    0.000    0.001    0.000 {method 'keys' of 'dict' 
objects}
       13    0.000    0.000    0.000    0.000 {method 'write' of 'file' 
objects}
   246655    0.555    0.000    0.555    0.000 {range}
  3848500    7.971    0.000    7.971    0.000 {time.time}
   246310    0.584    0.000    0.584    0.000 {zip}

For completeness, the diff against the trislam version in their archive, 
this version will run under Python 2.5 (which provides the cProfile module):

mcfletch@raistlin:~/tmp/trislam$ diff trislam_pyopengl_ctp.py 
trislam_pyopengl_ctp_profile.py
2a3
 > from __future__ import division
15a17,18
 > ##from OpenGL.error import ErrorChecker
 > ##ErrorChecker.registerChecker( ErrorChecker.nullGetError )
20d22
< from __future__ import division
25a28,29
 > import cProfile
 > PROFILER = cProfile.Profile()
662a667,668
 >     PROFILER.print_stats(  )
 >     PROFILER.dump_stats( 'test.profile' )
670a677
 >
671a679
 >     import cProfile
676c684
<         benchmark()
---
 >         PROFILER.runcall( benchmark )
914,919c922,928
< init()
< print "Benchmarks:",
< glutDisplayFunc(display)
< glutIdleFunc(display)
< glutKeyboardFunc(keyboard)
< glutMainLoop()
---
 > if __name__ == "__main__":
 >       init()
 >       print "Benchmarks:",
 >       glutDisplayFunc(display)
 >       glutIdleFunc(display)
 >       glutKeyboardFunc(keyboard)
 >       glutMainLoop()

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