pyopengl-users — Discussion of all PyOpenGL matters.

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

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

On 6/4/07, Mike C. Fletcher <mcf...@vr...> wrote:
> Aleksandar B. Samardzic wrote:
> > There was a set of benchmark results posted recently, comparing Perl
> > OpenGL (POGL) bindings performance with performance of some other
> > OpenGL bindings; results of comparison between Perl and Python OpenGL
> > bindings could be found here:
> >   http://graphcomp.com/pogl.cgi?v=0111s3B2&r=s3m3
> > PyOpenGL is claimed to be largely inferior in performance, especially
> > regarding using vertex array functionality.  Python benchmark code is
> > somewhat improved in the meantime, and PyOpenGL version 3, instead of
> > version 2, is used to retest, but claimed low PyOpenGL performance is
> > still there.  I was able to compare PyOpenGL based benchmark results
> > with Perl SDL based OpenGL binding results, and PyOpenGL perforance is
> > superior on my machine (as expected, because after all PyOpenGL in
> > version 3 is really thin layer above OpenGL C code); however I'm
> > unable to compile POGL properly, and run POGL based benchmarks on my
> > machine.  I do expect however, becauseof above mentioned reason, that
> > PyOpenGL performance must be at least in range with POGL performance,
> > thus I'd suggest to anyone interested to try  to run both benchmarks
> > on its machine, and to send results to POGL team; of course, further
> > improvements in Python benchmark code would be welcome too.
> >
> Actually, I would be *very* surprised if PyOpenGL is anywhere near the
> same speed.
>
> 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).
>
> That said, I couldn't get their benchmark code to run in PyOpenGL
> ("PyBench" doesn't seem to be the pybench module I'm familiar with), and
> didn't have enough time to try fixing it before checking to see if there
> are any gross issues with it.
>
> As for the vertex array functionality; we do a *lot* of Python-side code
> to do a vertex translation.  The PyOpenGL 3.x line has a far more
> flexible engine for the array sources than 2.x did, allowing run-time
> plugging of new array data-types.  The cost of that is some performance
> penalty on passing each array.  Larger arrays push average that expense
> out over the whole array, so a 10,000 point array would have almost no
> appreciable overhead (and would likely be faster than PyOpenGL 2.x),
> while passing in hundreds of 3 or 4 element arrays would show a huge
> overhead compared to PyOpenGL 2.x (which did all the array conversions
> in C, but often wound up silently copying the arrays).

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.

Regards,
Alex

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

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

Aleksandar B. Samardzic wrote:
> There was a set of benchmark results posted recently, comparing Perl
> OpenGL (POGL) bindings performance with performance of some other
> OpenGL bindings; results of comparison between Perl and Python OpenGL
> bindings could be found here:
>   http://graphcomp.com/pogl.cgi?v=0111s3B2&r=s3m3
> PyOpenGL is claimed to be largely inferior in performance, especially
> regarding using vertex array functionality.  Python benchmark code is
> somewhat improved in the meantime, and PyOpenGL version 3, instead of
> version 2, is used to retest, but claimed low PyOpenGL performance is
> still there.  I was able to compare PyOpenGL based benchmark results
> with Perl SDL based OpenGL binding results, and PyOpenGL perforance is
> superior on my machine (as expected, because after all PyOpenGL in
> version 3 is really thin layer above OpenGL C code); however I'm
> unable to compile POGL properly, and run POGL based benchmarks on my
> machine.  I do expect however, because of above mentioned reason, that
> PyOpenGL performance must be at least in range with POGL performance,
> thus I'd suggest to anyone interested to try  to run both benchmarks
> on its machine, and to send results to POGL team; of course, further
> improvements in Python benchmark code would be welcome too.
>   
Actually, I would be *very* surprised if PyOpenGL is anywhere near the 
same speed.

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).

That said, I couldn't get their benchmark code to run in PyOpenGL 
("PyBench" doesn't seem to be the pybench module I'm familiar with), and 
didn't have enough time to try fixing it before checking to see if there 
are any gross issues with it.

As for the vertex array functionality; we do a *lot* of Python-side code 
to do a vertex translation.  The PyOpenGL 3.x line has a far more 
flexible engine for the array sources than 2.x did, allowing run-time 
plugging of new array data-types.  The cost of that is some performance 
penalty on passing each array.  Larger arrays push average that expense 
out over the whole array, so a 10,000 point array would have almost no 
appreciable overhead (and would likely be faster than PyOpenGL 2.x), 
while passing in hundreds of 3 or 4 element arrays would show a huge 
overhead compared to PyOpenGL 2.x (which did all the array conversions 
in C, but often wound up silently copying the arrays).

Have fun,
Mike

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

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

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

There was a set of benchmark results posted recently, comparing Perl
OpenGL (POGL) bindings performance with performance of some other
OpenGL bindings; results of comparison between Perl and Python OpenGL
bindings could be found here:
  http://graphcomp.com/pogl.cgi?v=0111s3B2&r=s3m3
PyOpenGL is claimed to be largely inferior in performance, especially
regarding using vertex array functionality.  Python benchmark code is
somewhat improved in the meantime, and PyOpenGL version 3, instead of
version 2, is used to retest, but claimed low PyOpenGL performance is
still there.  I was able to compare PyOpenGL based benchmark results
with Perl SDL based OpenGL binding results, and PyOpenGL perforance is
superior on my machine (as expected, because after all PyOpenGL in
version 3 is really thin layer above OpenGL C code); however I'm
unable to compile POGL properly, and run POGL based benchmarks on my
machine.  I do expect however, because of above mentioned reason, that
PyOpenGL performance must be at least in range with POGL performance,
thus I'd suggest to anyone interested to try  to run both benchmarks
on its machine, and to send results to POGL team; of course, further
improvements in Python benchmark code would be welcome too.

Regards,
Alex

Re: [PyOpenGL-Users] Zipping and rendering numpy arrays

[Erik J. <ejo...@fa...>]

On Tue, 29 May 2007 18:49:29 -0700, "Martin Blais" said:
> Hi
> 
> I have 2 or 3 long numpy arrays to send to the vertex pipeline.
> This is actually most of my rendering time.
> 
> Here is what I do in Python:
> 
> def gliVertexArrays(a1, a2, a3=None):
>     """
>     Zip and output the given numpy arrays of floats through the GL vertex
>     pipeline.
>     """
>     if a3 is None:
>         list(starmap(glVertex2f, izip(a1, a2)))
>     else:
>         list(starmap(glVertex3f, izip(a1, a2, a3)))
> 
> Is there a C function that does this?

If I correctly understand your code, you are interleaving individual x y
and z coordinate arrays, and then calling glVertex on each set of
vertices.  I think that the function call overhead to do this is very
expensive.

> I saw glVertexPointer, but it seems I would have to create a temporary
> array that would contain both my arrays just to call this function.
> I'd rather avoid the memory allocation and zip-loop in C.

Using OpenGL vertex arrays to directly render a Numeric array can be
very fast, as long as you don't need to create the Numeric array every
frame.  Changing large portions of the array can also be slow.

If your vertices stay mostly fixed relative to each other, then you
should be able to get huge speed ups with vertex arrays using
glVertexPointer.  Display lists might also be worth investigating.

> This seems pretty basic and reasonable to me... is it already in
> PyOpenGL?

Storing your x, y and z coordinates in separate arrays strikes me as a
bit unusual, but then I'm not the most experienced OpenGL programmer in
the world.

> If not, is there another way I'm not thinking of?

If what I suggested above doesn't help, provide some more info about
what you are trying to do, and I'll see if I can offer any advice.

Erik

[PyOpenGL-Users] Picking with multiple viewports

[Peter S. <psc...@gm...>]

I have implemented picking using the selection buffer by constructing my
list of names for my objects with glPushName(index) and glPopName() and
making a call to glSelectWithCallback(...) when the user clicks on the
window.  This works perfectly when I am rendering a scene with a single
viewport in my OpenGL window.

But, ..... I have an pyOpenGL app that renders a scene with four viewports
(much like the default view in Maya, 3D studio max, etc.) like so:

------------------------
|      A       |     B     |
------------------------
|      C       |     D    |
------------------------

While debugging, I set each viewport to render the same scene from the same
camera angle.  Picking only works in the "A" viewport, and I only register
hits from the viewport that was rendered last.

I draw each viewport by doing the following:
###### START SNIP #########
            if (view==0):
                glViewport (0, window_height/2, window_width/2,
window_height/2);
                glMatrixMode (GL_PROJECTION); # // Select The Projection
Matrix
                glLoadIdentity (); # // Reset The Projection Matrix
                # // Set Up Perspective Mode To Fit 1/4 The Screen (Size Of
A Viewport)
                gluPerspective( 45.0, float(self.windowSize[0]/2.0) / float(
self.windowSize[1]/2.0), 0.1, 500.0 );

               # Select The Modelview Matrix
               glMatrixMode(GL_MODELVIEW);
               # Reset The Modelview Matrix
               glLoadIdentity();
               # Clear the Depth Buffer
               glClear(GL_DEPTH_BUFFER_BIT);

               self._DrawGLScene()
            ######################################
            # Top right: negative y-axis
            if (view==1):
                glViewport (window_width/2, window_height/2, window_width/2,
window_height/2);
                glMatrixMode (GL_PROJECTION);   # // Select The Projection
Matrix
                glLoadIdentity (); # // Reset The Projection Matrix
                # // Set Up Perspective Mode To Fit 1/4 The Screen (Size Of
A Viewport)
                gluPerspective( 45.0, float(self.windowSize[0]/2.0) / float(
self.windowSize[1]/2.0), 0.1, 500.0 )

               # Select The Modelview Matrix
               glMatrixMode(GL_MODELVIEW);
               # Reset The Modelview Matrix
               glLoadIdentity();
               # Clear the Depth Buffer
               glClear(GL_DEPTH_BUFFER_BIT);

               self._DrawGLScene()

               ...
               ...

        #  since this is double buffered, swap the buffers to display what
just got drawn.
        glutSwapBuffers()

###### END SNIP #########

I implement picking by making a call to glSelectWithCallback(...) following
the logic from example code posted at the first link from the google search
results titled  "3-D programming with python" from:
http://www.google.com/search?hl=en&client=firefox-a&rls=com.ubuntu%3Aen-US%3Aofficial&hs=HzU&q=%223-D+programming+with+python%22+site%3Aacm.org&btnG=Search
(note:  I think you might need an ACM subscription to access the example
source code posted in the above link that I used as a basis for my own code)

If it helps, I'm running python 2.5 in Ubuntu 7.04 with all the default
packages taken from synaptic (i.e. i did not compile pyopengl or anything
myself).

Let me know if you have any ideas.

Thanks!
Pete

[PyOpenGL-Users] Zipping and rendering numpy arrays

[Martin B. <bl...@fu...>]

Hi

I have 2 or 3 long numpy arrays to send to the vertex pipeline.
This is actually most of my rendering time.

Here is what I do in Python:

def gliVertexArrays(a1, a2, a3=None):
    """
    Zip and output the given numpy arrays of floats through the GL vertex
    pipeline.
    """
    if a3 is None:
        list(starmap(glVertex2f, izip(a1, a2)))
    else:
        list(starmap(glVertex3f, izip(a1, a2, a3)))

Is there a C function that does this?

I saw glVertexPointer, but it seems I would have to create a temporary
array that would contain both my arrays just to call this function.
I'd rather avoid the memory allocation and zip-loop in C.

This seems pretty basic and reasonable to me... is it already in PyOpenGL?
If not, is there another way I'm not thinking of?

Any idea welcome.
cheers,

[PyOpenGL-Users] OpenGL and py2exe

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

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

[PyOpenGL-Users] GLU verticies

[Andrew W. <and...@al...>]

Hello,
  I'm trying to get the verticies out of a GLU_tesselator.  I don't really
want to use the feedback buffer as it applies all the matrix transformations
(floating point errors) and is quite slow in pyopengl, are there any other
method to do this?
  Thanks
  Andrew



On 5/22/07, Jason Ward <ir...@gm...> wrote:
>
> Hi
>
> I am wanting to do collision detection.
> In order to do this I need to keep track of the vertices of my polygons.
> So I am storing all the vertices and then I am multiplying them by the
> modelview matrix, then the product of that I multiply
> by the projection matrix (which is a perspective one).
>
> To test whether my values are correct I then load the identity matrix and
> draw a white line using the same x and z coords
> that I calculated, (that is where my vertex should lie) the white line is
> drawn down the y axis so I don't bother calculating a y value.
>
> This doesn't work for any transformations.
> Either I am doing the matrix multiplications wrong or I am using the wrong
> matices.
>
> If there is a simpler way of keeping track of where my vertices are please
> let me know.
> If I can read the vertex values straight from the computer without doing
> any calcs please let me know.
>
>
>
> -------------------------------------------------------------------------
> 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] Matices

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

Jason Ward wrote:

> I am wanting to do collision detection.
> In order to do this I need to keep track of the vertices of my polygons.
> So I am storing all the vertices and then I am multiplying them by the 
> modelview matrix, then the product of that I multiply
> by the projection matrix (which is a perspective one).

Wouldn't it be better to do collision detection in world
space rather than screen space? I don't see the need for
a viewing transformation here.

But if you really want to, the easiest way is to use
gluProject.

--
Greg

[PyOpenGL-Users] subscribe

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

subscribe

[PyOpenGL-Users] Matices

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

Hi

I am wanting to do collision detection.
In order to do this I need to keep track of the vertices of my polygons.
So I am storing all the vertices and then I am multiplying them by the
modelview matrix, then the product of that I multiply
by the projection matrix (which is a perspective one).

To test whether my values are correct I then load the identity matrix and
draw a white line using the same x and z coords
that I calculated, (that is where my vertex should lie) the white line is
drawn down the y axis so I don't bother calculating a y value.

This doesn't work for any transformations.
Either I am doing the matrix multiplications wrong or I am using the wrong
matices.

If there is a simpler way of keeping track of where my vertices are please
let me know.
If I can read the vertex values straight from the computer without doing any
calcs please let me know.

Re: [PyOpenGL-Users] Subversion and Free GLUT

[shirish <shi...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi mike,
           if you move you also then get the option to use trac for
viewing stuff , atleast for people like me. Something like
http://transmission.m0k.org/development.php

Go down the page & you can see one can checkout from svn repository
while at the same time if want to view the progress of the project
then can use trac to  view it.

For people can also issue tickets & view the progress.
http://transmission.m0k.org/trac/roadmap
http://transmission.m0k.org/trac/browser/trunk

Actually  lot of open source projects are using trac alongwith
subversion. It looks, feels good, just a suggestion. See if you like
it.

- --
          Shirish Agarwal
  This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGUp2tlQ1T+3KaixcRAtn+AJoD5cmdtlaTP3dsK8mJvuaeINGFSQCeNaO2
OuAqZWzhAtf1X2PCwkc4QV0=
=zmPy
-----END PGP SIGNATURE-----

[PyOpenGL-Users] OpenGL Sweep Selection??

[Amy L. <al...@ms...>]

Has anyone implemented OpenGL Sweep Selection?? If so, can you give me any
pointers?  I'm relatively new to Python, but am already very comfortable
with it.  I'm very new to OpenGL, and have looked at tutorials, but to no
avail, I still don't have sweep selection implemented properly.  Selection
of one object works beautifully.  Here's the code that I implemented to do
single object selection:

 

def pick3d( self, event ):

 

      # 1. initialization

      self.recordMouse(event)

      x = event.pos().x()

      y = event.pos().y()

      pixels = 5

      buffer_size = 512

      viewport = glGetIntegerv(GL_VIEWPORT)

 

      # 2. selection logic

      glSelectBuffer(buffer_size)

      glRenderMode(GL_SELECT)

      glInitNames()

      glMatrixMode(GL_PROJECTION)

      previousviewmatrix = glGetDoublev(GL_PROJECTION_MATRIX)

      glLoadIdentity()

      gluPickMatrix( x, viewport[3]-y, pixels, pixels, viewport )

      glMultMatrixd(previousviewmatrix)

      glMatrixMode(GL_MODELVIEW)

      self.drawScene( self )

      glFlush()

      glMatrixMode(GL_PROJECTION)

      glLoadMatrixd(previousviewmatrix)

      self.buffer = glRenderMode(GL_RENDER)

 

      # 3. update graphics

      self.updateGL()

      

      # 4. process selction buffer if control is pressed

      return self.processBuffer()

 

where processBuffer is:  

 

   def processBuffer(self):

       print "--------- pick3d ----------"

       print " - nhits =", len( self.buffer )

       if( len(self.buffer) == 0 ): print "hit nothing"

       else:

           min = self.buffer[0][0] 

           for record in self.buffer:

               minDepth, maxDepth, names = record

               # add all hit objects to selectedObjects

               for i in range(len(names)):

                   if(self.selected.count(names[i]) == 1):

                       print " - unselected: ", names[i]

                       self.selected.remove(names[i])

                   else:

                       self.selected.append(names[i])                  

       print " - selectedObjects: ", self.selected

 

       return self.selected

 

The reason processBuffer is defined in this way is b/c I'm only working in
2D right now.  I know that to use this for 3D, I'd have to check the depth.
Currently, for multiple object selection, I'm requiring the user to do
ctrl+leftMouse.  As long as ctrl+leftMouse is done, I call pick3d which in
turn will add the selectedObject to my list variable.  

 

I know this is not the best way to do this, but it works for my purposes.
Can someone please tell me how I could 'edit' this to make it work for a
sweep selection?

 

Thanks,

Amy

 

 

Re: [PyOpenGL-Users] Subversion and Free GLUT

[shirish <shi...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 5/21/07, Mike C. Fletcher  wrote:
> shirish wrote:
> ...
> > Now it took me around 2 hrs. to browse through the whole tree. Being a
> > non-developer as well as not knowing the tree but if it was a
> > Subversion tree it would have taken me atleast 50% of the time. I'm
> > sure you have looked at Subversion which sourceforge also has. It
> > would be cool to use that. Of course I do understand there are still
> > few bugs/issues http://subversion.tigris.org/roadmap.html but do see
> > both as curous people like me as well as a developer like you benefit
> > from it as its much more easy to go through.
> >
> Really?  Never really found much of a difference between the web
> interfaces for them, then again I normally just check out and browse
> locally.  We haven't moved to subversion mostly because I expect it to
> take a solid day of work and I haven't had a solid day when there wasn't
> anything to do in the project coding-wise.

First of all thanx for answering so quickly. While I can agree with that but
would like to see in subversion at some point of time. Believe me when I
say there is a world of difference.

> > Free GLUT :- Are you thinking/making moves to use Free GLUT instead of
> > OpenGLUT as development has stagnated there & is more or less a
> > stagnated product/project.  http://en.wikipedia.org/wiki/Freeglut.
> > Hoping to get some comments from you on the same. Cheers !
> >
> AFAIK we're already FreeGLUT compatible with PyOpenGL 3.x.  There is a
> module in the GLUT directory which provides the FreeGLUT-specific
> extensions which is imported into the GLUT namespace.

Aha, I didn't know that, also I'm no package builder but an end-user who just
wants to play the games which are made on pyopengl something like
http://pyweek.org/4/entries/

and still for end-users either on windows as well as GNU/Linux (Ubuntu) haven't
found a simple way to install. Would be looking forward though to see
3.0 in beta
& then final phase. Maybe in the documentation somewhere maybe you or some
of the users can give idea from where end-users like me can have pre-compiled
binaries.

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

- --
          Shirish Agarwal
  This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGUbp6lQ1T+3KaixcRAoacAJ4ygRzVKX4rLSDic9aaYhDylz6bawCeOnvS
IEqCDlAs7/9YbPJa+CYSq4M=
=3wDp
-----END PGP SIGNATURE-----

Re: [PyOpenGL-Users] Subversion and Free GLUT

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

shirish wrote:
...
> Now it took me around 2 hrs. to browse through the whole tree. Being a
> non-developer as well as not knowing the tree but if it was a
> Subversion tree it would have taken me atleast 50% of the time. I'm
> sure you have looked at Subversion which sourceforge also has. It
> would be cool to use that. Of course I do understand there are still
> few bugs/issues http://subversion.tigris.org/roadmap.html but do see
> both as curous people like me as well as a developer like you benefit
> from it as its much more easy to go through.
>   
Really?  Never really found much of a difference between the web 
interfaces for them, then again I normally just check out and browse 
locally.  We haven't moved to subversion mostly because I expect it to 
take a solid day of work and I haven't had a solid day when there wasn't 
anything to do in the project coding-wise.
> Free GLUT :- Are you thinking/making moves to use Free GLUT instead of
> OpenGLUT as development has stagnated there & is more or less a
> stagnated product/project.  http://en.wikipedia.org/wiki/Freeglut.
> Hoping to get some comments from you on the same. Cheers !
>   
AFAIK we're already FreeGLUT compatible with PyOpenGL 3.x.  There is a 
module in the GLUT directory which provides the FreeGLUT-specific 
extensions which is imported into the GLUT namespace.

Have fun,
Mike

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

[PyOpenGL-Users] Subversion and Free GLUT

[shirish <shi...@gm...>]

Hi all,
      Glad to see you guys are are still doing something. While
browsing the CVS came to know how big the whole thing is. A list of
things where you guys did recent work :-

http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/GL/EXT/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/GL/MESAX/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/GL/NV/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/GL/VERSION/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/GL/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/GLUT/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/raw/GL/APPLE/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/raw/GL/EXT/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/raw/GL/MESAX/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/raw/GL/NV/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/raw/GL/VERSION/
http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/src/

http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/OpenGL/

Now it took me around 2 hrs. to browse through the whole tree. Being a
non-developer as well as not knowing the tree but if it was a
Subversion tree it would have taken me atleast 50% of the time. I'm
sure you have looked at Subversion which sourceforge also has. It
would be cool to use that. Of course I do understand there are still
few bugs/issues http://subversion.tigris.org/roadmap.html but do see
both as curous people like me as well as a developer like you benefit
from it as its much more easy to go through.


Free GLUT :- Are you thinking/making moves to use Free GLUT instead of
OpenGLUT as development has stagnated there & is more or less a
stagnated product/project.  http://en.wikipedia.org/wiki/Freeglut.
Hoping to get some comments from you on the same. Cheers !
-- 
          Shirish Agarwal
  This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17

Re: [PyOpenGL-Users] GLSL issue

[Crni G. <cg...@gm...>]

On 5/20/07, Mike C. Fletcher <mcf...@vr...> wrote:
> Crni Gorac wrote:
> > Am trying PyOpenGL on Linux together with recently announced Mesa
> > 6.5.3, that has full support for OpenGL shading language.  PyOpenGL
> > seems to be working fine, I was able to compile and use my shaders.
> > There was a PyOpenGL fix needed, however: glGetObjectParameter() calls
> > from OpenGL/GL/VERSION/GL_2_0.py should be replaced with
> > glGetShaderiv()/glGetProgramiv().  I was able to run my program by
> > simply deleting _afterCheck() error checking function registration
> > from above file, and then re-compiling and re-installing PyOpenGL, but
> > this issue should be probably properly fixed...
> >
> Hmm, I'm running Mesa 6.5.2 on my Gentoo machine (with the nvidia
> driver) and am not seeing errors with the original code.  I've replaced
> the calls in _afterCheck with the glGetShaderiv and glGetProgramiv
> calls.  Is there a reference somewhere that describes why the
> glGetObjectParameter calls are wrong, and in which cases they should be
> used?

Please find attached my test program.  I guess I can only point that
above call is not mentioned in OpenGL 2.0 specification:
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf...

There is really great deal of confusion regarding what actually
constitutes OpenGL 2.0, hopefully upcoming Mesa 7.0 release (that will
advertise OpenGL 2.1 support) will stabilize these things...

Anyway, kudos for your great work on PyOpenGL!

Best,
Crni

Re: [PyOpenGL-Users] GLSL issue

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

Crni Gorac wrote:
> Am trying PyOpenGL on Linux together with recently announced Mesa
> 6.5.3, that has full support for OpenGL shading language.  PyOpenGL
> seems to be working fine, I was able to compile and use my shaders.
> There was a PyOpenGL fix needed, however: glGetObjectParameter() calls
> from OpenGL/GL/VERSION/GL_2_0.py should be replaced with
> glGetShaderiv()/glGetProgramiv().  I was able to run my program by
> simply deleting _afterCheck() error checking function registration
> from above file, and then re-compiling and re-installing PyOpenGL, but
> this issue should be probably properly fixed...
>   
Hmm, I'm running Mesa 6.5.2 on my Gentoo machine (with the nvidia 
driver) and am not seeing errors with the original code.  I've replaced 
the calls in _afterCheck with the glGetShaderiv and glGetProgramiv 
calls.  Is there a reference somewhere that describes why the 
glGetObjectParameter calls are wrong, and in which cases they should be 
used?

Thanks,
Mike

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

Re: [PyOpenGL-Users] GLUT import error

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

Mike C. Fletcher wrote:
> 甜瓜 wrote:
>   
...
>> Is this a bug? What should I do for correctly importing GLUT?
>> Thank you.
>>   
>>     
> Yup, it's a bug.  I'll try to find some time to work on it this 
> weekend.  
The fix is in CVS now, if you don't *use* GLUT then you should still be 
able to load without it (at least, *this* error won't cause a problem, I 
haven't yet attempted to uninstall GLUT from my system and test it).

Have fun,
Mike

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

Re: [PyOpenGL-Users] GLUT import error

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

甜瓜 wrote:
> I have installed PyOpenGL-3.0.0a6 in Python2.5 by using "python
> setup.py install". However, when I was using it:
>   
>>>> import OpenGL.GLUT
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "d:\python25\lib\site-packages\pil\__init__.py", line 4, in <module>
>     #
>   File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in <module>
> AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow'
>
> Is this a bug? What should I do for correctly importing GLUT?
> Thank you.
>   
Yup, it's a bug.  I'll try to find some time to work on it this 
weekend.  That said, the bug I'm talking about fixing is that it's not 
returning a NULL function object that will raise a more informative 
error when you try to call it.  It looks like loading the GLUT DLL is 
failing.  You are on Win32, so it's *possible* you just don't have GLUT 
installed in system32, otherwise we'll need to track down why it's not 
finding/loading the DLL for you.

Good luck,
Mike

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

[PyOpenGL-Users] GLUT import error

[<lit...@gm...>]

I have installed PyOpenGL-3.0.0a6 in Python2.5 by using "python
setup.py install". However, when I was using it:
>>> import OpenGL.GLUT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "d:\python25\lib\site-packages\pil\__init__.py", line 4, in <module>
    #
  File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in <module>
AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow'

Is this a bug? What should I do for correctly importing GLUT?
Thank you.

ShenLei

[PyOpenGL-Users] GLSL issue

[Crni G. <cg...@gm...>]

Am trying PyOpenGL on Linux together with recently announced Mesa
6.5.3, that has full support for OpenGL shading language.  PyOpenGL
seems to be working fine, I was able to compile and use my shaders.
There was a PyOpenGL fix needed, however: glGetObjectParameter() calls
from OpenGL/GL/VERSION/GL_2_0.py should be replaced with
glGetShaderiv()/glGetProgramiv().  I was able to run my program by
simply deleting _afterCheck() error checking function registration
from above file, and then re-compiling and re-installing PyOpenGL, but
this issue should be probably properly fixed...

HTH,
Crni

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

[Alfonso C. <mis...@gm...>]

I exclude GLUT because it's malfunctioning, on my computer. I get the
following exception, when I import GLUT:

Traceback (most recent call last):
  File "C:\Documents and Settings\Alfonso\My
Documents\Python\PyOpenGL\PyOpenGL-
Demo-3.0.0a6\PyOpenGL-Demo\NeHe\lesson6.py", line 47, in <module>
    from OpenGL.GLUT import *
  File "build\bdist.win32\egg\OpenGL\GLUT\__init__.py", line 4, in <module>
  File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in <module>
AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow'

Since wxPython is operating well, I just left GLUT alone. In the test I
wrote, I rasterize the display, create a polygon the size of the
display-area, and *attempt* to render a mapped texture, on each cycle. I had
experienced no troble, coloring the rendered polygon. I've opened the
specified image, in a seperate program, and found that the image loads
properly. From my previous inquiries, I've come to believe that I've set up
OpenGL correctly. The texture ought to render. I do not understand what I am
doing wrongly.

from wx import *
from wx.glcanvas import GLCanvas

from OpenGL.GL  import *
from OpenGL.GLU import *

import Image, sys, math

SCREEN_WIDTH  = 400
SCREEN_HEIGHT = 400

def load_image(image_name):
    image = Image.open(image_name)

    width  = image.size[0]
    height = image.size[1]

    image_string = image.tostring('raw', 'RGBX', 0, -1)
    image_id     = glGenTextures(1)

    glBindTexture(GL_TEXTURE_2D, image_id)

    glPixelStorei(GL_UNPACK_ALIGNMENT, 1)
    glTexImage2D(GL_TEXTURE_2D, 0, 4, width, height, 0,
                 GL_RGBA, GL_UNSIGNED_BYTE, image_string)

    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP)
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP)
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST)
    glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL)

    return image_id

class Canvas(GLCanvas):
    def __init__(self, parent, image_name):
        GLCanvas.__init__(self, parent, -1)
        EVT_PAINT(self, self.paint)
        self.texture_id = load_image(image_name)

    def paint(self, event):
        global SCREEN_WIDTH
        global SCREEN_HEIGHT

        dc = wx.PaintDC(self)
        self.SetCurrent()

        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
        glLoadIdentity()

        glMatrixMode(GL_PROJECTION)
        glPushMatrix()
        glLoadIdentity()

        glOrtho(0, SCREEN_WIDTH, 0, SCREEN_HEIGHT, -1, 1)
        glScalef(1, -1, 1)
        glTranslatef(0, -SCREEN_HEIGHT, 0)

        glMatrixMode(GL_MODELVIEW)
        glPushMatrix()
        glLoadIdentity()

        glEnable(GL_TEXTURE_2D)

        self.draw()
        glMatrixMode(GL_PROJECTION)
        glPopMatrix()
        glMatrixMode(GL_MODELVIEW)
        glPopMatrix()

        self.SwapBuffers()
    #I kept draw() seperate to ease modifying the test-program.
    def draw(self):
        global SCREEN_WIDTH
        global SCREEN_HEIGHT

        glBindTexture(GL_TEXTURE_2D, self.texture_id)

        glBegin(GL_QUADS)

        glTexCoord2f(0, 0); glVertex2d(           0,             0)
        glTexCoord2f(1, 0); glVertex2d(SCREEN_WIDTH,             0)
        glTexCoord2f(1, 1); glVertex2d(SCREEN_WIDTH, SCREEN_HEIGHT)
        glTexCoord2f(0, 1); glVertex2d(           0, SCREEN_HEIGHT)

        glEnd()

def main():
    global SCREEN_WIDTH
    global SCREEN_HEIGHT
    app    = PySimpleApp()
    frame  = Frame(None, -1,
                   '2D Graphics',
                   DefaultPosition,
                   Size(SCREEN_WIDTH,SCREEN_HEIGHT))
    canvas = Canvas(frame, '128x128.bmp')
    #"128x128.bmp" is a place-holder.

    frame.Show()
    app.MainLoop()

if __name__ == '__main__': main()
-- 
...LOLz0rz.

[PyOpenGL-Users] Problem initialising with Cygwin build

[Mike E. <Mik...@ve...>]

I compiled and installed PyOpenGL 3.0.0a6 under Cygwin with no problems,
but at runtime it fails as follows:

$ python
Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)=20
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenGL.GL import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.cygwin-1.5.24-i686/egg/OpenGL/GL/__init__.py", line
2, in <module>
  File "build/bdist.cygwin-1.5.24-i686/egg/OpenGL/raw/GL/__init__.py",
line 6, in <module>
  File "build/bdist.cygwin-1.5.24-i686/egg/OpenGL/raw/GL/constants.py",
line 7, in <module>
  File "build/bdist.cygwin-1.5.24-i686/egg/OpenGL/platform/__init__.py",
line 24, in <module>
  File "build/bdist.cygwin-1.5.24-i686/egg/OpenGL/platform/glx.py", line
29, in <module>
  File
"build/bdist.cygwin-1.5.24-i686/egg/OpenGL/platform/ctypesloader.py",
line 37, in loadLibrary
  File "/tmp/python.2408/usr/lib/python2.5/ctypes/__init__.py", line
312, in __init__
OSError: No such file or directory
>>>=20

I also tried reinstalling via setuptools using 'easy_install.py
PyOpenGL' which installed fine, but gives the same error when starting
up.

Can anyone point to what the problem might be?

Thanks,
Mike.

[PyOpenGL-Users] How to install pyopengl?

[shirish a. <shi...@gm...>]

Hi all,
        I read this page
http://pyopengl.sourceforge.net/documentation/installation.html and got
everything except an howto how to install GLUT. I had to search but did find
this page http://www.opengl.org/resources/libraries/glut/ which supposedly
gives an pre-compiled binary but opening it I find an three files one of
which is a .dll , one is a .lib & .h with no readme.
        Further as I dug I did found there are alternative libraries to GLUT
as GLUT is copy-righted. http://www.opengl.org/resources/libraries/ perhaps
one of these is in some usable form which can be used.
         Please lemme know what can I do as I really want to play the games
at http://www.pyweek.org/4/entries/ and as u can see all of these games
require PYOpenGL 2.0 which i have been having quite a hard time doing a
proper install under windows as all the requirements listed on
http://pyopengl.sourceforge.net/documentation/installation.html I'm not able
to get. In case if the installation documentation is old please refresh it.
Thanx in advance.
-- 
          Shirish Agarwal
  This work is licensed under the Creative Commons NonCommercial Sampling
Plus 1.0 License. To view a copy of this license, visit
http://creativecommons.org/licenses/nc-sampling+/1.0/