pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] [ pyopengl-Feature Requests-742160 ] Provide per-context extension registration

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

Feature Requests item #742160, was opened at 2003-05-23 01:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=742160&group_id=5988

Category: new module-OpenGLContext
Group: OpenGLContext v2.0
Status: Open
Resolution: None
Priority: 6
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Provide per-context extension registration

Initial Comment:
Should provide mechanism for registering extensions for
a particular context object, including support for
querying whether the extension is currently available,
and for automatically initializing the extension if it
is available but not yet initialized. (Note: the
automatic initialization will need to be able to return
false if the extension could not be initialized for the
particular context despite being available).

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

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

[PyOpenGL-Users] Preliminary gl2ps wrapper for PyOpenGL

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

I've just built (and done some minimal testing of) a gl2ps wrapper for 
use with PyOpenGL.  Haven't tested anything save the two primary entry 
points, but they seem to work properly.  As a note, the mechanism works 
using view-space absolute coordinates w/out the benefit of the depth 
buffer, so if your background-drawing code plays tricks such as clearing 
the depth buffer after drawing (which OpenGLContext does), you can wind 
up with your scene behind the background's geometry.

Anyway, if people are interested enough, I'll post the source 
somewhere.  The wrapper script is basically just a slightly trimmed 
version of the gl2ps.h header with some minimal type-mapping.  I wound 
up renaming the gl2ps.c file to _gl2ps.c to get around an annoying error 
where the build system was creating two gl2ps.o files.  Other than that 
no noticable changes to the base package that I can recall.  Oh, and at 
the moment you need to define WIN32  explicitly to build.  Haven't 
figured out why that's necessary as of yet.

Here's the results from a simple VRML file (one normally intended to be 
drawn w/out textures):
    http://members.rogers.com/mcfletch/programming/test.eps

Anyway, if anyone's interested, I'll look at polishing/finishing the 
wrapper and releasing it.

Enjoy all,
Mike

Mike C. Fletcher wrote:
...

> Similar-looking C lib for the same purpose (also LGPL):
>
>    http://www.geuz.org/gl2ps/
>
> apparently had a Python wrapper at some point in time, though it 
> doesn't appear to be available any more (Toby?)  All in all this looks 
> like the most mature of the solutions (for instance it appears able to 
> deal with intersection polygons, though if I'm reading right it may 
> generate striated results for smooth-shaded polygons.

...

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Creating a postscript image of a scene : how do I use openglutil ?

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

If anyone's interested the GLP library is an (LGPL) C++ lib to do OpenGL 
-> postscript:

    http://www.easysw.com/~mike/opengl/index.html

it honestly doesn't seem particuarly complex, it uses the feedback 
buffer, and apparently does some culling of the results to eliminate 
massive overdraw. 

Similar-looking C lib for the same purpose (also LGPL):

    http://www.geuz.org/gl2ps/

apparently had a Python wrapper at some point in time, though it doesn't 
appear to be available any more (Toby?)  All in all this looks like the 
most mature of the solutions (for instance it appears able to deal with 
intersection polygons, though if I'm reading right it may generate 
striated results for smooth-shaded polygons.

There's another variant on the same approach here:

    http://192.48.159.181/developers/code/mjktips/Feedback.html

Enjoy,
Mike

gabor wrote:

>On Mon, 2003-05-19 at 19:16, Mike C. Fletcher wrote:
>  
>
>>gabor wrote:
>>...
>>    
>>
>>...
>>I assume you used glFeedbackBuffer (I'm interpreting your message to 
>>mean you did create such screenshots)?  Do you (or anyone) have any 
>>sample code you'd be willing to share?  Rendering an OpenGL scene to 
>>    
>>
>
>no, i didn't do anything sophisticated :)
>
>i simply create screenshots with kde, and that's all :(
>
>
>gabor
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Creating a postscript image of a scene : how do I use openglutil ?

[gabor <ga...@z1...>]

On Mon, 2003-05-19 at 19:16, Mike C. Fletcher wrote:
> gabor wrote:
> ...
> >
> ...
> I assume you used glFeedbackBuffer (I'm interpreting your message to=20
> mean you did create such screenshots)?  Do you (or anyone) have any=20
> sample code you'd be willing to share?  Rendering an OpenGL scene to=20

no, i didn't do anything sophisticated :)

i simply create screenshots with kde, and that's all :(


gabor

Re: [PyOpenGL-Users] Creating a postscript image of a scene : how do I use openglutil ?

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

gabor wrote:
...

>when i wrote my master thesis ( i used pyopengl -)), i needed to make a
>lot of screenshots.
>
>and i  also wanted to be able to make eps screenshots. i mean
>vector-based eps screenshots.
>
...
I assume you used glFeedbackBuffer (I'm interpreting your message to 
mean you did create such screenshots)?  Do you (or anyone) have any 
sample code you'd be willing to share?  Rendering an OpenGL scene to 
postscript commands seems like it would be a fairly doable thing, but I 
haven't any experience in the area.  I'd imagine with the basic 
mechanism in-place it would be just as easy (maybe easier) to go to a 
format such as SVG so that the result would be editable in Illustrator 
or CorelDraw.

BTW, the openglutils module was just storing a bitmap in the EPS file, 
it wasn't AFAIK trying to draw the scene with PS commands.

Enjoy all,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Creating a postscript image of a scene : how do I use openglutil ?

[gabor <ga...@z1...>]

On Mon, 2003-05-19 at 18:41, Mike C. Fletcher wrote:
> You can=20
> see samples of saving images linked off the glReadPixels manual page here=
:
>=20
>    =20
> http://pyopengl.sourceforge.net/documentation/manual/glReadPixels.3G.html
>=20
> AFAIK all of those save to png or jpeg, but PIL does (apparently)=20
> support writting EPS from an image, so it should work fine.

i'm not sure if he wants the same as me,but:

when i wrote my master thesis ( i used pyopengl -)), i needed to make a
lot of screenshots.

and i  also wanted to be able to make eps screenshots. i mean
vector-based eps screenshots.
that means if there is a line on the screen i want it to be described as
a line in the eps file. not as a series of dots. i know that eps is able
to handle vectorial data.
reason:
when printing the master-thesis, all the screenshots look a little ugly,
because the resolution of the monitor is a lot smaller than the
resolution of the printer. with a vector-based image i wouldn't have
that problem.

hope this helps,
gabor

Re: [PyOpenGL-Users] Creating a postscript image of a scene : how do I use openglutil ?

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

openglutil was a PyOpenGL 1.x-specific add-on module that was dropped 
for the 2.x series because the functionality could all be written in 
Python (this allowed us to eliminate the libpng and libjpeg dependencies 
of the 1.x series) and result in more flexible and robust code. You can 
see samples of saving images linked off the glReadPixels manual page here:

    
http://pyopengl.sourceforge.net/documentation/manual/glReadPixels.3G.html

AFAIK all of those save to png or jpeg, but PIL does (apparently) 
support writting EPS from an image, so it should work fine.

HTH,
Mike


Champ Hippy wrote:

>Hello,
>
>I need to create PostScript image of a scene created with PyOpenGL. I
>have seen that "openglutil" should provide the required
>functionnalities such as "openglutil.glSaveEPS('teapot.eps', 240,
>240)". However my installation does not seem to recognize "openglutil"
>and I get the error message : "NameError: global name 'openglutil' is
>not defined" when I run the following program (lising #3 of article
>http://www.linuxjournal.com/article.php?sid=4830):
>  
>
...

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Creating a postscript image of a scene : how do I use openglutil ?

[Champ H. <cha...@be...>]

Hello,

I need to create PostScript image of a scene created with PyOpenGL. I
have seen that "openglutil" should provide the required
functionnalities such as "openglutil.glSaveEPS('teapot.eps', 240,
240)". However my installation does not seem to recognize "openglutil"
and I get the error message : "NameError: global name 'openglutil' is
not defined" when I run the following program (lising #3 of article
http://www.linuxjournal.com/article.php?sid=4830):

from OpenGL.GL import *
from OpenGL.GLUT import *
from OpenGL.Tk import *
import sys

def display(togl):
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
   glColor3f(0.3, 1.0, 1.0)
   glMaterialfv(GL_FRONT, GL_AMBIENT,
   [0.1745, 0.0, 0.1, 0.0])
   glMaterialfv(GL_FRONT, GL_DIFFUSE,
   [0.1, 0.0, 0.6, 0.0])
   glMaterialfv(GL_FRONT, GL_SPECULAR,
   [0.7, 0.6, 0.8, 0.0])
   glMaterialf(GL_FRONT, GL_SHININESS, 80)
   glutSolidTeapot(1.0)
   glFlush()
   openglutil.glSaveEPS('teapot.eps', 240, 240)
   sys.exit()

togl = Opengl(width = 250, height = 250, double = 1)
togl.redraw  = display
togl.pack(side = 'top', expand = 1, fill = 'both')
togl.basic_lighting()
togl.set_background(0, 0, 0)
togl.mainloop()

Here is my system configuration:
- windows XP professional
- python 2.2.2
- PyOpenGL 2.0.0.44

What do I need to install openglutil ? How to do it ? Is there other
way of creating images (jpeg, bmp, png, gif ...) from PyOpenGL scenes ?

Thanks,

Bernard

[PyOpenGL-Users] [ pyopengl-Feature Requests-739335 ] Only create Tk root if necessary...

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

Feature Requests item #739335, was opened at 2003-05-18 06:08
Message generated for change (Comment added) made by rliebscher
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=739335&group_id=5988

Category: Tk
Group: v2.1
Status: Open
Resolution: None
Priority: 4
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Only create Tk root if necessary...

Initial Comment:
Importing the OpenGL.Tk module currently automatically
creates a Tkinter root.  Would be nice if this was only
done if there is no root when creating an actual
widget.  Work-around is to do:

from Tkinter import *
my_root = Tk()
from OpenGL.Tk import *

But that's sub-optimal.

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

>Comment By: Rene Liebscher (rliebscher)
Date: 2003-05-19 10:10

Message:
Logged In: YES 
user_id=28463

Maybe moving some initialization code to first class use
will do.
Please check this.


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

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

[PyOpenGL-Users] [ pyopengl-Feature Requests-739335 ] Only create Tk root if necessary...

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

Feature Requests item #739335, was opened at 2003-05-18 00:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=739335&group_id=5988

Category: Tk
Group: v2.1
Status: Open
Resolution: None
Priority: 4
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Only create Tk root if necessary...

Initial Comment:
Importing the OpenGL.Tk module currently automatically
creates a Tkinter root.  Would be nice if this was only
done if there is no root when creating an actual
widget.  Work-around is to do:

from Tkinter import *
my_root = Tk()
from OpenGL.Tk import *

But that's sub-optimal.

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

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

Re: [PyOpenGL-Users] Continued problems with PyOpenGL 2.0.1.04 on Mac OS X with (fink) Python 2.3

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

You're running from the source directory, so it's got '.' in the 
python-path.  It's picking up the source OpenGL/ directory as being on 
the python-path, and therefor a package.  Switch to another directory 
and try it.

HTH,
Mike

Richard Muller wrote:

> rpm-osx(~/Programs/PyOpenGL-2.0.1.04)106 % python
> Python 2.3b1 (#1, May 12 2003, 03:53:15)
> [GCC 3.1 20020420 (prerelease)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import OpenGL.GL
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "OpenGL/__init__.py", line 26, in ?
>     from GL.__init___ import __numeric_present__, __numeric_support__
> ImportError: No module named GL.__init___
> >>>

...

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Continued problems with PyOpenGL 2.0.1.04 on Mac OS X with (fink) Python 2.3

[Richard M. <rp...@wa...>]

You were correct, build_togl was set to 0 in the darwin.cfg file. I 
tried setting this to 1, but ran into some other problems when I tried 
to import OpenGL.GL:

rpm-osx(~/Programs/PyOpenGL-2.0.1.04)106 % python
Python 2.3b1 (#1, May 12 2003, 03:53:15)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import OpenGL.GL
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "OpenGL/__init__.py", line 26, in ?
     from GL.__init___ import __numeric_present__, __numeric_support__
ImportError: No module named GL.__init___
 >>>

The strange thing about this is that I was able to build and import 
OpenGL.GL before I changed build_togl to 1, it was only when I tried to 
import OpenGL.Tk that I ran into trouble.

OS X does have Tkinter, through the fink interface, which is the 
version of Python I'm using.

Has anyone successfully built togl under fink? If so, can you offer any 
pointers?

Thanks in advance,
Rick

On Monday, May 12, 2003, at 10:29  AM, Mike C. Fletcher wrote:

>
> Togl is a binary extension to the Tk GUI, I can't really tell from 
> your question whether you built PyOpenGL yourself, or solved the 
> problem by using a binary distribution.  If you built it yourself, 
> it's quite likely that during configuration, you either didn't have 
> tkinter installed, or you disabled the building of togl to try and get 
> PyOpenGL to compile and then didn't turn it back on before the final 
> compile (build_togl = 1 should be in your darwin.cfg)... just noticed 
> that it's actually disabled by default in the latest source (Jack and 
> co, is this for a reason? Does OS X even have tkinter?)
>
>
Rick Muller
rp...@wa...
http://wag.caltech.edu/home/rpm

Re: [PyOpenGL-Users] Continued problems with PyOpenGL 2.0.1.04 on Mac OS X with (fink) Python 2.3

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

Togl is a binary extension to the Tk GUI, I can't really tell from your 
question whether you built PyOpenGL yourself, or solved the problem by 
using a binary distribution.  If you built it yourself, it's quite 
likely that during configuration, you either didn't have tkinter 
installed, or you disabled the building of togl to try and get PyOpenGL 
to compile and then didn't turn it back on before the final compile 
(build_togl = 1 should be in your darwin.cfg)... just noticed that it's 
actually disabled by default in the latest source (Jack and co, is this 
for a reason? Does OS X even have tkinter?)

If you used a binary installer, it's possible that the builder didn't 
include togl in the package, or possibly included it as a separate 
package.  Check your OpenGL/Tk/ directory for a togl.so, and a 
pkgIndex.tcl file. If those are not there, then your package doesn't 
include togl, and you should ask the packager (likely Jack) if they have 
a togl compile available.  If the files *are* there, it's possible the 
installation of the package is not triggering the registration with 
Tkinter/Tcl/Tk package manager which the setup.py file does.  The actual 
command is at line 211 in togl_setup.py, it's basically something like this:

tkinter_root_widget.tk.call( "pkg_mkIndex", "-verbose", 
"path/to/togl/directory", "togl.so" )

which you could do manually, but if you do and it works, let your 
packager (and us) know, so that we can attempt to fix the problem.

Good luck,
Mike

Richard Muller wrote:

> I upgraded my Python to 2.3b over the weekend to try and fix the 
> problems that were reported on this list last week (the problem was 
> that Python 2.2 couldn't load multiple __init___.so files). Now I'm 
> getting a different problem:
>
> Traceback (most recent call last):
>   File "xyz_render_ogl.py", line 10, in ?
>     from BallStickOGL import Scene
>   File "/Users/rpm/Python/BallStickOGL.py", line 11, in ?
>     from OpenGL.Tk import *
>   File "/sw/lib/python2.3/site-packages/OpenGL/Tk/__init__.py", line 
> 81, in ?
>     _default_root.tk.call('package', 'require', 'Togl')
> _tkinter.TclError: can't find package Togl
>
> Does anyone have any suggestions for hacking around this?
>
> R.
>
> Rick Muller
> rp...@wa...
> http://wag.caltech.edu/home/rpm

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Continued problems with PyOpenGL 2.0.1.04 on Mac OS X with (fink) Python 2.3

[Richard M. <rp...@wa...>]

I upgraded my Python to 2.3b over the weekend to try and fix the 
problems that were reported on this list last week (the problem was 
that Python 2.2 couldn't load multiple __init___.so files). Now I'm 
getting a different problem:

Traceback (most recent call last):
   File "xyz_render_ogl.py", line 10, in ?
     from BallStickOGL import Scene
   File "/Users/rpm/Python/BallStickOGL.py", line 11, in ?
     from OpenGL.Tk import *
   File "/sw/lib/python2.3/site-packages/OpenGL/Tk/__init__.py", line 
81, in ?
     _default_root.tk.call('package', 'require', 'Togl')
_tkinter.TclError: can't find package Togl

Does anyone have any suggestions for hacking around this?

R.

Rick Muller
rp...@wa...
http://wag.caltech.edu/home/rpm

[PyOpenGL-Users] Re: passing Numeric arrays to PyOpenGL

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

(Again, switched to PyOpenGL users to avoid spamming general python people)

I'm assuming you've already discovered the problem in your geometry (you 
are using backward-facing polygons).  I've attached a working 
OpenGLContext module which shows both the list and array versions 
working properly (hit 'a' to switch between the two versions).

The switch makes no difference on my machine, by the way.  Both versions 
are drawn as nothing unless the face culling is disabled.  This is 
running with the latest version of PyOpenGL 2.0.1, by the way.  There 
are, obviously, two different paths through the wrapper for the list 
versus the array versions, but AFAIK, both versions should work, even 
with the 2.0.0 PyOpenGL release (I don't think I fixed any errors in 
this area for the 2.0.1 release).

Enjoy yourself,
Mike

TheDustbustr wrote:

>Here's the code.
>
>VertexArray=[[0,0,0],[1,0,0],[2,0,0],
>             [0,1,0],[1,1,0],[2,1,0],
>             [0,2,0],[1,2,0],[2,2,0]]
>IndiceArray=[0,3,4,0,4,1,1,4,5,1,5,2,3,6,7,3,7,4,4,7,8,4,8,5]
>
>#VertexArray=array(VertexArray, 'f')    #Here's the problem line
>IndiceArray=array(IndiceArray, 'i')
>
>glVertexPointerf(VertexArray)
>glDrawElementsui(GL_TRIANGLES, IndiceArray)
>
>With the noted line commented, a Python list is passed to glVertexPointer, and
>everything is dandy.  When the noted line is uncommented, nothing is drawn.  No
>Numeric errors.
>
>Whats the deal here?  Why isn't IndiceArray affected by being converted to an
>array, and why IS VertexArray affected?
>
>Thanks, Dustin
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Re: [OT] Texturing an indexed triangle mesh in OpenGL

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

(switched to PyOpenGL users, which is a slightly more appropriate venue 
for the discussion)

First things first, glDrawArrays:

    
http://pyopengl.sourceforge.net/documentation/manual/glDrawArrays.3G.html

It includes a start index, and a count of items to render.  If you are 
going to call this method on each pass of the renderer, you should 
compute those values (start, count) for each texture and then render 
with three calls to glDrawArrays from the cached values.  Note, however, 
that glDrawArrays assumes flat arrays of data.  You would need to pull 
out the data into those flat arrays, which can significantly bloat the 
data going across the memory bus.

So the next approach, glDrawElements:

    
http://pyopengl.sourceforge.net/documentation/manual/glDrawElements.3G.html

Designed for indexed geometry, glDrawElements takes an array of indices 
to draw from the enabled arrays.  In your case, you would need to create 
new arrays from your index array, with each being simply the actual 
indices to render (no -1's) for the particular texture.  You would cache 
those numTexture arrays, then render the geometry with numTexture calls 
to glDrawElements.

You'll find sample code for glDrawArrays and glDrawElements linked off 
the pages above.  Note, however, that if this is static geometry, you 
might be better off simply compiling to a display list.

Hope this helps,
Mike


TheDustbustr wrote:

>My renderer is written in python, and thats about all this has to do with this
>newsgroup, hence the [OT]
>
>This one has been bugging me forever, and nobody seems to know the answer (not
>even google!)  Once I have created a triangle mesh, what is the best way to
>texture it (with potentially different textures for each triangle)?  My current
>method, when used with a medium sized mesh (8000 triangles), yeilds me 40
>frames per second (I have a Geforce 4)- I should be getting about 200.
>
>        glVertexPointerf(VertexArray)
>        prevtexture=""
>        for ind_i in range(0, len(IndiceArray), 3):
>            if (VertexArray[int(IndiceArray[ind_i])][1] <= 0) and (prevtexture
>!= "data/water-0.bmp"):
>                glBindTexture(GL_TEXTURE_2D,
>ResourceMgr().get("data/water-0.bmp"))
>                prevtexture="data/water-0.bmp"
>            elif (VertexArray[int(IndiceArray[ind_i])][1] > 3 and
>VertexArray[int(IndiceArray[ind_i])][1] <= 10) and (prevtexture !=
>"data/grass-0.bmp"):
>                glBindTexture(GL_TEXTURE_2D,
>ResourceMgr().get("data/grass-0.bmp"))
>                prevtexture="data/grass-0.bmp"
>            elif (VertexArray[int(IndiceArray[ind_i])][1] > 0 and
>VertexArray[int(IndiceArray[ind_i])][1] <= 3) and (prevtexture !=
>"data/dirt-0.bmp"):
>                glBindTexture(GL_TEXTURE_2D,
>ResourceMgr().get("data/dirt-0.bmp"))
>                prevtexture="data/dirt-0.bmp"
>
>            glBegin(GL_TRIANGLES)
>            glArrayElement(IndiceArray[ind_i])
>            glArrayElement(IndiceArray[ind_i+1])
>            glArrayElement(IndiceArray[ind_i+2])
>            glEnd()
>
>IndiceArray is sorted by texture, so glBindTexture should only be called once
>per texture per frame (in this case, 3 times per frame).  Is there a better way
>to do this?
>
>If I render the terrain with just one tiled texture, I get roughly 120 frames
>per second.
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] [ pyopengl-Feature Requests-735840 ] Move GLE to GLUT 3.7.6 version

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

Feature Requests item #735840, was opened at 2003-05-10 18:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=735840&group_id=5988

Category: GLE
Group: v2.0
Status: Open
Resolution: None
Priority: 4
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Move GLE to GLUT 3.7.6 version

Initial Comment:
The new GLUT version includes a newer version of GLE. 
It would be nice to support that version.  A decision
should also be made whether we will continue to include
GLE as part of PyOpenGL now that it is part of GLUT.  I
don't think it's yet provided in the binary
distributions, but on non-Windows platforms, it might
be more appropriate to simply use the platform GLE.

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

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

Re: [PyOpenGL-Users] Problems using PyOpenGL-2.0.1.04 on Mac OS X

[Jack J. <Jac...@cw...>]

On zaterdag, mei 10, 2003, at 18:31 Europe/Amsterdam, Evan Jones wrote:

> On Friday, May 9, 2003, at 16:46 Canada/Eastern, Mike C. Fletcher  
> wrote:
>> I'm out of my depth here, having never tried to compile anything on a  
>> Mac, so I'd suggest asking on the mac python list if you don't get it  
>> working.  In particular, Jack Jansen probably can help, as I believe  
>> he's been building it fairly regularly on OS-X.
>
> Bingo. That was the clue I needed. Here's a link that will be useful  
> for others out there:
>
> http://mail.python.org/pipermail/pythonmac-sig/2003-February/ 
> 007213.html

Glad you found it! I knew I got it working, but I had completely  
forgotten how (2.3- has been my standard platform for ages).
>
> The bug is basically that OS X won't load two .so's with the same  
> name. I found a binary build that uses Fink's version of Python and  
> life is good. So in short, I hope that either Apple fixes this bug  
> with their dynamic linker, or else that someone hacks PyOpenGL to name  
> all the modules "DirName__init__.so".

Don't worry: the problem is gone with Python 2.3. It is caused by the  
way .so's are loaded into a single namespace for Python 2.2, and this  
can't be fixed in the 2.2.X series as there are some packages that  
depend on this bug.
--
- Jack Jansen        <Jac...@or...>         
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma  
Goldman -

Re: [PyOpenGL-Users] Problems using PyOpenGL-2.0.1.04 on Mac OS X

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

Evan Jones wrote:

> On Friday, May 9, 2003, at 16:46 Canada/Eastern, Mike C. Fletcher wrote:
>
>> I'm out of my depth here, having never tried to compile anything on a 
>> Mac, so I'd suggest asking on the mac python list if you don't get it 
>> working.  In particular, Jack Jansen probably can help, as I believe 
>> he's been building it fairly regularly on OS-X.
>
>
> Bingo. That was the clue I needed. Here's a link that will be useful 
> for others out there:
>
> http://mail.python.org/pipermail/pythonmac-sig/2003-February/007213.html
>
I assume this thread was discussing the following:

https://sourceforge.net/tracker/index.php?func=detail&aid=544084&group_id=5988&atid=105988

As far as I can see, the patch is not yet there (or did I misplace it 
somehow, sorry if so), did you (Evan) find it anywhere?  If there is 
someone in the know (Bob?), I would like to see the patch.  In 
particular, I'm interested in whether this is something we can adopt 
immediately for the 2.0.1.05 release, or whether it has significant side 
effects.

> The bug is basically that OS X won't load two .so's with the same 
> name. I found a binary build that uses Fink's version of Python and 
> life is good. So in short, I hope that either Apple fixes this bug 
> with their dynamic linker, or else that someone hacks PyOpenGL to name 
> all the modules "DirName__init__.so".

The renaming of the __init___.so/pyd files is something I'm planning for 
all platforms, which should make py2exe somewhat happier as well.  I 
would be quite happy to have this in 2.0.1.05.

I have no background information on the:

	OS X requires ranlib for static libraries

problem, I am assuming the solution is merely to add the library to the 
list of libraries in setup.py for the "interface_util" static library 
(if the os is OSX).

Similarly, no background on the:

	OS X GLUT changes the working directory on glutInit

problem.  I am assuming this is where the "working around" comes in.  
This sounds more like a GLUT error that should be reported to either the 
GLUT people or Apple, but if we can work around it without causing too 
much ugliness (and without breaking if the underlying error is fixed), 
I'm willing.

BTW: These really seem like three separate patches, one for each of the 
three problems.  We're still quite informal about these things, but it 
would be nice to be able to review each issue individually, rather than 
needing to pull apart a patch file's effects to see what's being changed 
and how.  I'd rather have a combined patch than no patch, of course :) .

The changes in Jack's original patch are already integrated into the 
2.0.1 release, even the """self.output_dir = "" # Try by Jack""" voodoo, 
though I still have no idea what this was for.  If someone can produce a 
patch for building on OS X, I'd love to review it and integrate it.  If 
you can't get the SourceForge file upload to work, and the patch is less 
than 10 MB, you can send it directly to me.

Despite there being "1-click" installation, I would still like PyOpenGL 
to build out of box with the standard "setup.py install" for OS X 
(though I understand that changing the described makefile is out of 
scope, we can include that in the build instructions).

Enjoy yourselves,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Projects using PyOpenGL and documentation examples

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

Rene Dudfield wrote:
...

> I was thinking of doing a bunch of articles reviewing each of the 
> python 3d libraries.  Where I make a small game using each of the 
> libraries.  Maybe a 3d version of tic tac toe/tetris.  Be good if 
> someone did a similar review for the visualisation ones from a 
> non-game perspective.  Like vision egg. 

Sounds fun.  Any particular place you are planning to publish?  
O'Reilly?  Or just on a personal web page, or the PyOpenGL site?

> Reminds me, there are a few python + pyopengl games which were done in 
> the ludumdare 48h competitions.  I'll have a look around and post the 
> links to them a bit later. 

Sounds cool.

> ps, did you add pycal3d to your list?  http://py3d.org/pycal3d/ 

Until you mentioned it, I had thought this was a inverse kinematics 
system, hadn't realized it did anything with the 3-D side.  By the way, 
didn't get it to run on my machine yet, as it appears to require a 
separate binary of the cal3d package (which I was too busy to find and 
download, (given that it's GPL, so not really usable for most of my 
purposes)).  Will add it to the list when I get around to creating it.

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Problems using PyOpenGL-2.0.1.04 on Mac OS X

[Evan J. <ej...@uw...>]

On Friday, May 9, 2003, at 16:46 Canada/Eastern, Mike C. Fletcher wrote:
> I'm out of my depth here, having never tried to compile anything on a 
> Mac, so I'd suggest asking on the mac python list if you don't get it 
> working.  In particular, Jack Jansen probably can help, as I believe 
> he's been building it fairly regularly on OS-X.

Bingo. That was the clue I needed. Here's a link that will be useful 
for others out there:

http://mail.python.org/pipermail/pythonmac-sig/2003-February/007213.html

The bug is basically that OS X won't load two .so's with the same name. 
I found a binary build that uses Fink's version of Python and life is 
good. So in short, I hope that either Apple fixes this bug with their 
dynamic linker, or else that someone hacks PyOpenGL to name all the 
modules "DirName__init__.so".

Thanks for all your assistance,

Evan Jones

--
Evan Jones: http://www.eng.uwaterloo.ca/~ejones/
"Computers are useless. They can only give answers" - Pablo Picasso

Re: [PyOpenGL-Users] Projects using PyOpenGL and documentation examples

[Rene D. <il...@ya...>]

Mike C. Fletcher wrote:

> Rene Dudfield wrote:
>
>> Mike C. Fletcher wrote:
>
>
> ..
>
>>> It might also be useful for the various PyOpenGL projects to have a 
>>> simple "uses PyOpenGL" advertising page.  Not sure how many projects 
>>> there really are at the moment, but we'll see I suppose.... (long 
>>> period of searching)  Here's the list I've been able to find so far 
>>> (I've included everything I've found, regardless of the license, so 
>>> only some would be available for use as sample code):
>>
>>
>>
>>
>> There's some more here:
>> http://www.py3d.org/py3d_zwiki/Python3dLinks
>>
>> Not all are pyopengl, some are python and 3d of some kind. 
>
>
>
> Yup, I actually put most of those entries there when I came back from 
> PyCon :) , but very few of them are using PyOpenGL, really, hence they 
> didn't get included in the list I posted here :) .
>
> I was thinking of moving the general 3D list to the PyOpenGL site to 
> leverage PyOpenGL's "standard" status to support "3D in Python" in 
> general (something that was mentioned on the edu-sig list was the 
> desire to have things such as VPython linked from PyOpenGL to give 
> more visibility to those projects.  Since we're still very much in the 
> "growing the market" stage, it seems like a good idea to me.
>
That's a good idea.

I was thinking of doing a bunch of articles reviewing each of the python 
3d libraries.  Where I make a small game using each of the libraries.  
Maybe a 3d version of tic tac toe/tetris.  Be good if someone did a 
similar review for the visualisation ones from a non-game perspective.  
Like vision egg.

Reminds me, there are a few python + pyopengl games which were done in 
the ludumdare 48h competitions.  I'll have a look around and post the 
links to them a bit later.

ps, did you add pycal3d to your list?  http://py3d.org/pycal3d/

Re: [PyOpenGL-Users] Projects using PyOpenGL and documentation examples

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

Rene Dudfield wrote:

> Mike C. Fletcher wrote:

...

>> It might also be useful for the various PyOpenGL projects to have a 
>> simple "uses PyOpenGL" advertising page.  Not sure how many projects 
>> there really are at the moment, but we'll see I suppose.... (long 
>> period of searching)  Here's the list I've been able to find so far 
>> (I've included everything I've found, regardless of the license, so 
>> only some would be available for use as sample code):
>
>
>
> There's some more here:
> http://www.py3d.org/py3d_zwiki/Python3dLinks
>
> Not all are pyopengl, some are python and 3d of some kind. 


Yup, I actually put most of those entries there when I came back from 
PyCon :) , but very few of them are using PyOpenGL, really, hence they 
didn't get included in the list I posted here :) .

I was thinking of moving the general 3D list to the PyOpenGL site to 
leverage PyOpenGL's "standard" status to support "3D in Python" in 
general (something that was mentioned on the edu-sig list was the desire 
to have things such as VPython linked from PyOpenGL to give more 
visibility to those projects.  Since we're still very much in the 
"growing the market" stage, it seems like a good idea to me.

Enjoy yourselves,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Initial crack at automatic sample linking for documentation

[Rene D. <il...@ya...>]

Mike C. Fletcher wrote:

> If you look at the PyOpenGL reference documentation on the Web site, 
> you'll find (for many functions) a section at the end of the manpage 
> containing a set of links to modules in OpenGL/Demo or OpenGLContext 
> which use the particular functions defined on the page.
>
> At the moment, I'm linking to the CVS HEAD copy of the modules, but 
> unfortunately, the ViewCVS script doesn't appear to allow for linking 
> to particular lines, which makes the immediacy of the links 
> considerably less.  I'm considering finding a decent Python 
> source-code colorizer and actually including the full text of the 
> modules somewhere with the linked lines defined with anchors.  That's 
> going to be considerably more work, so it may windup taking quite a 
> while for me to get around to it.
>
> Here is a direct link to one of the pages with samples:
>
>    
> http://pyopengl.sourceforge.net/documentation/manual/glDepthFunc.3G.html
>
> Feedback and/or suggestions for how to make the links more useful 
> welcome.
>
> Enjoy yourselves,
> Mike
>

Awesome!  that is quite useful indeed.  Well done.

[PyOpenGL-Users] Using lists vs. arrays with PyOpenGL (was: Re: PyOpenGL glVertexPointer trouble)

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

The...@ao... wrote:
...

>everything is working fine, but 
>brings up a related question: Experimentally, I didn't use Numeric arrays 
>when passing vertices/indices to GL, I used python lists;  is there an 
>inherant speed boost when using arrays?
>  
>
(copied to the list in case others have the same question)

There is a speed boost using arrays vs. lists.  If you create a 
contiguous Numeric python array of the correct data type (i.e. f, d, i, 
whatever), then PyOpenGL is able to do a very simple struct-member 
access on the array object to get the internal contiguous array pointer 
and can pass that directly to the OpenGL function.

In all other situations, PyOpenGL will have to copy the data from the 
source object (list or array) into a newly-allocated Numeric Python 
array, pass the internal pointer to the OpenGL function, and (at some 
point in time) de-allocate the newly allocated Numeric Python array.  I 
haven't tested, but I would expect that an array of a different type 
would be faster than the list, given the ability to assume data type for 
the array items (doesn't require any interaction with the individual 
objects to convert the values).

Contiguous arrays are generated on array creation, and generally arrays 
are contiguous unless you are growing the  array piecewise by appending 
sections.  The data type of an array must match exactly to avoid copying 
(i.e. an array of type "f" will have to be copied to be passed to an 
OpenGL "d" function). 

You will find a "contiguous" function in the OpenGL.GL module which can 
be used to ensure that a given array is a contiguous numeric python 
array of a specified type (you would normally cache a copy after calling 
contiguous on the array).  BTW: Although I am the author of that 
function, however, I've never actually used it in production code that I 
can recall, it was provided for a user who was experiencing problems in 
this area.

With all that said, for many situations, the issue is irrelevant.  All 
the code described above is at the C level, so unless you are dealing 
with very large arrays/lists, it's quite likely the copying effects 
would be entirely swamped by the overhead of using Python in the first 
place.  Not to say you should waste the cycles for no reason, but until 
you get into large arrays, it's not likely going to be a concern.

Hope that helps,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/