pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] OpenGLContext 1.0a2 Released

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

OpenGLContext: A Learning Environment for PyOpenGL 2.x

OpenGLContext provides you with an environment for learning OpenGL
programming.  It gives you an object-oriented Python-friendly set of
services which let you concentrate on your OpenGL code instead of the
underlying GUI environment.

This is the 1.0a2 release of the project, that is, it's still alpha
software, with the potential for changes to both internal and external
interfaces and the likelihood of lots of bugs.  There's also a lot of work
still needed on documentation.  With that said, since one of the major goals
of the project is to let people "open up the hood and look at what's going
on", it's still fun to download and poke through.

You can get OpenGLContext from here:
http://pyopengl.sourceforge.net/documentation/openglcontext/

Enjoy yourselves,
Mike Fletcher



Changes:

	Fixed a bug in Context that was causing "jitter" on slower machines (frames
were swapped even if no visible rendering was occurring).

	Added a loaders sub-package, currently just a skeletal VRML97 loader
(requires mcf.vrml) and a "native" format (compressed pickled files).  These
are more sketches of loaders than production-quality mechanisms.  A better
format is needed, of course, possibly a zipped archive of resources
eventually.

	Various minor bug fixes and enhancements.

	Added class documentation for pydoc-generated documents (and modified
pydoc2 to give more useful package summaries which include summary lines of
the modules, and to automatically link to documentation for OpenGL names
mentioned in the doc strings).

	Fixed logic bug in mouse move handlers.

	Added delta function to quaternion class.

	Changed implementation and API of utilities module to match and use vector
utilities.

	Eliminated a Python 2.2 from x import * warning.

	Added explicit request for double-buffering for GLUT contexts.

Re: [PyOpenGL-Users] Konqueror doc bug

[Richard J. <ric...@op...>]

On Tue, 25 Sep 2001 13:35, Tarn Weisner Burton wrote:
> The online PyOpenGL manual should work with Konqueror now.

Indeed it does.


> thanks all,

thank you :)


    Richard

[PyOpenGL-Users] Konqueror doc bug

[Tarn W. B. <twb...@ma...>]

The online PyOpenGL manual should work with Konqueror now.

thanks all,
Tarn

RE: [PyOpenGL-Users] installation (?) problem on irix646

[Tarn W. B. <twb...@ma...>]

| Was referring to the GLUT names.  Didn't realise you were doing
| any editing
| to create those links, assumed they were being auto-linked.  Sorry about
| that, yes, the links are there for the other modules.

The actual linking is automatic (done by local mods to the stylesheets), but
function names are mark up like foo -> <function>foo</function>

Tarn

RE: [PyOpenGL-Users] installation (?) problem on irix646

[Tarn W. B. <twb...@ma...>]

| BTW, when checking the GLUT docs for version notes, I noticed
| that even the
| interlinking isn't there with my IE 5.5 version.  Are you testing with IE
| 5.5 or 6.0 or 5.0?

I've got IE6.  Do mean that some of GLUT function names aren't hyperlinked?
Or are you saying that the web server isn't giving you the right page?  The
GLUT docs need the most editing and most of the function names aren't
labeled yet, so XSLT won't hyperlink the output.  GL, GLU and GLE names
should be hyperlinked though (a few exceptions).

Note that the only place I have been able to find version info is in glut.h

Tarn

RE: [PyOpenGL-Users] installation (?) problem on irix646

[Tarn W. B. <twb...@ma...>]

|   Yes most of the demos run just fine. ( Except lesson6,18 in NeHe -
| probably due to an error on my part. I get the message _imaging C module
| not installed - I have to figure out what this means.)
| 

You need PIL.  http://www.pythonware.com/products/pil/

Tarn

RE: [PyOpenGL-Users] installation (?) problem on irix646

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

Yup, the OpenGLContext docs say requires 3.7, but I suppose I should see
about what sub-set of functionality can be provided when regressing to
earlier versions.  Likely a lot, but apps using missing functionality are
going to have problems (obviously).  Suppose a mechanism for warning about
such things is in order <sigh> :) .

BTW, when checking the GLUT docs for version notes, I noticed that even the
interlinking isn't there with my IE 5.5 version.  Are you testing with IE
5.5 or 6.0 or 5.0?

Enjoy,
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Tarn
Weisner Burton
Sent: September 24, 2001 12:35
To: PyOpenGL Mailing List
Subject: RE: [PyOpenGL-Users] installation (?) problem on irix646
...
Note to Mike:  OpenGLContext should probably check for 3.7 if there isn't a
graceful fallback, i.e.
-----------------
from OpenGL.GLUT import __api_version__
if __api_version__ < 0xd:
    print "need 3.7"
    sys.exit(1)
-----------------
for future reference:

0x1=1.0, 0x2=2.0, 0x5=3.0, 0x7=3.1, 0x9=3.4, 0xb=3.6, 0xd=3.7

thanks,
Tarn


_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users

RE: [PyOpenGL-Users] installation (?) problem on irix646

[lothar e. <le...@he...>]

On Mon, 24 Sep 2001, Tarn Weisner Burton wrote:

> By the way, did all the PyOpenGL demos run fine?  If so I can put Irix in
> the list of ports presumed to work.

  Yes most of the demos run just fine. ( Except lesson6,18 in NeHe -
probably due to an error on my part. I get the message _imaging C module
not installed - I have to figure out what this means.)

I ran info.py and got: GLUT API Version 0x000b
( as you predicted it is < 0x0d )
Thanks for your help. I will now try to install glut3.7 (again because I
thought I did it a while ago but I was obviously wrong )

Thanks,

   Lothar.

RE: [PyOpenGL-Users] installation (?) problem on irix646

[Tarn W. B. <twb...@ma...>]

By the way, did all the PyOpenGL demos run fine?  If so I can put Irix in
the list of ports presumed to work.

Tarn

RE: [PyOpenGL-Users] installation (?) problem on irix646

[Tarn W. B. <twb...@ma...>]

|   I just installed python2.1.1 and pyOpenGL2.0.0.44 on IRIX646 (octane,
| Irix 6.5.11 ) and everything seemed to work smoothly. However I cannot run
| the example programs in OpenGLContext (tests) like spincube.py.
| I always get the error message:
|
| File
| "/usr/local/lib/python2.1/site-packages/OpenGLContext/glutcontext.py",
| line 55, in setupCallbacks glutKeyboardUpFunc(self.glutOnKeyUp)
| NameError: global name 'glutKeyboardUpFunc' is not defined

glutKeyboardUpFunc is GLUT 3.7 specific.  You probably have an older version
of GLUT.  To check this run the script
"site-packages/OpenGL/scripts/info.py".   It will output a file
"PyOpenGL_info.html"  Look in the GLUT section for the API version entry.
If it is less than 0xd than you have an older version of GLUT.  You don't
have to have 3.7 to run PyOpenGL.  PyOpenGL will adjust the Python binding
for whatever version you have, but apparently OpenGLContext needs 3.7.

Note to Mike:  OpenGLContext should probably check for 3.7 if there isn't a
graceful fallback, i.e.
-----------------
from OpenGL.GLUT import __api_version__
if __api_version__ < 0xd:
    print "need 3.7"
    sys.exit(1)
-----------------
for future reference:

0x1=1.0, 0x2=2.0, 0x5=3.0, 0x7=3.1, 0x9=3.4, 0xb=3.6, 0xd=3.7

thanks,
Tarn

[PyOpenGL-Users] installation (?) problem on irix646

[lothar e. <le...@he...>]

Hi,

  I just installed python2.1.1 and pyOpenGL2.0.0.44 on IRIX646 (octane,
Irix 6.5.11 ) and everything seemed to work smoothly. However I cannot run
the example programs in OpenGLContext (tests) like spincube.py.
I always get the error message:

File
"/usr/local/lib/python2.1/site-packages/OpenGLContext/glutcontext.py",
line 55, in setupCallbacks glutKeyboardUpFunc(self.glutOnKeyUp)
NameError: global name 'glutKeyboardUpFunc' is not defined

I have to say that I am not too familiar with python let alone with
pyOpenGL (which I install for the first time ).
Does anyone know what is wrong here ?

Thanks,
       Lothar

Dr. Lothar Esser
NIH / NCI
Tel. 301-435-6316
email le...@he...

RE: [PyOpenGL-Users] PyOpenGL Documentation, Ports & Future Features

[Tarn W. B. <twb...@ma...>]

| Unfortunately, the TOC loads ok, but sub-pages crash Konqueror 
| (2.2.1). I'll 
| look into that tomorrow night.

I'll look at that.

| ps. I just got moderation notes for the mailing list. Is it not 
| intended for 
| general discussion like this?

Yep.  I was just tweaking some spam settings.  Should work fine now.

Tarn

RE: [PyOpenGL-Users] PyOpenGL Documentation, Ports & Future Features

[Tarn W. B. <twb...@ma...>]

| I think Richard was referring to the links from the documentation page to
| "GL", "GLU", "GLUT", and "GLE", which up to a few minutes ago
| were pointing
| at my old proof-of-concept conversions of the man pages.  They
| now point to
| your XML-generated manual sections.  Note, however, that save for the GLE
| docs, none of the Python sections is currently showing up in IE 5.5,
| possibly a style sheet problem (your test document for adding the sections
| originally showed up with the Python section as I recall)?

Looks fine to me.  Most of the Python sections just haven't been written.
GLE is done
but only a few GL pages are done.

Tarn

RE: [PyOpenGL-Users] PyOpenGL Documentation, Ports & Future Features

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

I think Richard was referring to the links from the documentation page to
"GL", "GLU", "GLUT", and "GLE", which up to a few minutes ago were pointing
at my old proof-of-concept conversions of the man pages.  They now point to
your XML-generated manual sections.  Note, however, that save for the GLE
docs, none of the Python sections is currently showing up in IE 5.5,
possibly a style sheet problem (your test document for adding the sections
originally showed up with the Python section as I recall)?

Sorry for the delay in updating the site there,
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Tarn
Weisner Burton
Sent: September 24, 2001 07:51
To: pyo...@li...
Subject: RE: [PyOpenGL-Users] PyOpenGL Documentation, Ports & Future
Features


|
| On Mon, 24 Sep 2001 07:32, Tarn Weisner Burton wrote:
| > man2dbk is far from complete, but it is complete enough for the more
| > immediate task of converting the GL, GL, GLUT and GLE manpages.
|  I've done
| > this and the results are now in the "reference" section of the manual.
|
| The content there doesn't appear to have changed - does that mean
| the output
| is identical to the old generated HTML, or is something between
| me and there
| caching the pages where it shouldn't be?
|

The "User's Manual" with integrated manpages at
http://pyopengl.sf.net/documentation/manual has actually had the manpages
for about two weeks, I just hadn't announced it.

For the docs sent out with the distribution see <site-packages>/OpenGL/doc
...

RE: [PyOpenGL-Users] PyOpenGL Documentation, Ports & Future Features

[Tarn W. B. <twb...@ma...>]

|
| On Mon, 24 Sep 2001 07:32, Tarn Weisner Burton wrote:
| > man2dbk is far from complete, but it is complete enough for the more
| > immediate task of converting the GL, GL, GLUT and GLE manpages.
|  I've done
| > this and the results are now in the "reference" section of the manual.
|
| The content there doesn't appear to have changed - does that mean
| the output
| is identical to the old generated HTML, or is something between
| me and there
| caching the pages where it shouldn't be?
|

The "User's Manual" with integrated manpages at
http://pyopengl.sf.net/documentation/manual has actually had the manpages
for about two weeks, I just hadn't announced it.

For the docs sent out with the distribution see <site-packages>/OpenGL/doc

|
| > 1) integrated manpages
|
| As a quick note on directions I'd like to see... this is #1! I'm
| using the
| man page HTML on the sf.net site as a constant reference. I
| should pull my
| finger out and generate a local copy :)
|

It is possible to generate your own copy of the docs sent out with the
distribution.  To do so you need Saxon and DocBook XSL.  Its probably not
worth it though since the dist includes HTML and PDF pregenerated.

Right now I am the only one who can build the new docs, mostly because I
haven't formalized the build process.  It's also slow as hell.  Takes about
an hour to generate the docs for the website.

| > Note that the Mac port is currently stalled since
| > PyOpenGL setup requires the ability to compile executables, not just
| > dynamic/static libs.  I've talked to a few people about this
| but I haven't
| > heard any word about progress yet.  Fixing this involves adding some
| > capabilities to distutils.mwerkscompiler.  I can provide more details to
| > anyone who is interested.
|
| Hrm - I'm doing a fair bit of OS X / Python work these days, and
| I could give
| the source a try out at work. I use only the utilities
| distributed with OS X
| - gcc, the apple Project Builder etc. I can't develop for OS 9 or earlier.
|

Feel free to look at it.  I believe that the config file you will need to
create is "config/darwin"  Does OSX use mac line endings? Anyways there's a
dist with mac line endings at http://pyopengl.sf.net/ftp/

You're probably going to need the latest CVS of distutils since there have
been some Mac changes recently.

thanks,
Tarn

Re: [PyOpenGL-Users] PyOpenGL Documentation, Ports & Future Features

[Richard J. <ric...@op...>]

On Mon, 24 Sep 2001 07:32, Tarn Weisner Burton wrote:
> man2dbk is far from complete, but it is complete enough for the more
> immediate task of converting the GL, GL, GLUT and GLE manpages.  I've done
> this and the results are now in the "reference" section of the manual.

The content there doesn't appear to have changed - does that mean the output 
is identical to the old generated HTML, or is something between me and there 
caching the pages where it shouldn't be?


> 1) integrated manpages

As a quick note on directions I'd like to see... this is #1! I'm using the 
man page HTML on the sf.net site as a constant reference. I should pull my 
finger out and generate a local copy :)


> Note that the Mac port is currently stalled since
> PyOpenGL setup requires the ability to compile executables, not just
> dynamic/static libs.  I've talked to a few people about this but I haven't
> heard any word about progress yet.  Fixing this involves adding some
> capabilities to distutils.mwerkscompiler.  I can provide more details to
> anyone who is interested.

Hrm - I'm doing a fair bit of OS X / Python work these days, and I could give 
the source a try out at work. I use only the utilities distributed with OS X 
- gcc, the apple Project Builder etc. I can't develop for OS 9 or earlier.


      Richard

Re: [PyOpenGL-Users] Lighting and texturing

[Richard J. <ric...@op...>]

On Mon, 24 Sep 2001 02:10, Mike C. Fletcher wrote:
> Just a note, beyond just enabling blending, you normally want to sort the
> triangles from farthest to nearest for rendering.

Yep, noticed that pretty quickly. Fortunately, there's some characteristics 
of the stuff I'm drawing that I can exploit so that I can draw in the right 
order.


    Richard

[PyOpenGL-Users] PyOpenGL Documentation, Ports & Future Features

[Tarn W. B. <twb...@ma...>]

Just thought I'd update everyone on a few PyOpenGL issues.

First if you've visited the PyOpenGL documentation page at
http://pyopengl.sourceforge.net/documentation/ you may have noticed that the
PyOpenGL2 User's manual is a bit different from the one with the latest
distribution.  Two sections have been added: a "reference" section and a
"ports" section.

The reference section is an outgrowth of an idea that Mike had about
creating an integrated set of manpages which had the Python function
prototypes listed in addition the to C prototypes.  The proof of concept
that he originally created used some OpenGL 1.1 HTML manpages created by
SGI.  After some discussions with SGI it became clear that marking up the
HTML source with our own local notes was probably not going to work in the
long run since these sources were out of date and producing new versions was
difficult at best.  SGI also expressed an interest in converting the
original manpage source to a more modern format, probably some kind XML
format.  So on a lark I whipped up a Python script to convert the manpages
into DocBook XML, which is the format that the PyOpenGL manual is in.  I've
spun that effort off as the man2dbk project at http://man2dbk.sf.net

man2dbk is far from complete, but it is complete enough for the more
immediate task of converting the GL, GL, GLUT and GLE manpages.  I've done
this and the results are now in the "reference" section of the manual.  Alot
of work remains to be done on this section, namely the rather tedious final
formatting and addition of Python notes, but visible progress is being made.

These manpages are based on OpenGL 1.2 and contain a fair number of
equations.  For DocBook and HTML this ends up meaning that MathML is needed.
Right now only Amaya and Mozilla support MathML natively.  For these
browsers the web server will deliver XHTML pages with MathML.  For all other
browsers the web server will deliver HTML pages with inline images.  Note
that the standard distribution of Mozilla does not include MathML and since
there is no way for the web server to tell which version of Mozilla is
requesting a page it just always assumes that Mozilla is MathML enabled.
For more information on Mozilla MathML support see
http://www.mozilla.org/projects/mathml/   For more information on Amaya see
http://www.w3.org/Amaya/

As mentioned before, I've added a "ports" section to the manual which
attempts to list all the current ports of PyOpenGL and any specific building
or installation notes which pertain to each port.  This section woefully
incomplete at the present time, but its a start.  If anyone has information
on any other platforms which are not listed or more notes for listed
platforms please drop me a line.  I'd like to see this list become as
complete as possible.  Along with the status of ongoing ports and platform
specific notes I've also included the entries "maintainer" and "verified by"
If you've compiled PyOpenGL successfully on a platform than please tell me
so that at least I can indicate this with the "verified by" entry.  I'm also
looking for platform maintainers so we can make sure that new versions
PyOpenGL run on existing platforms.

Now as to future directions of PyOpenGL.  The PyOpenGL SF project page has
various item trackers, one of which is a feature request tracker.  I
encourage people to submit items to this list or make comments on the
existing items.  Although it is far to early to make statements about what
new features will be in 2.1, the following items are, in my mind, of top
priority:

1) integrated manpages
2) OpenGL 1.2 & 1.3 support
3) Mac port

Comments are welcome.  Note that the Mac port is currently stalled since
PyOpenGL setup requires the ability to compile executables, not just
dynamic/static libs.  I've talked to a few people about this but I haven't
heard any word about progress yet.  Fixing this involves adding some
capabilities to distutils.mwerkscompiler.  I can provide more details to
anyone who is interested.

thanks all,
Tarn

RE: [PyOpenGL-Users] Lighting and texturing

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

Just a note, beyond just enabling blending, you normally want to sort the
triangles from farthest to nearest for rendering.  The
OpenGLContext/scenegraph/arraygeometry classes (and some supporting modules)
do that if you need sample code.  It's not fancy (no resolution of
equi-distant interfering geometry, for instance, no tessellation where
triangles intersect for another), but it can avoid having some of the
artefacts.

Enjoy,
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Richard
Jones
Sent: September 22, 2001 19:21
To: pyo...@li...
Subject: Re: [PyOpenGL-Users] Lighting and texturing
...
Actually, the image is fine... I just got the alpha stuff going - the
GL_BLEND isn't the TexEnv, it's just something that needs glEnable'ing.
Fixed!
...

RE: [PyOpenGL-Users] Lighting and texturing

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

http://www.frii.com/~martz/oglfaq/

I found it by doing a search for

	OpenGL lighting texturing

on Google.

HTH,
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Richard
Jones
Sent: September 22, 2001 18:59
To: pyo...@li...
Subject: Re: [PyOpenGL-Users] Lighting and texturing
...
Mike - that info you posted looked like an FAQ entry - if it is, what's the
URL please?
...

Re: [PyOpenGL-Users] Lighting and texturing

[Richard J. <ric...@op...>]

On Sun, 23 Sep 2001 08:58, Richard Jones wrote:
> The other problem I had - the transparency not working - is still a
> problem. For that code, on Pete's suggestion, I've used GL_BLEND, but the
> resultant image turns blue! I suspect my image's alpha channel is not up to
> scratch. This is the image I attached to my last message. Any suggestions
> for paint packages that produce reliable alpha channels? The GIMP seems to
> (in editing) but I just loaded my PNG into another package and that said
> the image is 24 bit. That tells me that either the GIMP is writing 6 bits
> per channel (which as far as I can tell, it's not) or it's not writing the
> alpha channel. And yet when I load the image back into the GIMP, it's got
> transparency...

Actually, the image is fine... I just got the alpha stuff going - the 
GL_BLEND isn't the TexEnv, it's just something that needs glEnable'ing. Fixed!

Thanks for the help guys! :)


    Richard

Re: [PyOpenGL-Users] Lighting and texturing

[Richard J. <ric...@op...>]

Thanks Mike, the problem was in fact a GL_DECAL use. The lesson18 source in 
the NeHe demo directory needs to be fixed to remove it. Works a treat then.

The other problem I had - the transparency not working - is still a problem. 
For that code, on Pete's suggestion, I've used GL_BLEND, but the resultant 
image turns blue! I suspect my image's alpha channel is not up to scratch. 
This is the image I attached to my last message. Any suggestions for paint 
packages that produce reliable alpha channels? The GIMP seems to (in editing) 
but I just loaded my PNG into another package and that said the image is 24 
bit. That tells me that either the GIMP is writing 6 bits per channel (which 
as far as I can tell, it's not) or it's not writing the alpha channel. And 
yet when I load the image back into the GIMP, it's got transparency...

Mike - that info you posted looked like an FAQ entry - if it is, what's the 
URL please?


       Richard

RE: [PyOpenGL-Users] Lighting and texturing

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

21.030 Why doesn't lighting work when I turn on texture mapping?

There are many well-meaning texture map demos available on the Web that set
the texture environment to GL_DECAL or GL_REPLACE. These environment modes
effectively replace the primitive color with the texture color. Because
lighting values are calculated before texture mapping (lighting is a per
vertex operation, while texture mapping is a per fragment operation), the
texture color replaces the colors calculated by lighting. The result is that
lighting appears to stop working when texture mapping is enabled.

The default texture environment is GL_MODULATE, which multiplies the texture
color by the primitive (or lighting) color. Most applications that use both
OpenGL lighting and texture mapping use the GL_MODULATE texture environment.

Look for the following line in your code:

glTexEnv (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL); /* or GL_REPLACE
*/
You should change GL_DECAL to GL_MODULATE, or simply delete the line
entirely (since GL_MODULATE is the default).



Might that be the problem in your code?  I'll take a look at your code
tomorrow if I can get some time and see if I can see anything.  Also need to
make sure none of my code is well meaning :o) , pretty sure I have a few of
those hanging around...
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Richard
Jones
Sent: September 22, 2001 07:33
To: pyo...@li...
Subject: Re: [PyOpenGL-Users] Lighting and texturing


On Sat, 22 Sep 2001 20:15, Richard Jones wrote:
> I can't seem to figure how to have a surface lit and textured. The demo
> that comes with pyopengl (NeHe/lesson18.py) doesn't work, and my code
looks
> very similar to it...
>
> Ideas?
...
        glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL)
...

Re: [PyOpenGL-Users] Lighting and texturing

[Richard J. <ric...@op...>]

On Sat, 22 Sep 2001 20:15, Richard Jones wrote:
> I can't seem to figure how to have a surface lit and textured. The demo
> that comes with pyopengl (NeHe/lesson18.py) doesn't work, and my code looks
> very similar to it...
>
> Ideas?

I'm also having trouble getting things to be transparent, and I get the funny 
feeling they're related problems...

OK, this time I'll actually send some code :)

First up, the code that initialises things:
        glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH)
        glutInitWindowSize(self.width, self.height)
        glutCreateWindow("GLE demo")

        # display all the time
        glutDisplayFunc(self.on_display)
        glutIdleFunc(self.on_display)

        # go with both normal and passive (mouse button down and not)
        glutPassiveMotionFunc(self.on_motion)
        glutMotionFunc(self.on_motion)
        # and detect mouse clicks
        glutMouseFunc(self.on_mouse)
        # and key clicks
        glutKeyboardFunc(self.on_key)
        glutReshapeFunc(self.on_reshape)
        if '-fs' in args:
            glutFullScreen()

        # set up the display specifics
        glClearDepth(1.0)
        glEnable(GL_DEPTH_TEST)
        glClearColor(0.0, 0.0, 0.0, 0.0)
        glShadeModel(GL_FLAT)

        glMatrixMode(GL_MODELVIEW)

        # initialize lighting
        glLightfv(GL_LIGHT0, GL_POSITION,  (-40.0, 40, -100.0, 0.0))
        glLightfv(GL_LIGHT0, GL_DIFFUSE, (0.99, 0.99, 0.99, 1.0))
        glEnable(GL_LIGHT0)
        glLightfv(GL_LIGHT1, GL_POSITION, (-100.0, 40, -40.0, 0.0))
        glLightfv(GL_LIGHT1, GL_DIFFUSE, (0.99, 0.99, 0.99, 1.0))
        glEnable(GL_LIGHT1)
        glEnable(GL_LIGHTING)

        glColorMaterial(GL_FRONT_AND_BACK, GL_DIFFUSE)
        glEnable(GL_COLOR_MATERIAL)



Now, the code that is supposed to light and texture map surfaces:

        self.texture = Image.open('texmap_256.png')
        ix, iy = self.texture.size
        image = self.texture.tostring("raw", "RGB", 0, -1)
        self.maptex = glGenTextures(1)
        glBindTexture(GL_TEXTURE_2D, self.maptex)
        glPixelStorei(GL_UNPACK_ALIGNMENT,1)
        glTexImage2D(GL_TEXTURE_2D, 0, 3, ix, iy, 0, GL_RGB,
            GL_UNSIGNED_BYTE, image)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
        glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL)
        print "... done"

... later ...

        glPushMatrix()
        glEnable(GL_TEXTURE_2D)
        glBindTexture(GL_TEXTURE_2D, self.maptex)
        glEnable(GL_LIGHTING)
        glShadeModel(GL_FLAT)

        [ "i" loop ]
            [ "j" loop ]
                glBegin(GL_TRIANGLES)
                norm1, norm2, p1, p2, p3, p4 = z_row[j]

                glNormal(*norm1)

                glTexCoord2f(i*4./256., j*4./256.)
                glVertex(*p1)
                glTexCoord2f(i*4./256., (j*4.+4)/256.)
                glVertex(*p2)
                glTexCoord2f((i*4.+4)/256., (j*4.+4)/256.)
                glVertex(*p3)

                glNormal(*norm2)
                glTexCoord2f(i*4./256., j*4./256.)
                glVertex(*p1)
                glTexCoord2f((i*4.+4)/256., (j*4.+4)/256.)
                glVertex(*p3)
                glTexCoord2f((i*4.+4)/256., j*4./256.)
                glVertex(*p4)
                glEnd()
        glDisable(GL_TEXTURE_2D)



Next up, the code that is supposed to use a texture with an alpha channel:

        self.texture = Image.open('point_64.png')
        ix, iy = self.texture.size
        image = self.texture.tostring("raw", "RGBA", 0, -1)
        self.pointtex = glGenTextures(1)
        glBindTexture(GL_TEXTURE_2D, self.pointtex)
        glPixelStorei(GL_UNPACK_ALIGNMENT,1)
        glTexImage2D(GL_TEXTURE_2D, 0, 3, ix, iy, 0, GL_RGBA,
           GL_UNSIGNED_BYTE, image)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
        glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL)

... later ...
 
        glEnable(GL_TEXTURE_2D)
        glBindTexture(GL_TEXTURE_2D, self.pointtex)
        glDisable(GL_LIGHTING)
        glBegin(GL_QUADS)
        [ loop ]
            glTexCoord2f(0, 0)
            glVertex3f(x, y, z)
            glTexCoord2f(1, 0)
            glVertex3f(x+2, y, z)
            glTexCoord2f(1, 1)
            glVertex3f(x+2, y+2, z)
            glTexCoord2f(0, 1)
            glVertex3f(x, y+2, z)
        glEnd()
        glEnable(GL_LIGHTING)
        glDisable(GL_TEXTURE_2D)


I've also attached the point_64.png image, generated in the GIMP. I'm 
_pretty_ sure it's transparent - unlike Photoshop, the GIMP doesn't show me 
the alpha channel explicitly (unless I'm doing something wrong, which is 
possible :)

I can post the complete code, but it's supposed to be a surprise :)


    Richard

[PyOpenGL-Users] Lighting and texturing

[Richard J. <ric...@op...>]

I can't seem to figure how to have a surface lit and textured. The demo that 
comes with pyopengl (NeHe/lesson18.py) doesn't work, and my code looks very 
similar to it...

Ideas?


    Richard