pyopengl-users

[PyOpenGL-Users] PyOpenGL, GLUT, and MacOS X

[T.J. Jankun-K. <tj...@ac...>]

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

Greetings,

I am using PyOpenGL 2.0.1.04 on Mac OS X 10.2 and Python 2.3  
(MacPython). When using some of the demos, I notice errors appear. For  
example, when running the demo in Demo/twburton:
#  pythonw knot.py
Traceback (most recent call last):
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/OpenGL/Demo/twburton/knot.py", line 239, in ?
     views.append(knotView(file))
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/OpenGL/Demo/twburton/knot.py", line 115, in __init__
     self.knot = loadKnot(filename)
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/OpenGL/Demo/twburton/knot.py", line 18, in loadKnot
     f = open(filename)
IOError: [Errno 2] No such file or directory: '8.10'

However, there is a file called 8.10 that exists. Upon further  
experimentation, I discovered the following.  Say I start python from  
my home directory:
# python
Python 2.3 (#2, Jul 30 2003, 11:45:28)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import os,sys
 >>> os.system('pwd')
/Users/tjk
0
 >>> from OpenGL.GLUT import *
 >>> glutInit(sys.argv)
['']
 >>> os.system('pwd')
/usr/local/bin
0
 >>>

I.e., after I run glutInit, the path has changed, so references to  
files in the "current" (current before the call to glutInit) will fail.

Is this supposed to happen? Or is this a bug? Any quick workarounds?

Thanks.

TJK

- --
Dr. T.J. Jankun-Kelly
Assistant Professor (Information and Scientific Visualization)
Computer Science and Engineering, Mississippi State University
http://www.cse.msstate.edu/~tjk/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE/NEDJKB/hCI9AntwRAg6PAKCs/VoVj1az+g5jxYXs3YwkgyX6JgCfZszi
39N2WJf+iKRu4AIzfJ7JV1w=
=0WJ5
-----END PGP SIGNATURE-----

Re: [PyOpenGL-Users] PyOpenGL, GLUT, and MacOS X

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

T.J. Jankun-Kelly wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings,
>
> I am using PyOpenGL 2.0.1.04 on Mac OS X 10.2 and Python 2.3  
> (MacPython). When using some of the demos, I notice errors appear. 
> For  example, when running the demo in Demo/twburton:
> #  pythonw knot.py
> Traceback (most recent call last):
>   File  
> "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
> packages/OpenGL/Demo/twburton/knot.py", line 239, in ?
>     views.append(knotView(file))
>   File  
> "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
> packages/OpenGL/Demo/twburton/knot.py", line 115, in __init__
>     self.knot = loadKnot(filename)
>   File  
> "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
> packages/OpenGL/Demo/twburton/knot.py", line 18, in loadKnot
>     f = open(filename)
> IOError: [Errno 2] No such file or directory: '8.10'
>
> However, there is a file called 8.10 that exists. Upon further  
> experimentation, I discovered the following.  Say I start python from  
> my home directory:
> # python
> Python 2.3 (#2, Jul 30 2003, 11:45:28)
> [GCC 3.1 20020420 (prerelease)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os,sys
> >>> os.system('pwd')
> /Users/tjk
> 0
> >>> from OpenGL.GLUT import *
> >>> glutInit(sys.argv)
> ['']
> >>> os.system('pwd')
> /usr/local/bin
> 0
> >>>
>
> I.e., after I run glutInit, the path has changed, so references to  
> files in the "current" (current before the call to glutInit) will fail.
>
> Is this supposed to happen? Or is this a bug? Any quick workarounds?


Here's a work around.

old_cwd = os.path.realpath( os.curdir )
glutInit(sys.argv)
os.chdir(old_cwd)

[PyOpenGL-Users] Extensions, etc

[Brian H. <sd...@br...>]

I am new to PyOpenGL and did not find much in the docs or archives on
OpenGL extensions.  Specifically, how are new extensions added to
PyOpenGL?  I would think a script (in Python) would be used to download
the specs from the registry, create the glue code, run Swig or whatever,
etc.  Is this done now?  Again, I am brand new (2 days) to PyOpenGL.

Also, as I understand it, PyOpenGL supports OpenGL 1.1 which
is quite old...  Are there plans to update to say OpenGL 1.3? 1.4?

Looks good though!
Thanks, Brian

Re: [PyOpenGL-Users] Extensions, etc

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

Brian Hammond wrote:

>I am new to PyOpenGL and did not find much in the docs or archives on
>OpenGL extensions.  Specifically, how are new extensions added to
>PyOpenGL?  I would think a script (in Python) would be used to download
>the specs from the registry, create the glue code, run Swig or whatever,
>etc.  Is this done now?  Again, I am brand new (2 days) to PyOpenGL.
>

The process of wrapping trivial extensions (e.g. ones that are just 
collections of constants) is probably close to automatable.  However, 
it's not currently automated.  Feel free to contribute a script to do 
this :) .  For most non-trivial extensions it's necessary to write an 
extension module .i file (swig interface file).  Putting these into the 
correct directory (e.g. PyOpenGL2\interface\GL\ARB) of the source 
distribution will automatically build them.

Writing the .i file is not a particularly difficult task (there's a lot 
of samples in the interface directories), but it requires effort by a 
developer for every extension so supported.  Even more restrictively, it 
requires that the developer *have* that extension on their machine so 
that they can *test* it.  My old Radeon 7500 has very few of the 
features required by OpenGL 1.2 and above (at least for the interesting 
extensions).  There are two or three (interesting) extensions I have 
that aren't wrapped, but they haven't been interesting *enough* to get 
me to write the wrapper :) .

>Also, as I understand it, PyOpenGL supports OpenGL 1.1 which
>is quite old...  Are there plans to update to say OpenGL 1.3? 1.4?
>
OpenGL 1.3 and 1.4 are just a collection of extensions to OpenGL 1.1, so 
it's really the same question.  You could AFAIK write the entire OpenGL 
1.3 or 1.4 extension-set on top of PyOpenGL 2.0.1 w/out needing to 
upgrade the core (unless you discover a bug in the process, of course).  
The only thing missing would be the names in the core name-space for the 
extension features.  (Not sure if that holds for 2.0, however).

That said, if new extensions are contributed back, we would probably do 
a point release to include it in the main package, so adding the names 
to the core namespace wouldn't be a real problem. 

Note: for any real-world programming these days, you'd need to take the 
extension-based approach anyway (since most users *don't* have OpenGL 
1.3/1.4 drivers installed (I've never even *seen* one), and it will 
likely be a few years before they do (unless Microsoft decides to write 
one)).

>Looks good though!
>
Thanks.  Have fun,
Mike

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

Re: [PyOpenGL-Users] Extensions, etc

[Brian H. <pyo...@br...>]

* Mike C. Fletcher <mcf...@ro...> [2003-08-11 23:09]:
> Writing the .i file is not a particularly difficult task (there's a lot 
> of samples in the interface directories), but it requires effort by a 
> developer for every extension so supported.  

Ok - Why though? Maybe I am too naive with this but can't this be
automated as well? AFAIK you have to expose the enumerations and the
functions, both of which you have access to from the specs, no?

> Even more restrictively, it 
> requires that the developer *have* that extension on their machine so 
> that they can *test* it.  My old Radeon 7500 has very few of the 

Whoa - I wasn't expecting that... Testing that the extension is callable
is part of the build process?  I would think that having the function
ptr exposed would be all you'd need to do.

> >Also, as I understand it, PyOpenGL supports OpenGL 1.1 which
> >is quite old...  Are there plans to update to say OpenGL 1.3? 1.4?
> >
> OpenGL 1.3 and 1.4 are just a collection of extensions to OpenGL 1.1, so 
> it's really the same question.  You could AFAIK write the entire OpenGL 
> 1.3 or 1.4 extension-set on top of PyOpenGL 2.0.1 w/out needing to 
> upgrade the core (unless you discover a bug in the process, of course).  

> Note: for any real-world programming these days, you'd need to take the 
> extension-based approach anyway (since most users *don't* have OpenGL 
> 1.3/1.4 drivers installed (I've never even *seen* one), and it will 

Gotcha -- Makes sense. Just use the extensions instead of the core.

> likely be a few years before they do (unless Microsoft decides to write 
> one)).

I don't think they're doing any new OGL drivers other than 1.1 AFAIK

Unsuredly-yours,
Brian

> >Looks good though!
> >
> Thanks.  Have fun,
> Mike
> 
> _______________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://members.rogers.com/mcfletch/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

-- 
Willow: I knew it! I knew it! Well, not in the sense of having 
the slightest idea, but I knew there was something I didn't know.

Re: [PyOpenGL-Users] Extensions, etc

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

Brian Hammond wrote:

>* Mike C. Fletcher <mcf...@ro...> [2003-08-11 23:09]:
>  
>
>>Writing the .i file is not a particularly difficult task (there's a lot 
>>of samples in the interface directories), but it requires effort by a 
>>developer for every extension so supported.  
>>    
>>
>
>Ok - Why though? Maybe I am too naive with this but can't this be
>automated as well? AFAIK you have to expose the enumerations and the
>functions, both of which you have access to from the specs, no?
>
For simple modules, this works.  The wrapping of an extension module is 
as "automated" as the rest of the PyOpenGL system (which is fairly 
automated for the bulk of OpenGL).  The thing is that there are certain 
types of things that just don't have any automated machinery.  For 
instance, we don't currently have anything to automate generating 
wrappers around Python callbacks.  We also manually encode information 
regarding parameters that should not be passed in for the Python 
versions (i.e. array-length variables or the like).

If an extension doesn't require any of that special handling it's 
basically just the .h file for the extension with some boilerplate 
wrappers to make it get recognised by the system.  Creating *those* 
extensions with an automated script should be quite easy.

>>Even more restrictively, it 
>>requires that the developer *have* that extension on their machine so 
>>that they can *test* it.  My old Radeon 7500 has very few of the 
>>    
>>
>
>Whoa - I wasn't expecting that... Testing that the extension is callable
>is part of the build process?  I would think that having the function
>ptr exposed would be all you'd need to do.
>
It's not part of the build process, it's part of the *development* 
process.  Sending out code that's never been run tends to cause a lot of 
headaches.  There's actually quite a bit of it in PyOpenGL's extensions 
(for exactly this reason), but I'm *not* a fan of doing it for any 
non-trivial extension (i.e. one where we have to write *code* in the 
wrapper).

I'm serious when I say feel free to contribute a script to do the 
downloading and wrapping automatically (that goes for anyone).  It would 
probably allow access to quite a few extensions not currently 
supported.  I just don't have time to do it, as there are lots of things 
on my todo list that are already languishing for all 8 or 9 projects I'm 
running.
...

>>likely be a few years before they do (unless Microsoft decides to write 
>>one)).
>>    
>>
>
>I don't think they're doing any new OGL drivers other than 1.1 AFAIK
>
My impression too.  The ARB still seems to be hoping they will, but it 
just doesn't seem likely that they'll do all that work just to help 
people remain cross-platform.  After all, they *want* developers to lock 
into Direct3D (and therefor Windows).

Enjoy,
Mike

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