pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] No OpenGL hardware accelleration on Win2k box - am I missing something?

[Benjamin D. <be...@fi...>]

Hello,

I'm currently experimenting with python, pygame and pyopengl on two 
computers (I just love portable programming !-):

1) One Linux box, Debian unstable, 700 MHz Duron, nVidia GeForce 2 MX, 
256 MB Ram, and
2) One Win2k box, 2.0 GHz Pentium 4, nVidia Geforce 4, 512 MB Ram

The thing is, all my test programs, and all NeHe demos, run about 8-10 
times SLOWER on the Win2k box than on the Linux box in terms of fps! 
This applies to several versions of the NeHe Demos, and happens even 
when I chose HWSURFACE and FULLSCREEN (for pygame.display.set_mode).

I'm assuming I missed a step somewhere that enables hardware 
acceleration under Win2k? I haven't been able to find any mention of 
this in the documentation, or in Google. If it's not a well-known and/or 
newbie issue, I'll be happy to provide any additional information.

By the way, under Win2k I'm using python 2.2.3, PyOpenGL 2.0.0.44, and 
pygame 1.5.5, though I assume it's not a pygame issue, since the 
PyOpenGL/GLUT NeHe Demos show the same behaviour without pygame.

Thanks for your time,

-- 
:__:     Benjamin Deutsch
(OO)     be...@fi...
(__)
=""=========================

[PyOpenGL-Users] python 2.3 on Windows

[Alexandre P. <aub...@ho...>]

Hi,

Did someone try pyopengl with python2.3c2 on Windows ? I get an access 
violation when installing (loading ?) Togl.

I don't get the access violation when doing a debug build (python setup.py 
build -g).

I use SWIG Version 1.3.19 (Cygwin), Python 2.3c2 (python.org)

Thanks,
alex.

copying build\lib.win32-2.3\OpenGL\WGL\EXT\extensions_string.pyd -> 
C:\Python23\
Lib\site-packages\OpenGL\WGL\EXT
copying build\lib.win32-2.3\OpenGL\WGL\EXT\swap_control.pyd -> 
C:\Python23\Lib\s
ite-packages\OpenGL\WGL\EXT
copying build\lib.win32-2.3\OpenGL\WGL\ARB\buffer_region.pyd -> 
C:\Python23\Lib\
site-packages\OpenGL\WGL\ARB
copying build\lib.win32-2.3\OpenGL\WGL\ARB\extensions_string.pyd -> 
C:\Python23\
Lib\site-packages\OpenGL\WGL\ARB
copying build\lib.win32-2.3\OpenGL\WGL\__init___.pyd -> 
C:\Python23\Lib\site-pac
kages\OpenGL\WGL
copying build\lib.win32-2.3\OpenGL\GLE.pyd -> 
C:\Python23\Lib\site-packages\Open
GL
copying build\lib.win32-2.3\OpenGL\GLUT.pyd -> 
C:\Python23\Lib\site-packages\Ope
nGL
running install_data
warning: no previously-included files matching 'Cvs\*' found anywhere in 
distrib
ution
warning: no previously-included files matching 'CVS\*' found anywhere in 
distrib
ution
copying build\Togl-1.6-tk8.4\Togl.dll -> 
C:\Python23\Lib\site-packages\OpenGL\Tk
\win32-tk8.4

<access violation>

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[PyOpenGL-Users] New pycal3d.

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

Hey,

new pycal3d out. 

Details here: http://py3d.org/pycal3d/

[PyOpenGL-Users] nehe lesson 19

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

Here's the python version of lesson 19 nehe tute. 
http://www.py3d.org/files/lesson19.zip It's particles. Looks really 
nice. Also this version runs faster than their one in c(on my computer 
anyway). Thanks to the magic of psyco. Please make some additions to it, 
and email me with them if you want: rene AT py3d dot org

It's a fun one to play around with :)


You need python, pygame, pyopengl and psyco for it to run nicely.

[PyOpenGL-Users] glInterleavedArrays memory leak

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

Hi Everybody,

I believe I found a memory leak in PyOpenGL's wrapper for
glInterleavedArrays. The following is the simplest test case I could
come up with:

------8<------
import pygame, time
from pygame.locals import *
from OpenGL.GL import *
pygame.init()
pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF)
while 1:
    glInterleavedArrays(GL_T2F_N3F_V3F, 0, " " * 10000)
    time.sleep(0.01)
------>8------
	
In 'top' this should show the python process' memory usage steadily
rising. This is from a Gentoo Linux system on an Athlon XP.
I have tested it with PyOpenGL 2.0.0.42 and 2.0.1.04, both show the bug.

As much as I'm interested in helping squash this bug, I'm also
interested in finding a workaround so my users (when they exist :) won't
absolutely have to have the latest PyOpenGL code.

I have tried using glVertexPointer and friends, however
glTexCoordPointerf() would always cause an "OpenGL.GL.GLerror: [Errno
1281] invalid value" exception.

I'd like to thank the PyOpenGL developers for bringing such a neat
interface to life. I have been using it for a 3D frontend to PyBZFlag
with amazing results. Most people think Python is too slow for games,
then they see what can be accomplished with outstanding modules like
PyOpenGL and Numeric :)

In case you're curious, I have a few screenshots of what we've done so
far: (Yep, there's a realtime cloth simulation in there too)
   http://navi.picogui.org/images/bzflag/
The code is in BZFlag's CVS repository.

--Micah

-- 
Only you can prevent creeping featurism!

Re: [PyOpenGL-Users] Using both PyOpenGL and C to drive OpenGL

[Lorcan H. <lh-...@lo...>]

Mike,

Thanks for that quick response!  You've certainly given me plenty
to think about... :)

I'm not sure if I'll go ahead with this or not, but I'll certainly
look into it further - maybe writing a simple test program or
two, to test the ideas.  Any progress, or problems I get stuck on,
will be reported back here to the list. 

Thanks again,

Lorcan

Mike C. Fletcher wrote:
> Lorcan Hamill wrote:
> 
>> Hi folks,
>>
>> (Just discovered this list, so sorry if this is an FAQ - there
>> doesn't seem to be a list archive, or I'd have searched it.)
>>
>> I'm working on a new fork of TuxRacer (based on the last
>> GPL'd release, at http://tuxracer.sourceforge.net/), and
>> I'm think of replacing the UI code with Python, using PyOpenGL.
>> The main game engine, which is written in C, would remain
>> intact, as far as possible.  Could that be done?  How? :) 
> 
> 
> Every PyOpenGL function is written in C, there is nothing at all to stop 
> you from integrating with a C system.  You need to work out which system 
> has the responsibility of setting up the context, which one is going to 
> handle input/output etc., but there should be no problem with rendering 
> as long as you use the same OpenGL context for both sides of the system.
> 
>>  A top-level Python script initialises OpenGL, loads
>>  the textures using pygame.image, draws the splash screen,
>>  menus, etc. using PyOpenGL, handling input with pygame. 
> 
> 
> Careful with your mental model here, as a general rule, menus are going 
> to be redrawn at least as often as the main screen, they're going to 
> acquire a callback from the engine to do the actual drawing on the 
> rendering context.
> 
>>  The script creates an instance of a new GameEngine class
>>  that I would implement in C, and invokes methods on that
>>  object to set up the course. 
> 
> 
> No problem, standard python extending model.
> 
>>  When the game is ready to go, the Python script would
>>  invoke GameEngineObject.run().  At that point, the C
>>  code in the extension module would take over - using
>>  the OpenGL API to refresh the screen, and SDL for
>>  keyboard and/or joystick input. 
> 
> 
> I'm not an SDL/PyGame expert, but I think this is where you will run 
> into trouble.  You will need to be sure that the registered functions 
> are actually getting the events from the input.  Most likely the 
> GameEngineObject isn't implementing a single-step run, but instead 
> implements a mainloop in which large numbers of events are processed.  
> You'll likely need to have registered callbacks which defer to the 
> python code to make this work.
> 
>> Is that approach feasible?  Can both PyOpenGL and
>> a custom C extension module share the use of OpenGL
>> like that?  
> 
> 
> No problems should arise.  As long as both are using the same OpenGL 
> context.
> 
>> They'd take turns, obviously, so that
>> the Python script would not invoke any OpenGL functions
>> until after GameEngineObject.run() had returned. 
> 
> 
> Not a big problem, really.  It's quite possible to have PyOpenGL 
> plug-ins to rendering engines which render just as if they were written 
> in C, after all, in the end they are.  PyOpenGL really is just calling 
> regular OpenGL functions.  You might need to watch out for the global 
> interpreter lock, but unless you are doing a lot of threading, it's 
> probably a pretty low issue on the tree of potential problems.
> 
>> The screen would be repainted completely (and the OpenGL
>> context could be reset) between the two different modes
>> of operation, but it shouldn't change resoltion, or flicker,
>> or anything like that. 
> 
> 
> You might want to look into overlays, rather than distinct contexts.  
> There's no real reason to repaint the whole window before running the 
> PyOpenGL code.  OpenGL contexts are just OpenGL contexts as far as 
> PyOpenGL is concerned.  It doesn't care where it renders, and will quite 
> happily interact with your C code.
> 
>> Has anyone done anything like this?  A working example
>> would be *really* useful... 
> 
> 
> I don't have any samples of C extensions in hand, other than PyOpenGL 
> itself.  By the way, one significant issue you may run into (I would 
> expect it, though you haven't mentioned it) would be that you'll want to 
> in some way wrap the internal structures of the game so that they can be 
> manipulated by the python code.  There is very little which is 
> PyOpenGL-specific, about this, just another exercise in extending 
> python.  Depending on how much of the system you want to expose, you may 
> want to pick up SWIG to automate the process.
> 
>> I'd also have the problem of making the C extension and
>> pygame take turns in handling input events, but I guess
>> that's off-topic for this list. :)
> 
> 
> Probably, but the PyGame folks are fairly friendly :) .
> 
> Have fun,
> Mike
> 
> _______________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://members.rogers.com/mcfletch/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 
> 

Re: [PyOpenGL-Users] Fade to black?

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

Rene Dudfield wrote:

> Hello.
>
> I was wondering if anyone had an idea on how to do fade to black?
>
> I was thinking of overlaying a texture over the scene and slowly 
> changing the alpha this texture has. 

This should work on anything from a TNT2 onward, though you don't 
actually need it to be a texture unless you are interested in having the 
fade be textured (e.g. having the game logo fade in on a 
black/white/whatever background).  A simple polygon with the required 
color and alpha should work.

> But would that work ok on slower hardware?  If it is slow any other 
> ways to do fade to black(or from black, or to/from white etc)? 

I would strongly suggest just implementing it first and seeing if it 
really is slow, I wouldn't expect it to be too slow if your game is 
running reasonably well before the fade starts, yes there will be a lot 
of overdraw, but you can disable depth buffer updates, so only 
one/(three) buffers are getting changed.  Possible optimization strategies:

    * use overlays where available
          o i.e. render your transparency as an overlay rather than part
            of your main scene
          o if not, do a screen-capture to a bitmap and just blit the
            bitmap, then the fading polygon each time you want to
            increase the fading level, you may find that using the
            captured bitmap as a texture works considerably faster
    * use screendoor transparency
          o only likely to be useful on very old hardware, (e.g. TNT or
            previous)
    * use solid-color polygon instead of textured (likely only an issue
      if the texture is very large)
    * do a screen capture, turn it to a texture  and blend it *on top
      of* a solid-color background of the target color (i.e. glClear)
      each frame with altered alpha level, opaque at start, transparent
      to end (saves extra geometry/overdraw).

Have fun,
Mike

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

Re: [PyOpenGL-Users] Using both PyOpenGL and C to drive OpenGL

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

Lorcan Hamill wrote:

> Hi folks,
>
> (Just discovered this list, so sorry if this is an FAQ - there
> doesn't seem to be a list archive, or I'd have searched it.)
>
> I'm working on a new fork of TuxRacer (based on the last
> GPL'd release, at http://tuxracer.sourceforge.net/), and
> I'm think of replacing the UI code with Python, using PyOpenGL.
> The main game engine, which is written in C, would remain
> intact, as far as possible.  Could that be done?  How? :) 

Every PyOpenGL function is written in C, there is nothing at all to stop 
you from integrating with a C system.  You need to work out which system 
has the responsibility of setting up the context, which one is going to 
handle input/output etc., but there should be no problem with rendering 
as long as you use the same OpenGL context for both sides of the system.

>  A top-level Python script initialises OpenGL, loads
>  the textures using pygame.image, draws the splash screen,
>  menus, etc. using PyOpenGL, handling input with pygame. 

Careful with your mental model here, as a general rule, menus are going 
to be redrawn at least as often as the main screen, they're going to 
acquire a callback from the engine to do the actual drawing on the 
rendering context.

>  The script creates an instance of a new GameEngine class
>  that I would implement in C, and invokes methods on that
>  object to set up the course. 

No problem, standard python extending model.

>  When the game is ready to go, the Python script would
>  invoke GameEngineObject.run().  At that point, the C
>  code in the extension module would take over - using
>  the OpenGL API to refresh the screen, and SDL for
>  keyboard and/or joystick input. 

I'm not an SDL/PyGame expert, but I think this is where you will run 
into trouble.  You will need to be sure that the registered functions 
are actually getting the events from the input.  Most likely the 
GameEngineObject isn't implementing a single-step run, but instead 
implements a mainloop in which large numbers of events are processed.  
You'll likely need to have registered callbacks which defer to the 
python code to make this work.

> Is that approach feasible?  Can both PyOpenGL and
> a custom C extension module share the use of OpenGL
> like that?  

No problems should arise.  As long as both are using the same OpenGL 
context.

> They'd take turns, obviously, so that
> the Python script would not invoke any OpenGL functions
> until after GameEngineObject.run() had returned. 

Not a big problem, really.  It's quite possible to have PyOpenGL 
plug-ins to rendering engines which render just as if they were written 
in C, after all, in the end they are.  PyOpenGL really is just calling 
regular OpenGL functions.  You might need to watch out for the global 
interpreter lock, but unless you are doing a lot of threading, it's 
probably a pretty low issue on the tree of potential problems.

> The screen would be repainted completely (and the OpenGL
> context could be reset) between the two different modes
> of operation, but it shouldn't change resoltion, or flicker,
> or anything like that. 

You might want to look into overlays, rather than distinct contexts.  
There's no real reason to repaint the whole window before running the 
PyOpenGL code.  OpenGL contexts are just OpenGL contexts as far as 
PyOpenGL is concerned.  It doesn't care where it renders, and will quite 
happily interact with your C code.

> Has anyone done anything like this?  A working example
> would be *really* useful... 

I don't have any samples of C extensions in hand, other than PyOpenGL 
itself.  By the way, one significant issue you may run into (I would 
expect it, though you haven't mentioned it) would be that you'll want to 
in some way wrap the internal structures of the game so that they can be 
manipulated by the python code.  There is very little which is 
PyOpenGL-specific, about this, just another exercise in extending 
python.  Depending on how much of the system you want to expose, you may 
want to pick up SWIG to automate the process.

> I'd also have the problem of making the C extension and
> pygame take turns in handling input events, but I guess
> that's off-topic for this list. :)

Probably, but the PyGame folks are fairly friendly :) .

Have fun,
Mike

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

[PyOpenGL-Users] Using both PyOpenGL and C to drive OpenGL

[Lorcan H. <lh-...@lo...>]

Hi folks,

(Just discovered this list, so sorry if this is an FAQ - there
doesn't seem to be a list archive, or I'd have searched it.)

I'm working on a new fork of TuxRacer (based on the last
GPL'd release, at http://tuxracer.sourceforge.net/), and
I'm think of replacing the UI code with Python, using PyOpenGL.
The main game engine, which is written in C, would remain
intact, as far as possible.  Could that be done?  How? :)

I'm thinking along these lines:

  A top-level Python script initialises OpenGL, loads
  the textures using pygame.image, draws the splash screen,
  menus, etc. using PyOpenGL, handling input with pygame.

  The script creates an instance of a new GameEngine class
  that I would implement in C, and invokes methods on that
  object to set up the course.

  When the game is ready to go, the Python script would
  invoke GameEngineObject.run().  At that point, the C
  code in the extension module would take over - using
  the OpenGL API to refresh the screen, and SDL for
  keyboard and/or joystick input.

Is that approach feasible?  Can both PyOpenGL and
a custom C extension module share the use of OpenGL
like that?  They'd take turns, obviously, so that
the Python script would not invoke any OpenGL functions
until after GameEngineObject.run() had returned.
The screen would be repainted completely (and the OpenGL
context could be reset) between the two different modes
of operation, but it shouldn't change resoltion, or flicker,
or anything like that.

Has anyone done anything like this?  A working example
would be *really* useful...

I'd also have the problem of making the C extension and
pygame take turns in handling input events, but I guess
that's off-topic for this list. :)

Thanks in advance, for any helpful replies.  And thanks
for PyOpenGL!

Lorcan Hamill

[PyOpenGL-Users] Fade to black?

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

Hello.

I was wondering if anyone had an idea on how to do fade to black?

I was thinking of overlaying a texture over the scene and slowly 
changing the alpha this texture has.

But would that work ok on slower hardware?  If it is slow any other ways 
to do fade to black(or from black, or to/from white etc)?

Re: [PyOpenGL-Users] best/good method for namespace pollution avoidance?

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

Maciej Kalisiak wrote:

>Hello all,
>
>For the longest time I've been using the following method to import
>OpenGL functions and constants:
>
>    from OpenGL.GL import *
>
>After starting to use pydoc to make documentation of my code, I came to
>realize how badly this pollutes the namespace (and makes huge HTML
>files).  I'm also recently concerned that this is seriously slowing down
>my app's startup time on old HW.
>
To avoid this, see the OpenGLContext package's subclass of pydoc which 
allow for filtering out names imported from other modules.

>In view of this I looked at alternatives.  Thought of two.  Either
>  
>
...

>I'm unhappy with both methods.  Method 1 makes for long import lines,
>and you end up invariably running into unimported names as they get used
>in the code.  The second method is also error-prone, as it is quite easy
>to forget the prefix each time you add a block of OpenGL code.
>
I can't see doing either in regular rendering code, really.  I've used 
both in situations where there's only a few functions, but it's really 
awkward.  The wxPython peoples have recently gone through the process of 
renaming everything from:

    wxBlah to wx.Blah

but that would make PyOpenGL code require rewriting C code for 
*everything*, while today you can often just copy the code directly and 
have it run.  Not a real option in my books.  (At one time IIRC we did 
have that naming and just gave up on it as too awkward).

>Surely this is an old problem, and someone on the list can deliver me
>from my misery by showing me the "one, true, perfect" method, no?  :)
>
Perfect solutions are few and far between, but searching for them is 
still a noble goal.  Good luck,
Mike

PS: PyGTA meets on the 4th Tuesday of the month ;)

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

Re: [PyOpenGL-Users] best/good method for namespace pollution avoidance?

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

Maciej Kalisiak wrote:

>Hello all,
>
>For the longest time I've been using the following method to import
>OpenGL functions and constants:
>
>    from OpenGL.GL import *
>
>After starting to use pydoc to make documentation of my code, I came to
>realize how badly this pollutes the namespace (and makes huge HTML
>files).  I'm also recently concerned that this is seriously slowing down
>my app's startup time on old HW.
>
>In view of this I looked at alternatives.  Thought of two.  Either
>
>    from OpenGL.GL import glBegin, glVertex3f, glEnd, GL_LINES
>    # ... and whatever else is used in module
>
>or
>
>    import OpenGL.GL as GL
>
>    GL.glBegin(GL.GL_LINES)
>    GL.glVertex3f(0,0,0)
>    GL.glVertex3f(1,1,1)
>    GL.glEnd()
>
>I'm unhappy with both methods.  Method 1 makes for long import lines,
>and you end up invariably running into unimported names as they get used
>in the code.  The second method is also error-prone, as it is quite easy
>to forget the prefix each time you add a block of OpenGL code.
>
>Surely this is an old problem, and someone on the list can deliver me
>from my misery by showing me the "one, true, perfect" method, no?  :)
>
>  
>
Hey,


A more environmentally friendly way is to make a module where you import 
the functions you use most often.

So you could do:
from my_gl_funcs import *


If that polutes, maybe get a muffler.

[PyOpenGL-Users] best/good method for namespace pollution avoidance?

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

Hello all,

For the longest time I've been using the following method to import
OpenGL functions and constants:

    from OpenGL.GL import *

After starting to use pydoc to make documentation of my code, I came to
realize how badly this pollutes the namespace (and makes huge HTML
files).  I'm also recently concerned that this is seriously slowing down
my app's startup time on old HW.

In view of this I looked at alternatives.  Thought of two.  Either

    from OpenGL.GL import glBegin, glVertex3f, glEnd, GL_LINES
    # ... and whatever else is used in module

or

    import OpenGL.GL as GL

    GL.glBegin(GL.GL_LINES)
    GL.glVertex3f(0,0,0)
    GL.glVertex3f(1,1,1)
    GL.glEnd()

I'm unhappy with both methods.  Method 1 makes for long import lines,
and you end up invariably running into unimported names as they get used
in the code.  The second method is also error-prone, as it is quite easy
to forget the prefix each time you add a block of OpenGL code.

Surely this is an old problem, and someone on the list can deliver me
from my misery by showing me the "one, true, perfect" method, no?  :)

-- 
Maciej Kalisiak|mac@] "It's a shallow life that doesn't give a person a few
dgp.toronto.edu|www.]  scars." -- Garrison Keillor
dgp.toronto.edu/~mac]  

[PyOpenGL-Users] OpenGLContext 2.0.0b1 now available...

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

I have just released the first beta version of OpenGLContext 2.0.0 for 
PyOpenGL 2.0.1. 

OpenGLContext is a teaching/testing tool for those looking to learn 
OpenGL programming using Python and PyOpenGL.  It provides a large body 
of BSD-licensed PyOpenGL sample code for the beginning OpenGL 
programmer, and a simplified environment for experimenting with OpenGL 
programming.

Major new features since alpha 4 include:

    * cross platform polygonal text from (system) TrueType fonts,
          o (with the TTFQuery and FontTools packages)
          o applications can use non-system fonts with minimal extra effort
          o antialiased bitmap text also available from Pygame (with
            TTFQuery and Fonttools)
          o wxPython and/or GLUT can provide basic aliased bitmap text
            when ttfquery and/or FontTools are not available
    * frustum culling and bounding box calculations,
          o occlusion-culling is also available when the extension is
            available, but isn't currently supported by any of the
            scenegraph geometry types, so is not particularly effective,
            and is disabled by default,
    * optimization of the rendering pipeline,
          o includes introduction of C modules to accelerate "hotspot"
            operations
    * GLE-based extrusion geometry types,
          o screw, lathe and spiral
    * enhanced polygon tessellation code,
    * and a considerable number of bug fixes.

The new release has three new requirements beyond those for alpha 4:

    * Python 2.2.3
          o weak reference errors in 2.2.2 were found because of
            OpenGLContext's rather intense usage of them
          o OpenGLContext tries to minimize the effect of the errors,
            but there is no way to completely eliminate them without
            upgrading
    * FontTools
          o a cross platform library to read TrueType font files directly
    * TTFQuery
          o a Python package using FontTools to query and match system
            TrueType font names and families
          o also provides outline extraction for polygonal text

You can find updated installation instructions here:
    http://pyopengl.sourceforge.net/documentation/installation.html

There are a number of areas where the API is likely to change during the 
upcoming beta process, particularly there will likely be a new 
configuration mechanism for user-specified preferences (for instance key 
bindings, frame locations, rendering-context-parameters and preferred 
GUI library).  Beyond this, I'm not planning any significant (i.e. core) 
enhancements, though adding a small 2D controls library may be necessary 
to allow the (planned) configuration system to work properly, and there 
will likely be a considerable number of bug-fixes and optimizations.

As always, you can find the download from the homepage:

    http://pyopengl.sourceforge.net/context/

or directly here:

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

Enjoy,
Mike

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

[PyOpenGL-Users] [ pyopengl-Feature Requests-452946 ] Font modules

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

Feature Requests item #452946, was opened at 2001-08-19 11:00
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=452946&group_id=5988

Category: new module
>Group: OpenGLContext v2.0
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Tarn Weisner Burton (twburton)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: Font modules

Initial Comment:
Create font modules.  Targets: bitmap + outline.  It 
would be nice if out lines could be sent to GLE

methods:

1) wrap GLTT (see http://gltt.sf.net) -> under GPL!  
Also doesn't interface with GLE
2) Use PyFT to create own variant of GLTT.  Problem 
with this is that PyFT is under GPL, even though 
Freetype can be used with either BSD/GPL.  Also PyFT 
is Freetype1 not Freetype2.
3) Wrap Freetype2 and write own python code.
4) write own C version of GLTT that uses Freetype.
5) Use python FontTools? (No rasterizer)
6) expose platform specific bitmap font capabilities 
through WGL, AGL, GLX, etc.  or come up with common 
call.

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-06-05 03:33

Message:
Logged In: YES 
user_id=34901

Okay, now have the following in a fairly decent framework in
OpenGLContext.scenegraph.text:

fonttools -- provides outline or polygonal fonts, including
capping and extrusion. Cross-platform, requires only
fonttools, GL, GLU and GLE.  Uses TTF files directly. 
(Note: there are trivial dependencies on OpenGLContext,
nothing that couldn't be stripped out in a few hours if
someone wanted to use the lib outside of OpenGLContext). 
Can extract font-names from those font-files of which it's
made aware.

pygame -- provides antialiased rendering of fonts into
images, cross-platform, requires pygame and the attendant
libraries, including SDL_ttf.  Uses TTF files directly.  Has
no way to find out font-face or font-family names.

wxPython -- provides non-antialiased rendering of fonts into
images, cross-platform (but not cross-context), requires
wxPython.  Has access to registered system fonts and can use
font-names instead of filenames to reference fonts, can't
load TTF files directly.

GLUT -- fallback provider, in case none of the others is
available, provides non-antialiased glBitmap display of
ASCII 7-bit characters in a small range of fonts and sizes.

WGL -- provides polygonal fonts on Win32 (bitmap fonts are
missing metrics)

The image-based types are all currently doing glDrawPixels
rendering, will likely be adding a texture-based version
eventually as well.

I'm marking the general request "closed", feel free to open
more specific requests anybody.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-06-27 19:35

Message:
Logged In: YES 
user_id=34901

Python fonttools project does a nice job of giving you the
shells for the code, I'm playing around with making a
run-time renderer with it.  As noted, no rasteriser,
however, so have to roll both geometry and raster-mode
implementations.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-01-17 04:25

Message:
Logged In: YES 
user_id=34901

Another possible option:
http://oglft.sourceforge.net/ -- LGPL, (apparently) same
basic functionality as GLTT, based on FreeType2.  Claims to
be 0.0 status, but has what looks to be fairly close to a
completed OGLFT.CPP (haven't tested it's functionality, just
browsed the code).  Note that it's C++, not C, code.  By the
look of it, could be its own module, rather than being part
of the base PyOpenGL module (especially given the license),
as it's interactions are all self-contained (you pass in
strings, booleans, etceteras, there's no arrays/callbacks).
 Has all the bells+whistles you'd want (multiple 2D and 3D
formats, extrusions with GLE, use of truetype, etceteras).

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-01-17 04:02

Message:
Logged In: YES 
user_id=34901

Another possible option:
http://oglft.sourceforge.net/ -- LGPL, (apparently) same
basic functionality as GLTT, based on FreeType2.  Claims to
be 0.0 status, but has what looks to be fairly close to a
completed OGLFT.CPP (haven't tested it's functionality, just
browsed the code).  Note that it's C++, not C, code.  By the
look of it, could be its own module, rather than being part
of the base PyOpenGL module (especially given the license),
as it's interactions are all self-contained (you pass in
strings, booleans, etceteras, there's no arrays/callbacks).
 Has all the bells+whistles you'd want (multiple 2D and 3D
formats, extrusions with GLE, use of truetype, etceteras).

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

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

[PyOpenGL-Users] Re: [wxPython-users] Anyone using wxPython's GLCanvas on Linux?

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

Isn't it always the way that you discover more information as soon as 
you send the last message?  Turns out the display-list problem (at 
least) only shows up in the __init__ method of the wxGLCanvas, 
display-lists *can* be created from within Paint callbacks.  Seems as 
though there may be a delay in setting up the wxGLCanvas' OpenGL 
structures so that within the __init__ method there just isn't a useful 
context to be had.

I'll work more on this, but at the moment I'm planning to seperate out 
the user-level "OnInit" method so that it's occuring after whatever 
point it is the OpenGL structures are established.  I'm hoping there's 
an event or the like to signal that point.  I'll trim all further 
updates to PyOpenGL, BTW.

Enjoy all,
Mike

Mike C. Fletcher wrote:
...

> The symptoms would all suggest that (Py)OpenGL isn't recognising the 
> current context (display-lists are context-specific, as are extensions 
> and texture-objects), 

...

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

[PyOpenGL-Users] Anyone using wxPython's GLCanvas on Linux?

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

I've just discovered yet another "how can that possibly not work" issue 
with wxPython + PyOpenGL under RHLinux 8.0, which is making me wonder:

    * Does wxGLCanvas just not work on Linux?
          o Has anyone else really used it (not just running the demos,
            actually used it, doing any of the things decribed below)?
          o Did you discover and work around these problems (described
            below)?
          o Did the problems not show up at all?
    * Is there something wrong with how I'm doing SetCurrent() for the
      context?
          o I'm just calling  wxGLCanvas.SetCurrent(), which AFAICS is
            the correct thing to do.

Basically, here are the things that are not working:

    * Display-lists can't be generated, glGenLists always returns 0
    * glInitMultitextureARB returns 0 under wxPython contexts, but 1 for
      GLUT contexts (same machine, same everything else).  In other
      words, the extension isn't recognised for wxPython contexts but is
      for GLUT contexts
    * gluBuild2DMipmaps seg-faults under wxPython, works fine under GLUT

The symptoms would all suggest that (Py)OpenGL isn't recognising the 
current context (display-lists are context-specific, as are extensions 
and texture-objects), but I can't imagine what would cause such a thing 
in my code.  I've checked, and I'm definitely calling

        wxGLCanvas.SetCurrent(self)

on the wxGLCanvas instance.

So, I'm wondering, am I just the first person to really use the wxPython 
wxGLCanvas?  My testing on Linux has never been particularly extensive, 
but I can't imagine that anyone really using wxGLCanvas on this platform 
hasn't noticed such an effect.

Oh, same code, same versions of wxPython and PyOpenGL works fine on 
Win2K, and as noted above, all the code works fine with the GLUT 
contexts on Linux (and Win2K).

So, is this an isolated incident, or am I tredding upon new ground here?
Mike

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

Re: [PyOpenGL-Users] My recent experiments in text...

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

Just in case anyone is interested, I am working on a spike test using 
Fonttools to extract font outlines directly from .ttf files to use in 
creating polygonal fonts.  Fonttools is primarily written in Python, 
with a tiny C module to accelerate a few parts (with a python backup if 
that's not available).  So far have the ability to extract the glyph 
outlines and dump the results to NURBs curves for preliminary display.

Haven't yet figured out how to get the on/off contour information 
transferred, which results in somewhat "lumpy" fonts when you get close 
(ideas welcome). Still working on extracting the metrics (line height, 
advance width/glyph), and then will look at doing polygonalisation.

Enjoy yourselves,
Mike

Mike C. Fletcher wrote:

...

> The WGL-based polygonal text, is still there, haven't come up with a 
> good cross platform solution for that yet.

...

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

[PyOpenGL-Users] My recent experiments in text...

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

I've been working on text-node support for OpenGLContext.  At the moment 
I have basic glDrawPixels-based text support using any of:

    * PyGame (antialiased, most control, loaded directly from ttf files
      via SDL_ttf),
    * WGL (Win32 only, obviously)
    * wxPython (non-antialiased, but has (primitive) font-name matching
      to allow specifying, for instance "times roman" and having the
      system search for a font with Times Roman included in the name)

the same code drives the (basic) layout for the three sources.

I'm going to look at creating texture-based text as well (a single 
texture mapped to polygons to create flat text affected by the current 
transform).

The WGL-based polygonal text, is still there, haven't come up with a 
good cross platform solution for that yet.

Have fun,
Mike

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

[PyOpenGL-Users] Orbiting camera around objects demo

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

Added an orbiting camera effect to my game, and thought I'd put it into 
a demo.

You can find it  at this link:
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyopengl/PyOpenGL2/OpenGL/Demo/rened/sin_cos_reloaded.py?rev=HEAD&content-type=text/vnd.viewcvs-markup>

Or in pyopengl cvs under OpenGL/Demo/rened/sin_cos_reloaded.py

Press 1,2,3 to change which cube you orbit around.

You can really give yourself motion sickness playing around with moving 
cameras.  First time I've gotten motion sickness from a computer!  Note 
that the demo above moves nice and slow, and shouldn't make you sick.

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

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

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

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

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

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-05-25 02:50

Message:
Logged In: YES 
user_id=34901

Extension manager is checked in an functional.

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

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

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

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

I'll discuss how we want to handle these kinds of modules (i.e. ones 
under non BSD/MIT license) over on the dev list.  It'll probably be 
distributed as an "add in tarball" (it currently builds from within the 
PyOpenGL tree).  Not sure whether to distribute the actual module with 
the wrapper or let people download and use the latest version.

Enjoy,
Mike

Champ Hippy wrote:

>Dear Mike,
>
>Thanks very much to you and gabor for the answers you provided me. For
>the moment, glReadPixels() should satisfy my needs. But I surely am
>interested in a wrapper to gl2ps and I would be very pleased if you
>could publish it (as you kindely proposed so in your post :
>Preliminary gl2ps wrapper for PyOpenGL). I'm currently starting to
>learn the use of swig so I am also interested in the interface file,
>swig commands, comments, windows MDSDEV compilation ... anything you have.
>
>Bernard
>  
>
...

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

Re: [PyOpenGL-Users] true type fonts

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

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

is the feature request currently in the hopper.  Note that, if you're 
using PyGame as your hosting context, it has the sdl_ttf module 
available to do TrueType raster fonts with anti-aliasing.  You can find 
sample code in the Python cookbook here:

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/115418

Alternately, if you're willing to do platform-specific code, see 
OpenGLContext.scenegraph.text.wglfont.WGLBitmapFont , which uses 
wglUseFontBitmapsW to create pixmap fonts similar to those in the PyGame 
recipe.  The WGLOutlineFont class in the same module uses 
wglUseFontOutlinesW to create polygonal text.

See the tracker page for discussion of issues relating to licensing and 
the like.  I've got decent font support on my radar, but at the moment, 
all the approaches available seem far less than ideal.

Enjoy,
Mike

Champ Hippy wrote:

>Hello,
>
>I'm looking for a way to display "nice" font text on my OpenGL scene
>(a simple 2D function plot). So far I used the "glutBitmapCharacter()"
>function but I'm not satisfied with it for I at least need greek letters.
>
>I know the existence of GLTT (http://gltt.sourceforge.net/index.html)
>and OGLFT (http://oglft.sourceforge.net) and I would like to wrap them
>(if possible) using swig. Unfortunately, my comprehension of swig is
>too low for that task : I do not how to cope with nested class in GLTT
>(class FTGlyphVectorizer) and OGLFT start with a namespace definition,
>both c++ features that are difficult to handle with swig.
>
>So my questions are : 
>- is it possible to wrap these libraries ?
>- did someone managed to wrap these or equivalent libraries ?
>- is there another solution to my problem ?
>
>Thanks,
>
>Bernard
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>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] true type fonts

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

Hello,

I'm looking for a way to display "nice" font text on my OpenGL scene
(a simple 2D function plot). So far I used the "glutBitmapCharacter()"
function but I'm not satisfied with it for I at least need greek letters.

I know the existence of GLTT (http://gltt.sourceforge.net/index.html)
and OGLFT (http://oglft.sourceforge.net) and I would like to wrap them
(if possible) using swig. Unfortunately, my comprehension of swig is
too low for that task : I do not how to cope with nested class in GLTT
(class FTGlyphVectorizer) and OGLFT start with a namespace definition,
both c++ features that are difficult to handle with swig.

So my questions are : 
- is it possible to wrap these libraries ?
- did someone managed to wrap these or equivalent libraries ?
- is there another solution to my problem ?

Thanks,

Bernard

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

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

Dear Mike,

Thanks very much to you and gabor for the answers you provided me. For
the moment, glReadPixels() should satisfy my needs. But I surely am
interested in a wrapper to gl2ps and I would be very pleased if you
could publish it (as you kindely proposed so in your post :
Preliminary gl2ps wrapper for PyOpenGL). I'm currently starting to
learn the use of swig so I am also interested in the interface file,
swig commands, comments, windows MDSDEV compilation ... anything you have.

Bernard