pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Anyone have a working script using PyOpenGL with threads?

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

Hi.

I've used threads before with pyopengl.  I use them
when flipping the backbuffer.  As on some(many?)
machines you have a lot of free cpu time which
otherwise gets wasted.

the code I used is old and rotten :)  It relies on
other code which has morphed into other stuff.  So
I'll paste the thread parts.


from threading import Thread

import threading

class SomeThread(Thread):

    def __init__(self):

        Thread.__init__(self)
        self.an_event = threading.Event()

    def run(self):
        # do some calculations here.
        map(cos, xrange(1000))


a_thread = SomeThread()


Then in the main loop(this is with pygame which allows
you to have a main loop).


DrawOpenGLStuff()

# start off thread.
if not (threading_activeCount() > 1):
    a_thread.start()

# flip back buffer
pygame.display.flip()


I guess this is not how you want to use threads. 
Maybe you could post some code that we could test? 
The problem might be to do with your driver/platform.




 --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
I've been trying to make OpenGLContext use a model
> where a background 
> server thread does the rendering to allow foreground
> threads to be 
> application-specific & largely unconcerned with the
> rendering operations.
> 
> However, whenever I try to put the rendering thread
> in the background, 
> the entire works gets gummed up, with the symptoms
> looking like the 
> OpenGL calls just aren't writing to the buffers at
> all (the results from 
> previous runs are present, along with random data,
> etceteras), though 
> the swap-buffers methods seem to be working for both
> GLUT and wx.  I'm 
> using the context.setCurrent equivalents for the
> various contexts, BTW.
> 
> I'd love to see a script using threads + OpenGL so I
> can figure out what 
> I'm doing wrong here.  I assume it's something dumb,
> but I can't figure 
> out what.
> 
> Any help appreciated,
> Mike


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

[PyOpenGL-Users] Anyone have a working script using PyOpenGL with threads?

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

I've been trying to make OpenGLContext use a model where a background 
server thread does the rendering to allow foreground threads to be 
application-specific & largely unconcerned with the rendering operations.

However, whenever I try to put the rendering thread in the background, 
the entire works gets gummed up, with the symptoms looking like the 
OpenGL calls just aren't writing to the buffers at all (the results from 
previous runs are present, along with random data, etceteras), though 
the swap-buffers methods seem to be working for both GLUT and wx.  I'm 
using the context.setCurrent equivalents for the various contexts, BTW.

I'd love to see a script using threads + OpenGL so I can figure out what 
I'm doing wrong here.  I assume it's something dumb, but I can't figure 
out what.

Any help appreciated,
Mike
_______________________________________
   Mike C. Fletcher
   Why, yes, I am looking for a job...
   http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Re: Build notes...

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

Overall, very close to completely functional.  There were two bugs in 
PyOpenGL showing up (one related to a previously seen one), and one in 
the OpenGLContext wxContext (some key-presses aren't getting forwarded 
to the handlers).  The first bug in OpenGL is in code trying to check 
for an extension in the GLU module. The test is 
OpenGLContext/tests/nurbsobject.py:

Traceback (most recent call last):
   File "P:\OpenGLContext\tests\nurbsobject.py", line 11, in ?
     from OpenGLContext.scenegraph import shape, nurbs, material
   File "p:\OpenGLContext\scenegraph\nurbs.py", line 101, in ?
     object_space_tess.gluInitObjectSpaceTessEXT()
   File 
"C:\bin\lang\py22\Lib\site-packages\OpenGL\GLU\EXT\object_space_tess.py",
  line 13, in gluInitObjectSpaceTessEXT
     return __has_extension("GLU_EXT_object_space_tess")
TypeError: __has_extension() takes exactly 2 arguments (1 given)

Second bug is in code trying to use the gluNurbsSurface function, looks 
as though the wrapping code is generating negative indices when passed 
an array, I'm guessing this is a typed/untyped or off-by-one style error 
(typo in the GLUError as well, but I believe that's provided by the 
driver, not PyOpenGL).  You can check this with the redbook_surface (or 
redbook_trim) test(s) in OpenGLContext (or the PyOpenGL molehill demo, 
likely):

Traceback (most recent call last):
   File "p:\OpenGLContext\glutcontext.py", line 93, in OnResize
     self.triggerRedraw(1)
   File "p:\OpenGLContext\context.py", line 182, in triggerRedraw
     self.OnDraw()
   File "p:\OpenGLContext\context.py", line 132, in OnDraw
     result = mode( self ) and mode.visible
   File "p:\OpenGLContext\rendermode.py", line 16, in __call__
     self.Draw( client)
   File "p:\OpenGLContext\rendermode.py", line 33, in Draw
     self.Render( client )
   File "p:\OpenGLContext\rendermode.py", line 48, in Render
     return client.Render( self.mode )
   File "P:\OpenGLContext\tests\redbook_surface.py", line 78, in Render
     GL_MAP2_VERTEX_3
OpenGL.GLU.GLUerror: [Errno 100284] negative byte-stride encounteed

All OpenGLContext tests not mentioned above now pass.

Note: platform tested...
	Win2K, Radeon, VC6, Py2.2.1 w/ Numeric

Comments on the rest interspersed below...

Rene Dudfield wrote:
...
>  --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
...
>>gluProject, seem just to be missing %name directives
>>in the wrapper), 
...
> TODO: On windows, see if this still happens?  Works ok
> here(debian/linux).
...

<snip a number of problems>
> Not sure of these problems yet.  Be good to see if it
> is happening
>  in the old version.
...
I'll check when I get some time.

> 
> I'm not sure how many people are interested in this
> library?
> Anyone interested in fixing it up?  If not, I'd be
> happy to leave
>  it as is, and note in the docs that it is
> unmaintained.

I'm interested in it in a desultory sort of way, mostly because I can 
see it being useful in such things as creating extruded text.  That 
said, I don't see it as critical to the project's success, so I'd devote 
resources elsewhere before here.

...
> I think we need some docs to describe how to build it.
>  - required libraries, how to set up system etc.
> 
> Do these exist allready?
> 
> TODO: write build docs, if not allready existing.

Sub-project for documentation added to tracker, this item added as a task.

> Also need to make the tk/tcl stuff optional.
> TODO: make build path without tcl( this
> possible/desirable? ).

Desired: definitely
Possible: I wouldn't be suprised if it's possible now, with some 
esoteric flag or another.  Problem would be finding it (then documenting 
it).  Anyway, togl is just a particular setup module, so 
worse-comes-to-worst we just yank it out and fix whatever complains ;) .

...
>>Edit the __init__ file to not import the missing
>>values as you suggested.
>>
> 
> 
> Not needed anymore.  The __numeric_* stuff comes
> through properly.

Yup, works w/out any changes.


...
> All seemed fine(except array_landscape.py) 
> Traceback (most recent call last):
>   File "array_landscape.py", line 30, in ?
>     base = landscape (2,2)
>   File "array_landscape.py", line 14, in landscape
>     base [:,:,1] = heights
> ValueError: matrices are not aligned for copy
> 
> TODO: check/fix this error.

This file is actually no longer in the project, I fixed that particular 
error a while ago, but eventually decided the whole approach was wrong 
for landscapes and just killed the experiment.

...
> This one is a framework for the other tests.
Ah, thanks.

> 
> 
>>gle/texas -- builds window, but no visible geometry
> 
> 
> TODO: see if gle/texas.py runs ok with last version. 
> see why not showing anything.

Okay, will include that in my "tests of previous version" run when I get 
the time.

...
<molehill error>
>>OpenGL.GLU.GLUerror: [Errno 100284] negative
>>byte-stride encounteed
> 
> 
> TODO: look at this and fix.  I still get same error.

See also error report for Context redbook_surface/trim, looks like the 
same error.

...
>>simple/* -- all work as expected
> 
> works.  this is a GLE test, looks like the helix one. 
> 
> TODO: see if same as GLE/helix.py one.  if so remove.
...
Looks as though the "suite" package is where Tarn was beginning work on 
a single-script test-suite?

>>tom/arraytest, poly -- weird spikes into the
>>triangle/loop, not sure 
>>why, but looks like an array storage problem, or
>>maybe a problem in the 
>>loop code
> 
> 
> looks ok here.  it's a multi colored circle.  can you
> give me a screen shot if it's still happening?
> TODO: test on Mikes system.
Bug report opened, screenshot of the test under the CVS version attached 
to it:
http://sourceforge.net/tracker/index.php?func=detail&aid=584322&group_id=5988&atid=105988

>>tom/demo -- seems to have tk menu problems (not
>>likely OpenGL related)
>>
> 
> works ok here.

Further info: bug only occurs if you close the render window before 
choosing a menu item, apparently code assumes the render window exists. 
  Not a critical error AFAIC.

...
> TODO: find someone who wants to maintain the GLE
> library.  else mark as unmaintained.
...
_______________________________________
   Mike C. Fletcher
   Why, yes, I am looking for a job...
   http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Parse error in GLU.__init__.0102.inc

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

Hi John.

When you made mesa did it make the sgi one or the mesa
one.  The sgi one requires a c++ compiler, but is the
recommended one, as the mesa one is old, and not being
maintained.

When you configure mesa it says:
checking which GLU to build (SGI requires a C++
compiler)... Mesa

or 

checking which GLU to build (SGI requires a C++
compiler)... SGI

I think the header file is the same in either case
though.


If after using the SGI version it still doesn't work
try this:

in src/config.h maybe line 112, try removing some of
the defines:
#define GLUquadric GLUquadricObj
#define GLUnurbs GLUnurbsObj
#define GLUtesselator GLUtriangulatorObj



If none of that works maybe have a look at this:


Could be a problem with PyObject_HEAD and your python
installation.  PyObject_HEAD is a macro included from
Python.h.  Which gets it from object.h from your
/usr/local/include/python2.2/ directory.


This is from my object.h  

Is yours similar?

#ifdef Py_TRACE_REFS
#define PyObject_HEAD \
	struct _object *_ob_next, *_ob_prev; \
	int ob_refcnt; \
	struct _typeobject *ob_type;
#define PyObject_HEAD_INIT(type) 0, 0, 1, type,
#else /* !Py_TRACE_REFS */
#define PyObject_HEAD \
	int ob_refcnt; \
	struct _typeobject *ob_type;
#define PyObject_HEAD_INIT(type) 1, type,
#endif /* !Py_TRACE_REFS */



That's about all I can think of for now.  If you find
out what was wrong could you please tell us what the
problem was?


Good luck :)


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

[PyOpenGL-Users] Re: Build notes...

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

Hi Mike,

this is in reply to your message about testing before.
.  Updated with some notes about the new changes in
the cvs.  Thought I'd cc it to the list in case there
is someone there who wants to help out :)

The current cvs needs swig 1.3.13 to build wrappers
and compile.

Now the pragma(python) code = "" has been replaced by
the new style shadow %{ %}, most of the problems seem
to be gone.

However a few problems remain, so I've gone through
the list of things you tested, and tested them again. 
I wrote something like 'works' if it was working, else
a description of the problem, and a TODO note.


If no one wants to work on the problems below, I'll
start working on them next weekend :)

For the moment I'm working on some bugs and patches
from sourceforge, and the mailing list.




 --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
(Basically successful build, 1 major error (missing
> gluUnproject, 
> gluProject, seem just to be missing %name directives
> in the wrapper), 

TODO: On windows, see if this still happens?  Works ok
here(debian/linux).

>a 
> strange result with the array-based tests (point
> appears in wildly 
> inappropriate position), and a few failures which
> may or may not be 
> related to the conversion (I didn't normally run the
> OpenGL tests, Tarn 
> did, so I'm not sure the code was correct before)).
> 
> Okay, must get some other work done.  Hope things
> are good with you,
> Mike
> 
> 
> Log of building and testing on Python 2.2.1 with
> VC++6 starts here...
> 
> Uninstall PyOpenGL 2.0.0.45, delete package
> directory.
> 
> Okay, have just installed swig 1.3.13, put swig.bat
> in a directory on 
> the path, pointing to the installation directory and
> am proceeding to build.
> 
> First problem, without Tk installed, setup.py bombs
> out.  Probably 
> should have a try/except around import of
> togl_setup.
> 
> Okay, installed Python+Tkinter again from installer,
> killed old Tk 
> environmental variables and installation, trying
> again.
> 
> setup.py build_w
> 
> Fails, saying that it can't find swig.  Typing swig
> at the prompt starts 
> swig, swig takes variables.  Turns out the distutils
> script assumes that 
> a programme on windows will use .exe, so it doesn't
> accept the .bat . 
> Solution is to add swig install directory directly
> to path.
> 
> setup.py build_w
> 
> Now runs to completion.
> 
> setup.py build
> 
> Generates a considerable number of warnings for the
> GLE module, for 
> instance:
> 
> src/interface/GLE.0300.inc(1080) : warning C4024:
> 'gleExtrusion' : 
> different types for formal and actual parameter 7
> src/interface/GLE.0300.inc(1156) : warning C4090:
> 'function' : different 
> 'const' qualifiers
> 
> (I consider this notable because of the failure of a
> few of the gle 
> tests (notably the twburton one) during testing)
> 

Not sure of these problems yet.  Be good to see if it
is happening
 in the old version.

I'm not sure how many people are interested in this
library?
Anyone interested in fixing it up?  If not, I'd be
happy to leave
 it as is, and note in the docs that it is
unmaintained.


> then eventually fails because tcl.h can't be found.
> 
> tcl.h is not available from the Python installation,
> so go to 
> ActiveState and download Active TCL 8.3.4.3
> installer.  Add tcl include 
> directory to environment's include setting.
> 

I think we need some docs to describe how to build it.
 - required libraries, how to set up system etc.

Do these exist allready?

TODO: write build docs, if not allready existing.

Also need to make the tk/tcl stuff optional.
TODO: make build path without tcl( this
possible/desirable? ).

> setup.py build
> 
> No go, still can't find tcl.h, is apparently only
> looking in the 
> explicitly specified directories, so I copy tcl.h
> and tk.h into the 
> Python include directory.
> 
> setup.py build
> 
> No go, the files include other files from the tcl
> include directory, so 
> I copy the whole lot of them into the Python include
> directory, 
> including the X11 subdirectory.
> 
> setup.py build
> 
> Okay, that compiles all the way through.
> 
> setup.py install
> 
> Installation succeeds.
> Edit the __init__ file to not import the missing
> values as you suggested.
> 

Not needed anymore.  The __numeric_* stuff comes
through properly.

> Try to run some OpenGLContext tests.
> All fail, the gluUnproject function is missing (the
> Context uses this 
> for the navigation mechanisms, so every Context
> sub-class fails to load).

Ran a number of these.  

All seemed fine(except array_landscape.py) 
Traceback (most recent call last):
  File "array_landscape.py", line 30, in ?
    base = landscape (2,2)
  File "array_landscape.py", line 14, in landscape
    base [:,:,1] = heights
ValueError: matrices are not aligned for copy

TODO: check/fix this error.

> 
> Switch to running the non-Context tests...
> dots.py -- works
works.
> dek/* -- works, but missing gluUnproject, so can't
> interact

works now, can interact.

> gle/maintest -- silently exits

This one is a framework for the other tests.

> gle/texas -- builds window, but no visible geometry

TODO: see if gle/texas.py runs ok with last version. 
see why not showing anything.

> gle/* -- others work
works.
> 
>
C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\GLUT\examples>molehill.py
> Traceback (most recent call last):
>    File 
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\GLUT\examples\molehill.py
> ", line 153, in ?
>      main()
>    File 
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\GLUT\examples\molehill.py
> ", line 122, in main
>      gluNurbsSurface(nurb, knots, knots, pts1,
> GL_MAP2_VERTEX_3)
> OpenGL.GLU.GLUerror: [Errno 100284] negative
> byte-stride encounteed

TODO: look at this and fix.  I still get same error.

> 
> nehe/* -- all work as expected
works ok here.
> redbook/* -- all work as expected
works.

> simple/* -- all work as expected
works.  this is a GLE test, looks like the helix one. 

TODO: see if same as GLE/helix.py one.  if so remove.

> tom/arraytest, poly -- weird spikes into the
> triangle/loop, not sure 
> why, but looks like an array storage problem, or
> maybe a problem in the 
> loop code

looks ok here.  it's a multi colored circle.  can you
give me a screen shot if it's still happening?
TODO: test on Mikes system.


> tom/demo -- seems to have tk menu problems (not
> likely OpenGL related)
> 
works ok here.

>
C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\tom>fog.py
> Traceback (most recent call last):
>    File
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\tom\fog.py",
> 
> line 86, in
> ?
>      main()
>    File
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\tom\fog.py",
> 
> line 84, in
> main
>      f.run()
>    File
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\tom\fog.py",
> 
> line 32, in
> run
>      self.init()
>    File
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\tom\fog.py",
> 
> line 59, in
> init
>      glFogf(GL_FOG_COLOR, fogColor)
> TypeError: bad argument type for built-in operation
> 

I get the same error.

TODO: look at this, try and fix.  compare to old
version.


> All of the "tom" demos are without gluUnproject
> support, so no testing 
> of left-click functionality is possible.
> 
>
C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\twburton>knot.py
> Traceback (most recent call last):
>    File 
>
"C:\bin\lang\py22\Lib\site-packages\OpenGL\Demo\twburton\knot.py",
> line 1
> 96, in onDisplay
>      glePolyCylinder(self.knot[i] +
> self.knot[i][:3], None, 
> self.radius/15.0)
> ValueError: frames are not aligned
> 

I still get the same error.

TODO: find someone who wants to maintain the GLE
library.  else mark as unmaintained.


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

Re: [PyOpenGL-Users] Parse error in GLU.__init__.0102.inc

[John J. L. <jj...@po...>]

On Tue, 16 Jul 2002, Rene Dudfield wrote:
> I'm going to look at your problem after work today.

Oops, sorry for my slow reply -- infrequent access to net ATM.

> Just wanted to get a few bits of info.
>
> Are you using the cvs version, or the release tar
> ball?

Release tarball.

> Are you generating the swig wrappers again?  If so
> which version of swig are you using? Don't think you
> are from your post, just making sure :)

I'm not regenerating the SWIG wrappers.

> I'm in the process of changing the cvs version to use
> newer swig versions, and it currently isn't entirely
> working.
>
> The release tarball on the other hand should compile
> with python setup.py build out of the box, as it

That's what I did.

> doesn't regenerate the swig wrappers.  My box at home
> is a duron running debian unstable, it compiled the

I'm using debian 2.2r0.

> release tar ball last time I tried it(some months
> ago).  I haven't tried it with mesa though.

Are there any other free sort-of-replacements for GL?  I presume you're
using an SGI-blessed commercial OpenGL implementation?

> Anyway... I'll write back when I install mesa/compile
> at home.

Thanks


John

Re: [PyOpenGL-Users] Antialiasing...

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

On Wednesday, July 17, 2002, at 01:40 , Magnus Lie Hetland wrote:

> Hi!
>
> I'm sorry if this is a standard newbie question, but... Is there an
> easy way to get antialiasing with OpenGL? I've scoured the Net and
> looked in the red book, but thus far it all seems a bit complicated to
> me... I haven't learned too much about the API yet, and I was hoping
> maybe there was just a standard recipe for turning on anti-aliasing in
> general... Especially for filled polygons, I guess; I'd like to avoid
> jagged outlines on my (filled) 3D objects...

Look at GlEnable(GL_POLYGON_SMOOTH) (or GL_POINT_SMOOTH, GL_LINE_SMOOTH).

There's also GlHint(GL_POLYGON_SMOOTH_HINT, ...) and friends whereby you 
can influence how the antialiasing is done.

The result of this may not always be nice enough (as each polygon is 
antialiases "by itself"), then you'll have to look at using the 
accumulation buffer or some such. But I would start with the simple 
GlEnable() call above:-)
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[PyOpenGL-Users] Antialiasing...

[Magnus L. H. <ma...@he...>]

Hi!

I'm sorry if this is a standard newbie question, but... Is there an
easy way to get antialiasing with OpenGL? I've scoured the Net and
looked in the red book, but thus far it all seems a bit complicated to
me... I haven't learned too much about the API yet, and I was hoping
maybe there was just a standard recipe for turning on anti-aliasing in
general... Especially for filled polygons, I guess; I'd like to avoid
jagged outlines on my (filled) 3D objects...

- Magnus, new and eager PyOpenGL user :)

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

Re: [PyOpenGL-Users] Parse error in GLU.__init__.0102.inc

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

Hi,

I'm going to look at your problem after work today.

Just wanted to get a few bits of info.

Are you using the cvs version, or the release tar
ball?

Are you generating the swig wrappers again?  If so
which version of swig are you using? Don't think you
are from your post, just making sure :)


I'm in the process of changing the cvs version to use
newer swig versions, and it currently isn't entirely
working.  

The release tarball on the other hand should compile
with python setup.py build out of the box, as it
doesn't regenerate the swig wrappers.  My box at home
is a duron running debian unstable, it compiled the
release tar ball last time I tried it(some months
ago).  I haven't tried it with mesa though.

Anyway... I'll write back when I install mesa/compile
at home.




 --- "John J. Lee" <jj...@po...> wrote: > I built
and installed Mesa 4.0.3 (with GLUT 3.7),
> and then tried
> compiling PyOpenGL 2.0.0.44 (with the same gcc that
> I used to compile
> Python).  Here are the system details:
> 
> >>> print sys.platform
> linux2
> >>> print sys.version
> 2.2 (#1, Jan  6 2002, 16:57:53)
> [GCC 2.95.2 20000220 (Debian GNU/Linux)]
> >>> print distutils.__version__
> 1.0.3
> 
> The examples from Mesa work fine.  However, I get a
> parse error a little
> while after starting a python setup.py build (not
> build_w):
> 


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

[PyOpenGL-Users] Parse error in GLU.__init__.0102.inc

[John J. L. <jj...@po...>]

I built and installed Mesa 4.0.3 (with GLUT 3.7), and then tried
compiling PyOpenGL 2.0.0.44 (with the same gcc that I used to compile
Python).  Here are the system details:

>>> print sys.platform
linux2
>>> print sys.version
2.2 (#1, Jan  6 2002, 16:57:53)
[GCC 2.95.2 20000220 (Debian GNU/Linux)]
>>> print distutils.__version__
1.0.3

The examples from Mesa work fine.  However, I get a parse error a little
while after starting a python setup.py build (not build_w):

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DGLX_PLATFORM -DNUMERIC -I/usr/include -I/usr/local/include -I/usr/X11$6/include -I/usr/local/include/python2.2/Numeric -Isrc/gle/src -I/usr/local/include/python2.2 -c src/interface/GLU.__init___.c -o build/temp.linux-i586-2.2/GLU.__init___.o
In file included from src/interface/GLU.__init___.c:9:
src/interface/GLU.__init___.0102.inc: In function `SWIG_ConvertPtr':
src/interface/GLU.__init___.0102.inc:361: warning: suggest explicit braces to avoid ambiguous `else'
src/interface/GLU.__init___.0102.inc:364: warning: suggest explicit braces to avoid ambiguous `else'
src/interface/GLU.__init___.0102.inc:380: warning: suggest explicit braces to avoid ambiguous `else'
src/interface/GLU.__init___.0102.inc: At top level:
src/interface/GLU.__init___.0102.inc:676: warning: function declaration isn't a prototype
src/interface/GLU.__init___.0102.inc:722: warning: function declaration isn't a prototype
src/interface/GLU.__init___.0102.inc:770: warning: function declaration isn't a prototype
src/interface/GLU.__init___.0102.inc:1007: parse error before `GLUquadric'
src/interface/GLU.__init___.0102.inc:1007: warning: no semicolon at end of struct orunion
src/interface/GLU.__init___.0102.inc:1010: parse error before `}'


The problem seems to be src/interface/GLU.__init__.0102.inc , but
there's nothing obviously wrong with it.  This file is 120k or so, but
here is a snippet of it (the first parse error occurs on the line
'GLUquadric *obj;'):

[...]
 static char _doc_gluBuild2DMipmapsui[] = "gluBuild2DMipmapsui(target, components, format, pixels) -> None";
 static char _doc_gluBuild2DMipmapsf[] = "gluBuild2DMipmapsf(target, components, format, pixels) -> None";

void CALLBACK throwGLUerror(GLenum code)
{
        PyErr_SetGLUerror(code);
}


typedef struct
{
        PyObject_HEAD
        GLUquadric *obj;
        PyObject *begin, *beginData, *edgeFlag, *edgeFlagData, *vertex, *vertexData;
        PyObject *end, *endData, *combine, *combineData;
} PyGLUquadric;


PyGLUquadric *currentQuadric = NULL;

static void PyGLUquadric_Del(PyObject *self)
{
        gluDeleteQuadric(((PyGLUquadric*)self)->obj);

    PyObject_Del(self);
}


PyTypeObject PyGLUquadric_Type =
{
    PyObject_HEAD_INIT(0)
    0,                                                  /* ob_size */
    "GLUquadric",                       /* tp_name */
[...]


Thanks for any help


John

[PyOpenGL-Users] [ pyopengl-Feature Requests-455686 ] Demonstration of py2exe with PyOpenGL

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

Feature Requests item #455686, was opened at 2001-08-27 03:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=455686&group_id=5988

Category: Demo
Group: v2.0
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Mike C. Fletcher (mcfletch)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: Demonstration of py2exe with PyOpenGL

Initial Comment:
A demonstration/document describing how to create 
PyOpenGL exe's with py2exe would be useful for some 
users (this request is based on a post to the pygame 
mailing list).

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2002-07-10 17:41

Message:
Logged In: YES 
user_id=34901

Okay, just checked in a document to the website project that
explains basically the same thing as I just posted to the
PyOpenGL users list, which is functional recipes for both
PyOpenGL and OpenGLContext applications using py2exe.

Tested with GLUT, GL, GLU, Togl, and
OpenGLContext.wxtestingcontext, which should cover most
common uses likely to cause problems.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-10 15:35

Message:
Logged In: NO 

would be realllllyyy nice, if that could be donw

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

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-10-05 10:24

Message:
Logged In: YES 
user_id=21784

This looks like it works out of the box, but its a bit 
greedy about the modules that it includes due to the fact 
that OpenGL/__init__.py imports pygame, wxPython, etc. to 
support the info script.  I've fixed this in CVS.

Users will run into problems if their script uses both 
OpenGL.GL and OpenGL.GLU since py2exe just tosses all pyds 
into same directory and a name collision will then occur 
since their names are both __init___.pyd

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

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

[PyOpenGL-Users] PyOpenGL and OpenGLContext with py2exe, tentative recipes

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

Okay, here's the basic recipe I'm using for OpenGL scripts using GL, 
GLU, WGL and GLUT:

Basic (ugly, but working) approach:

	Use --excludes=OpenGL flag to py2exe:
		setup_gldraw py2exe -k --excludes=OpenGL
this prevents the OpenGL package, or any sub-module from being included. 
  This avoids the conflicts with the various __init__.* files.

	import Tkinter directly in your script if you use OpenGL.Tk (many scripts 
don't explicitly import Tkinter, they just use the environment from 
OpenGL.Tk, which will be excluded by the step above, so Tkinter won't 
get packaged up.  Alternately use an --includes=Tkinter flag for py2exe

	copy (a subset of) the OpenGL package into your distribution directory 
(see below)...


OpenGL Package Subset:

	The subset can exclude the scripts, demo and doc directories.

	For considerable space savings if you're not using an extension, you can 
exclude that extension's directory from OpenGL/GL/ (about 8MB savings on 
disk for systems with inefficient support for small files and no used 
extensions).

	If you don't want TOGL support, you can exclude  that too.

	If you don't want WGL support, you can exclude that too (same for GLU, 
GLUT, etceteras).

	If you really don't care about space, just include the whole OpenGL package.


It would be nice if py2exe had a way to specify _how_ to deal with a 
particular included module/package, instead of just specifying "include 
or exclude", so that we could say "if OpenGL.GL is imported, include 
this directory in the final dist", but oh well.


OpenGLContext:

	OpenGLContext is a much simpler recipe.  Basically, you have to 
explicitly import/include the _concrete_ Context class you want to use 
(because testingcontext tries to load your "favourite" context using an 
__import__ statement).  So, add:

	from OpenGLContext import wxtestingcontext
or
	from OpenGLContext import gluttestingcontext
or
	from OpenGLContext import pygametestingcontext

to your script, depending on which context you want to use.  (You could 
alternately use an --includes=OpenGLContext.wxtestingcontext for the 
py2exe command if you prefer).  You can import/include all of them if 
you want to include all of them (and all of the underlying libraries) 
for your app for some reason (such as a command-line switch that lets 
someone choose among them.

I'd be happy if anyone had a better recipe for the PyOpenGL package, but 
the one above should work for now (though, of course, it doesn't help at 
all with getting OpenGL itself installed on older machines, that's an 
installer issue).

Enjoy yourselves,
Mike

[PyOpenGL-Users] py2exe installer

[Lucian <ge...@gm...>]

Hello pyopengl-users,

  has anyone successful compiled pyopengl to a transportable exe file?

  Can one give me advice on that?

  Lucian

-- 
Best regards,
 Lucian                          mailto:ge...@gm...

[PyOpenGL-Users] [ pyopengl-Feature Requests-455686 ] Demonstration of py2exe with PyOpenGL

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

Feature Requests item #455686, was opened at 2001-08-27 00:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=455686&group_id=5988

Category: Demo
Group: v2.0
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Tarn Weisner Burton (twburton)
Summary: Demonstration of py2exe with PyOpenGL

Initial Comment:
A demonstration/document describing how to create 
PyOpenGL exe's with py2exe would be useful for some 
users (this request is based on a post to the pygame 
mailing list).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-10 12:35

Message:
Logged In: NO 

would be realllllyyy nice, if that could be donw

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

Comment By: Tarn Weisner Burton (twburton)
Date: 2001-10-05 07:24

Message:
Logged In: YES 
user_id=21784

This looks like it works out of the box, but its a bit 
greedy about the modules that it includes due to the fact 
that OpenGL/__init__.py imports pygame, wxPython, etc. to 
support the info script.  I've fixed this in CVS.

Users will run into problems if their script uses both 
OpenGL.GL and OpenGL.GLU since py2exe just tosses all pyds 
into same directory and a name collision will then occur 
since their names are both __init___.pyd

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

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

[PyOpenGL-Users] Re: [wxPython] Re: pyopengl compiling

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

Switched from wxPython list...

Lucian is trying to build a wxPython + PyOpenGL application into a 
stand-alone app using Py2exe or Installer.  He's discovered that the 
PyOpenGL packages are mis-behaving when packaged.

By the look of it, Tarn's directory structure (where he has both 
__init__.py and __init__.pyd (or __init__.so) in the packages) is 
causing the import hooks in Py2exe to go mad.

I'm guessing you could exclude the entire OpenGL package, then include 
it manually in the output directory, with a script to add it to the 
path.  That's just a guess, but it sounds plausible.  I know I've done 
something similar with an app using Installer (more than a year ago, for 
an old employer) which wanted certain packages not to be "built-in" to 
the executable.

Suppose I should spend some time this afternoon trying to build a Py2exe 
app... sigh, wasn't what I needed to do.

Okay, will talk later,
Mike


Robin Dunn wrote:
<snip partial quotes of the discussion>
> Have you tried asking the PyOpenGL folks?  Somebody somewhere must have
> tried using py2exe or Installer on a PyOpenGL app and have solved this
> problem.
...

Re: [PyOpenGL-Users] Re: my latest swigging update

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

oops for the cvs changes, there is an error with
__numeric_support__ not being put from GL.__init__.so
to GL.__init__.py.  

You can comment out the import in OpenGL.__init__.py
for it to work until this problem is fixed.

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

[PyOpenGL-Users] Re: my latest swigging update

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

 --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
I think Tarn called the tag b45 or b44, but I'd
> suggest making your own 
> tag across the whole repository before checking in,
> just to be sure. 
> Make it something explicit and descriptive
> (something like 
> v2_0_0_44_final or before_swig_1_3_10_update) so
> that we know why it's 
> there in the future.  Tags are cheap, might as well
> use them :) .
> 

Ok, I've tagged it "before_swig_1_3_13_update" from a
fresh check out.  Then committed the changes.

I noticed in the cvsbook that you can retrieve based
on date also.  So we could grab the code from cvs
around the time of the last release with that too :)


> I'd do it myself, but WinCVS is telling me there's
> someone doing a 
> man-in-the-middle attack between myself and
> SourceForge at the moment 
> (which is weird, 'cause I've been using it all night
> w/out catching them 
> before, so might just be a mis-config, but oh well).
> 

Strange.  Hopefully everything is ok with their
servers.

> I'll try a download, compile, test cycle tomorrow
> evening (well, guess 
> that's later today, really).
> 

That would be good.  I haven't been able to get it
working with windows/mingw yet, or give it a good
test.    Been a while since I've used mingw, so I'm
still trying to get opengl working with it.

Hopefully the changes mostly work :)  I'll give it
some more testing tomorrow, and try and fix up
problems we find.



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

[PyOpenGL-Users] Re: my latest swigging update

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

I think Tarn called the tag b45 or b44, but I'd suggest making your own 
tag across the whole repository before checking in, just to be sure. 
Make it something explicit and descriptive (something like 
v2_0_0_44_final or before_swig_1_3_10_update) so that we know why it's 
there in the future.  Tags are cheap, might as well use them :) .

I'd do it myself, but WinCVS is telling me there's someone doing a 
man-in-the-middle attack between myself and SourceForge at the moment 
(which is weird, 'cause I've been using it all night w/out catching them 
before, so might just be a mis-config, but oh well).

I'll try a download, compile, test cycle tomorrow evening (well, guess 
that's later today, really).

Enjoy yourself,
Mike

Rene Dudfield wrote:
> Hello,
> 
> I've converted pyopengl to use the new swig (ie
> 1.3.13).
> 
> Unfortunately I don't think it will work with versions
> of swig <= 1.3.10.  Does this matter too much?  I
> don't think it does :)
> 
> Should I put my changes in the cvs?  Has the last
> release been marked in some way?
> 
> 
> Now to try and get pyopengl to compile with mingw.
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 


-- 
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] How to make documentation?

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

 --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
If I'm not mistaken, Tarn was using the DocBook DTD,
> here's his comments 
> from an old email... the build process has
> apparently formalised 
> somewhat since then:
> 
> > It is possible to generate your own copy of the
> docs sent out with the
> > distribution.  To do so you need Saxon and DocBook
> XSL.  Its probably not
> > worth it though since the dist includes HTML and
> PDF pregenerated.
> > 
> > Right now I am the only one who can build the new
> docs, mostly because I
> > haven't formalized the build process.  It's also
> slow as hell.  Takes about
> > an hour to generate the docs for the website. 
> 
> I've never done it myself since this new system came
> into use.  I'm 
> assuming that with those two pieces installed (Saxon
> is an XSL 
> processor, if I'm recalling correctly) and
> configured in the environment 
> the process should just go ahead and run. (But may
> take an hour, as 
> noted above).
> 


Thanks for the info, I'll look into those packages and
try and figure it out.



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

[PyOpenGL-Users] Re: [PyOpenGL-Devel] How to make documentation?

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

If I'm not mistaken, Tarn was using the DocBook DTD, here's his comments 
from an old email... the build process has apparently formalised 
somewhat since then:

> It is possible to generate your own copy of the docs sent out with the
> distribution.  To do so you need Saxon and DocBook XSL.  Its probably not
> worth it though since the dist includes HTML and PDF pregenerated.
> 
> Right now I am the only one who can build the new docs, mostly because I
> haven't formalized the build process.  It's also slow as hell.  Takes about
> an hour to generate the docs for the website. 

I've never done it myself since this new system came into use.  I'm 
assuming that with those two pieces installed (Saxon is an XSL 
processor, if I'm recalling correctly) and configured in the environment 
the process should just go ahead and run. (But may take an hour, as 
noted above).

HTH,
Mike

Rene Dudfield wrote:
> Hello.
> 
> "python setup.py build_doc" gives me a message:
> 
> warning: build_doc: Can't generate docs because
> SAXON_HOME, DOCBOOK_XSL_HOME, WEBEQ_HOME or
> warning: build_doc: RESOLVER_HOME environment variable
> is not set.  Will just use existing docs.
> 
> 
> How do I set up the necessary programs?
> 
> any help appreciated :)
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
> 


-- 
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] parse big list

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

 --- Strato <fl...@id...> wrote: > I
apologize for sending the wrong file. I hadn't
> noticed that I sent you a
> compressed one, but the clearly readable one is
> about 3MB. If you would like
> to see it, or if it would be enough to see a part,
> please tell me.
> Until now I haven't found out how many sides a
> polygon has.
> 

I'm sorry, I don't have enough spare time to look
through the file at the moment.  I'll have a look on
the weekend if you still need it.

good luck

> 
> ----- Original Message -----
> From: "Strato" <fl...@id...>
> To: "Rene Dudfield" <il...@ya...>;
> <pyo...@li...>
> Sent: Monday, September 30, 2002 8:00 PM
> Subject: Re: [PyOpenGL-Users] parse big list
> 
> 
> > Hi again,
> > helped a lot, fr drawing I put the file by mail.
> Not the same as I
> mentioned
> > before, to keep it small, but the file format is
> the same. At first only
> the
> > parts that describe the shape and the two textures
> are from interest. The
> > part about the lights and so on has to wait.
> > I tried "glVertex3f(x, y, z)"
> > and so on. before this the color was set.
> > Actually I don't now how many sides a polygon has.
> I'll try to figure it
> > out.
> >
> >
> > ----- Original Message -----
> > From: "Rene Dudfield" <il...@ya...>
> > To: "Strato" <fl...@id...>;
> <pyo...@li...>
> > Sent: Sunday, June 30, 2002 2:59 PM
> > Subject: Re: [PyOpenGL-Users] parse big list
> >
> >
> > > Hello.
> > >
> > >  --- Strato <fl...@id...> wrote: > The
> > > import problem got solved (Thanks!) but there is
> > > > one thing I have again.
> > > > I want to read in a file and used
> "file("E111B.s",
> > > > "R")
> > > > and then how do I get a long list inside this
> file
> > > > "point (x, y, z)"
> > > > .....
> > > >
> > >
> > > So the file format is like this?:
> > >
> > > """point(1., 3., 3.9893824234)
> > > point(2., 2., 3.9893824234)
> > > point(7.2, 2.12, 3.9893824234)
> > > point(5.31, 2.32, 3.9893824234)"""
> > >
> > > How do you know how many sides each polygon has?
> > >
> > >
> > > You can read a file like this:
> > >
> > > f = open("E111B.s","r")
> > > lines = f.readlines()
> > >
> > > # if the last line does not have a newline at
> the end,
> > > #  add one.
> > > if lines[-1][-1] != "\n":
> > >   lines[-1] += "\n"
> > >
> > > points = []
> > >
> > > for line in lines:
> > >   # get rid of the "point(" and ")\n"
> > >   point = line[len("point("):-2]
> > >
> > >   # convert the parts into floats
> > >   points.append( map(float, point.split(",")) )
> > >
> > >
> > > For drawing we need to know how many points make
> up a
> > > polygon.
> > >
> > >
> > > Good luck!
> > >
> > >
> > > > read into a variable and then do for every
> point a
> > > > glVertex3f to draw the
> > > > shape. (of an engine)
> > > > If I have something valuable done I'll tell
> you
> > > > probably open an sourceforge
> > > > project
> > > >
> > > > Florian Idelberger
> > > >
> > > > P.S.: If you want the file as an example, tell
> me
> > > > and note if I could send
> > > > it to the list or not. (43,9kb)
> > > >
> > > >
> > > >
> > >
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Everything you'll ever need on one web page
> > > from News and Sport to Email and Music Charts
> > > http://uk.my.yahoo.com
> > >
> >
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: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 

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

Re: [PyOpenGL-Users] parse big list

[Strato <fl...@id...>]

I apologize for sending the wrong file. I hadn't noticed that I sent you a
compressed one, but the clearly readable one is about 3MB. If you would like
to see it, or if it would be enough to see a part, please tell me.
Until now I haven't found out how many sides a polygon has.


----- Original Message -----
From: "Strato" <fl...@id...>
To: "Rene Dudfield" <il...@ya...>;
<pyo...@li...>
Sent: Monday, September 30, 2002 8:00 PM
Subject: Re: [PyOpenGL-Users] parse big list


> Hi again,
> helped a lot, fr drawing I put the file by mail. Not the same as I
mentioned
> before, to keep it small, but the file format is the same. At first only
the
> parts that describe the shape and the two textures are from interest. The
> part about the lights and so on has to wait.
> I tried "glVertex3f(x, y, z)"
> and so on. before this the color was set.
> Actually I don't now how many sides a polygon has. I'll try to figure it
> out.
>
>
> ----- Original Message -----
> From: "Rene Dudfield" <il...@ya...>
> To: "Strato" <fl...@id...>;
<pyo...@li...>
> Sent: Sunday, June 30, 2002 2:59 PM
> Subject: Re: [PyOpenGL-Users] parse big list
>
>
> > Hello.
> >
> >  --- Strato <fl...@id...> wrote: > The
> > import problem got solved (Thanks!) but there is
> > > one thing I have again.
> > > I want to read in a file and used "file("E111B.s",
> > > "R")
> > > and then how do I get a long list inside this file
> > > "point (x, y, z)"
> > > .....
> > >
> >
> > So the file format is like this?:
> >
> > """point(1., 3., 3.9893824234)
> > point(2., 2., 3.9893824234)
> > point(7.2, 2.12, 3.9893824234)
> > point(5.31, 2.32, 3.9893824234)"""
> >
> > How do you know how many sides each polygon has?
> >
> >
> > You can read a file like this:
> >
> > f = open("E111B.s","r")
> > lines = f.readlines()
> >
> > # if the last line does not have a newline at the end,
> > #  add one.
> > if lines[-1][-1] != "\n":
> >   lines[-1] += "\n"
> >
> > points = []
> >
> > for line in lines:
> >   # get rid of the "point(" and ")\n"
> >   point = line[len("point("):-2]
> >
> >   # convert the parts into floats
> >   points.append( map(float, point.split(",")) )
> >
> >
> > For drawing we need to know how many points make up a
> > polygon.
> >
> >
> > Good luck!
> >
> >
> > > read into a variable and then do for every point a
> > > glVertex3f to draw the
> > > shape. (of an engine)
> > > If I have something valuable done I'll tell you
> > > probably open an sourceforge
> > > project
> > >
> > > Florian Idelberger
> > >
> > > P.S.: If you want the file as an example, tell me
> > > and note if I could send
> > > it to the list or not. (43,9kb)
> > >
> > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> >
>

Re: [PyOpenGL-Users] parse big list

[Strato <fl...@id...>]

Hi again,
helped a lot, fr drawing I put the file by mail. Not the same as I mentioned
before, to keep it small, but the file format is the same. At first only the
parts that describe the shape and the two textures are from interest. The
part about the lights and so on has to wait.
I tried "glVertex3f(x, y, z)"
and so on. before this the color was set.
Actually I don't now how many sides a polygon has. I'll try to figure it
out.


----- Original Message -----
From: "Rene Dudfield" <il...@ya...>
To: "Strato" <fl...@id...>; <pyo...@li...>
Sent: Sunday, June 30, 2002 2:59 PM
Subject: Re: [PyOpenGL-Users] parse big list


> Hello.
>
>  --- Strato <fl...@id...> wrote: > The
> import problem got solved (Thanks!) but there is
> > one thing I have again.
> > I want to read in a file and used "file("E111B.s",
> > "R")
> > and then how do I get a long list inside this file
> > "point (x, y, z)"
> > .....
> >
>
> So the file format is like this?:
>
> """point(1., 3., 3.9893824234)
> point(2., 2., 3.9893824234)
> point(7.2, 2.12, 3.9893824234)
> point(5.31, 2.32, 3.9893824234)"""
>
> How do you know how many sides each polygon has?
>
>
> You can read a file like this:
>
> f = open("E111B.s","r")
> lines = f.readlines()
>
> # if the last line does not have a newline at the end,
> #  add one.
> if lines[-1][-1] != "\n":
>   lines[-1] += "\n"
>
> points = []
>
> for line in lines:
>   # get rid of the "point(" and ")\n"
>   point = line[len("point("):-2]
>
>   # convert the parts into floats
>   points.append( map(float, point.split(",")) )
>
>
> For drawing we need to know how many points make up a
> polygon.
>
>
> Good luck!
>
>
> > read into a variable and then do for every point a
> > glVertex3f to draw the
> > shape. (of an engine)
> > If I have something valuable done I'll tell you
> > probably open an sourceforge
> > project
> >
> > Florian Idelberger
> >
> > P.S.: If you want the file as an example, tell me
> > and note if I could send
> > it to the list or not. (43,9kb)
> >
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>

Re: [PyOpenGL-Users] parse big list

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

Hello.

 --- Strato <fl...@id...> wrote: > The
import problem got solved (Thanks!) but there is
> one thing I have again.
> I want to read in a file and used "file("E111B.s",
> "R")
> and then how do I get a long list inside this file
> "point (x, y, z)"
> .....
> 

So the file format is like this?:

"""point(1., 3., 3.9893824234)
point(2., 2., 3.9893824234)
point(7.2, 2.12, 3.9893824234)
point(5.31, 2.32, 3.9893824234)"""

How do you know how many sides each polygon has?


You can read a file like this:

f = open("E111B.s","r")
lines = f.readlines()

# if the last line does not have a newline at the end,
#  add one.
if lines[-1][-1] != "\n":
  lines[-1] += "\n"

points = []

for line in lines:
  # get rid of the "point(" and ")\n"
  point = line[len("point("):-2]

  # convert the parts into floats
  points.append( map(float, point.split(",")) )
  

For drawing we need to know how many points make up a
polygon.


Good luck!


> read into a variable and then do for every point a
> glVertex3f to draw the
> shape. (of an engine)
> If I have something valuable done I'll tell you
> probably open an sourceforge
> project
> 
> Florian Idelberger
> 
> P.S.: If you want the file as an example, tell me
> and note if I could send
> it to the list or not. (43,9kb)
> 
> 
> 

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

[PyOpenGL-Users] parse big list

[Strato <fl...@id...>]

The import problem got solved (Thanks!) but there is one thing I have again.
I want to read in a file and used "file("E111B.s", "R")
and then how do I get a long list inside this file "point (x, y, z)"
.....

read into a variable and then do for every point a glVertex3f to draw the
shape. (of an engine)
If I have something valuable done I'll tell you probably open an sourceforge
project

Florian Idelberger

P.S.: If you want the file as an example, tell me and note if I could send
it to the list or not. (43,9kb)