pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] PyOpenGl2 can't find ___init__

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

Seems like you aren't using swig 1.3.13

What version do you have?  Cause I added a check into
the setup.py to exit if it didn't find 1.3.13.

Could you send me the output of swig -version


Also read README.cvs, there might be some other notes
in there of help.



 --- Dan Christian <Dan...@NA...>
wrote: > I've been trying for several hours to get a
working
> OpenGl with Python 
> 2.2 under RedHat 7.3.
> 
> I downloaded PyOpenGl2 from CVS and hit the compile
> problem.  So I made 
> the mods that Scott Nichols mentioned.  That got it
> to build and 
> install, but it won't load.
> 
> cd OpenGL/Demo/da
> python2 dots.py 
> Traceback (most recent call last):
>   File "dots.py", line 20, in ?
>     from OpenGL.GL import *
>   File
>
"/usr/lib/python2.2/site-packages/OpenGL/__init__.py",
> line 26, 
> in ?
>     from GL.__init___ import __numeric_present__,
> __numeric_support__
>   File
>
"/usr/lib/python2.2/site-packages/OpenGL/GL/__init__.py",
> line 4, 
> in ?
>     import ___init__
> ImportError: No module named ___init__
> 
> 
> site-packages/OpenGL/GL has an __init___.so, but not
> an ___init__.so.  I 
> tried making a link, but then it just fails here:
> 
> Traceback (most recent call last):
>   File "dots.py", line 20, in ?
>     from OpenGL.GL import *
>   File
>
"/usr/lib/python2.2/site-packages/OpenGL/__init__.py",
> line 26, 
> in ?
>     from GL.__init___ import __numeric_present__,
> __numeric_support__
>   File
>
"/usr/lib/python2.2/site-packages/OpenGL/GL/__init__.py",
> line 
> 35, in ?
>     __numeric_present__ =
> __init___.__numeric_present__
> NameError: name '__init___' is not defined
> 
> I got the same errors when trying to run the dots or
> gear demo in pygtk.
> 
> Help!  Is there a way to make this work?
> 
> -Dan Christian
> I'm not on the list.  Please CC me.
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
>
https://lists.sourceforge.net/lists/listinfo/pyopengl-users 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[PyOpenGL-Users] PyOpenGl2 can't find ___init__

[Dan C. <Dan...@NA...>]

I've been trying for several hours to get a working OpenGl with Python 
2.2 under RedHat 7.3.

I downloaded PyOpenGl2 from CVS and hit the compile problem.  So I made 
the mods that Scott Nichols mentioned.  That got it to build and 
install, but it won't load.

cd OpenGL/Demo/da
python2 dots.py 
Traceback (most recent call last):
  File "dots.py", line 20, in ?
    from OpenGL.GL import *
  File "/usr/lib/python2.2/site-packages/OpenGL/__init__.py", line 26, 
in ?
    from GL.__init___ import __numeric_present__, __numeric_support__
  File "/usr/lib/python2.2/site-packages/OpenGL/GL/__init__.py", line 4, 
in ?
    import ___init__
ImportError: No module named ___init__


site-packages/OpenGL/GL has an __init___.so, but not an ___init__.so.  I 
tried making a link, but then it just fails here:

Traceback (most recent call last):
  File "dots.py", line 20, in ?
    from OpenGL.GL import *
  File "/usr/lib/python2.2/site-packages/OpenGL/__init__.py", line 26, 
in ?
    from GL.__init___ import __numeric_present__, __numeric_support__
  File "/usr/lib/python2.2/site-packages/OpenGL/GL/__init__.py", line 
35, in ?
    __numeric_present__ = __init___.__numeric_present__
NameError: name '__init___' is not defined

I got the same errors when trying to run the dots or gear demo in pygtk.

Help!  Is there a way to make this work?

-Dan Christian
I'm not on the list.  Please CC me.

Re: [PyOpenGL-Users] A puzzle regarding running PyOpenGL interactively

[Douglas S. B. <db...@br...>]

I have confirmed that Perry's problem listed below is also a problem on my
RedHat 8.0 with an NVIDIA video binary. But I don't think that has too much to
do with the problem (except that I think it is a timing issue).

I think that this is an issue in interactive mode, but only if the system has
time to attempt a redraw before one can assign the o.redraw method. For
example, if I paste the following code all at once into the Python
interpreter, it sometimes works, sometimes doesn't:

def redraw(win = 0):
    print win

import OpenGL
from OpenGL.GL import *
from OpenGL.Tk import *
o=Opengl()
o.redraw = redraw

If I pause just a little before the last line, I get the same error.

The solution: I think that OpenGL/Tk/__init__.py should have a default redraw
method that just has a pass, like:

       def redraw(self, *dummy):
                pass


If this is added, then the error never occurs, because there is a redraw
method now. This also doesn't require a "try" to see if there is a redraw
(that could slow it down), and doesn't seem to have any adverse effects.

Hope that helps,

-Doug

Perry Greenfield <pe...@st...> said:

> We have had problems with PyOpenGL for more recent releases
> of Redhat (e.g., 6.x,7.x, 8.x) that manifest themselves in odd ways.
> This is the simplest illustration of something that works for
> some OpenGL implementations and not others.
> 
> If you start an interactive Python session and types the following
> sequence of commmands:
> 
> >>> import OpenGL
> >>> from OpenGL.GL import *
> >>> from OpenGL.Tk import *
> >>> o=Opengl()
> 
> >>> Exception in Tkinter callback
> Traceback 
> [...]
> AttributeError: 'Opengl' instance has no attribute 'redraw'
> [window turns pink]
> 
> >>> glClearColor(1,0,0,0)
> >>> glClear(GL_COLOR_BUFFER_BIT)
> 
> On some installations, this results in a Tk window appearing, and
> the last command changes the background color to red.
> On other installstions, nothing happens with the last command.
> (Nor does the window turn pink on o=Opengl()).
> The above will not work for the default installations of OpenGL
> for Redhat 8 for example (The SGI library apparently).
> 
> [A natural question is why anyone would run OpenGL in this manner.
> We use OpenGL to generate plot windows from an interactive
> command line for a scientific command-line-oriented analysis
> environment. We do not use it in the usual way of generating
> a standalone GUI application. The above test illustrates the
> installations for which the plotting windows are nonfunctional
> or not]
> 
> Does anyone understand what it is that causes PyOpenGL to stop
> working with Python's interactive mode?
> 
> When we use Mesa instead on Redhat, it works. Unfortunately some
> users have NVIDIA cards that require the NVIDIA OpenGL library
> which does not work.
> 
> We would like to understand what the fundamental problem is and 
> whether there is any solution.
> 
> Thanks, Perry Greenfield
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 



-- 
Douglas S. Blank,       Assistant Professor         
db...@br...,          (610)526-6501
Bryn Mawr College,  Computer Science Program
101 North Merion Ave,  Park Science Building
Bryn Mawr, PA 19010 dangermouse.brynmawr.edu

Re: [PyOpenGL-Users] A puzzle regarding running PyOpenGL interactively

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

I'm not sure about tk; but I use pygame interactively
a lot.

Maybe you need to call the buffer flip functions, or
define a redraw function?



In my code I have display objects with start, and stop
video method calls.  Which basically call
pygame.display.init() and pygame.display.quit() (
which opens and closes the display).

Then I have a draw method.

This all works nicely with nvidia drivers on linux.


I get the same behaviour with your tk example.


Sorry I'm of not much help.


 --- Perry Greenfield <pe...@st...> wrote: > We
have had problems with PyOpenGL for more recent
> releases
> of Redhat (e.g., 6.x,7.x, 8.x) that manifest
> themselves in odd ways.
> This is the simplest illustration of something that
> works for
> some OpenGL implementations and not others.
> 
> If you start an interactive Python session and types
> the following
> sequence of commmands:
> 
> >>> import OpenGL
> >>> from OpenGL.GL import *
> >>> from OpenGL.Tk import *
> >>> o=Opengl()
> 
> >>> Exception in Tkinter callback
> Traceback 
> [...]
> AttributeError: 'Opengl' instance has no attribute
> 'redraw'
> [window turns pink]
> 
> >>> glClearColor(1,0,0,0)
> >>> glClear(GL_COLOR_BUFFER_BIT)
> 
> On some installations, this results in a Tk window
> appearing, and
> the last command changes the background color to
> red.
> On other installstions, nothing happens with the
> last command.
> (Nor does the window turn pink on o=Opengl()).
> The above will not work for the default
> installations of OpenGL
> for Redhat 8 for example (The SGI library
> apparently).
> 
> [A natural question is why anyone would run OpenGL
> in this manner.
> We use OpenGL to generate plot windows from an
> interactive
> command line for a scientific command-line-oriented
> analysis
> environment. We do not use it in the usual way of
> generating
> a standalone GUI application. The above test
> illustrates the
> installations for which the plotting windows are
> nonfunctional
> or not]
> 
> Does anyone understand what it is that causes
> PyOpenGL to stop
> working with Python's interactive mode?
> 
> When we use Mesa instead on Redhat, it works.
> Unfortunately some
> users have NVIDIA cards that require the NVIDIA
> OpenGL library
> which does not work.
> 
> We would like to understand what the fundamental
> problem is and 
> whether there is any solution.
> 
> Thanks, Perry Greenfield
> 
> 
> 
> 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[PyOpenGL-Users] A puzzle regarding running PyOpenGL interactively

[Perry G. <pe...@st...>]

We have had problems with PyOpenGL for more recent releases
of Redhat (e.g., 6.x,7.x, 8.x) that manifest themselves in odd ways.
This is the simplest illustration of something that works for
some OpenGL implementations and not others.

If you start an interactive Python session and types the following
sequence of commmands:

>>> import OpenGL
>>> from OpenGL.GL import *
>>> from OpenGL.Tk import *
>>> o=Opengl()

>>> Exception in Tkinter callback
Traceback 
[...]
AttributeError: 'Opengl' instance has no attribute 'redraw'
[window turns pink]

>>> glClearColor(1,0,0,0)
>>> glClear(GL_COLOR_BUFFER_BIT)

On some installations, this results in a Tk window appearing, and
the last command changes the background color to red.
On other installstions, nothing happens with the last command.
(Nor does the window turn pink on o=Opengl()).
The above will not work for the default installations of OpenGL
for Redhat 8 for example (The SGI library apparently).

[A natural question is why anyone would run OpenGL in this manner.
We use OpenGL to generate plot windows from an interactive
command line for a scientific command-line-oriented analysis
environment. We do not use it in the usual way of generating
a standalone GUI application. The above test illustrates the
installations for which the plotting windows are nonfunctional
or not]

Does anyone understand what it is that causes PyOpenGL to stop
working with Python's interactive mode?

When we use Mesa instead on Redhat, it works. Unfortunately some
users have NVIDIA cards that require the NVIDIA OpenGL library
which does not work.

We would like to understand what the fundamental problem is and 
whether there is any solution.

Thanks, Perry Greenfield

Re: texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpe

[Scott N. <scu...@ho...>]

Rene,

Below is the three lines I commented out to get PyOpenGl 2.0.1.02 to build.
After seeing Thomas's e-mail I went back to the wrapper code and looked at 
interface/GL/ARB/texture_compression.i  I noticed that for the 
glCompressedTexSubImage* fuctions the declaration in the wrapper did not 
match the headers in glext.h.  Although I have limited experience with swig, 
shouldn't the declarations match? Maybe I will try and change the wrapper in 
my version and see if I can get it to compile or not.

# 3 lines I commented out in GL/glext.h

extern void APIENTRY glCompressedTexSubImage3DARB (GLenum, GLint, GLint, 
GLint, GLint, GLsizei, GLsizei, GLsizei, GLenum, GL
sizei, const GLvoid *);
extern void APIENTRY glCompressedTexSubImage2DARB (GLenum, GLint, GLint, 
GLint, GLsizei, GLsizei, GLenum, GLsizei, const GLv
oid *);
extern void APIENTRY glCompressedTexSubImage1DARB (GLenum, GLint, GLint, 
GLsizei, GLenum, GLsizei, const GLvoid *);

-------------------------------------------------------------------
# Corresponding definitions from interface/GL/ARB/texture_compression.i

DECLARE_VOID_EXT(glCompressedTexSubImage3DARB, (GLenum target, GLint level, 
GLint xoffset, GLint yoffset, GLint zoffset, GLe
num internalformat,\
GLsizei width, GLsizei height, GLsizei depth, GLint border,\
GLsizei imageSize, const void *data),\
(target, level, xoffset, yoffset, zoffset, internalformat, width, height, 
depth, border, imageSize, data))

DECLARE_VOID_EXT(glCompressedTexSubImage2DARB, (GLenum target, GLint level, 
GLint xoffset, GLint yoffset, GLenum internalformat,\
GLsizei width, GLsizei height, GLint border,\
GLsizei imageSize, const void *data),\
(target, level, xoffset, yoffset, internalformat, width, height, border, 
imageSize, data))

DECLARE_VOID_EXT(glCompressedTexSubImage1DARB, (GLenum target, GLint level, 
GLint xoffset, GLenum internalformat,\
GLsizei width, GLint border,\
GLsizei imageSize, const void *data),\
(target, level, xoffset, internalformat, width, border, imageSize, data))

Let me know if you find out anything.

Thanks,

Scott

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: [PyOpenGL-Users] arcball.py: arcball rotation widget

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

On Sat, 2003-02-08 at 07:53, Maciej Kalisiak wrote:
> I've made available an implementation of the arcball method of rotation.
>      http://www.dgp.toronto.edu/~mac/code-n-patches/
> Perhaps it might be useful to someone.
it was very useful for me . thanks a lot
actually, it was useful because of 2 reasons:
	1. the actual arcball code
	2. it made me realise how easy it is to use Tkinter + OpenGL together (
until now i used the glut bindings, but now i'll definitively do it the
Tkinter way )

:)

gabor

Re: [PyOpenGL-Users] texture_compression hopefully fixed in cvs.

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

Will put it on the agenda, though this would be the _only_ change AFAIK 
(2 releases for a single bug ;) ).  At the moment I'm thinking it'll 
happen after I get a chance to work on the glu tessellator bug, which 
hopefully will be today (I'm in the middle of CV rewriting, so no 
promises (I hate job-hunting)).

BTW: Has one of the people running into the problem done a CVS build to 
confirm it works?

Have fun,
Mike

Rene Dudfield wrote:

>This is very weird.  I could swear I applied that
>patch.  But looking at the cvs log, it appears it's
>not in there.  I probably forgot to commit or
>something :(.  
>
>Appologies all round.
>
>
>Mike; could you do another release?
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Users mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>  
>

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

[PyOpenGL-Users] texture_compression hopefully fixed in cvs.

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

This is very weird.  I could swear I applied that
patch.  But looking at the cvs log, it appears it's
not in there.  I probably forgot to commit or
something :(.  

Appologies all round.


Mike; could you do another release?

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpe

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

Could you please send me the section you commented
out?


 --- Scott Nichols <scu...@ho...> wrote: >
Rene,
> 
>   I commented out the section you were talking about
> in GL/glext.h and it 
> compiled fine.  Probably not the best solution but I
> can at least use it 
> now, and I was able to run all tests/demos.  If
> anyone knows of a better 
> solution, let me know.
> 
> Thanks,
> 
> Scott
> 
> 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpenGL on RedHat 8.0

[Thomas W. <th...@xs...>]

On Sun, Feb 09, 2003 at 07:23:05AM +0000, Rene Dudfield wrote:

> What version of pyopengl are you using?  2.0.1.02
> should work for you.

> If not, arg!!!

Yes, 'arg!!!'.

> extern void APIENTRY glCompressedTexSubImage3DARB
> (GLenum, GLint, GLint, GLint, GLint, GLsizei, GLsizei,
> GLsizei, GLenum, GLsizei, const GLvoid *);

extern void APIENTRY glCompressedTexSubImage3DARB (GLenum, GLint, GLint, GLint, GLint, GLsizei, GLsizei, GLsizei, GLenum, GLsizei, const GLvoid *);

Matches. Note how it's 11 arguments. However, from the actual wrapper
template:

DECLARE_VOID_EXT(glCompressedTexSubImage3DARB, (GLenum target, GLint level,
    GLint xoffset, GLint yoffset, GLint zoffset, GLenum internalformat,
    GLsizei width, GLsizei height, GLsizei depth, GLint border,
    GLsizei imageSize, const void *data),

    (target, level, xoffset, yoffset, zoffset, internalformat,
    width, height, depth, border, imageSize, data))

Notice how there's 12 arguments. The 'internalformat' GLenum is made up; it
doesn't exist for the SubImage API. You should have just accepted the patch
I uploaded, it was correct and tested on a platform that was actually
broken :-)

But that's why it's an alpha release, right ? :-)

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Re: texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpenGL on RedHat 8.0

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

I've had similar problems with GL.ARB.texture_compression on MacOSX 
(using PyOpenGL from CVS). As I don't need the extension (and don't 
even know what it's supposed to do, let alone how I should debug it:-) 
I simply did a "touch 
build/lib.blablabla/GL/ARB/texture_compression.so" after the build 
failed and restarted the build.

I didn't bother to enter a sourceforge bugreport, because the response 
to my earlier bug reports hasn't exactly been overwhelming. But maybe I 
should post them anyway, so other people can benefit from at least 
knowning they're not alone in experiencing problems...
--
- 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: texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpe

[Scott N. <scu...@ho...>]

Rene,

  I commented out the section you were talking about in GL/glext.h and it 
compiled fine.  Probably not the best solution but I can at least use it 
now, and I was able to run all tests/demos.  If anyone knows of a better 
solution, let me know.

Thanks,

Scott

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

Re: texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpenGL on RedHat 8.0

[Scott N. <scu...@ho...>]

Rene,

Thanks for the help.  I am using PyOpenGL 2.0.1.02, I also tried installing 
PyOpenGL 2.0.1.01, but got the same error.  Hopefully someone has ran into 
this problem before and knows how to fix it.

Scott

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus

texture_compression weirdness was Re: [PyOpenGL-Users] unable to build PyOpenGL on RedHat 8.0

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

What version of pyopengl are you using?  2.0.1.02
should work for you.


If not, arg!!!

Maybe there are different definitions for these
functions?  Could someone give me their ones if they
differ from the definitions below?

from GL/glext.h:

#ifndef GL_ARB_texture_compression
#define GL_ARB_texture_compression 1
#ifdef GL_GLEXT_PROTOTYPES
extern void APIENTRY glCompressedTexImage3DARB
(GLenum, GLint, GLenum, GLsizei, GLsizei, GLsizei,
GLint, GLsizei, const GLvoid *);
extern void APIENTRY glCompressedTexImage2DARB
(GLenum, GLint, GLenum, GLsizei, GLsizei, GLint,
GLsizei, const GLvoid *);
extern void APIENTRY glCompressedTexImage1DARB
(GLenum, GLint, GLenum, GLsizei, GLint, GLsizei, const
GLvoid *);
extern void APIENTRY glCompressedTexSubImage3DARB
(GLenum, GLint, GLint, GLint, GLint, GLsizei, GLsizei,
GLsizei, GLenum, GLsizei, const GLvoid *);
extern void APIENTRY glCompressedTexSubImage2DARB
(GLenum, GLint, GLint, GLint, GLsizei, GLsizei,
GLenum, GLsizei, const GLvoid *);
extern void APIENTRY glCompressedTexSubImage1DARB
(GLenum, GLint, GLint, GLsizei, GLenum, GLsizei, const
GLvoid *);
extern void APIENTRY glGetCompressedTexImageARB
(GLenum, GLint, void *);
#endif /* GL_GLEXT_PROTOTYPES */
typedef void (APIENTRY *
PFNGLCOMPRESSEDTEXIMAGE3DARBPROC) (GLenum target,
GLint level, GLenum internalformat, GLsizei width,
GLsizei height, GLsizei depth, GLint border, GLsizei
imageSize, const GLvoid *data);
typedef void (APIENTRY *
PFNGLCOMPRESSEDTEXIMAGE2DARBPROC) (GLenum target,
GLint level, GLenum internalformat, GLsizei width,
GLsizei height, GLint border, GLsizei imageSize, const
GLvoid *data);
typedef void (APIENTRY *
PFNGLCOMPRESSEDTEXIMAGE1DARBPROC) (GLenum target,
GLint level, GLenum internalformat, GLsizei width,
GLint border, GLsizei imageSize, const GLvoid *data);
typedef void (APIENTRY *
PFNGLCOMPRESSEDTEXSUBIMAGE3DARBPROC) (GLenum target,
GLint level, GLint xoffset, GLint yoffset, GLint
zoffset, GLsizei width, GLsizei height, GLsizei depth,
GLenum format, GLsizei imageSize, const GLvoid *data);
typedef void (APIENTRY *
PFNGLCOMPRESSEDTEXSUBIMAGE2DARBPROC) (GLenum target,
GLint level, GLint xoffset, GLint yoffset, GLsizei
width, GLsizei height, GLenum format, GLsizei
imageSize, const GLvoid *data);
typedef void (APIENTRY *
PFNGLCOMPRESSEDTEXSUBIMAGE1DARBPROC) (GLenum target,
GLint level, GLint xoffset, GLsizei width, GLenum
format, GLsizei imageSize, const GLvoid *data);
typedef void (APIENTRY *
PFNGLGETCOMPRESSEDTEXIMAGEARBPROC) (GLenum target,
GLint level, void *img);
#endif



 --- Scott Nichols <scu...@ho...> wrote: > I
am unable to install PyOpenGL on RedHat 8.0. 
> Below is a portion of the 
> install log that shows the error.  I think it may be
> very similar to some of 
> the problems other people asked about earlier. 
> Christoph Lehmann posted a 
> message about a changed linux.cnf file but his
> attachment was not accessible 
> from sourceforge.  Any help would be greatly
> appreciated.
> 
> Thanks,
> 
> Scott Nichols
> 
> 
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
> -DGLX_PLATFORM -DNUMERIC 
> -I/usr/include -I/usr/local/include -I/usr/X11/
> include -I/usr/X11R6/include
> -I/usr/local/include/python2.2/Numeric 
> -I/usr/local/include/python2.2 -c
> src/interface/GL.ARB.p
> oint_parameters.c -o
> build/temp.linux-i686-2.2/GL.ARB.point_parameters.o
> gcc -shared
> build/temp.linux-i686-2.2/GL.ARB.point_parameters.o
> -L/usr/lib 
> -L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
> -Lbuild/temp.linux-i686-2.2 -lGL -lX11 -lXext -lGLU
> -linterface_util -o 
> build/lib.linux-i686-2.2/OpenGL/GL/ARB/point_paramet
> ers.so
> building 'GL.ARB.texture_compression' extension
> cc1: warning: changing search order for system
> directory 
> "/usr/local/include"
> cc1: warning:   as it has already been specified as
> a non-system directory
> cc1: warning: changing search order for system
> directory "/usr/include"
> cc1: warning:   as it has already been specified as
> a non-system directory
> In file included from
> src/interface/GL.ARB.texture_compression.c:8:
>
src/interface/GL.ARB.texture_compression.0103.inc:750:
> warning: function 
> declaration isn't a prototype
>
src/interface/GL.ARB.texture_compression.0103.inc:798:
> warning: function 
> declaration isn't a prototype
>
src/interface/GL.ARB.texture_compression.0103.inc:929:
> warning: function 
> declaration isn't a prototype
> src/interface/GL.ARB.texture_compression.0103.inc:
> In function 
> `_wrap_glCompressedTexSubImage3DARB':
>
src/interface/GL.ARB.texture_compression.0103.inc:1127:
> warning: passing arg 
> 11 of `glCompressedTexSubImage3DARB' makes poin
> ter from integer without a cast
>
src/interface/GL.ARB.texture_compression.0103.inc:1127:
> too many arguments 
> to function `glCompressedTexSubImage3DARB'
> src/interface/GL.ARB.texture_compression.0103.inc:
> In function 
> `_wrap_glCompressedTexSubImage2DARB':
>
src/interface/GL.ARB.texture_compression.0103.inc:1176:
> warning: passing arg 
> 9 of `glCompressedTexSubImage2DARB' makes point
> er from integer without a cast
>
src/interface/GL.ARB.texture_compression.0103.inc:1176:
> too many arguments 
> to function `glCompressedTexSubImage2DARB'
> src/interface/GL.ARB.texture_compression.0103.inc:
> In function 
> `_wrap_glCompressedTexSubImage1DARB':
>
src/interface/GL.ARB.texture_compression.0103.inc:1223:
> warning: passing arg 
> 7 of `glCompressedTexSubImage1DARB' makes point
> er from integer without a cast
>
src/interface/GL.ARB.texture_compression.0103.inc:1223:
> too many arguments 
> to function `glCompressedTexSubImage1DARB'
> src/interface/GL.ARB.texture_compression.0103.inc:
> At top level:
>
src/interface/GL.ARB.texture_compression.0103.inc:875:
> warning: 
> `_doc_glCompressedTexImage3DARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:876:
> warning: 
> `_doc_glCompressedTexImage2DARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:877:
> warning: 
> `_doc_glCompressedTexImage1DARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:878:
> warning: 
> `_doc_glCompressedTexSubImage3DARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:879:
> warning: 
> `_doc_glCompressedTexSubImage2DARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:880:
> warning: 
> `_doc_glCompressedTexSubImage1DARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:907:
> warning: 
> `_doc_glGetCompressedTexImageARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:925:
> warning: 
> `_doc_glInitTextureCompressionARB' defined but not
> used
>
src/interface/GL.ARB.texture_compression.0103.inc:926:
> warning: 
> `_doc_glInitTexCompressionARB' defined but not used
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
> -DGLX_PLATFORM -DNUMERIC 
> -I/usr/include -I/usr/local/include -I/usr/X11/
> include -I/usr/X11R6/include
> -I/usr/local/include/python2.2/Numeric 
> -I/usr/local/include/python2.2 -c
> src/interface/GL.ARB.t
> exture_compression.c -o 
>
build/temp.linux-i686-2.2/GL.ARB.texture_compression.o
> error: command 'gcc' failed with exit status 1
> 
> 
> 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[PyOpenGL-Users] unable to build PyOpenGL on RedHat 8.0

[Scott N. <scu...@ho...>]

I am unable to install PyOpenGL on RedHat 8.0.  Below is a portion of the 
install log that shows the error.  I think it may be very similar to some of 
the problems other people asked about earlier.  Christoph Lehmann posted a 
message about a changed linux.cnf file but his attachment was not accessible 
from sourceforge.  Any help would be greatly appreciated.

Thanks,

Scott Nichols


gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DGLX_PLATFORM -DNUMERIC 
-I/usr/include -I/usr/local/include -I/usr/X11/
include -I/usr/X11R6/include -I/usr/local/include/python2.2/Numeric 
-I/usr/local/include/python2.2 -c src/interface/GL.ARB.p
oint_parameters.c -o build/temp.linux-i686-2.2/GL.ARB.point_parameters.o
gcc -shared build/temp.linux-i686-2.2/GL.ARB.point_parameters.o -L/usr/lib 
-L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
-Lbuild/temp.linux-i686-2.2 -lGL -lX11 -lXext -lGLU -linterface_util -o 
build/lib.linux-i686-2.2/OpenGL/GL/ARB/point_paramet
ers.so
building 'GL.ARB.texture_compression' extension
cc1: warning: changing search order for system directory 
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system directory
cc1: warning: changing search order for system directory "/usr/include"
cc1: warning:   as it has already been specified as a non-system directory
In file included from src/interface/GL.ARB.texture_compression.c:8:
src/interface/GL.ARB.texture_compression.0103.inc:750: warning: function 
declaration isn't a prototype
src/interface/GL.ARB.texture_compression.0103.inc:798: warning: function 
declaration isn't a prototype
src/interface/GL.ARB.texture_compression.0103.inc:929: warning: function 
declaration isn't a prototype
src/interface/GL.ARB.texture_compression.0103.inc: In function 
`_wrap_glCompressedTexSubImage3DARB':
src/interface/GL.ARB.texture_compression.0103.inc:1127: warning: passing arg 
11 of `glCompressedTexSubImage3DARB' makes poin
ter from integer without a cast
src/interface/GL.ARB.texture_compression.0103.inc:1127: too many arguments 
to function `glCompressedTexSubImage3DARB'
src/interface/GL.ARB.texture_compression.0103.inc: In function 
`_wrap_glCompressedTexSubImage2DARB':
src/interface/GL.ARB.texture_compression.0103.inc:1176: warning: passing arg 
9 of `glCompressedTexSubImage2DARB' makes point
er from integer without a cast
src/interface/GL.ARB.texture_compression.0103.inc:1176: too many arguments 
to function `glCompressedTexSubImage2DARB'
src/interface/GL.ARB.texture_compression.0103.inc: In function 
`_wrap_glCompressedTexSubImage1DARB':
src/interface/GL.ARB.texture_compression.0103.inc:1223: warning: passing arg 
7 of `glCompressedTexSubImage1DARB' makes point
er from integer without a cast
src/interface/GL.ARB.texture_compression.0103.inc:1223: too many arguments 
to function `glCompressedTexSubImage1DARB'
src/interface/GL.ARB.texture_compression.0103.inc: At top level:
src/interface/GL.ARB.texture_compression.0103.inc:875: warning: 
`_doc_glCompressedTexImage3DARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:876: warning: 
`_doc_glCompressedTexImage2DARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:877: warning: 
`_doc_glCompressedTexImage1DARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:878: warning: 
`_doc_glCompressedTexSubImage3DARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:879: warning: 
`_doc_glCompressedTexSubImage2DARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:880: warning: 
`_doc_glCompressedTexSubImage1DARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:907: warning: 
`_doc_glGetCompressedTexImageARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:925: warning: 
`_doc_glInitTextureCompressionARB' defined but not used
src/interface/GL.ARB.texture_compression.0103.inc:926: warning: 
`_doc_glInitTexCompressionARB' defined but not used
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DGLX_PLATFORM -DNUMERIC 
-I/usr/include -I/usr/local/include -I/usr/X11/
include -I/usr/X11R6/include -I/usr/local/include/python2.2/Numeric 
-I/usr/local/include/python2.2 -c src/interface/GL.ARB.t
exture_compression.c -o 
build/temp.linux-i686-2.2/GL.ARB.texture_compression.o
error: command 'gcc' failed with exit status 1




_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[PyOpenGL-Users] arcball.py: arcball rotation widget

[Maciej K. <ma...@dg...>]

I've made available an implementation of the arcball method of rotation.
     http://www.dgp.toronto.edu/~mac/code-n-patches/
Perhaps it might be useful to someone.

,----
| arcball.py: defines a subclass of 'Opengl' that supports the use of
| arcball method of rotation, which is frequently used in the graphics
| field. Run the script to see a very rough and quick demo. You'll
| probably want to bring up a different pyopengl app to compare the
| rotation methods.
| 
| Arcball summary: one of the main benefits is that it has no hysterisis:
| once you start dragging out a rotate, coming back to the same spot with
| the mouse cursor always gives the same rotation, no matter what path was
| taken to get the cursor to that spot. Also, if you drag the rotation
| outside the ball's perimeter (alas, it is currently not drawn; it's on
| the TODO), the axis of rotation is perpendicular to the
| screen/projection surface.
`----

-- 
"Millions long for immortality who do not know what to do with themselves on
 a rainy Sunday afternoon."
				-- Susan Ertz

Re: [PyOpenGL-Users] GLU with multiple tesselators

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

I haven't been ignoring this, just haven't figured out how to fix it yet 
(it is a PyOpenGL problem).  Here is what's going on:

    Although each Tesselator is stored as an independent object, there 
are only 10 callback functions defined in the GLU wrapper.  Each of 
these callbacks merely looks at the "currentTesselator" objects to 
determine what method to call currentTesselator is set by the input and 
output type-maps.

    I haven't yet figured out why this doesn't cause the "outer" 
tesselator's methods to get called...

What I am considering doing is:

    * always using the "data" versions of the callback functions
      internally,
    * storing the externally-passed data value in the PyGLUTesselator
      object,
    * and passing a pointer to the tesselator object to the
      gluTessBeginPolygon method as the "data" pointer.  

When the callback triggers:

    * it will look at the tesselator pointer (the "data" pointer),
    * determine whether there is a real data value,
    * and determine whether there is a relevant callback.

I had thought we got rid of all these callback problems more than a year 
ago, guess not.  We'll probably need to check that the GLUT wrappers 
aren't suffering from similar problems.  If one of the C programmers 
would like to step up and take this bug, I'd be happy to let them work 
on it, (hint, hint, all), if not, I'll probably work on it on Monday.

Enjoy yourself, Maciej, and don't forget the PyGTA meeting on the 18th!
Mike

Maciej Kalisiak wrote:

>[This has also been posted to comp.graphics.api.opengl, as I don't know whether
> this is an OpenGL issue, or pyopengl.]
>
>Hello all.  I'm trying to do some 2D CSG stuff using OpenGL's tesselator and
>the winding rules.  I've run into a problem with using multiple tesselators.
>According to the redbook, I should be able to feed one tesselator's output
>(using its callbacks) to the input of another one [midway on p421 of 2nd
>ed... look for "GLU_TESS_BOUNDARY_ONLY"].  I tried to set up something along
>those lines.  Here's roughly what occurs at runtime:
>
>(NOTE: "outer" refers to actions taken on the "receiving" tesselator, while
>"inner" refers to the "feeding" one)
>
>% ./test.py
>outer: gluTessBeginPolygon <GLUtesselator object at 0x816c150>
>inner: gluTessBeginPolygon <GLUtesselator object at 0x8121898>
>inner: gluTessBeginContour <GLUtesselator object at 0x8121898>
>inner: gluTessEndContour <GLUtesselator object at 0x8121898>
>inner: gluTessEndPolygon <GLUtesselator object at 0x8121898>
>inner: cb_begin <GLUtesselator object at 0x816c150> 2
>outer: gluTessEndPolygon <GLUtesselator object at 0x816c150>
>Traceback (most recent call last):
>  File "./test.py", line 75, in ?
>    main()
>  File "./test.py", line 70, in main
>    gluTessEndPolygon(tobj)
>OpenGL.GLU.GLUerror: [Errno 100154] gluTessEndContour() must follow a gluTessBeginContour()
>
>Strangely, gluTessEndPolygon() of the "feeding/inner" tesselator only fires the
>GLU_TESS_BEGIN callback, and that's it!  Bizarre.
>
>Here's the Python code for the above.  All it's trying to do is tesselate a
>circle using one tesselator, which then feeds the boundary (i.e., the same
>circle, it should be) to a second tesselator.
>
>Any ideas?  Did I miss something?  I tried pyopengl 2.0.0.44, as well as
>2.0.1.02.
>  
>
...

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

Re: [PyOpenGL-Users] openglcontext.trackball

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

There are two primary reasons for the inclusion of camera orientation:

    * The trackball exists in "eye space", so that the rotations it
      generates are always relative to your starting orientation.  For
      instance, dragging upward always rotates around the camera's
      current x-axis as projected through the center point. If you
      didn't have the camera orientation, then dragging up would always
      be rotating you around the world-space x-vector through the
      center.  That doesn't create the "holding an object in the hand to
      examine it" effect that the trackball tries to create.
    * There isn't actually enough information without the camera
      orientation to determine the "look at" orientation for the center
      point.  For every point on the sphere, there are 360 degrees worth
      (i.e. infinite) numbers of possible orientations for that point
      and center for the sphere.  You need at minimum an "up vector" to
      choose the appropriate orientation from that set.  The
      quaternion-based code is just ever so much nicer :) .

The use of the full camera orientation quaternion allows for very simple 
operation, and prevents "popping" when using the trackball.  This effect 
would occur if you were using a default up orientation: as soon as you 
started dragging the trackball, you would suddenly pop from your current 
orientation to the "default" up orientation facing the center, which can 
be quite disorienting (especially if you were previously "upside-down" 
in world-space coordinates).

Hope this helps,
Mike


gabor wrote:

>hi,
>
>i'm trying to use the trackball.py from oglcontext,
>but there's something i don't understand..
>
>as i understand, these track/arc/whateverball routines allow me to
>easily move the camera around an object... so that the camera basically
>moves on a sphere around the object...
>
>but why is the camera orientation needed as an input?
>
>if the camera moves on a sphere looking at a certain point, then the
>camera orintation can be calculated from them... or not?
>
>gabor
>  
>

[PyOpenGL-Users] openglcontext.trackball

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

hi,

i'm trying to use the trackball.py from oglcontext,
but there's something i don't understand..

as i understand, these track/arc/whateverball routines allow me to
easily move the camera around an object... so that the camera basically
moves on a sphere around the object...

but why is the camera orientation needed as an input?

if the camera moves on a sphere looking at a certain point, then the
camera orintation can be calculated from them... or not?

gabor

Re: [PyOpenGL-Users] Newbie question....

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

You might want to check out the installation instructions here:

    http://pyopengl.sourceforge.net/documentation/installation.html

which should cover all of the various dependencies of PyOpenGL and 
OpenGLContext.

HTH, and have fun,
Mike

...

> --- Jesse Crookston <cf...@ms...> wrote: > Hi,
>  
>
>>I did a lot of OPENGL at the university and was
>>excited when I found that 
>>there was a port to Python!!, (a language a tinkered
>>with a couple of years 
>>ago...)  Inspired to regain lost knowledge, I
>>installed the module.  
>>Unfortunately, I found the following error message:
>>
>>===============================
>>C:\Python22\Lib\site-packages\OpenGLContext>python
>>drawcube.py
>>Traceback (most recent call last):
>>  File "drawcube.py", line 13, in ?
>>    from OpenGL.GL import *
>>ImportError: No module named OpenGL.GL
>>===============================
>>
>>Can anyone comment/help?
>>
>>Thanks,
>>Jess
>>    
>>
...

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

[PyOpenGL-Users] GLU with multiple tesselators

[Maciej K. <ma...@dg...>]

[This has also been posted to comp.graphics.api.opengl, as I don't know whether
 this is an OpenGL issue, or pyopengl.]

Hello all.  I'm trying to do some 2D CSG stuff using OpenGL's tesselator and
the winding rules.  I've run into a problem with using multiple tesselators.
According to the redbook, I should be able to feed one tesselator's output
(using its callbacks) to the input of another one [midway on p421 of 2nd
ed... look for "GLU_TESS_BOUNDARY_ONLY"].  I tried to set up something along
those lines.  Here's roughly what occurs at runtime:

(NOTE: "outer" refers to actions taken on the "receiving" tesselator, while
"inner" refers to the "feeding" one)

% ./test.py
outer: gluTessBeginPolygon <GLUtesselator object at 0x816c150>
inner: gluTessBeginPolygon <GLUtesselator object at 0x8121898>
inner: gluTessBeginContour <GLUtesselator object at 0x8121898>
inner: gluTessEndContour <GLUtesselator object at 0x8121898>
inner: gluTessEndPolygon <GLUtesselator object at 0x8121898>
inner: cb_begin <GLUtesselator object at 0x816c150> 2
outer: gluTessEndPolygon <GLUtesselator object at 0x816c150>
Traceback (most recent call last):
  File "./test.py", line 75, in ?
    main()
  File "./test.py", line 70, in main
    gluTessEndPolygon(tobj)
OpenGL.GLU.GLUerror: [Errno 100154] gluTessEndContour() must follow a gluTessBeginContour()

Strangely, gluTessEndPolygon() of the "feeding/inner" tesselator only fires the
GLU_TESS_BEGIN callback, and that's it!  Bizarre.

Here's the Python code for the above.  All it's trying to do is tesselate a
circle using one tesselator, which then feeds the boundary (i.e., the same
circle, it should be) to a second tesselator.

Any ideas?  Did I miss something?  I tried pyopengl 2.0.0.44, as well as
2.0.1.02.


# --8<--

#!/usr/bin/env python
import math
from math import *

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

def inner(tobj):
    tobj_inner = gluNewTess()

    def cb_begin(type):
        print 'inner: cb_begin', tobj, type
        gluTessBeginContour(tobj)
        print '(done) inner: cb_begin', tobj
    def cb_end():
        print 'inner: cb_end', tobj
        gluTessEndContour(tobj)
    def cb_vertex(v):
        print 'inner: cb_vertex', tobj, v
        gluTessVertex(tobj, v, v)

    gluTessCallback(tobj_inner, GLU_TESS_BEGIN, cb_begin)
    gluTessCallback(tobj_inner, GLU_TESS_END, cb_end)
    gluTessCallback(tobj_inner, GLU_TESS_VERTEX, cb_vertex)

    gluTessProperty(tobj_inner, GLU_TESS_WINDING_RULE,
                    GLU_TESS_WINDING_POSITIVE)
    gluTessProperty(tobj_inner, GLU_TESS_BOUNDARY_ONLY, GL_TRUE)

    print 'inner: gluTessBeginPolygon', tobj_inner
    gluTessBeginPolygon(tobj_inner, None)

    SLICES=32
    print 'inner: gluTessBeginContour', tobj_inner
    gluTessBeginContour(tobj_inner)
    for i in range(SLICES):
        ang = i/float(SLICES-1) * 2 * math.pi
        v = [cos(ang), sin(ang), 0]
        gluTessVertex(tobj_inner, v, v)

    print 'inner: gluTessEndContour', tobj_inner
    gluTessEndContour(tobj_inner)
    print 'inner: gluTessEndPolygon', tobj_inner
    gluTessEndPolygon(tobj_inner)

    gluDeleteTess(tobj_inner)


def main():
    tobj = gluNewTess()

    def cb_begin(type):
        print 'outer: cb_begin', tobj, type
        glBegin(type)
    def cb_end():
        print 'outer: cb_end', tobj
        glEnd()
    def cb_vertex(v):
        print 'outer: cb_vertex', tobj
        glVertex3dv(v)

    gluTessCallback(tobj, GLU_TESS_BEGIN, cb_begin)
    gluTessCallback(tobj, GLU_TESS_END, cb_end)
    gluTessCallback(tobj, GLU_TESS_VERTEX, cb_vertex)

    print 'outer: gluTessBeginPolygon', tobj
    gluTessBeginPolygon(tobj, None)
    inner(tobj)
    print 'outer: gluTessEndPolygon', tobj
    gluTessEndPolygon(tobj)

    gluDeleteTess(tobj)

main()


# --8<--

-- 
"Television: a medium. So called because it is neither rare nor well done."
				-- Ernie Kovacs.

Re: [PyOpenGL-Users] Newbie question....

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

Looks like you need to install the PyOpenGL module.

Get it from here:

http://sourceforge.net/project/showfiles.php?group_id=5988&release_id=137930


note: for the windows exe's you'll need numeric 21


 --- Jesse Crookston <cf...@ms...> wrote: > Hi,
> 
> I did a lot of OPENGL at the university and was
> excited when I found that 
> there was a port to Python!!, (a language a tinkered
> with a couple of years 
> ago...)  Inspired to regain lost knowledge, I
> installed the module.  
> Unfortunately, I found the following error message:
> 
> ===============================
> C:\Python22\Lib\site-packages\OpenGLContext>python
> drawcube.py
> Traceback (most recent call last):
>   File "drawcube.py", line 13, in ?
>     from OpenGL.GL import *
> ImportError: No module named OpenGL.GL
> ===============================
> 
> Can anyone comment/help?
> 
> Thanks,
> Jess
> 
> 
>
_________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months
> FREE*  
> http://join.msn.com/?page=features/virus
> 
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
>
https://lists.sourceforge.net/lists/listinfo/pyopengl-users 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[PyOpenGL-Users] Newbie question....

[Jesse C. <cf...@ms...>]

Hi,

I did a lot of OPENGL at the university and was excited when I found that 
there was a port to Python!!, (a language a tinkered with a couple of years 
ago...)  Inspired to regain lost knowledge, I installed the module.  
Unfortunately, I found the following error message:

===============================
C:\Python22\Lib\site-packages\OpenGLContext>python drawcube.py
Traceback (most recent call last):
  File "drawcube.py", line 13, in ?
    from OpenGL.GL import *
ImportError: No module named OpenGL.GL
===============================

Can anyone comment/help?

Thanks,
Jess


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

Re: [PyOpenGL-Users] Pointer functions copying memory.

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

On Tuesday, Feb 4, 2003, at 00:00 Europe/Amsterdam, Mike C. Fletcher 
wrote:

> Strangely, that first post of Guido's is what gave me the impression 
> the buffer API was considered less than optimal for continued use.

Here's the full scoop:
1. Buffer objects are bad (mainly because of refcount problems and 
more).
2. The buffer API in general is a good idea, and it will stay, but
3. The multi-segment capability of the buffer API may go away (or may 
not be supported in future calls), as it was never used much anyway 
(most users of the buffer API will simply complain and stop if there is 
more than one segment).
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman