pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] Problem during install: can't find package Tk 8.1

[Leonardo <lbe...@ya...>]

Hi, I am trying to install with

python setup.py install

and I got the following error:

copying build/Togl-1.6-tk8.3/Togl.so ->
/usr/lib/python2.2/site-packages/OpenGL/Tk/linux2-tk8.3
running "pkg_mkIndex
/usr/lib/python2.2/site-packages/OpenGL/Tk/linux2-tk8.3
Togl.so"
warning: error while loading Togl.so: can't find
package Tk 8.1

My system:

Red Hat 9.0 with python 2.2 and I already install
glut-devel-3.7-12.i386.rpm nvidia drivers and Numeric
23 and gl development (glut-devel-3.7-12.i386.rpm)

I also have Tk 8.3 installed. Should I install 8.1???

#rpm -qai tk
Name        : tk                          
Relocations: (not relocateable)
Version     : 8.3.5                            
Vendor: Red Hat, Inc.
Release     : 88                            Build
Date: Thu 06 Feb 2003 08:41:20 AM CST
Install Date: Thu 23 Oct 2003 08:32:23 PM CDT     
Build Host: daffy.perf.redhat.com
Group       : Development/Languages         Source
RPM: tcltk-8.3.5-88.src.rpm


Help please !!! 

Thanks a lot!

Leonardo


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Re: [PyOpenGL-Users] PyOpenGL 2.0.x, Python 2.3 and Red Hat 9.0

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

Matt Pickering wrote:

>Hi,
>
>I'm a new user of PyOpenGL (and OpenGL in general) and
>I'm wanting to use Python in a few 3D projects I am
>working on.  However, I am stymied by the fact I
>cannot get PyOpenGL to build or work successfully on
>my system.
>
>I have a stock Red Hat 9.0 Personal installation on an
>AMD Athlon with an nVidia GeForce 4 video card.  I am
>using the nVidia drivers for hardware acceleration
>(and it is fast judging by the OpenGL screen savers).
>
>I have installed glut 3.7 from RPM.  I have, however,
>replaced Python 2.2 with a build of Python 2.3 from
>source.  I've had no problems with Python 2.3 with the
>exception of PyOpenGL.  I have SWIG 1.1 (comes with
>RH9), Numeric 23.0 (from source), the Python Imaging
>Library (latest stable release built from source).  I
>also have OpenGLContext 2.x installed from RPM.
>
>However, when I try to build PyOpenGL (either the beta
>release or the RC2 release), I either get build
>failures (headers not found) or segmentation faults. 
>Once I got glut installed, the major build failures
>disappeared.  I disabled the build of Togl since it
>kept causing seg faults.  With Togl builds disabled,
>PyOpenGL compiles but fails to install fully.  
>
>I can import the OpenGL module but I can get nothing
>to run.  Half of the time, it reports failure to
>locate module GL.__init__.  The rest of the time, I
>get a good import and then Python seg faults.
>
>FYI, I have Mesa 3.x installed (which ever version
>ships with RH9).  I have managed to compile Mesa 5.x
>but haven't installed it for fear of throwing one more
>variable into the unknown.
>
>So my question is: has anyone had any success getting
>PyOpenGL up and running using Python 2.3 under Red Hat
>9?  RH9 is largely an incremental upgrade to RH8
>(which I upgraded from) so I don't see any major
>library differences.  Could GCC 3.2.2 be the problem? 
>I desperately would like to use PyOpenGL and I need it
>since it is the low-level rendering API the other APIs
>I want to use depend on (PyGame and PyUI). 
>  
>

I think pyui can run without opengl.  It could at one point in time anyway.

>I am open to any suggestions short of rebuilding my
>box.  :)  I also have a SuSe 8.2 Pro machine with a
>Voodoo3 I can experiment on.  It is a new install and
>hasn't been touched yet.
>
>Any help appreciated.
>
>Matt Pickering
>  
>

Get swig 1.3.13.  Check out the readme.cvs and the docs on 
pyopengl.sf.net for some other build instructions.

Also note, you'll probably need the nvidia opengl drivers for full 
opengl goodness(or does redhat come with their drivers?).


Have fun!
http://www.holepit.com/

Re: [PyOpenGL-Users] PyOpenGL 2.0.x, Python 2.3 and Red Hat 9.0

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

Matt Pickering wrote:
...

>I have a stock Red Hat 9.0 Personal installation 
>  
>
...

>I have SWIG 1.1 (comes with
>RH9), 
>
Shouldn't be necessary for any packaged build (e.g. rc2 or 2.0.1.07).

>Numeric 23.0 (from source), 
>
Okay.

>the Python Imaging
>Library (latest stable release built from source).  I
>also have OpenGLContext 2.x installed from RPM.
>  
>
Okay, neither of these should affect PyOpenGL itself, they're loosely 
coupled by Python code.

>However, when I try to build PyOpenGL (either the beta
>release or the RC2 release), I either get build
>failures (headers not found) 
>
Could it be you don't have the Python 2.3 headers/libs available in your 
path?  RedHat normally has a python-devel RPM that has this stuff IIRC.  
Not sure how it works for a from-source install.

>or segmentation faults. 
>Once I got glut installed, the major build failures
>disappeared.  I disabled the build of Togl since it
>kept causing seg faults.  With Togl builds disabled,
>PyOpenGL compiles but fails to install fully.  
>  
>
Just to be clear: you completely cleaned out any previous version of 
PyOpenGL, right?  That is, you nuked the entire site-packages/OpenGL 
directory?

>I can import the OpenGL module but I can get nothing
>to run.  Half of the time, it reports failure to
>locate module GL.__init__.  The rest of the time, I
>get a good import and then Python seg faults.
>  
>
Sounds very much as though you have an older version (likely compiled 
against Python 2.2.x) conflicting with the new version.  rc2 changed the 
name of that module to GL.GL__init__ to allow OS-X to load the 
libraries.  I'd suggest trying a clean build (i.e. nuke the final 
installation directory and the source-directory/build directory and then 
re-build).

>FYI, I have Mesa 3.x installed (which ever version
>ships with RH9).  I have managed to compile Mesa 5.x
>but haven't installed it for fear of throwing one more
>variable into the unknown.
>  
>
Shouldn't be necessary.  PyOpenGL knows basically nothing about Mesa.

>So my question is: has anyone had any success getting
>PyOpenGL up and running using Python 2.3 under Red Hat
>9?  RH9 is largely an incremental upgrade to RH8
>(which I upgraded from) so I don't see any major
>library differences.  
>
I switched my dual-boot drive to Knoppix a few weeks ago, so I don't 
have a RedHat install for testing/building any more.

>Could GCC 3.2.2 be the problem? 
>  
>
Not likely.

>I am open to any suggestions short of rebuilding my
>box.  :)  
>
:)  Debian is a comparative dream. ;)

>I also have a SuSe 8.2 Pro machine with a
>Voodoo3 I can experiment on.  It is a new install and
>hasn't been touched yet.
>  
>
Sure, you could try it there, but probably won't help you any?  rc2 is 
known to build and run on Knoppix (Debian) under Python 2.3 (with togl 
disabled), so it would really seem that it's your RedHat install that 
needs some love.

Okay, must get back to paying work now.  Good luck,
Mike

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

[PyOpenGL-Users] PyOpenGL 2.0.x, Python 2.3 and Red Hat 9.0

[Matt P. <mp...@ya...>]

Hi,

I'm a new user of PyOpenGL (and OpenGL in general) and
I'm wanting to use Python in a few 3D projects I am
working on.  However, I am stymied by the fact I
cannot get PyOpenGL to build or work successfully on
my system.

I have a stock Red Hat 9.0 Personal installation on an
AMD Athlon with an nVidia GeForce 4 video card.  I am
using the nVidia drivers for hardware acceleration
(and it is fast judging by the OpenGL screen savers).

I have installed glut 3.7 from RPM.  I have, however,
replaced Python 2.2 with a build of Python 2.3 from
source.  I've had no problems with Python 2.3 with the
exception of PyOpenGL.  I have SWIG 1.1 (comes with
RH9), Numeric 23.0 (from source), the Python Imaging
Library (latest stable release built from source).  I
also have OpenGLContext 2.x installed from RPM.

However, when I try to build PyOpenGL (either the beta
release or the RC2 release), I either get build
failures (headers not found) or segmentation faults. 
Once I got glut installed, the major build failures
disappeared.  I disabled the build of Togl since it
kept causing seg faults.  With Togl builds disabled,
PyOpenGL compiles but fails to install fully.  

I can import the OpenGL module but I can get nothing
to run.  Half of the time, it reports failure to
locate module GL.__init__.  The rest of the time, I
get a good import and then Python seg faults.

FYI, I have Mesa 3.x installed (which ever version
ships with RH9).  I have managed to compile Mesa 5.x
but haven't installed it for fear of throwing one more
variable into the unknown.

So my question is: has anyone had any success getting
PyOpenGL up and running using Python 2.3 under Red Hat
9?  RH9 is largely an incremental upgrade to RH8
(which I upgraded from) so I don't see any major
library differences.  Could GCC 3.2.2 be the problem? 
I desperately would like to use PyOpenGL and I need it
since it is the low-level rendering API the other APIs
I want to use depend on (PyGame and PyUI). 

I am open to any suggestions short of rebuilding my
box.  :)  I also have a SuSe 8.2 Pro machine with a
Voodoo3 I can experiment on.  It is a new install and
hasn't been touched yet.

Any help appreciated.

Matt Pickering

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

[PyOpenGL-Users] newbie question, create a 3D water tank with falling water

[cyue <cy...@te...>]

(sorry for repeating)


hi all,

has anyone ever done a 3D water tank with falling water in PyOpenGL, i.e.
the water drains and the water level falls? i would be interested in looking
at the code. if there is a opensource code example, that will be fine too.
thanks.


cyu

ps: i seem receiving broken mesage back and losing the title when sending to
the list

[PyOpenGL-Users] newbie question, create a 3D water tank with falling water

[cyue <cy...@te...>]

aGkgYWxsLA0KDQpoYXMgYW55b25lIGV2ZXIgZG9uZSBhIDNEIHdhdGVyIHRhbmsgd2l0aCBmYWxs
aW5nIHdhdGVyIGluIFB5T3BlbkdMLCBpLmUuIHRoZSB3YXRlciBkcmFpbnMgYW5kIHRoZSB3YXRl
ciBsZXZlbCBmYWxscz8gaSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGxvb2tpbmcgYXQgdGhlIGNv
ZGUuIGlmIHRoZXJlIGlzIGEgb3BlbnNvdXJjZSBjb2RlIGV4YW1wbGUsIHRoYXQgd2lsbCBiZSBm
aW5lIHRvby4gdGhhbmtzLg0KDQoNCmN5dQ0KDQpwczogaSBzZWVtIHJlY2VpdmluZyBicm9rZW4g
bWVzYWdlIGJhY2sgYW5kIGxvc2luZyB0aGUgdGl0bGUgd2hlbiBzZW5kaW5nIHRvIHRoZSBsaXN0
Lg==

[PyOpenGL-Users] newbie question, create a 3D water tank with falling water

[Philip Y. <phi...@te...>]

aGkgYWxsLA0KDQpoYXMgYW55b25lIGV2ZXIgZG9uZSBhIDNEIHdhdGVyIHRhbmsgd2l0aCBmYWxs
aW5nIHdhdGVyIGluIFB5T3BlbkdMLCBpLmUuIHRoZSB3YXRlciBkcmFpbnMgYW5kIHRoZSB3YXRl
ciBsZXZlbCBmYWxscz8gaSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGxvb2tpbmcgYXQgdGhlIGNv
ZGUuIGlmIHRoZXJlIGlzIGEgb3BlbnNvdXJjZSBjb2RlIGV4YW1wbGUsIHRoYXQgd2lsbCBiZSBm
aW5lIHRvby4gdGhhbmtzLg0KDQoNCmN5dQ0KDQpwczogaSBzZWVtIHJlY2VpdmluZyBicm9rZW4g
bWVzYWdlIGJhY2sgYW5kIGxvc2luZyB0aGUgdGl0bGUgd2hlbiBzZW5kaW5nIHRvIHRoZSBsaXN0
Lg==

[PyOpenGL-Users] newbie question, create a 3D water tank with falling water

[cyue <cy...@te...>]

aGkgYWxsLA0KDQpoYXMgYW55b25lIGV2ZXIgZG9uZSBhIDNEIHdhdGVyIHRhbmsgd2l0aCBmYWxs
aW5nIHdhdGVyIGluIFB5T3BlbkdMLCBpLmUuIHRoZSB3YXRlciBkcmFpbnMgYW5kIHRoZSB3YXRl
ciBsZXZlbCBmYWxscz8gaSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGxvb2tpbmcgYXQgdGhlIGNv
ZGUuIGlmIHRoZXJlIGlzIGEgb3BlbnNvdXJjZSBjb2RlIGV4YW1wbGUsIHRoYXQgd2lsbCBiZSBm
aW5lIHRvby4gdGhhbmtzLg0KDQpjeXVl

[PyOpenGL-Users] Marketing Details

[Marketing <Pro...@29...>]

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Sales & Marketing
Su...@1c...
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm

[PyOpenGL-Users] [ pyopengl-Feature Requests-661691 ] OpenGL is at 1.4

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

Feature Requests item #661691, was opened at 2003-01-03 07:54
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=661691&group_id=5988

Category: GL
Group: v2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenGL is at 1.4

Initial Comment:
Currently, OpenGL is at version 1.4.  It sure would be 
nice to access the new features from withion Python.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-10-23 06:41

Message:
Logged In: NO 

i love pyopengl, it is great! but is it dead?

why isn't opengl 1.4 supported? and why isn't there a win32 
installer for python 2.3?

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-01-07 05:06

Message:
Logged In: YES 
user_id=34901

Agreed, want to submit a patch ;) .

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

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

[PyOpenGL-Users] [ pyopengl-Feature Requests-661691 ] OpenGL is at 1.4

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

Feature Requests item #661691, was opened at 2003-01-03 10:54
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=661691&group_id=5988

Category: GL
Group: v2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenGL is at 1.4

Initial Comment:
Currently, OpenGL is at version 1.4.  It sure would be 
nice to access the new features from withion Python.

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-10-23 11:00

Message:
Logged In: YES 
user_id=34901

Not dead AFAIK, we just released a new version 2 or 3 days
ago ;) .  That said, the primary developer (me) is not
particularly flush for time to work on PyOpenGL, so I'm
mostly acting as manager, rather than developer these days.
 I'd *love* to see the extensions for 1.4 added, but unless
someone decides to pay my employer for me to work on
PyOpenGL (which really doesn't seem likely), or someone with
far more time steps up to do the work, the development is
going to be slow.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-10-23 09:41

Message:
Logged In: NO 

i love pyopengl, it is great! but is it dead?

why isn't opengl 1.4 supported? and why isn't there a win32 
installer for python 2.3?

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-01-07 08:06

Message:
Logged In: YES 
user_id=34901

Agreed, want to submit a patch ;) .

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

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

[PyOpenGL-Users] Passing GL_DOUBLEBUFFER in display.set_mode() causes title bar and frame to disappear

[Andy Sy <an...@ne...>]

When using Pygame 1.5.6 with PyOpenGL-Minimal 2.0.1.04 (GeForce 4
Ti4200/Detonator 45.23/Windows XP SP1), I get the following
behaviour:

Passing GL_DOUBLEBUFFER in display.set_mode() causes the title bar
and frame to disappear.  This is not the behaviour in a C SDL
app.

Also, the DOUBLEBUF flag must be passed if doing OpenGL, otherwise
display flickers badly... and again in a C SDL app, there is no
such requirement.

Note that I'm using pygame.display.flip() to update the frame.


(CC'ed this to the PyOpenGL-users list just in case someone wants to
confirm if this is a problem with the version of PyOpenGL I'm
using.)

[PyOpenGL-Users] GL_ARB_imaging

[Joe C. <joe...@ho...>]

<html><div style='background-color:'><DIV>
<P>Hi,</P>
<P>The docs make repeated mention to GL_ARB_imaging, but pyopengl doesn't seem to have a module for it (nothing in the GL/ARB folder), does pyopengl support GL_ARB_imaging?</P>
<P>It is being return by glGetString(GL_EXTENSIONS).</P>
<P>Thanks,</P>
<P>Joe<BR><BR></P></DIV></div><br clear=all><hr>Chat via SMS. Simply send 'CHAT' to 1889918. <a href="http://g.msn.com/8HMAENAU/2728??PS="> More info here.</a> </html>

Re: [PyOpenGL-Users] features from OpenGL > 1.1

[Andrew S. <as...@in...>]

Mike C. Fletcher wrote:

> Andrew Straw wrote:
> 
>> I'm trying to understand what/how/if PyOpenGL deals with multiple 
>> versions of OpenGL.  For example, if I run PyOpenGL on a machine with 
>> OpenGL 1.3 libraries, I should have multitexturing abilities built-in 
>> (e.g. glActiveTexture() function).  This is specified in the OpenGL 
>> 1.3 spec:
>> http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf
> 
> 
> PyOpenGL is currently limited to OpenGL 1.1.  At the moment, I don't 
> have drivers which support features from OpenGL 1.2 or above.

You can always run Mesa to get OpenGL 1.4.  (It's not HW accelerated, 
but it'll at least let you test.)

> There are 
> a few extensions that, if I get the time, I might code up wrappers for, 
> but they aren't the fun/sexy stuff for new hardware, I only have a 
> Radeon 7500.

OK, but my question really is: how does/would PyOpenGL deal with the 
concept that at build time I might not have access to OpenGL > 1.1 libs, 
  but may want to run later (without re-compiling) on a system with 
later libs.  It seems that as long as you have header files that support 
OpenGL > 1.1 (easy to get), we should be able to provide a correct and 
complete interface to the dynamic library, regardless of version at 
build and run time.

Perhaps on PyOpenGL load-time, PyOpenGL could call 
glGetString(GL_VERSION) to figure out which names to load into its 
namespace.  Does this seem like a reasonable idea? Do any of the 
supported platforms statically link OpenGL libs?  (That sounds really 
silly, but...)

 From what I've learned about the PyOpenGL system, many of the tricky 
wrapping issues have already been taken care of, so it would "simply" be 
a matter of creating this load-time system and adding the interface code 
for the new calls.

The reason for this email is that I see a few numbers in the PyOpenGL 
source that I'm not exactly sure what they mean, and I wonder if this 
road was gone down before, or at least started. (e.g. in 
interface_util.c there are heaps of "#ifndef GL_VERSION_1_2" type 
conditionals, although this clearly points to a build-time rather than 
run time interface selection, which is non-optimal.)

>> Another workaround is that some OpenGL 1.3 drivers (nVidia) still 
>> support the multitexturing ARB extension, but others (ATI) don't.  
> 
> Hmm, strange.  They really should be providing OpenGL 1.1 drivers with 
> the extensions alongside the 1.3 drivers... sigh.  Not that it would 
> help much, as we don't have the extensions in many (most) cases.

Luckily we do have the ARB multitexturing extension, which is pretty 
darn useful!  (It is a pain that ATI doesn't seem to support it with 
their Windows OpenGL 1.3 drivers.)

>> This success with ctypes and the continued good things I hear about 
>> Pyrex make me wonder if maybe the PyOpenGL build system could be 
>> simplified by getting away from SWIG and using these two technologies?
> 
> ctypes is likely to be too slow for more than a few functions, as 
> there's a lot of manipulation required to make the Python objects OpenGL 
> compatible.  Pyrex is possible, but in the end, it's almost the same 
> problem as with the SWIG system, you wind up needing to extend Pyrex to 
> support polymorphic array parameters, to provide the bridge code for 
> various Python-ised calls, etceteras.  Code complexity doesn't go down 
> much AFAICS... that said, if someone wants to prove me wrong, I'd be 
> delighted :) .  I'd be more interested in seeing someone model the whole 
> problem in Python with a code-generator to create SWIG, Pyrex or Ctypes 
> code for any given function so that we could try them all out alongside 
> one another (and maybe add a straight C code generator to see if that 
> makes things easier...).  Oh well.

Sounds like fun for a rainy month...  But I guess there's no point 
worrying about this until someone has time to dive in and tackle it. 
Which may never happen given that they may not get a speed boost over 
the current SWIG system.  (It's good to hear you think SWIG will result 
in the fastest interface, since with OpenGL that's probably what people 
care about most.)

Cheers!
Andrew

Re: [PyOpenGL-Users] features from OpenGL > 1.1

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

Andrew Straw wrote:

> I'm trying to understand what/how/if PyOpenGL deals with multiple 
> versions of OpenGL.  For example, if I run PyOpenGL on a machine with 
> OpenGL 1.3 libraries, I should have multitexturing abilities built-in 
> (e.g. glActiveTexture() function).  This is specified in the OpenGL 
> 1.3 spec:
> http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf

PyOpenGL is currently limited to OpenGL 1.1.  At the moment, I don't 
have drivers which support features from OpenGL 1.2 or above.  There are 
a few extensions that, if I get the time, I might code up wrappers for, 
but they aren't the fun/sexy stuff for new hardware, I only have a 
Radeon 7500.

> Incidentally, on linux, I can get around the missing glActiveTexture() 
> function by using ctypes to load the function. (On Windows, I get an 
> error that the arguments must be 4 bytes longer...  I haven't tracked 
> this down, though.) 

Don't know.

> Another workaround is that some OpenGL 1.3 drivers (nVidia) still 
> support the multitexturing ARB extension, but others (ATI) don't.  

Hmm, strange.  They really should be providing OpenGL 1.1 drivers with 
the extensions alongside the 1.3 drivers... sigh.  Not that it would 
help much, as we don't have the extensions in many (most) cases.

> This success with ctypes and the continued good things I hear about 
> Pyrex make me wonder if maybe the PyOpenGL build system could be 
> simplified by getting away from SWIG and using these two technologies?

ctypes is likely to be too slow for more than a few functions, as 
there's a lot of manipulation required to make the Python objects OpenGL 
compatible.  Pyrex is possible, but in the end, it's almost the same 
problem as with the SWIG system, you wind up needing to extend Pyrex to 
support polymorphic array parameters, to provide the bridge code for 
various Python-ised calls, etceteras.  Code complexity doesn't go down 
much AFAICS... that said, if someone wants to prove me wrong, I'd be 
delighted :) .  I'd be more interested in seeing someone model the whole 
problem in Python with a code-generator to create SWIG, Pyrex or Ctypes 
code for any given function so that we could try them all out alongside 
one another (and maybe add a straight C code generator to see if that 
makes things easier...).  Oh well.

> So, what's the story?  Anyone know?

HTH,
Mike

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

Re: [PyOpenGL-Users] Killing Togl for Python 2.3 release and gett ing 2.0.1 out the door...

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

Rodgers, Kevin wrote:

>Is there any alternative to Togl for Tkinter users, or does dropping Togl
>mean I either have to drop Tkinter or drop Python 2.3?
>  
>
At the moment, you'll have to drop Tkinter (dropping Python 2.3 seems 
pointless, as it's the future).  If at some point someone were to get 
Togl building with Tk 8.4, the PyOpenGL Togl widget would be usable 
again (it's just a Python wrapper that calls through Tk to the Tk Togl 
widget).  There is at least one other Tk OpenGL widget (i.e. not Togl, a 
different OpenGL binding), but I have neither interest nor time to 
devote to wrapping it.

Honestly, in my opinion, Togl has been more pain than it's worth for a 
*long* time now, especially given that most GUI Python developers have 
long since moved away from Tk to wxPython, PyGame, PyGTK and/or PyQT.  
Tk's only strong recommendation for Python GUI development these days is 
that it's (still) bundled with the core distribution.

Togl (the underlying Tk widget) is basically dead as a project, and I'm 
not interested in becoming a deep TCL-C-API developer just to maintain 
it, so I can't see investing more time in maintaining the wrapper as a 
great investment of my rather tiny amounts of PyOpenGL time.

Good luck with whichever path you choose,
Mike

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

RE: [PyOpenGL-Users] Killing Togl for Python 2.3 release and gett ing 2.0.1 out the door...

[Rodgers, K. <kev...@ng...>]

Is there any alternative to Togl for Tkinter users, or does dropping Togl
mean I either have to drop Tkinter or drop Python 2.3?

Kevin Rodgers

-----Original Message-----
From: Mike C. Fletcher [mailto:mcf...@ro...]
Sent: Tuesday, September 23, 2003 10:43 PM
To: PyOpenGL Devel; PyOpenGL
Subject: [PyOpenGL-Users] Killing Togl for Python 2.3 release and
getting 2.0.1 out the door...


Well, I've given up on getting togl to work with Tkinter 8.4 under 
Python 2.3, so given that no-one else has stepped up to the plate on 
this one, I'm going to decree that we drop Togl support from PyOpenGL 
versions for Python 2.3 and above.  Honestly, I'd be happy to drop it 
from all PyOpenGL 2.0.1 distributions, but that seems a little too 
extreme this late in the game.

With that out of the way, we should look at releasing 2.0.1 (final) some 
time over the next month.  Here's what seems to be left to do:

    * Confirm that we've got all Mac-specific patches integrated and
      that we build on Mac OS X
    * Document file-permission problem for Unix (need to set umask
      before install)
    * Decide whether glGet bug # 691935
 
(https://sourceforge.net/tracker/index.php?func=detail&aid=691935&group_id=5
988&atid=105988)
      is real, is going to get fixed, needs to be transferred to someone
      else, or what
    * Figure out what the solaris/sun-os build issues are, and whether
      we can integrate a patch for them
    * Document problems with togl and gle's use of malloc.h for FreeBSD,
      possibly provide a patch to work around it, I assume this is
      trivial for someone on BSD to create, I just don't know what it
      requires.  I'm not planning to integrate it into 2.0.1 as it's all
      part of libraries we are, up to this point, just including unmodified.
    * Get a build environment set up for Win32 so that we can produce
      2.2.3 and 2.3 binary distributions on a computer with MSVC++
    * Test RPMs on more than just Red Hat 8.0 (where they are created)

You may imagine that since I have no Mac, FreeBSD or Solaris machines on 
which to test, some of those items will need a little feedback.  We'll 
have to see if we've got anyone still interested in doing the binary 
builds for win32.  Won't hold up the release for that, but would be nice 
to have them available on the release day if possible.

My time this month is very limited, but I'll try to get at least one 
full day to work on a PyOpenGL release, likely the weekend after this 
one.  It would be good if, before then, I had any feedback regarding 
what's outstanding, what's critical for us to move forward, what issues 
people have, etceteras.

Enjoy yourselves,
Mike

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





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] features from OpenGL > 1.1

[Andrew S. <and...@ad...>]

I'm trying to understand what/how/if PyOpenGL deals with multiple 
versions of OpenGL.  For example, if I run PyOpenGL on a machine with 
OpenGL 1.3 libraries, I should have multitexturing abilities built-in 
(e.g. glActiveTexture() function).  This is specified in the OpenGL 1.3 
spec:
http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf

Another example is that with OpenGL 1.2, the GL_CLAMP_TO_EDGE constant 
should be defined.

However, PyOpenGL doesn't provide these names in the GL module when run 
on an appropriate system.  I wonder if this is simply an oversight 
which would be easily fixed, a purposeful omission because runtime GL 
version checking and name exporting may be tricky, or has never been 
thought about.

Incidentally, on linux, I can get around the missing glActiveTexture() 
function by using ctypes to load the function. (On Windows, I get an 
error that the arguments must be 4 bytes longer...  I haven't tracked 
this down, though.) Another workaround is that some OpenGL 1.3 drivers 
(nVidia) still support the multitexturing ARB extension, but others 
(ATI) don't.  This success with ctypes and the continued good things I 
hear about Pyrex make me wonder if maybe the PyOpenGL build system 
could be simplified by getting away from SWIG and using these two 
technologies?

So, what's the story?  Anyone know?

[PyOpenGL-Users] Re: [PyOpenGL-Devel] Killing Togl for Python 2.3 release and getting 2.0.1 out the door...

[Andrew S. <and...@ad...>]

Mike,

I'm glad to see you're taking the bull by the horns...

>    * Confirm that we've got all Mac-specific patches integrated and
>      that we build on Mac OS X

The patches I've submitted have been working for Bob Ippolito and me 
since late July, and since it seems a substantial majority of OS X 
PyOpenGL users download their binaries from Bob, I reckon they're 
working OK.

>    * Get a build environment set up for Win32 so that we can produce
>      2.2.3 and 2.3 binary distributions on a computer with MSVC++

I've got access to MSVC 6.0 on Win2K, so I might be able to handle 
this.  I say "might" because I'm not an expert with Windows 
compiling/linking issues, so if anything tricky arises, I'm not sure 
what I'll be able to do.  I would probably build the SWIG interfaces on 
a different (*nix) machine (or, preferably, use those included with the 
source).

Cheers!
Andrew

[PyOpenGL-Users] Killing Togl for Python 2.3 release and getting 2.0.1 out the door...

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

Well, I've given up on getting togl to work with Tkinter 8.4 under 
Python 2.3, so given that no-one else has stepped up to the plate on 
this one, I'm going to decree that we drop Togl support from PyOpenGL 
versions for Python 2.3 and above.  Honestly, I'd be happy to drop it 
from all PyOpenGL 2.0.1 distributions, but that seems a little too 
extreme this late in the game.

With that out of the way, we should look at releasing 2.0.1 (final) some 
time over the next month.  Here's what seems to be left to do:

    * Confirm that we've got all Mac-specific patches integrated and
      that we build on Mac OS X
    * Document file-permission problem for Unix (need to set umask
      before install)
    * Decide whether glGet bug # 691935
      (https://sourceforge.net/tracker/index.php?func=detail&aid=691935&group_id=5988&atid=105988)
      is real, is going to get fixed, needs to be transferred to someone
      else, or what
    * Figure out what the solaris/sun-os build issues are, and whether
      we can integrate a patch for them
    * Document problems with togl and gle's use of malloc.h for FreeBSD,
      possibly provide a patch to work around it, I assume this is
      trivial for someone on BSD to create, I just don't know what it
      requires.  I'm not planning to integrate it into 2.0.1 as it's all
      part of libraries we are, up to this point, just including unmodified.
    * Get a build environment set up for Win32 so that we can produce
      2.2.3 and 2.3 binary distributions on a computer with MSVC++
    * Test RPMs on more than just Red Hat 8.0 (where they are created)

You may imagine that since I have no Mac, FreeBSD or Solaris machines on 
which to test, some of those items will need a little feedback.  We'll 
have to see if we've got anyone still interested in doing the binary 
builds for win32.  Won't hold up the release for that, but would be nice 
to have them available on the release day if possible.

My time this month is very limited, but I'll try to get at least one 
full day to work on a PyOpenGL release, likely the weekend after this 
one.  It would be good if, before then, I had any feedback regarding 
what's outstanding, what's critical for us to move forward, what issues 
people have, etceteras.

Enjoy yourselves,
Mike

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

[PyOpenGL-Users] OpenGL Context and Lighting

[Griffin, J. L <Jos...@us...>]

Hi,
I'm stumped. I'm trying to setup a Boa app with OpenGL Context using the
wxcontext class. I'm following the instructions in Example 5-1 in the Red
Book (Version 1.1). I would appreicate some pointers. The sphere is not
reflecting light as it should. I've eliminated surface normals as a
potential problem by calling glutSolidSphere.
 
Thanks,
Joseph
 
#Code Starts Here
 
 
#Boa:Frame:wxFrame1
 
from wxPython.wx import *
from OpenGLContext import wxcontext
from OpenGL import *
from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
from Numeric import *

def create(parent):
    return wxFrame1(parent)
 
[wxID_WXFRAME1, wxID_WXFRAME1SPLITTERWINDOW1, 
] = map(lambda _init_ctrls: wxNewId(), range(2))
 
class DrawProperties:
    """Holds Properties for OpenGL parameters"""
    def __init__(self):
        """Initialization Method"""
        
        
class DrawContext(wxcontext.wxContext):
    """OpenGL Context Class"""
    def __init__(self,parent,objProps=None):
        """Initialization Method"""
        wxcontext.wxContext.__init__(self,parent)
        self.objProps = objProps
        
    def DoInit(self):
        """Init Method"""
        glClearColor(0.0,0.0,0.0,0.0)
        mat_specular = array([1.0,1.0,1.0,1.0])
        mat_shininess = array([50.0])
        
        glShadeModel(GL_SMOOTH)
        glMaterialfv(GL_FRONT,GL_SPECULAR,mat_specular)
        glMaterialfv(GL_FRONT,GL_SHININESS,mat_shininess)
        
        light_model_ambient = array([0.2,0.2,0.2,1.0])
        glLightModelfv(GL_LIGHT_MODEL_AMBIENT,light_model_ambient)
        glLightfv(GL_LIGHT0,GL_AMBIENT,light_model_ambient)
        
        glEnable(GL_LIGHTING);
        glEnable(GL_LIGHT0);
        glEnable(GL_DEPTH_TEST);
        
    def Render( self, mode = None):
        """This method is call repeatly"""
        glTranslated (0,0,0);
        gluLookAt(2.0,2.0,2.0,0.0,0.0,0.0,0.0,1.0,0.0);
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
        #drawcube.drawCube()
        glutSolidSphere(1.0,20,16);
        glFlush()
        
    def Viewpoint(self,mode=None):
        """Overloaded Method"""
        glLoadIdentity()
        # calculate a 3D perspective view
        glFrustum(-0.5, 0.5, -0.5, 0.5, .5, 5.0);
    
    def Lights(self,mode=None):
        """pass"""
 
class wxFrame1(wxFrame):
    def _init_ctrls(self, prnt):
        # generated method, don't edit
        wxFrame.__init__(self, id=wxID_WXFRAME1, name='', parent=prnt,
              pos=wxPoint(444, 241), size=wxSize(502, 411),
              style=wxDEFAULT_FRAME_STYLE, title='wxFrame1')
        self.SetClientSize(wxSize(494, 376))
 
        self.splitterWindow1 =
wxSplitterWindow(id=wxID_WXFRAME1SPLITTERWINDOW1,
              name='splitterWindow1', parent=self, point=wxPoint(296, 144),
              size=wxSize(376, 280), style=wxSP_3D)
 
    def init_context(self):
        """Context Initialization Code """
        self.objProps = DrawProperties()
        self.p1 = wxWindow(self.splitterWindow1, -1)
        self.DrawContext =
DrawContext(self.splitterWindow1,objProps=self.objProps)
 
        self.splitterWindow1.SetMinimumPaneSize(0)
        self.splitterWindow1.SplitVertically(self.p1, self.DrawContext, 100)
 
    def init_SetProps(self):
        """Initilize OpenGL Props"""
 
    def __init__(self, parent):
        self._init_ctrls(parent)
        self.init_context()
        self.init_SetProps()
        
    def OnSlider1Scroll(self, event):
        #self.staticText2.SetLabel(str(self.slider1.GetValue()))
        event.Skip()
 
class BoaApp(wxApp):
    def OnInit(self):
        wxInitAllImageHandlers()
        self.main = create(None)
        # needed when running from Boa under Windows 9X
        self.SetTopWindow(self.main)
        self.main.Show();self.main.Hide();self.main.Show()
        return True
 
def main():
    application = BoaApp(0)
    application.MainLoop()
 
if __name__ == '__main__':
    main()

#Code Ends Here

Re: [PyOpenGL-Users] any font fns on the horizon? (in Linux)

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

Maciej Kalisiak wrote:

>Is there any work being done on getting some font functionality into
>PyOpenGL?  I'm mostly interested in fonts for just plain OpenGL (i.e.,
>not GLUT, not GLContext... don't want to port my code, if I can help
>it).  
>
Realistically, no. 

I'm barely managing to find time to work on PyOpenGL once every couple 
of months with my new job, and then only for a few hours to try and 
integrate patches and/or work on fixing particular errors. 

Keep in mind that the code inside GLContext is available to rip out and 
use even if you don't want to use the rest of it.  I tried to keep the 
code that actually does the rendering separate from the OpenGLContext 
scenegraph code.  It provides polygonal (via TTFQuery/FontTools), 
anti-aliased bitmap (PyGame) and aliased bitmap (wxPython) font types.  
It does not, however, do anything with hinting.

>If so, what type will they be? Lines?  Polygonal? Texture-based?
>  
>
Again, nothing is planned for the core system (by me, anyway).  
OpenGLContext has code samples for doing all of those IIRC.

>For the time being, until something official (and solid) comes out in
>PyOpenGL, I've hacked myself a SWIG wrapper for a set of C functions
>that do texture fonts, the ones described here:
>  http://www.opengl.org/developers/code/mjktips/TexFont/TexFont.html
>
>If anyone is interested, I can make it available.  Drop me a line and
>I'll try to clean it up before putting it up online.  Be warned though,
>it is just a quick SWIG wrap (and I just "learned" SWIG), *and* even the
>original is not the cleanest, most robust C code either.  A bit of
>tweaking will likely be necessary.
>  
>
If you want, put a feature request on the site for linking to this 
module and I'll try to get to it when I find some time.  Should really 
have links to all of the approaches we have available I suppose. Sigh.

Enjoy yourselves,
Mike

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

Re: [PyOpenGL-Users] Re: Re: any font fns on the horizon? (in Linux)

[<mi...@na...>]

On Sun, Sep 21, 2003 at 01:43:58PM -0400, Maciej Kalisiak wrote:
> On Sun, Sep 21, 2003 at 03:09:46AM -0400, mi...@na... wrote:
> > On Sun, Sep 21, 2003 at 12:06:54AM -0400, Maciej Kalisiak wrote:
> > > I would encourage you strongly to refactor this a bit, to make it a
> > > separate, stand-alone package, since it seems terribly useful and quite
> > > robust.  It seems like little work.  Not only separate it from BZEngine,
> > > but hopefully from pygame as well, to give it the largest application
> > 
> > Patches welcome :)
> 
> Heh.  I won't have the time to do a complete, nicely polished package,
> but perhaps the stuff I do for my own project might be of use to whoever
> decides to go all the way.  Is GLText.py code fairly stable now, or
> does it still change quite a bit.

It still needs better Unicode support (for example, searching for missing
glyphs in other fonts) but aside from that and some polishing I think it's
pretty much done.

> 
> > Hinting is the process of tweaking a font's rendering a bit so stems of
> 
> Ah, thanks.  What is "escapement" then?  Is it just the width of a
> glyph?

Oop, forgot that one. Escapement is a vector added to the 'pen' location
when the glyph is drawn. Usually the x component is the 'width' and the y
is zero. It's important to make a distinction between the escapement and
the glyph width though, since there may be extra space between characters
or there might be overlap. Then this leads into kerning...

I'm no font guru, I've just used freetype a good bit and have read their
documentation ;)

> 
> > > I'm not too familiar with fonts in pygame, but my understanding is that
> > > it only handles truetype fonts at the moment.  Do you know if adding
> > > support for general X11 fonts is in the plans, or even how hard a task
> > > that is?  (Murphy's Law says that soon enough I'll find that I must have
> > > a given font, and it won't be .ttf... :)
> > 
> > Well, GLText uses pygame's font capabilities, which is just a python binding
> > for SDL_ttf. SDL_ttf is a simple wrapper for freetype, so it will handle any
> > font format freetype can. This includes truetype, Postscript Type1, .pcf,
> > windows fonts, and probably more.
> 
> Oh.  So I just have to pass it the full path to a .pcf file?  Just tried
> it; cool!  Although when I tried it with helvetica, it seems it lacks
> metrics on ascenders because all the letters don't line up on the
> baseline, but are flushed to the top of the bounding box.  Does this
> sounds like a GLText.py bug or something upstream in SDL_ttf?

I'd guess something in SDL_ttf. I've dealt with bitmapped fonts in .pcf files
before in a freetype-based font engine I wrote a while ago. Freetype handled
them fine. SDL_ttf hides all the metrics from GLText.

> 
> > The downside of using SDL_ttf is that it hides most of the glyph metrics stored
> > in the original font. The glyphs GLText stores will be padded to the font's
> > line height rather than stored in tightly fitting bounding boxes.
> 
> Hmm, basically sounds like helvetica is NOT padded.  I also tried "modd"
> font (character cell), and those were lined up.  I guess the problem
> is only with proportional fonts (Utopia had the problem as well).  I
> suppose it's not a big deal though.. these bitmapped fonts don't look
> nearly as nice as the scalable ones.

SDL_ttf probably wasn't written with bitmapped fonts in mind. When such high
quality free truetype fonts exist, there's no reason to use X's fonts. Bitstream
Vera looks beautiful and is OSS-friendly. Before Vera was released, I had been
using some fairly nice fonts from the OpenOffice and Ghostscript projects.

--Micah

> 
> -- 
> "In a time of universal deceit, telling the truth is a revolutionary act."
> 	-- George Orwell
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] Re: Re: any font fns on the horizon? (in Linux)

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

On Sun, Sep 21, 2003 at 03:09:46AM -0400, mi...@na... wrote:
> On Sun, Sep 21, 2003 at 12:06:54AM -0400, Maciej Kalisiak wrote:
> > I would encourage you strongly to refactor this a bit, to make it a
> > separate, stand-alone package, since it seems terribly useful and quite
> > robust.  It seems like little work.  Not only separate it from BZEngine,
> > but hopefully from pygame as well, to give it the largest application
> 
> Patches welcome :)

Heh.  I won't have the time to do a complete, nicely polished package,
but perhaps the stuff I do for my own project might be of use to whoever
decides to go all the way.  Is GLText.py code fairly stable now, or
does it still change quite a bit.

> Hinting is the process of tweaking a font's rendering a bit so stems of

Ah, thanks.  What is "escapement" then?  Is it just the width of a
glyph?

> > I'm not too familiar with fonts in pygame, but my understanding is that
> > it only handles truetype fonts at the moment.  Do you know if adding
> > support for general X11 fonts is in the plans, or even how hard a task
> > that is?  (Murphy's Law says that soon enough I'll find that I must have
> > a given font, and it won't be .ttf... :)
> 
> Well, GLText uses pygame's font capabilities, which is just a python binding
> for SDL_ttf. SDL_ttf is a simple wrapper for freetype, so it will handle any
> font format freetype can. This includes truetype, Postscript Type1, .pcf,
> windows fonts, and probably more.

Oh.  So I just have to pass it the full path to a .pcf file?  Just tried
it; cool!  Although when I tried it with helvetica, it seems it lacks
metrics on ascenders because all the letters don't line up on the
baseline, but are flushed to the top of the bounding box.  Does this
sounds like a GLText.py bug or something upstream in SDL_ttf?

> The downside of using SDL_ttf is that it hides most of the glyph metrics stored
> in the original font. The glyphs GLText stores will be padded to the font's
> line height rather than stored in tightly fitting bounding boxes.

Hmm, basically sounds like helvetica is NOT padded.  I also tried "modd"
font (character cell), and those were lined up.  I guess the problem
is only with proportional fonts (Utopia had the problem as well).  I
suppose it's not a big deal though.. these bitmapped fonts don't look
nearly as nice as the scalable ones.

-- 
"In a time of universal deceit, telling the truth is a revolutionary act."
	-- George Orwell

Re: [PyOpenGL-Users] Re: any font fns on the horizon? (in Linux)

[<mi...@na...>]

On Sun, Sep 21, 2003 at 12:06:54AM -0400, Maciej Kalisiak wrote:
> On Sat, Sep 20, 2003 at 09:08:18PM -0400, mi...@na... wrote:
> > I wrote a relatively simple but effective "GLText" module for pybzengine.
> > It's texture based, generally produces nicely hinted output, and has some
> > Unicode support.
> > 
> > No documentation, but there is LGPL'ed source at 
> > http://navi.picogui.org/svn/misc/trunk/pybzengine/BZEngine/UI/GLText.py
> 
> Wow, very nice!  I just took it for a spin.  A bit of tweaking to disentangle
> it from rest of BZEngine, but works like a charm now.  I like that this
> approach uses multiple textures per font; texfont was limited to a
> single texture per font.

Spiffy.

> 
> I would encourage you strongly to refactor this a bit, to make it a
> separate, stand-alone package, since it seems terribly useful and quite
> robust.  It seems like little work.  Not only separate it from BZEngine,
> but hopefully from pygame as well, to give it the largest application

Patches welcome :)

I'll probably get to this eventually, but currently I'm still at the stage
of separating pybzengine from pybzflag so I can use it in another project
easily.

> area.  I think pygame could be used to generate the fonts as a
> standalone utility, just like in genfont in "texfonts", which could then
> be pickled for use in apps which don't want to import pygame (e.g., in
> my stuff I'm trying to limit the number of packages it relies on...).

That would be a nice feature. With pybzengine this might already be possible,
since it's Texture class is pickle-friendly. Would take some more work to make
this work if GLText was standalone. For my own purposes I'd rather just keep
this as-is, since the relevant parts of pybzengine are small and fairly
general-purpose.

> 
> I'm not super familiar with fonts.  Could you elaborate a tiny bit on
> some of the terms you use in the head comment in GLText.py?  I'm
> wondering about the full meaning of "proper hinting" and "escapement".

Hinting is the process of tweaking a font's rendering a bit so stems of
letters, for example, line up better on a pixel grid. Without hinting, fonts
generally look a bit blurry and are hard to read at normal-looking sizes.
GLText can keep fonts rendered at multiple sizes so commonly used sizes can
be rendered with a one to one correspondance between pixels and texels. These
common sizes can therefore be rendered with correct hinting rather than looking
a little blurry due to relying on OpenGL's trilinear filtering.

In the applications I've used this technique for, it has worked nicely. Small
fonts are used at the same size they were rendered at, giving high quality
output. Large fonts are scaled using trilinear filtering, but lack of hinting
isn't noticeable.

> 
> I'm not too familiar with fonts in pygame, but my understanding is that
> it only handles truetype fonts at the moment.  Do you know if adding
> support for general X11 fonts is in the plans, or even how hard a task
> that is?  (Murphy's Law says that soon enough I'll find that I must have
> a given font, and it won't be .ttf... :)

Well, GLText uses pygame's font capabilities, which is just a python binding
for SDL_ttf. SDL_ttf is a simple wrapper for freetype, so it will handle any
font format freetype can. This includes truetype, Postscript Type1, .pcf,
windows fonts, and probably more.

The downside of using SDL_ttf is that it hides most of the glyph metrics stored
in the original font. The glyphs GLText stores will be padded to the font's
line height rather than stored in tightly fitting bounding boxes. This wastes
a little VRAM, but prevents requiring real freetype bindings.

--Micah

> 
> -- 
> "If you sit down at a poker game and don't see a sucker, get up.  You're
>  the sucker."
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users