pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Failure to build on Linux

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

On Thursday 18 December 2003 02:34, Rene Dudfield wrote:
> downgrade to swig 1.3.13 if you want it to work.  Or install 1.3.13
> somewhere not in your main path, and have your pyopengl build have it in
> its path before the normal swig path.
>
> I just started working on making pyopengl work with 1.3.19.  However I'm
> having trouble with the GLU wrapper segfaulting, so it may take a while
> to debug.
>
> Anyone allready got pyopengl working with 1.3.19?

Any chance this is remedied yet?


     Richard

[PyOpenGL-Users] Work-around for Togl on Linux

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

Craig posted this to the cs488 course's site regarding how to build 
(with Togl) on RedHat Linux.  There was one response saying the 
instructions didn't work for one other person, but it apparently worked 
on at least the one machine.

Enjoy yourselves,
Mike

-------- Original Message --------
Subject: PyOpenGL Linux goodness...
Date: Thu, 15 Jan 2004 14:54:45 -0500
From: Craig S. Kaplan <cs...@mu...>
Organization: University of Waterloo
Newsgroups: uw.cs.cs488

Hi everyone,

One of your brave fellow students provided her laptop in what
proved to be a successful PyOpenGL linux building experience.
Here are some simple instructions.  They should work for, say,
RedHat 8/9 and Python 2.2 or 2.3.  I'll assume you're using
Python2.2 for these instructions -- the substitutions for 2.3
should be obvious.

  1. tar xzvf PyOpenGL-2.0.1.07.tar.gz
     cd PyOpenGL-2.0.1.07
     python setup.py install

At this point we'll get to that mysterious "can't find Tcl 8.1"
error that some of you have experienced.  But a lot of the
files we need have already been installed.

  4. Edit the file "setup/togl_setup.py".  Look for the lines

      # make package index for tcl/tk
      if not dry_run:

     Change "if not dry_run:" to "if 0:" to disable the block of
     code that follows.

  5. Edit the file
     "/usr/lib/python2.2/site-packages/OpenGL/Tk/linux2-tk8.3/pkgIndex.tcl"
     (the name may be slightly different for you).  Add the following lines
     to the end of it:

------------ CUT HERE --------------
if {![package vsatisfies [package provide Tcl] 8]} {return}
package ifneeded Togl 1.6.0 \
     [list load [file join $dir Togl.so] Togl]
------------ CUT HERE --------------

  6. Go back to the PyOpenGL-2.0.1.07 directory and re-run
     "python setup.py install".  This time the installation should
     run until the end.

  7. Don't try to test that it works from within the PyOpenGL
     source directory -- it fails for some reason.  Switch to
     a different directory and try "from OpenGL.Tk import *"
     from within a Python session.  You shouldn't get any errors,
     and a small window should appear on the screen.

Good luck to those of you who are still trying to make this
work.  Let me know about continuing problems.

-- 
Craig S. Kaplan                     ``Evolution drives a steamroller,
School of Computer Science          disguised as a stationary bike.''
University of Waterloo              http://www.cgl.uwaterloo.ca/~csk/

Re: [PyOpenGL-Users] Bus Error on GtkGLArea using Fink on OS X 10.2

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

GtkGLArea() is provided by Gtk, so if you're not calling anything else 
(i.e. PyOpenGL functions) the error is *likely* going to be somewhere 
over on the Gtk side.  To the best of my knowledge PyGTK doesn't know 
anything about PyOpenGL, so wouldn't be calling back into it.

Good luck,
Mike

Rick Muller wrote:

> I'm getting a bus error when I call GtkGLArea() under Fink on 
> Macintosh OS X 10.2. I can't tell whether this is an OpenGL error or a 
> Gtk error, and I'm posting here to see whether it rings any bells with 
> other users. Has anyone else seen anything similar? Does anyone have 
> any suggested work-arounds?
>
> Thanks in advance,
>
> Rick
>
> Rick Muller
> rm...@sa...
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

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

[PyOpenGL-Users] Bus Error on GtkGLArea using Fink on OS X 10.2

[Rick M. <rm...@sa...>]

I'm getting a bus error when I call GtkGLArea() under Fink on Macintosh 
OS X 10.2. I can't tell whether this is an OpenGL error or a Gtk error, 
and I'm posting here to see whether it rings any bells with other 
users. Has anyone else seen anything similar? Does anyone have any 
suggested work-arounds?

Thanks in advance,

Rick

Rick Muller
rm...@sa...

[PyOpenGL-Users] Custom Marketing

[Neves <Loo...@29...>]

E-mail is the fastest growing marketing tool.

We offer E-mail Marketing with quality service and the lowest prices.

1. Targeted E-mail Addresses

We can provide targeted e-mail addresses you need, which are compiled 
only on your order. We will customize your customer e-mail addresses.

* We have millions of e-mail addresses in a wide variety of categories.

2. Send out Targeted E-mails for you

We can send your e-mail message to your targeted customers! We will
customize your email addresses and send your message for you.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to:  Http://www.Marketing-Savant.com

Looking forward to serving you, and your business needs!


Regards!

Tony Madu
Marketing Support
www.Marketing-Savant.com
Sa...@Ma...

*************************************************************************
To remove your address from list:
http://quicktell.net/responder/delist.cgi/q/3/17134747/142960
*************************************************************************

[PyOpenGL-Users] PyOpenGL 2.0.1.07, MacOSX 10.3, python2.3 and aqua, problem with Line demo.

[Alexandre G. <gi...@sc...>]

Hi,
I am try to run the deom/tom/Line.py which use Togl on a Mac G5 with a 
ATI card.
I compile a version of Togl that run with Aqua.
I install a binary distribtuion of PyOpenGL 2.0.1.07, Tkinter for python2.3

When I run the demo, I see a 400*400 widows open with a little black 
windows which seems to be the opengl context. If I resize my frame to be 
the same size of the black square I can see the line.
  But then if I try to scale the windows, the OpenGL context don't get 
resize.
It's seems that the glViewport don't get update correctly.

Anyone has seen that problem? Has anyone be able to run the Demo on 
MacOSX 10.3 using aqua and not a Xserver?

Thanks
Alex
-- 
   o Alexandre Gillet               email: gi...@sc...
  /  The Scripps Research Institute,
o   Dept. Molecular Biology,  MB-5,
  \  10550  North Torrey Pines Road,
   o La Jolla,  CA 92037-1000,  USA.
  /  tel: (858) 784-2053
o   fax: (858) 784-2860

Re: [PyOpenGL-Users] glDeleteTextures crash?

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

Proper place for this discussion is probably on the project's 
bug-tracker, so that the bug and history are managed properly and it 
doesn't fall through the cracks.  Anyway, I just tried the file on Win2K 
w/ PyOpenGL 2.0.1.07 on Python 2.2.3 and Numpy 23.1 and was unable to 
provoke a crash of any description.  Are you running Linux or something 
similar?  What is the actual crash, a Python traceback, a memory-access 
failure or a core-dump?  What versions of PyOpenGL and Python are you 
running?

Good luck,
Mike

fl...@go... wrote:

>I was writing somethign to manage textures, and when trying to free up some
>unused textures, it seems to cause a crash.
>
>I've attatched a shortened file that makes it crash.
>(requires pyopengl and pygame)
>
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] glDeleteTextures crash?

[<fl...@go...>]

I was writing somethign to manage textures, and when trying to free up some
unused textures, it seems to cause a crash.

I've attatched a shortened file that makes it crash.
(requires pyopengl and pygame)

[PyOpenGL-Users] visual c++ runtime error

[SGD <vib...@ce...>]

 
Hi,
I just downloaded python2.3.3 and pyopengl 2.0.1.07, and when ever I try
to run any of the examples I get this error; 
 
"Microsoft Visual C++ Runtime LIbrary
 
Runtime Error!
Program c:\python23\pythonw.exe
This application has requested the runtime to terminate it in an unusual
way. Please contact the application's support team for more
information."
 
I only seem to get this error with pyopengl. Could someone please help
me resolve this issue?
 
WinXP pro
 
 
Thanks,
Steven
 
 

[PyOpenGL-Users] visual c++ runtime error

[SGD <vib...@ce...>]

Hi,
I just downloaded python2.3.3 and pyopengl 2.0.1.07, and when ever I try
to run any of the examples I get this error; 
 
"Microsoft Visual C++ Runtime LIbrary
 
Runtime Error!
Program c:\python23\pythonw.exe
This application has requested the runtime to terminate it in an unusual
way. Please contact the application's support team for more
information."
 
I only seem to get this error with pyopengl. Could someone please help
me resolve this issue?
 
WinXP pro
 
 
Thanks,
Steven
 
 

Re: [PyOpenGL-Users] Collision Detections

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

On Friday 02 January 2004 12:43, Yannick Gingras wrote:
> On January 1, 2004 20:00, Richard Jones wrote:
> > Note that any implementation using map() will incur a function call
> > overhead, which is slow if you're not using a builtin function. Use a f=
or
> > loop instead
>
> Strange, I thought that the map() version was alway the more efficient
> as long as the lambda form was not invloved...
>
> Sure I can kick most of my map()s to rewrite in-line.  I like to
> substract vectors like that:
>
>   v1 =3D (0.0, 0.0,-0.5)
>   v2 =3D (1.0, 0.0, 0.5)
>   v3 =3D map(sub, v1, v2)

Well, the performance of that approach depends a lot on what "sub" is. If i=
t's=20
a function defined by you in Python, it's going to be as slow as a lambda=20
call. If it's a Python builtin function (say, operator.sub) then it'll be=20
very fast.

Note that you may want to look into Numeric Python to perform array=20
operations, as they're generally much faster than even using operator.sub (=
as=20
the former is highly optimised, whereas the latter is as general as it can=
=20
be).


> Thanks for the pointers.  I never tried to subdivide my world into
> sectors, I guess it's time.

Subdividing and bounds-checking are definitely worth the effort before you =
get=20
into code optimisation like we're talking about above :)


    Richard

Re: [PyOpenGL-Users] Collision Detections

[Yannick G. <ygi...@yg...>]

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

On January 1, 2004 20:00, Richard Jones wrote:
> Note that any implementation using map() will incur a function call
> overhead, which is slow if you're not using a builtin function. Use a for
> loop instead

Strange, I thought that the map() version was alway the more efficient
as long as the lambda form was not invloved...

Sure I can kick most of my map()s to rewrite in-line.  I like to
substract vectors like that:

  v1 = (0.0, 0.0,-0.5)
  v2 = (1.0, 0.0, 0.5)
  v3 = map(sub, v1, v2)

And it help to keep some code in 2D and 3D but I guess that there is
no easy win...

Thanks for the pointers.  I never tried to subdivide my world into
sectors, I guess it's time.

- --
Yannick Gingras             "Do not attempt to think or depression may occur"
Coder for OBB : Old-maidish Biflagellate Brahmaputra          -- Jello Biafra
http://OpenBeatBox.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/9MzfZJ8/OobqizMRAo80AKC8Q9o1Tn3pIHjgpS7hSa44CAZabACfSRzH
4vX2p67+B+ZJ66Qyy7yD7KA=
=QhW2
-----END PGP SIGNATURE-----

Re: [PyOpenGL-Users] Collision Detections

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

On Friday 02 January 2004 11:30, Yannick Gingras wrote:
> just a quick question, how do you do your collision detections ?

Personally, I've not implemented such a beast yet. I believe a standard=20
approach is to have several levels of accuracy:

1. for all objects, determine a bounding sphere or box (your preference),
2. group those bounding objects in space using an octree to do broad=20
elimination of objects that are too far apart to bother each other,
3. for all objects that may be close enough, use the bounding object to see=
=20
whether they're close enough to collide,
4. if you're a) using boxes and b) the boxes are a good enough approximatio=
n=20
for you, then you're done, otherwise
5. perform per-plane/line/vertex collision detection.


> I made a few quick tests with pure python implementation based on
> map() and lists to store vertex coordinates. The performance is=20
> understandably really bad, I drop to 1/5 of the FPS I had before
> collision detection.

Note that any implementation using map() will incur a function call overhea=
d,=20
which is slow if you're not using a builtin function. Use a for loop instea=
d.=20
=46or some other optimisation techniques, see:

   http://www.py3d.org/py3d_zwiki/OptimisationHints

and the links from:

   http://simon.incutio.com/archive/2003/10/28/optimisingPython


> Is there a way to implement a decent collision detection in pure
> python or will I have to rely on C++ binding ?

I'd recommend that you first look at your algorithm - it's almost always=20
easier (and better) to optimise your code than to push it off to C or C++.=
=20
I've previously gone down the path of reimplementing core functionality in =
C=20
with some gain, but then a different approach proved to give a much better=
=20
gain, with no C code.

BTW, you don't *need* to use C++, unless you have a particular liking for i=
t.=20
C will do fine.


     Richard

[PyOpenGL-Users] Collision Detections

[Yannick G. <ygi...@yg...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi guys,=20
   just a quick question, how do you do your collision detections ?

I made a few quick tests with pure python implementation based on
map() and lists to store vertex coordinates.  The performance is
understandably really bad, I drop to 1/5 of the FPS I had before
collision detection.

Is there a way to implement a decent collision detection in pure
python or will I have to rely on C++ binding ?

Regards,=20

=2D --=20
Yannick Gingras             "Do not attempt to think or depression may occu=
r"
Coder for OBB : Over-the-hill Bookable Bruin                  -- Jello Biaf=
ra
http://OpenBeatBox.org

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/9LuyZJ8/OobqizMRAsr2AJ9O0KRny3tjeVha32XJ/qxZmIisoACeJspH
goGaNEddae4L6D9hqrp8eAE=3D
=3DqS7u
=2D----END PGP SIGNATURE-----

[PyOpenGL-Users] Togl - python 2.3

[Claire G. <Cla...@ya...>]

Hi, I have some troubles with the togl module.
I can't build PyOpenGL due to my version of Visual Studio (7.0). Python 
was built with version 6 of Visual Studio and extensions need to be 
built with the same version of the compiler, but I haven't this version.
I have togl sources too, but I can't build them for the same reason. So 
I can't do what Mike Fletcher suggests.
So I downloaded and installed the version which doesn't need any 
compilation (PyOpenGL-2.0.1.07.py2.3-numpy23.exe). But when I run a 
module (with Python 2.3.2) which include togl, I have the following 
message :

    Traceback (most recent call last):
      File "C:\Program
    Files\Python23\Lib\site-packages\OpenGL\Demo\tom\checker.py", line
    15, in ?
        from OpenGL.Tk import *
      File
    "C:\PROGRA~1\Python23\Lib\site-packages\OpenGL\Tk\__init__.py", line
    81, in ?
        _default_root.tk.call('package', 'require', 'Togl')
    TclError: can't find package Togl

Does anyone have the same problem, and if so, how can you fix it ?

Thanks

Claire

Re: [PyOpenGL-Users] no blue in texture

[Dave P. <da...@re...>]

I don't have an answer for your color problem, but you ought to consider
using glCopyTexImage2D instead.  It goes straight from the framebuffer
to a texture, without having to read the pixels back first.

e.g.
	glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 0, 0, 128, 128, 0)


On Wed, 24 Dec 2003, Fulko van Westrenen wrote:
>
> After some hard work I have my textures working, but I noticed
> something very funny: There is no blue in my textures
>
> The code looke like this:
> glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB,
>               128,128,0,GL_RGB,GL_UNSIGNED_BYTE,
>               glReadPixels( 0,0,128,128,
>                             GL_RGB, GL_UNSIGNED_BYTE ))
>

-- 
Dave Pape                                               Assistant Professor
dav...@ac...                                 Department of Media Study
http://resumbrae.com/                                 University at Buffalo

[PyOpenGL-Users] no blue in texture

[Fulko v. W. <Ful...@dt...>]

Hello,

After some hard work I have my textures working, but I noticed 
something very funny: There is no blue in my textures

The code looke like this:
glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB,
              128,128,0,GL_RGB,GL_UNSIGNED_BYTE,
              glReadPixels( 0,0,128,128,
                            GL_RGB, GL_UNSIGNED_BYTE ))

I tried to use shorts (GL_UNSIGNED_SHORT), but then Python 
runs out of memory. Using GL_RGBA makes no difference,
and PyOpenGL does not know GL_BGR or more fancy codings.

All is made on Debian GNU/Linux (Woody), with Python 2.2.1 and 
PyOpenGL 1.5.7. I will try to upgrade to PyOpenGL 2.0, but 
probably not this year. If it is of any interrest: GeForce2GTS
with the NVidia 1.0-4496 driver.

Does anyone know how to get all three colours?

Thanks,

Fulko

-- 
Fulko van Westrenen

Re: [PyOpenGL-Users] generating textures

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

Fulko van Westrenen wrote:

>On Mon, Dec 22, 2003 at 10:04:07AM -0500, Mike C. Fletcher wrote:
>  
>
...

>>   * You currently have OpenGL code that renders the map as geometric
>>     primitives (lines, triangles & such)
>>   * You want to render this geometry into a texture to allow for
>>     faster rendering and transformation
>>    
>>
>This is very correct. I'm clearly not a programmer, let alone a graphics
>programmer.
>  
>
Hey, I'm a designer by training, so I'll never say boo on that grounds ;) .

>>See the demo OpenGLContext/tests/saveimage.py, which demonstrates the 
>>use of glReadPixels to read data back from the OpenGL buffers into an 
>>image (which can then be turned into a texture in the same way as you 
>>see done in all the "load from image file" demos).
>>
>>    
>>
>I checked my pyopengl 1.5.7, but no luck. Stop
>OpenGLContext! I will download that right now.
>  
>
You should likely also download PyOpenGL 2.0.1, as 1.5.7 is over two 
years old, and playing with OpenGLContext is going to require that you 
use 2.0.x.

>It was my hope that it would be possible to render the map in the 
>background. Using glReadPixels looks like it can only be used for an
>image that is rendered for displaying.
>  
>
Easiest (and most reliably available) thing to do is this:

    * During setup (or whenever you can handle a 1/2 second delay in
      screen rendering), render your map to the back buffer (i.e. render
      as normal), do the glReadPixels, then call glClear(...) again and
      render the next frame of your game.

Within Mesa, and other implementations, there are ways to create other 
off-screen buffers (there's also the "pbuffer" mechanism which is, IIRC 
done through an OpenGL extension) for this type of work, but none of 
those are particularly portable AFAIK.

>>It's also possible to generate bitmaps using such things as setting 
>>values in Numpy arrays (particularly useful for creating fractals), 
>>using PyGame/wxPython to draw into in-memory surfaces/DCs (simple 
>>device-context-based drawing systems), or other mechanisms, btw.  Images 
>>are just data to be manipulated, and the number of ways you can 
>>manipulate/create them is pretty large.
>>    
>>
>
>This is a hard one. I do understand what you want to say, but for an
>inexperienced programmer as myself this needs some serious studying
>and experimenting.
>  
>
Well, rendering it with PyOpenGL and glReadPixels should work fine if 
you can handle the one-time 1/2 second "hiccup" in rendering.

>Just to be complete: my map is a maritime map with coastlines,
>depthlines, altitudelines, etc.
>  
>
Cool.

>I hope I can figure it out tonight.
>  
>
Good luck,
Mike

PS: copied to PyOpenGL-Users for posterity :)

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

Re: [PyOpenGL-Users] generating textures

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

I'm assuming what you are describing is this:

    * You currently have OpenGL code that renders the map as geometric
      primitives (lines, triangles & such)
    * You want to render this geometry into a texture to allow for
      faster rendering and transformation

See the demo OpenGLContext/tests/saveimage.py, which demonstrates the 
use of glReadPixels to read data back from the OpenGL buffers into an 
image (which can then be turned into a texture in the same way as you 
see done in all the "load from image file" demos).

It's also possible to generate bitmaps using such things as setting 
values in Numpy arrays (particularly useful for creating fractals), 
using PyGame/wxPython to draw into in-memory surfaces/DCs (simple 
device-context-based drawing systems), or other mechanisms, btw.  Images 
are just data to be manipulated, and the number of ways you can 
manipulate/create them is pretty large.

Hope this helps,
Mike

Fulko van Westrenen wrote:

>Hello,
>
>I'm rather new to Python and have only basic OpenGL knowledge. I started 
>building a user interface using both. It works very fine (thanks to all 
>developers!), but I can't figure out how to make a texture. 
>
>For this display I draw a detailed map, and the drawing takes about 0.5s. 
>Rotating the map is far to slow. To speed things up I want to turn the 
>map into a texture, so I can rotate and shift the texture. Loading 
>textures from an image-file is widely described, but I want/need to generate 
>the texture using pyOpenGL. Can that be done?, and if so: how?
>All tutorials/books say: generate a bitmap. This sounds logical, but I have 
>no idea how to draw a bitmap using OpenGL, let alone making one using Python.
>
>Thanks for your help,
>
>Fulko
>  
>
 
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] generating textures

[Fulko v. W. <Ful...@dt...>]

Hello,

I'm rather new to Python and have only basic OpenGL knowledge. I started 
building a user interface using both. It works very fine (thanks to all 
developers!), but I can't figure out how to make a texture. 

For this display I draw a detailed map, and the drawing takes about 0.5s. 
Rotating the map is far to slow. To speed things up I want to turn the 
map into a texture, so I can rotate and shift the texture. Loading 
textures from an image-file is widely described, but I want/need to generate 
the texture using pyOpenGL. Can that be done?, and if so: how?
All tutorials/books say: generate a bitmap. This sounds logical, but I have 
no idea how to draw a bitmap using OpenGL, let alone making one using Python.

Thanks for your help,

Fulko

-- 
Fulko van Westrenen
fu...@li...

[PyOpenGL-Users] Binary Win32 installer available (thanks to John Carter)

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

John Carter (who is a Lecturer at Trinity College, Dublin) has compiled 
and made available a Win32 binary installer of PyOpenGL.  It's available 
from the project download page, as is normal.  This is PyOpenGL version 
2.0.1.07, btw.

Have fun all,
Mike

PS Jesse Hager has also put together a package, but his sourceforge 
email address is bouncing.  Jesse, if you're reading, please let me know 
what email I should use for you.  I'm *very* interested in your 
modifications to make Togl work.

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

Re: [PyOpenGL-Users] Failure to build on Linux

[Rene D. <re...@py...>]

Hi,

downgrade to swig 1.3.13 if you want it to work.  Or install 1.3.13 
somewhere not in your main path, and have your pyopengl build have it in 
its path before the normal swig path.

I just started working on making pyopengl work with 1.3.19.  However I'm 
having trouble with the GLU wrapper segfaulting, so it may take a while 
to debug.

Anyone allready got pyopengl working with 1.3.19?

Have fun!

Re: [PyOpenGL-Users] Failure to build on Linux

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

On Tue, 16 Dec 2003 05:29 pm, Mike C. Fletcher wrote:
> Richard Jones wrote:
> >On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote:
>
> ...
>
> >I get a ton of these warnings when I run "python setup.py install" on a
> >freshly unpacked source::
> >
> >interface/complex_typemaps.inc:193: Warning(119): %typemap(ignore) has
> > been replaced by %typemap(in,numinputs=3D0).
> >interface/complex_typemaps.inc:194: Warning(119): %typemap(ignore) has
> > been replaced by %typemap(in,numinputs=3D0).
> >
> >and once the build is done, those "interface" and "shadow" files appear.=
 I
> >blame SWIG 1.3.19 ;)
>
> Me too :) :-/ , the .inc files are SWIG inputs, they shouldn't be used
> if you're using the pre-built wrappers.  Try doing a clean unpack and
> then running python setup.py build_ext install, which should skip the
> build_w (wrapper) stage.

This doesn't work. I get an error regarding a missing library=20
"interface_util".


> Alternately, change the binary search path to=20
> *not* point to swig 1.3.19 while building.

Tried this, still no dice :(

Will look into it some more tomorrow.



     Richard

Re: [PyOpenGL-Users] Failure to build on Linux

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

Richard Jones wrote:

>On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote:
>  
>
...

>I get a ton of these warnings when I run "python setup.py install" on a 
>freshly unpacked source::
>
>interface/complex_typemaps.inc:193: Warning(119): %typemap(ignore) has been 
>replaced by %typemap(in,numinputs=0).
>interface/complex_typemaps.inc:194: Warning(119): %typemap(ignore) has been 
>replaced by %typemap(in,numinputs=0).
>
>and once the build is done, those "interface" and "shadow" files appear. I 
>blame SWIG 1.3.19 ;)
>  
>
Me too :) :-/ , the .inc files are SWIG inputs, they shouldn't be used 
if you're using the pre-built wrappers.  Try doing a clean unpack and 
then running python setup.py build_ext install, which should skip the 
build_w (wrapper) stage.  Alternately, change the binary search path to 
*not* point to swig 1.3.19 while building. 

Entering a bug report about SWIG 1.3.19 confusing the SWIG-checking code 
would be a help as well, though I'll leave this message marked as todo 
so I should remember to do it at some point.

HTH,
Mike

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

Re: [PyOpenGL-Users] Failure to build on Linux

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

On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote:
> Richard Jones wrote:
> >I just tried to build 2.0.1.07 on Linux (Mandrake 9.1) against python
> > 2.3.2. Used the standard "python setup.py install". It appeared to build
> > OK, but any attempt to use it breaks:
>
> ...
>
> >The contents of OpenGL/GL/ are:
> >
> >_3DFX/     EXT/             IBM/           INTEL/  PGI/   SGIX/
> >APPLE/     GL__init__.py    INGR/          KTX/    REND/  SUN/
> >ARB/       GL__init__.pyc   __init__.py    MESA/   S3/    SUNX/
> >ATI/       GL__init___.so*  __init__.pyc   NV/     SGI/   WIN/
> >Autodesk/  HP/              __init___.so*  OML/    SGIS/
>
> Where are those __init___.so files coming from I wonder?  Possibly an
> old 2.0.0 installation?  2.0.1 should not have any __init___.so files,
> as they were renamed to GL__init___.so, GLU__init___.so and
> GLUT__init___.so .

OK, the dir now looks like:

_3DFX/  Autodesk/       GL__init___.so*  __init__.py   MESA/  REND/  SGIX/
APPLE/  EXT/            HP/              __init__.pyc  NV/    S3/    SUN/
ARB/    GL__init__.py   IBM/             INTEL/        OML/   SGI/   SUNX/
ATI/    GL__init__.pyc  INGR/            KTX/          PGI/   SGIS/  WIN/

GL__init__.py is definitely still referring to _GL__init__ and not=20
GL__init___. There's references to the former in:

=2E/src/interface/GL.GL__init___.0100.inc
=2E/src/interface/GL.GL__init___.0101.inc
=2E/src/shadow/GL.GL__init__.0100.py
=2E/src/shadow/GL.GL__init__.0101.py

(and nowhere else) if that helps any. They're obviously constructed as part=
 of=20
the build process, as they don't exist in the source dist. There's no match=
=20
on _GL__init__ in the raw source.

I get a ton of these warnings when I run "python setup.py install" on a=20
freshly unpacked source::

interface/complex_typemaps.inc:193: Warning(119): %typemap(ignore) has been=
=20
replaced by %typemap(in,numinputs=3D0).
interface/complex_typemaps.inc:194: Warning(119): %typemap(ignore) has been=
=20
replaced by %typemap(in,numinputs=3D0).

and once the build is done, those "interface" and "shadow" files appear. I=
=20
blame SWIG 1.3.19 ;)


     Richard