pyopengl-users — Discussion of all PyOpenGL matters.

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

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

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.

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
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...).

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".

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... :)

-- 
"If you sit down at a poker game and don't see a sucker, get up.  You're
 the sucker."

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

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

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

--Micah

On Sat, Sep 20, 2003 at 03:41:08PM -0400, 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).  If so, what type will they be? Lines?  Polygonal? Texture-based?
> 
> 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.
> 
> -- 
> "Everything should be made as simple as possible, but no simpler."
> 	-- Albert Einstein
> 
> 
> -------------------------------------------------------
> 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] any font fns on the horizon? (in Linux)

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

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).  If so, what type will they be? Lines?  Polygonal? Texture-based?

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.

-- 
"Everything should be made as simple as possible, but no simpler."
	-- Albert Einstein

[PyOpenGL-Users] better way to zoom? was: small bug: tkScale() and `distance' < 0

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

(Blast from the past.)

On Wed, Apr 30, 2003 at 09:55:12PM -0400, Mike C. Fletcher wrote:
> Okay, I just fixed this one.  I didn't do anything fancy, just limited 
> total scaling to within 1:1000 through 1000:1 of current scale.  I'm 
> unable to provoke the situation of pushing past the focus point with the 
> current code, though I could imagine having it occur just through 
> successively scaling in so that the scale just disappears entirely (i.e. 
> the floating-point value becomes so small as to be effectively 0), but 
> if you're zooming in that far, well, expect problems.

I've been doing some stuff on my own version of OpenGL window (OpenGL
embedded in wxPython window, with whole bunch of extra defaul
functionality), and I ended up revisiting how my code does scaling.  I
found a scaling/zooming method which IMHO works better.

currently tkScale() does this:
	scale = 1 - 0.01 * (event.y - self.ymouse)
	self.distance = self.distance * scale

what I think works/*feels* better:
        scaler_speed = 0.98
        dist = event.y - self.ymouse
        scale = scaler_speed ** dist
        self.distance *= scale

you might also want to put in a threshold so that you can't go down to scale =
0, which would be unescapable.
        # make sure that `eye_dist' doesn't hit 0, else we won't be able to
        # zoom out
        zero_thresh = 0.0001
        if self.distance < zero_thresh:
            self.distance = zero_thresh


Benefits of new method:
    * no hysterisis: as long as you keep the mouse button down,
      each mouse position corresponds to a unique zoom setting, no
      matter how you move the mouse to that position; (this might not be
      so clear, so here's a more practical example: put mouse in center
      of screen, hold mouse button down for zooming, go crazy with the
      mouse, move it everywhere, bring it back to center: you'll be at
      the original zoom level.)

    * the bug from the OT is impossible here

    * it might be just me, but the zooming speed at various zoom-in
      levels feels more resonable and comfortable.

-- 
Maciej Kalisiak|mac@] "The person who says it cannot be done should not
dgp.toronto.edu|www.]  interrupt the person doing it." -- Chinese Proverb
dgp.toronto.edu/~mac]  

Re: [PyOpenGL-Users] newbie install question: PyOpenGL confused by 2.2 and 2.3?

[David v. K. <dvu...@ho...>]

Answering my own question, from the command line in the Python22 directory,
it worked fine. So I think it was a problem of GUI conflict.

----- Original Message ----- 
From: "David vun Kannon" <dvu...@ho...>
To: <pyo...@li...>
Sent: Wednesday, August 27, 2003 2:59 PM
Subject: [PyOpenGL-Users] newbie install question: PyOpenGL confused by 2.2
and 2.3?


> Hi,
> I've tried to follow the instructions on
> http://pyopengl.sourceforge.net/documentation/installation.html
> to install PyOpenGL on my Win XP system. I first D/L'ed GLUT 3.7.6 and
> updated my NVIDIA driver, just in case! I can see a prebuilt .exe (smooth)
> so I know that everything is OK outside the Python world.
>
> However, running the GLUT example molehill.py doesn't quite work. Double
> clicking the .py file gets me the "OpenGL.GL module doesn't exist" error
> that means (to me) that I'm running the IDE from the Python 2.3 directory.
> Choosing Pythonwin from the 2.2 directory and opening/running molehill.py
> gets me a blank window, titled molehill. Is my problem that I shouldn't
try
> to launch a PyOpenGL app from inside a Python GUI? Or is 2.3 still getting
> in the way at some other level?
>
> My ultimate interest in PyOpenGL is to write an OpenGL accelerator script
> for the app Poser, from Curious Labs. Poser renders in software, slowly.
> Poser has an embedded Python 2.2 interpreter. Poser can export Wavefront
OBJ
> files, so I hope to take the OBJ file, parse it with glm, render, and
> ReadPixels back into Poser. Looking beyond my immediate problems, I notice
> that Poser creates polygons other than triangles. Will I have to
triangulate
> everything before I can use glm?
>
> Thanks for your advice,
> David vun Kannon
>
>
> -------------------------------------------------------
> 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] newbie install question: PyOpenGL confused by 2.2 and 2.3?

[David v. K. <dvu...@ho...>]

Hi,
I've tried to follow the instructions on
http://pyopengl.sourceforge.net/documentation/installation.html
to install PyOpenGL on my Win XP system. I first D/L'ed GLUT 3.7.6 and
updated my NVIDIA driver, just in case! I can see a prebuilt .exe (smooth)
so I know that everything is OK outside the Python world.

However, running the GLUT example molehill.py doesn't quite work. Double
clicking the .py file gets me the "OpenGL.GL module doesn't exist" error
that means (to me) that I'm running the IDE from the Python 2.3 directory.
Choosing Pythonwin from the 2.2 directory and opening/running molehill.py
gets me a blank window, titled molehill. Is my problem that I shouldn't try
to launch a PyOpenGL app from inside a Python GUI? Or is 2.3 still getting
in the way at some other level?

My ultimate interest in PyOpenGL is to write an OpenGL accelerator script
for the app Poser, from Curious Labs. Poser renders in software, slowly.
Poser has an embedded Python 2.2 interpreter. Poser can export Wavefront OBJ
files, so I hope to take the OBJ file, parse it with glm, render, and
ReadPixels back into Poser. Looking beyond my immediate problems, I notice
that Poser creates polygons other than triangles. Will I have to triangulate
everything before I can use glm?

Thanks for your advice,
David vun Kannon

Re: [PyOpenGL-Users] difficulty with installing

[Rob B. <rbo...@ya...>]

> >I have installed
> >python 2.3 
> >
> There's your problem.  Note that the dependency
> listed on the page is 
> Python 2.2.3+, that is, Python 2.2, latest version,
> *not* Python 2.3.  


  thanks a lot Mike, I did misread that. I'll try
reinstalling the whole lot.

  cheers,
  Rob

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [PyOpenGL-Users] difficulty with installing

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

Rob Boellaard wrote:

>   Hi list,
>
>  I am trying to get OpenGL and Python to work. I have
>worked through the installation list on the
>pyopengl.sourceforge.net webpage. 
>
Just to be clear, you're using the main (current) installation page here:

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

>I have installed
>python 2.3 
>
There's your problem.  Note that the dependency listed on the page is 
Python 2.2.3+, that is, Python 2.2, latest version, *not* Python 2.3.  
Python 2.3's Tkinter/togl is currently broken, so we aren't currently 
able to support it (at least, not with togl).

>and most of the other dependencies.
>
You'll need to re-install those for Python 2.2.

>  I have two questions:
>  1. about the glut binaries, where exactly should I
>place the glut.c, glut.lib and glut.def? 
>  As I couldn't find any DeveloperStudio program to
>istall it for me, and I dont know my way around very
>well in windows system files and makefiles, I have
>done the following
>  glut32.dll --> C:\WINDOWS\System\
>  glut.c     --> C:\Python\include\
>  glut.lib   --> C:\Python\lib\
>  glut.def   --> ??
>
The glut.lib would need to be in c:\python\libs, not c:\python\lib.  I 
put the .def files in the libs directory, but for MSVC++, they aren't 
necessary AFIAK.  Note that the PyOpenGL build system will also put a 
../lib and ../include directory in the lib and include paths 
respectively (from the PyOpenGL source directory), so you can just 
create directories at that level if you don't want to put 
OpenGL-specific stuff in your Python directories.

>  2. the other question is about PyOpenGL and
>OpenGlContext itself. I didn't find an installer for
>the context for Python 2.3, just for 2.2. However, in
>the installation doc-page it says that Python 2.3 is
>required (! it is even in bold) for the context - so
>now I am hesitating.
>
It's Python "2.2.3+", that's in bold. Having the + there is probably the 
confusing thing (given that the 2.2.4 branch isn't really doing much at 
the moment).  Use Python 2.2.3, not Python 2.3.

>  I guess I should now get the sources, and compile
>them, but I have zero expierence with Python or OpenGl
>( it is my goal to learn them both together - I do
>have experience with unix and C & Java, though), so
>before I mess up, I would like to ask your advice.
>  Could you please tell me which versions to download,
>exactly how to install themin which order, using wich
>shell or other program?
>
Please try again from the installation instructions page (which is 
trying to give you everything you've described).  The order to install 
is the order of listing for the most part (if you use that order 
everything's fine, but you can actually switch around the order for lots 
of things w/out problems).

Good luck,
Mike

Re: [PyOpenGL-Users] difficulty with installing

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

>  Could you please tell me which versions to download,
>exactly how to install themin which order, using wich
>shell or other program?
>
>  Thank you very much
>
>  Rob
>  
>

Probably best to install python2.2 for now.  Until a lot of packages are 
released for python2.3.  Numeric and pyopengl are two which haven't yet 
done python2.3 packages.

[PyOpenGL-Users] difficulty with installing

[Rob B. <rbo...@ya...>]

   Hi list,

  I am trying to get OpenGL and Python to work. I have
worked through the installation list on the
pyopengl.sourceforge.net webpage. I have installed
python 2.3 and most of the other dependencies.
  I have two questions:
  1. about the glut binaries, where exactly should I
place the glut.c, glut.lib and glut.def? 
  As I couldn't find any DeveloperStudio program to
istall it for me, and I dont know my way around very
well in windows system files and makefiles, I have
done the following
  glut32.dll --> C:\WINDOWS\System\
  glut.c     --> C:\Python\include\
  glut.lib   --> C:\Python\lib\
  glut.def   --> ??

  2. the other question is about PyOpenGL and
OpenGlContext itself. I didn't find an installer for
the context for Python 2.3, just for 2.2. However, in
the installation doc-page it says that Python 2.3 is
required (! it is even in bold) for the context - so
now I am hesitating.
  I guess I should now get the sources, and compile
them, but I have zero expierence with Python or OpenGl
( it is my goal to learn them both together - I do
have experience with unix and C & Java, though), so
before I mess up, I would like to ask your advice.
  Could you please tell me which versions to download,
exactly how to install themin which order, using wich
shell or other program?

  Thank you very much

  Rob

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[PyOpenGL-Users] [ pyopengl-Feature Requests-787688 ] PyOpenGl-Python23-win32.zip installer?

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

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

>Category: build
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Raymond A. St. Marie (rastm2)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: PyOpenGl-Python23-win32.zip installer?

Initial Comment:
Is there any movement on an installer that will install the 
current PyOpenGl and PyOpenGlContext on win32
(98notSE) for Python2.3?

Thanks
Ray St. Marie
Ra...@us...

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2003-08-12 19:10

Message:
Logged In: YES 
user_id=34901

Arthur has packaged up a minimal distribution of PyOpenGL
for Python 2.3 here:

    http://home.ix.netcom.com/~ajs/download/

Note that it doesn't include the extension modules or togl.  

We can't produce a full installer because of a bug in
Togl/Tk 8.4 (I hate that bleeping widget).  Once we have
that fixed I'd love to get a full build done for Python
2.2.3 and Python 2.3, but that will be primarily dependent
on getting our volunteer packager set up to go.

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

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

[PyOpenGL-Users] [ pyopengl-Feature Requests-787688 ] PyOpenGl-Python23-win32.zip installer?

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

Feature Requests item #787688, was opened at 2003-08-12 17:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=787688&group_id=5988

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond A. St. Marie (rastm2)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOpenGl-Python23-win32.zip installer?

Initial Comment:
Is there any movement on an installer that will install the 
current PyOpenGl and PyOpenGlContext on win32
(98notSE) for Python2.3?

Thanks
Ray St. Marie
Ra...@us...

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

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

Re: [PyOpenGL-Users] Extensions, etc

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

Brian Hammond wrote:

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

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

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

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

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

Enjoy,
Mike

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

Re: [PyOpenGL-Users] Extensions, etc

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

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

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

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

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

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

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

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

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

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

Unsuredly-yours,
Brian

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

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

[PyOpenGL-Users] glBitmap coredump

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

Hi,

I think I'm getting memory errors inside a call to glBitmap, I have 
generated an image as a string and am displaying it using glDrawpixels() but 
prior to that I am setting the rasterpos with glBitmap. When displaying the 
same image and not changing any arguments my program seems to randomly 
choose whether it's going to crash or not, the output below is me printing 
out the 'a' line before the glBitmap and the 'b' line afterwards.

a - glBitmap(4096.000000, 576.000000, 0, 0, 0.000000, 0.000000, 0)
b - glBitmap done
a - glBitmap(4096.000000, 576.000000, 0, 0, 0.000000, 0.000000, 0)

I know the image size is huge, but it's the only way I can make it happen 
predictably - I have used 600x600 sized images and my app crashes about 1 in 
20 goes.

I have tested it under windows and linux using a geforce4 level card and 
windows using a radeon 9700, they all do the same thing. I have also tried 
both 2.0.0.44 and 2.0.1.04 under windows and linux.

If I comment out the glBitmap line the application runs with no problem so I 
dont think it's a problem with my code. Also I am not trying to do anything 
clever

Has anyone come across this before or know what could be causing the 
problem?

failing that can anyone hint towards a workaround? I don't want to texture a 
poly due to texture size limitations.

Thanks in advance, if I should provide any more information please let me 
know.

Joe

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp

Re: [PyOpenGL-Users] Extensions, etc

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

Brian Hammond wrote:

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

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

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

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

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

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

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

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

[PyOpenGL-Users] Extensions, etc

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

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

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

Looks good though!
Thanks, Brian

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

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

T.J. Jankun-Kelly wrote:

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


Here's a work around.

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

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

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

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

Greetings,

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

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

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

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

Thanks.

TJK

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

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

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

Re: [PyOpenGL-Users] glInterleavedArrays memory leak

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

On Sat, Aug 02, 2003 at 01:01:20PM +1000, Rene Dudfield wrote:
> Micah Dowty wrote:
...
> >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.
...
> Very nice on the bzFlag front!
> 
> The memory leak is there.  It leaks with numeric arrays as well.
> 
> #--------------------------------------------------------------------------------------------
> import pygame, time
> from pygame.locals import *
> from OpenGL.GL import *
> import Numeric
> try:
>    from numeric_gl import *
> except:
>    print "numeric_gl import failed"
> 
> pygame.init()
> pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF)
> while 1:
>    b = [ 0.0, 0.0, 0.0,
>          1.0, 0.0, 0.0,
>          1.0, 1.0, 0.0,
>          0.0, 1.0, 0.0 ] * (10000 / 12)
> 
>    glInterleavedArrays( GL_V3F, 0, b)
> 
>    time.sleep(0.01)
>    pygame.display.flip()
> #--------------------------------------------------------------------------------------------
> 
> 
> It's related to the way that array related functions in pyopengl are 
> used.  I've been thinking of redoing them for a while but haven't had 
> time :(
> 
> I've made a seperate numeric module with the gl*Pointer functions.  I 
> just added a glInterleavedArrays which doesn't seem to have a memory leak.
> 
> Could you give it a go and tell me what you think?
> 
> 
> It can be found here:
> http://py3d.org/files/numeric_gl.tar.gz
> 
> It only works with numeric arrays(ie strings etc will probably not work).
> 
> It's only tested/compiled on debian linux.  I ran the OpenglContext test 
> which used numeric arrays and it ran ok once I removed the tostring() calls.
> 

I'm on Gentoo here with Python 2.2.3 and it compiled fine. Appears to
solve the memory leak too :)

> 
> I will eventually add this into pyopengl I think.  That is a seperate 
> sub module for numeric stuff.  Which would be automatically detected and 
> included into OpenGL.GL using python.

I'm looking forward to it!

> 
> Along with some PyArray_ContiguousFromObject type function calls to 
> allow you to check if memory is being copied unnecessarily(or did you 
> allready add something like this Mike?).
> 
> 
> Have fun!
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

-- 
Only you can prevent creeping featurism!

Re: [PyOpenGL-Users] glInterleavedArrays memory leak

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

Rene Dudfield wrote:
...

> The memory leak is there.  It leaks with numeric arrays as well. 

:(
...

> It's related to the way that array related functions in pyopengl are 
> used.  I've been thinking of redoing them for a while but haven't had 
> time :( 

The typemaps are definitely the hairiest part of PyOpenGL.  I'd really 
love to rewrite them in a more robust way (was considering producing 
them with a Python script, rather than the huge numbers of pre-processor 
macros currently used).  What I'd like even more would be a test-suite 
for the set of type-maps, but that's probably beyond my resources for a 
good long while.
...

> I will eventually add this into pyopengl I think.  That is a seperate 
> sub module for numeric stuff.  Which would be automatically detected 
> and included into OpenGL.GL using python. 

I'll try to get some time to look at it.  Too many projects going 
simultaneously, and with the new job I really don't have more than a few 
hours/week to work on the Open Source stuff that isn't related to the 
job.  Probably should wade through the patches and bug-reports that have 
been piling up first I suppose :) .

> Along with some PyArray_ContiguousFromObject type function calls to 
> allow you to check if memory is being copied unnecessarily(or did you 
> allready add something like this Mike?). 

The code currently only copies if there is a type mis-match.  However, 
it would likely be a better strategy to first see if there's a matching 
function for the given data-type and use that instead of the specified 
function.  i.e. if someone calls gl*Pointerf( ) with a double array, use 
the gl*Pointerd( ) version rather than converting to 'f' and calling the 
specified function.

Have fun,
Mike

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

Re: [PyOpenGL-Users] glInterleavedArrays memory leak

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

Micah Dowty wrote:

>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
>
>  
>
Very nice on the bzFlag front!

The memory leak is there.  It leaks with numeric arrays as well.

#--------------------------------------------------------------------------------------------
import pygame, time
from pygame.locals import *
from OpenGL.GL import *
import Numeric
try:
    from numeric_gl import *
except:
    print "numeric_gl import failed"

pygame.init()
pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF)
while 1:
    b = [ 0.0, 0.0, 0.0,
          1.0, 0.0, 0.0,
          1.0, 1.0, 0.0,
          0.0, 1.0, 0.0 ] * (10000 / 12)

    glInterleavedArrays( GL_V3F, 0, b)

    time.sleep(0.01)
    pygame.display.flip()
#--------------------------------------------------------------------------------------------
 

It's related to the way that array related functions in pyopengl are 
used.  I've been thinking of redoing them for a while but haven't had 
time :(

I've made a seperate numeric module with the gl*Pointer functions.  I 
just added a glInterleavedArrays which doesn't seem to have a memory leak.

Could you give it a go and tell me what you think?


It can be found here:
http://py3d.org/files/numeric_gl.tar.gz

It only works with numeric arrays(ie strings etc will probably not work).

It's only tested/compiled on debian linux.  I ran the OpenglContext test 
which used numeric arrays and it ran ok once I removed the tostring() calls.


I will eventually add this into pyopengl I think.  That is a seperate 
sub module for numeric stuff.  Which would be automatically detected and 
included into OpenGL.GL using python.

Along with some PyArray_ContiguousFromObject type function calls to 
allow you to check if memory is being copied unnecessarily(or did you 
allready add something like this Mike?).


Have fun!

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

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

Benjamin Deutsch wrote:

> Hello again,
>
>> > 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).
>
>
>> what driver do you have installed?  Sounds like a software version is
>> being used.
>>
>> glInfo is good for getting that info.  You can find a copy here:
>> http://delphi3d.net/hardware/index.php
>
>
> Thanks for the link, but it seems my problem isn't hardware
> accelleration after all. It seems that under Windows, PyOpenGL always
> does an implicit vsync, but not under Linux. It took me a while to
> realize that my fps were suspiciously close to my monitor's framerate...
>
> Does anyone know a way to turn this on or off? I guess it's no longer a
> problem, just an oddity; in fact, it might be beneficial (my programs
> won't really get any actual framerate faster than the monitor, will 
> they?)
>
> Thanks though,
>
It's probably good to use vsync :)

You can turn it off with the driver settings.

Be interesting to know how to do it from your program.  I did a bit of 
searching but couldn't figure out how.

With sdl it seems to try and get vertical sync, but sometimes it can't 
get it.  eg Full screen in windows with nvidia drivers for me doesn't 
sync I think.


Sam I am.

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

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

Hello again,

> > 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).

> what driver do you have installed?  Sounds like a software version is
> being used.
>
> glInfo is good for getting that info.  You can find a copy here:
> http://delphi3d.net/hardware/index.php

Thanks for the link, but it seems my problem isn't hardware
accelleration after all. It seems that under Windows, PyOpenGL always
does an implicit vsync, but not under Linux. It took me a while to
realize that my fps were suspiciously close to my monitor's framerate...

Does anyone know a way to turn this on or off? I guess it's no longer a
problem, just an oddity; in fact, it might be beneficial (my programs
won't really get any actual framerate faster than the monitor, will they?)

Thanks though,

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

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

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

Benjamin Deutsch wrote:
Hey,

what driver do you have installed?  Sounds like a software version is 
being used.

glInfo is good for getting that info.  You can find a copy here:
http://delphi3d.net/hardware/index.php


> 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,
>