pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] HDR image format support?

[Unit3 <un...@de...>]

Hi everyone,

I'm trying to quickly test some HDR algorithm ideas, and so I thought 
that PyOpenGL would let me build some apps quickly to try out my ideas. 
However, it's starting to look like that at least with the packages in 
Ubuntu, the recent extensions to add 16 bit / channel float formats 
aren't supported under PyOpenGL. Specifically, I'm looking for the stuff 
like ARB_color_buffer_float.

Did I just miss how to use the extensions properly? Or is support really 
missing? If so, is there any plan to add support for any of the 
HDR-related image formats?

Thanks!
Graeme

[PyOpenGL-Users] PyOpenGL-3.0.0a5 is now available

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

I've just uploaded the next alpha release of PyOpenGL 3.x.  This release 
includes the "raw" package hierarchy with the auto-generated wrappers 
available for those who want to do low-level hacking.  It also has 
wrappers for OpenGL 1.2, 1.3, 1.4, 1.5 and 2.0 (though only 1.2 and 1.3 
have been looked at for usability, expect some usability-focused API 
changes in the higher versions).  There are also a number of small 
bug-fixes throughout.

This is still a rather early alpha.  We're missing big tracts of 
functionality, such as the AGL and WGL libraries (we do have raw XGL 
support).  There is lots of work still to be done and we would love to 
see your patches to get your favourite bit of the package working.  Bug 
reports, reports of success/failure and the like are also useful.  We 
haven't even begun to optimise the code, btw, so expect it to be very slow.

For users:
    http://pyopengl.sourceforge.net/ctypes/using.html

For developers (and remember, one of the major points of re-implementing 
in pure Python is to make it easier to become a contributor; get involved):
    http://pyopengl.sourceforge.net/ctypes/development.html

We could really use people testing the weird and exotic platforms (e.g. 
Windows, OS-X) and/or porting to other systems (e.g. DOS, HPUX, Solaris, 
*BSD, Irix and the like).  Porting to your platform is just a matter of 
writing a simple Python module.   Testing with existing PyOpenGL 
code-bases to document what needs to be changed when upgrading (or to 
fix bugs) would also help greatly.

Thanks everyone, and have fun,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] python-2.5

[Gary H. <gh...@di...>]

Mike C. Fletcher wrote:
>
> PyOpenGL 3.x (currently in fairly early alpha) uses numpy by default, 
> with support for numarray and numeric available with non-standard builds.
>   
Cool!  Great news!  This begs the question:  What's the time line for 
various 3.x releases?  And is there any way to help?

-- 
Gary Herron, PhD.
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

Re: [PyOpenGL-Users] python-2.5

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

Rurpy wrote:
> Let's try again with a correct subject line...
>
> Are there any plans for Windows binaries for Python-2.5?
>   
Python 2.5 is supported by the PyOpenGL 3.x code line.  I'm not going to 
say I will never get around to updating the PyOpenGL 2.x code-line 
release, but as of right now it's pretty low on my priority list (and a 
royal PITA due to the lack of a properly working Win32 compiler on my 
workstations).  The fact that there are also going to be lots of code 
changes due to the switch to ssize usage is making it a bigger project 
as well.
> Also, the install page says pyopengl is dependent on
> Numerics-23 which is 2 versions old in the Numerics line,
> and Numerics itself is (from what I read) obsoleted by 
> Numpy-1.0.  Are there eany plans to update this dependency?
>   
PyOpenGL 3.x (currently in fairly early alpha) uses numpy by default, 
with support for numarray and numeric available with non-standard builds.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] bug on glcanvas?

[altern <al...@gm...>]

hi again

i also forgot to say that exactly the same code using pygame instead of 
wxpython works fine in both windows, linux and OSX

enrike

George Paci wrote:
> altern wrote:
> 
>  > This is the detailed description of error:
>  > I use  glOrtho(0, 800,  600, 0, 5000, 0)
>  > to set up the projection,
> 
>  From the docs at
> http://pyopengl.sourceforge.net/documentation/manual/glOrtho.3G.xml
> :
> 
> Python Specification
> 
> glOrtho	(left, right, bottom, top, zNear, zFar) -> None
> 
> Parameters
> 
> left, right -- Specify the coordinates for the left and right
>                 vertical clipping planes.			
> bottom, top -- Specify the coordinates for the bottom and top
>                 horizontal clipping planes.
> zNear, zFar -- Specify the distances to the nearer and farther
>                 depth clipping planes. These values are negative
>                 if the plane is to be behind the viewer.
> 
> 
> So you're calling it with bottom=600 and top=0, which is the reverse
> of the way OpenGL handles y coordinates: greater Y in OpenGL is UP.
> 
> The depth values also seem to be backwards: the docs say they're the
> *distances* to the nearer and farther clipping planes.  So you probably
> want zNear=0 and zFar=5000 .
> 
> Try this and see if it works:
> 
> glOrtho(0, 800, 0, 600, 0, 5000)
> 
> 
> Except this looks like you're trying to do things in pixels,
> not OpenGL's units.  A much more natural way would be:
> 
> glOrtho(-400, 400, -300, 300, 0, 5000)
> 
> ... and then (0,0,0) would be at the center of the viewport.
> 
>  > This is true in windows but under Linux I get the (0,0) on the
>  > center of  the screen and if I increase the y value of a vertex
>  > it moves up instead  of down. On top of this the values of the
>  > opengl are not mapped to  pixels and moving a vertex by 1 unit
>  > (should move 1 pixel) moves it out of the window.
> 
> It sounds like your glOrtho() call flat-out failed on Linux
> (more precisely, using whatever driver is associated with
> your rendering context).  Are you sure you're not eating an
> exception thrown by the call?  My guess is it doesn't like
> your depth coordinates.
> 
> To sum up:
> 
> Try:
>    glOrtho(0, 800, 0, 600, 0, 5000)
> 
> Then, if you really want y=0 at the top, try:
>    glOrtho(0, 800, 600, 0, 0, 5000)
> 
> In case you're losing polygons in the front part of
> the scene, try a negative near depth:
>    glOrtho(0, 800, 0, 600, -100, 5000)
> 
> Finally, consider putting everything near the origin
> (i.e. (0,0,0)) and projecting that in the center:
>    glOrtho(-400, 400, -300, 300, -100, 5000)
> 
> 
> --George Paci
> 
>    The desire to remain the same is the single most powerful motivator
>    for change.  In order to preserve something, people will change
>    anything that's less important.  -- Dale Emery
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 

Re: [PyOpenGL-Users] bug on glcanvas?

[altern <al...@gm...>]

hi george

first of all, thanks for your help.

George Paci wrote:
> altern wrote:
> 
>  > This is the detailed description of error:
>  > I use  glOrtho(0, 800,  600, 0, 5000, 0)
>  > to set up the projection,
> 
>  From the docs at
> http://pyopengl.sourceforge.net/documentation/manual/glOrtho.3G.xml
> :
> 
> Python Specification
> 
> glOrtho	(left, right, bottom, top, zNear, zFar) -> None
> 
> Parameters
> 
> left, right -- Specify the coordinates for the left and right
>                 vertical clipping planes.			
> bottom, top -- Specify the coordinates for the bottom and top
>                 horizontal clipping planes.
> zNear, zFar -- Specify the distances to the nearer and farther
>                 depth clipping planes. These values are negative
>                 if the plane is to be behind the viewer.
> 
> 
> So you're calling it with bottom=600 and top=0, which is the reverse
> of the way OpenGL handles y coordinates: greater Y in OpenGL is UP.
> 
> The depth values also seem to be backwards: the docs say they're the
> *distances* to the nearer and farther clipping planes.  So you probably
> want zNear=0 and zFar=5000 .
> 
> Try this and see if it works:
> 
> glOrtho(0, 800, 0, 600, 0, 5000)
> 
> 
> Except this looks like you're trying to do things in pixels,
> not OpenGL's units.  A much more natural way would be:
> 
> glOrtho(-400, 400, -300, 300, 0, 5000)
> 
> ... and then (0,0,0) would be at the center of the viewport.

i forgot to say i am doing a 2D orthogonal system and that i need to 
work with pixels, this is why i match the opengl units to width and 
height of the window in pixels. I set the projection to those values 
because i want it to be like that.
I already tried to see if changing the values passed to the glOrtho 
would make any difference but they dont. Thats pretty weird.

>  > This is true in windows but under Linux I get the (0,0) on the
>  > center of  the screen and if I increase the y value of a vertex
>  > it moves up instead  of down. On top of this the values of the
>  > opengl are not mapped to  pixels and moving a vertex by 1 unit
>  > (should move 1 pixel) moves it out of the window.
> 
> It sounds like your glOrtho() call flat-out failed on Linux
> (more precisely, using whatever driver is associated with
> your rendering context).  Are you sure you're not eating an
> exception thrown by the call?  My guess is it doesn't like
> your depth coordinates.

interesting, so you suggest there mus be something that linux doesnt 
like about my projection but i am not getting the exception, that could 
be a possibility and explains why passing different values to glOrtho 
does not make any difference.

But the problem should be caused by something else than the glOrtho 
setyo, otherwise my simple example (find it attached) would not work either.

I tested today the same code in another linux machine and i get the same 
result. I guess I will have to do some step by step testing to find out 
what is causing this.

thanks!

enrike

> To sum up:
> 
> Try:
>    glOrtho(0, 800, 0, 600, 0, 5000)
> 
> Then, if you really want y=0 at the top, try:
>    glOrtho(0, 800, 600, 0, 0, 5000)
> 
> In case you're losing polygons in the front part of
> the scene, try a negative near depth:
>    glOrtho(0, 800, 0, 600, -100, 5000)
> 
> Finally, consider putting everything near the origin
> (i.e. (0,0,0)) and projecting that in the center:
>    glOrtho(-400, 400, -300, 300, -100, 5000)
> 
> 
> --George Paci
> 
>    The desire to remain the same is the single most powerful motivator
>    for change.  In order to preserve something, people will change
>    anything that's less important.  -- Dale Emery
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 

[PyOpenGL-Users] python-2.5

[Rurpy <ru...@ya...>]

Let's try again with a correct subject line...

Are there any plans for Windows binaries for Python-2.5?
 
Also, the install page says pyopengl is dependent on
Numerics-23 which is 2 versions old in the Numerics line,
and Numerics itself is (from what I read) obsoleted by 
Numpy-1.0.  Are there eany plans to update this dependency?




Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: [PyOpenGL-Users] bug on glcanvas?

[George P. <ge...@ri...>]

altern wrote:

 > This is the detailed description of error:
 > I use  glOrtho(0, 800,  600, 0, 5000, 0)
 > to set up the projection,

 From the docs at
http://pyopengl.sourceforge.net/documentation/manual/glOrtho.3G.xml
:

Python Specification

glOrtho	(left, right, bottom, top, zNear, zFar) -> None

Parameters

left, right -- Specify the coordinates for the left and right
                vertical clipping planes.			
bottom, top -- Specify the coordinates for the bottom and top
                horizontal clipping planes.
zNear, zFar -- Specify the distances to the nearer and farther
                depth clipping planes. These values are negative
                if the plane is to be behind the viewer.


So you're calling it with bottom=600 and top=0, which is the reverse
of the way OpenGL handles y coordinates: greater Y in OpenGL is UP.

The depth values also seem to be backwards: the docs say they're the
*distances* to the nearer and farther clipping planes.  So you probably
want zNear=0 and zFar=5000 .

Try this and see if it works:

glOrtho(0, 800, 0, 600, 0, 5000)


Except this looks like you're trying to do things in pixels,
not OpenGL's units.  A much more natural way would be:

glOrtho(-400, 400, -300, 300, 0, 5000)

... and then (0,0,0) would be at the center of the viewport.

 > This is true in windows but under Linux I get the (0,0) on the
 > center of  the screen and if I increase the y value of a vertex
 > it moves up instead  of down. On top of this the values of the
 > opengl are not mapped to  pixels and moving a vertex by 1 unit
 > (should move 1 pixel) moves it out of the window.

It sounds like your glOrtho() call flat-out failed on Linux
(more precisely, using whatever driver is associated with
your rendering context).  Are you sure you're not eating an
exception thrown by the call?  My guess is it doesn't like
your depth coordinates.

To sum up:

Try:
   glOrtho(0, 800, 0, 600, 0, 5000)

Then, if you really want y=0 at the top, try:
   glOrtho(0, 800, 600, 0, 0, 5000)

In case you're losing polygons in the front part of
the scene, try a negative near depth:
   glOrtho(0, 800, 0, 600, -100, 5000)

Finally, consider putting everything near the origin
(i.e. (0,0,0)) and projecting that in the center:
   glOrtho(-400, 400, -300, 300, -100, 5000)


--George Paci

   The desire to remain the same is the single most powerful motivator
   for change.  In order to preserve something, people will change
   anything that's less important.  -- Dale Emery

[PyOpenGL-Users] bug on glcanvas?

[altern <al...@gm...>]

hi all

I am having a strange error with the corrdinate system with a glcanvas 
on Linux (but not on windows!). I have a complex system for 2D opengl 
rendering and it is proving to be really difficult to fix this. So I 
decided to do a simple example to see where the problem was. The simple 
example does work fine both on linux and windows now. So once this is 
working I thought it should be pretty easy to find out the point that 
causes the error in the complex code, but I cannot really find which is 
the different bit. So I was wondering if this error sounds familiar to 
anyone in the list. I am writing both to wxPython-users and 
pyOpenGL-users lists.

This is the detailed description of error:
I use  glOrtho(0, 800,  600, 0, 5000, 0)
to set up the projection, this means that if I set a vertex like this
glVertex2i(400, 300)
this should be in the center of the canvas (0,0 is top left of the 
window). Moreover, if I increase the y value, this should move the 
vertex to the bottom of the window
This is true in windows but under Linux I get the (0,0) on the center of 
the screen and if I increase the y value of a vertex it moves up instead 
of down. On top of this the values of the opengl are not mapped to 
pixels and moving a vertex by 1 unit (should move 1 pixel) moves it out 
of the window.

If anyone ever had a similar problem it would be great to hear some hints.

Thanks

enrike

Re: [PyOpenGL-Users] glTexImage2d size

[Jonathan H. <jh...@sp...>]

Jon wrote:

>  AFAIK the ability to support non-power-of-2 (NPO2 or NPOT) textures is a
>  card-specific thing, and hence their OpenGL driver thing.
>  
>  I _think_ NPO2 texture support is supposed to be a standard feature of OpenGL
>  2.X, but I don't think all cards support it.

I also understand that this is the case, but I don't have a reference 
handy. In any case, I think the right thing to do is to test for the 
presence of the GL_ARB_texture_non_power_of_two extension.

This is what I do:

try:
     from OpenGL.GL.ARB.texture_non_power_of_two import 
glInitTextureNonPowerOfTwoARB
except:	# not defined in PyOpenGL 2.0.0.44
     def glInitTextureNonPowerOfTwoARB(): return False


# call this after glInit()
card_handles_NPOT = glInitTextureNonPowerOfTwoARB()


Jonathan.

[PyOpenGL-Users] python-1.5

[Rurpy <ru...@ya...>]

Are there any plans for Windows binaries for Python-2.5?

Also, the install page says pyopengl is dependent on
Numerics-23 which is 2 versions old in the Numerics line,
and Numerics itself is (from what I read) obsoleted by 
Numpy-1.0.  Are there eany plans to update this dependency?

Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: [PyOpenGL-Users] glTexImage2d size

[JoN <jo...@we...>]

Hi guys,

AFAIK the ability to support non-power-of-2 (NPO2 or NPOT) textures is a
card-specific thing, and hence their OpenGL driver thing.

I _think_ NPO2 texture support is supposed to be a standard feature of Op=
enGL
2.X, but I don't think all cards support it.

Jon


Quoting Matt Bailey <ma...@rt...>:

> Oh, cool, I didn't know about that function, might have to check that o=
ut. In
>=20
> my current game I'm just making them all a power of 2, which works well=
=20
> enough for most things (I like having the extra space to work with in t=
he=20
> image just in case I or someone else chooses to edit the look of things=
 a bit
>=20
> later on), but to save disk space/memory I re-sized my player's weapon =
images
>=20
> some to make them a power of 2, and then expand the OpenGL surface out =
to the
>=20
> aspect ratio of the "correct" original gun image....since I'm downsizin=
g the
>=20
> image in one dimension, I lose some detail.
>=20
> 	-Matt Bailey
>=20
> On Monday 13 November 2006 14:26, Andrew Wilson set 1,000 monkies in fr=
ont of
>=20
> keyboards and the following appeared:
> > Hello,
> >   You are correct, I would like to use textures that are not of power=
 2 in
> > dimension.  I have an Nvidia Quadro FX 3450 that mysteriously support=
s it.
> > I seem to have found a work around using the gluBuild2DMipmaps call, =
the
> > appear to automatically pad the image correctly.  I guess I should re=
ad
> the
> > documentation a little closer!
> >   Thanks
> >   Andrew
> >
> > On 11/13/06, Matt Bailey <ma...@rt...> wrote:
> > > Hrrrmmm, OpenGL textures should always have dimensions that are a p=
ower
> > > of 2.
> > > Are you saying you want to use images that do not conform to this? =
This
> > > normally is not possible, I don't know of a way around it. If that'=
s
> what
> > > you're trying to do, I'm surprised it works on any video card at al=
l.
> > >
> > >         -Matt Bailey
>=20
>=20
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>=20




--------------------------------------------------------------------
Come and visit Web Prophets Website at http://www.webprophets.net.au

Re: [PyOpenGL-Users] glTexImage2d size

[Matt B. <ma...@rt...>]

Oh, cool, I didn't know about that function, might have to check that out. In 
my current game I'm just making them all a power of 2, which works well 
enough for most things (I like having the extra space to work with in the 
image just in case I or someone else chooses to edit the look of things a bit 
later on), but to save disk space/memory I re-sized my player's weapon images 
some to make them a power of 2, and then expand the OpenGL surface out to the 
aspect ratio of the "correct" original gun image....since I'm downsizing the 
image in one dimension, I lose some detail.

	-Matt Bailey

On Monday 13 November 2006 14:26, Andrew Wilson set 1,000 monkies in front of 
keyboards and the following appeared:
> Hello,
>   You are correct, I would like to use textures that are not of power 2 in
> dimension.  I have an Nvidia Quadro FX 3450 that mysteriously supports it.
> I seem to have found a work around using the gluBuild2DMipmaps call, the
> appear to automatically pad the image correctly.  I guess I should read the
> documentation a little closer!
>   Thanks
>   Andrew
>
> On 11/13/06, Matt Bailey <ma...@rt...> wrote:
> > Hrrrmmm, OpenGL textures should always have dimensions that are a power
> > of 2.
> > Are you saying you want to use images that do not conform to this? This
> > normally is not possible, I don't know of a way around it. If that's what
> > you're trying to do, I'm surprised it works on any video card at all.
> >
> >         -Matt Bailey

Re: [PyOpenGL-Users] glTexImage2d size

[Andrew W. <and...@al...>]

Hello,
  You are correct, I would like to use textures that are not of power 2 in
dimension.  I have an Nvidia Quadro FX 3450 that mysteriously supports it.
I seem to have found a work around using the gluBuild2DMipmaps call, the
appear to automatically pad the image correctly.  I guess I should read the
documentation a little closer!
  Thanks
  Andrew



On 11/13/06, Matt Bailey <ma...@rt...> wrote:
>
> Hrrrmmm, OpenGL textures should always have dimensions that are a power of
> 2.
> Are you saying you want to use images that do not conform to this? This
> normally is not possible, I don't know of a way around it. If that's what
> you're trying to do, I'm surprised it works on any video card at all.
>
>         -Matt Bailey
>
> On Monday 13 November 2006 13:46, Andrew Wilson set 1,000 monkies in front
> of
> keyboards and the following appeared:
> > Hello,
> >   I'm trying to load some textures that do not have width and height of
> > 2n+2.  It seems that this works great on some graphics cards and bombs
> on
> > other cards.  I know it is supposed to be 2n+2 but why would some cards
> let
> > me do this and others not?  And any suggestions on how to detect if the
> > graphics card is compatible?  Also any suggestions on efficient padding
> so
> > that the images still co-register properly?
> >   Thanks
> >   Andrew
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

[PyOpenGL-Users] Running PyOpenGL problem

[red p. <red...@ya...>]

I installed PyOpenGL and ctypes in my cygwin.

But when I excute following command it said, 

>>> from Tkinter import Tk
>>> from OpenGL.GL import *
      6 [main] python2.4 2676
f:\cygwin\bin\python2.4.exe: *** fatal error -
f:\cygwin\bin\python2.4.exe: *** unable to remap
f:\cygwin\bin\tk84.dll to same address as
parent(0x18E10000) != 0x18E20000
      8 [main] python 1760 fork: child 2676 - died
waiting for dll loading, errno 11
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib/python2.4/site-packages/OpenGL-3.0.0a4-py2.4.egg/OpenGL/GL/__init__.py",
line 3, in ?
    from OpenGL.GL.simple import *
  File
"/usr/lib/python2.4/site-packages/OpenGL-3.0.0a4-py2.4.egg/OpenGL/GL/simple.py",
line 3, in ?
    from OpenGL import platform, arrays
  File
"/usr/lib/python2.4/site-packages/OpenGL-3.0.0a4-py2.4.egg/OpenGL/platform/__init__.py",
line 24, in ?
    from OpenGL.platform.glx import *
  File
"/usr/lib/python2.4/site-packages/OpenGL-3.0.0a4-py2.4.egg/OpenGL/platform/glx.py",
line 29, in ?
    mode=ctypes.RTLD_GLOBAL 
  File
"/usr/lib/python2.4/site-packages/OpenGL-3.0.0a4-py2.4.egg/OpenGL/platform/ctypesloader.py",
line 30, in loadLibrary
    name = util.find_library( name )
  File "ctypes/util.py", line 95, in find_library
    lib = _findLib_ld(name) or _findLib_gcc(name)
  File "ctypes/util.py", line 78, in _findLib_ld
    res = re.search(expr, os.popen('/sbin/ldconfig -p
2>/dev/null').read())
OSError: [Errno 11] Resource temporarily unavailable


Anybody can tell me why and how to solve this problem

Thank,

John


 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

Re: [PyOpenGL-Users] glTexImage2d size

[Matt B. <ma...@rt...>]

Hrrrmmm, OpenGL textures should always have dimensions that are a power of 2. 
Are you saying you want to use images that do not conform to this? This 
normally is not possible, I don't know of a way around it. If that's what 
you're trying to do, I'm surprised it works on any video card at all.

	-Matt Bailey

On Monday 13 November 2006 13:46, Andrew Wilson set 1,000 monkies in front of 
keyboards and the following appeared:
> Hello,
>   I'm trying to load some textures that do not have width and height of
> 2n+2.  It seems that this works great on some graphics cards and bombs on
> other cards.  I know it is supposed to be 2n+2 but why would some cards let
> me do this and others not?  And any suggestions on how to detect if the
> graphics card is compatible?  Also any suggestions on efficient padding so
> that the images still co-register properly?
>   Thanks
>   Andrew

[PyOpenGL-Users] glTexImage2d size

[Andrew W. <and...@al...>]

Hello,
  I'm trying to load some textures that do not have width and height of
2n+2.  It seems that this works great on some graphics cards and bombs on
other cards.  I know it is supposed to be 2n+2 but why would some cards let
me do this and others not?  And any suggestions on how to detect if the
graphics card is compatible?  Also any suggestions on efficient padding so
that the images still co-register properly?
  Thanks
  Andrew

[PyOpenGL-Users] install PyopenGL error in Cygwin

[red p. <red...@ya...>]

This is the error information I got when I want to
install pyopenGL. Anybody can help me fix it?

Thanks,

John


$ python setup.py install
Togl to be built: Togl-1.6
running install
running build
running build_w
swig -version
      6 [main] python2.4 3148
f:\cygwin\bin\python2.4.exe: *** fatal error -
f:\cygwin\bin\python2.4.exe: *** unable to remap
f:\cygwin\bin\tk84.dll to same address as
parent(0x18920000) != 0x18E10000
     11 [main] python 480 fork: child 3148 - died
waiting for dll loading, errno 11
swig1.3 -version
  51824 [main] python2.4 3108
f:\cygwin\bin\python2.4.exe: *** fatal error -
f:\cygwin\bin\python2.4.exe: *** unable to remap
f:\cygwin\bin\tk84.dll to same address as
parent(0x18920000) != 0x18E10000
  54688 [main] python 480 fork: child 3108 - died
waiting for dll loading, errno 11

SWIG Version 1.3.23
Copyright (c) 1995-1998
University of Utah and the Regents of the University
of California
Copyright (c) 1998-2004
University of Chicago
Compiled with g++ [i686-pc-cygwin]

Please see http://www.swig.org for reporting bugs and
further information
sh: swig1.3: command not found
warning: build_w: Can't find SWIG, will just have to
do with the existing wrapper source.
running config
compiling '_configtest.c':

#ifdef _WIN32
#include <windows.h>
#endif
#ifdef __APPLE_CC__
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#else
#include <GL/gl.h>
#include <GL/glu.h>
#endif
#ifdef GLU_VERSION_1_2
GLUnurbs *x;
GLUtesselator *y;
GLUquadric *z;
#endif
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I/usr/include/python2.4/Numeric
-c _configtest.c -o _configtest.o
 278705 [main] python2.4 2400
f:\cygwin\bin\python2.4.exe: *** fatal error -
f:\cygwin\bin\python2.4.exe: *** unable to remap
f:\cygwin\bin\tk84.dll to same address as
parent(0x18920000) != 0x18E10000
 282185 [main] python 480 fork: child 2400 - died
waiting for dll loading, errno 11
error: Resource temporarily unavailable




 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

[PyOpenGL-Users] how to install opengl into Cygwin

[red p. <red...@ya...>]

Anybody has the experience to install PyOpenGl into
Cygwin. I have a python program to 

from OpenGL.tk import *

but when I excute it, it said the error

from OpenGL.Tk import *
ImportError: No module named OpenGL.Tk


I suspect this is because I didn't install OpenGL in
my python.

Thanks,

John


 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re: [PyOpenGL-Users] glNormal3f not working for me

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

McTaggart, Kevin wrote:
> When drawing a square, a call to glNormal3f doesn't appear to affect how
> the square is drawn.  I'm trying to get a coloured front and dark back
> by using the following:
>
> 	glColorMaterial(GL_FRONT_AND_BACK, GL_EMISSION)
> 	glPolygonMode(GL_FRONT, GL_FILL)
> 	glPolygonMode(GL_BACK, GL_LINE)
> 	glColor3f(0.0, 1.0, 0.0)	
> 	glBegin(GL_POLYGON)
> 	glNormal3f(0.0, -1.0, 0.0) # Doesn't appear to have any
> influence
> 	glVertex3f(1.0, -1.0, -1.0)           
> 	glVertex3f(1.0, -1.0, 1.0)          
> 	glVertex3f(-1.0, -1.0, 1.0)          
> 	glVertex3f(-1.0, -1.0, -1.0)         
> 	glEnd()                             
>
> It appears that calling glNormal3f has no influence on which is the
> front or back, and that I have to rearrange the order in which vertices
> are called (clockwise versus counter-clockwise).  Any hints on how to
> get glNormal3f to influence which is front and back?  
>   
AFAIK this is working correctly.  That is, the "front" and "back" faces 
of a polygon are determined by winding rules, not normals.  You can 
reverse the direction by setting the winding rule to CCW or CW, but I 
don't *think* you can make it use normals... after all, a polygon can 
have a different normal at every vertex, one pointing backward, another 
forward, then how do you decide which is "back" and which is "front".

I would imagine you might be able to write a shader program that 
implements the rules for you so that it *looks* like the normals are 
used in your situation, but I don't think you can readily do it in 
general OpenGL, as the engine is going to look at the front/back status 
long before it gets around to lighting calculations (I'm guessing, but 
that would make sense to me).

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] glNormal3f not working for me

[McTaggart, K. <Kev...@dr...>]

When drawing a square, a call to glNormal3f doesn't appear to affect how
the square is drawn.  I'm trying to get a coloured front and dark back
by using the following:

	glColorMaterial(GL_FRONT_AND_BACK, GL_EMISSION)
	glPolygonMode(GL_FRONT, GL_FILL)
	glPolygonMode(GL_BACK, GL_LINE)
	glColor3f(0.0, 1.0, 0.0)=09
	glBegin(GL_POLYGON)
	glNormal3f(0.0, -1.0, 0.0) # Doesn't appear to have any
influence
	glVertex3f(1.0, -1.0, -1.0)          =20
	glVertex3f(1.0, -1.0, 1.0)         =20
	glVertex3f(-1.0, -1.0, 1.0)         =20
	glVertex3f(-1.0, -1.0, -1.0)        =20
	glEnd()                            =20

It appears that calling glNormal3f has no influence on which is the
front or back, and that I have to rearrange the order in which vertices
are called (clockwise versus counter-clockwise).  Any hints on how to
get glNormal3f to influence which is front and back? =20

[PyOpenGL-Users] Lettre d'information 2le - Octobre 2006

[<2l...@2l...>]

<html><head>
        <meta content=3D"text/html;charset=3Diso-8859-1"
http-equiv=3D"Content-Type">
        <title></title></head><body><title></title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-885=
9-1" />
<style type=3D"text/css">
<!--
body {
background-color: #dfe1ec;
margin: 0 0 0 0;
}
a {
color: #000;
}
p {
font-family: Arial, Helvetica, sans-serif;
font-size: 12px;
margin : 0;
padding-top: 7px;
padding-bottom: 7px;
padding-right: 25px;
padding-left: 25px;
}
td.gauche {
border-right: #003399 1px dashed ;
}
p.spacer {
padding-top: 0px;
padding-bottom: 0px;
padding-right: 0px;
padding-left: 0px;
border-bottom: #003399 1px dashed ;
}
h1
{
font-family: Trebuchet MS;
font-size: 16px;
font-style: bold;
color: #0000AE;
margin : 0;
padding-top: 7px;
padding-bottom: 0px;
padding-right: 25px;
padding-left: 25px;
}
td.titre {
background-color: #0000AE;
font-family: Trebuchet MS;
font-size: 1.2em;
color: #ffffff;
font-weight: bold;
text-align: right;
padding-right: 10px;
}
-->
</style>
<table width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" border=3D"0"
bgcolor=3D"#dfe1ec">
    <tbody>
        <tr>
            <td bgcolor=3D"#dfe1ec">
            <table width=3D"580" cellspacing=3D"0" cellpadding=3D"0" bord=
er=3D"0"
background=3D"http://www.2le.net/Newsletter/0106img/bg.png" align=3D"cent=
er">
                <tbody>
                    <tr>
                        <td>
                        <table width=3D"550" cellspacing=3D"0" cellpaddin=
g=3D"0"
border=3D"0" align=3D"center">
                            <tbody>
                                <tr>
                                    <td><a href=3D"http://www.2le.net"
target=3D"_blank"><img width=3D"550" height=3D"97" border=3D"0" alt=3D""
src=3D"http://www.2le.net/Newsletter/0906img/entete-vide.png" /></a></td>
                                </tr>
                                <tr>
                                    <td class=3D"titre">Lettre d'informat=
ion
- Octobre 2006</td>
                                </tr>
                                <tr>
                                    <td>
                                    <table width=3D"550" cellspacing=3D"0=
"
cellpadding=3D"0" border=3D"0" bgcolor=3D"#ffffff">
                                        <tbody>
                                            <tr valign=3D"top">
                                                <td><h1>2le, partenaire d=
e
la Rentr&eacute;e du Libre</h1>
<p style=3D"text-align: center;"><a
href=3D"http://strasbourg.linuxfr.org/rdl2006/accueil" target=3D"_blank">=
<img
border=3D"0" alt=3D""
src=3D"http://strasbourg.linuxfr.org/depot/RDL2006/banner.png" /></a></p>
<p>2le sponsorise cette ann&eacute;e la Rentr&eacute;e                   =
 =20
      du Libre qui aura lieu le 28 octobre 2006 &agrave; Strasbourg.<br /=
>=20
                         Organis&eacute;e par le LUG (Linux Users Group) =
de
Strasbourg,                            cette journ&eacute;e est
destin&eacute;e aussi bien au grand                            public
qu'aux entreprises et a pour but de pr&eacute;senter                     =
 =20
    les diff&eacute;rents acteurs alsaciens dans le domaine              =
 =20
           des logiciels libres.<br />                            Plusieu=
rs
conf&eacute;rences auront lieu tout au long                            de
la journ&eacute;e. Chacune s'adressant soit &agrave;                     =
 =20
    un public initi&eacute;, soit &agrave; un public d&eacute;sireux     =
 =20
                    de d&eacute;couvrir les logiciels libres.</p>
<p><img width=3D"20" height=3D"18" align=3D"absmiddle" alt=3D""
src=3D"http://www.2le.net/Newsletter/0506img/fleche.png" />              =
   =20
         <a href=3D"http://strasbourg.linuxfr.org/" target=3D"_blank"><st=
rong>=20
                          Le site du LUG de Strasbourg</strong></a><br />=
 =20
                         <img width=3D"20" height=3D"18" align=3D"absmidd=
le"
alt=3D"" src=3D"http://www.2le.net/Newsletter/0506img/fleche.png" />     =
     =20
                <strong><a
href=3D"http://strasbourg.linuxfr.org/rdl2006/accueil" target=3D"_blank">=
Le   =20
                       programme de la Rentr&eacute;e du
Libre</a></strong></p>
<p class=3D"spacer">&nbsp;</p>
<h1>Kiwi Backup lance une nouvelle offre sp&eacute;ciale                 =
 =20
        revendeurs</h1>
<p>Afin de permettre &agrave; tous les sp&eacute;cialistes               =
 =20
          de l'informatique d'&ecirc;tre pr&eacute;sents sur le          =
 =20
               march&eacute; de la sauvegarde en ligne, Kiwi Backup      =
 =20
                   vient de lancer sa nouvelle offre de sauvegarde en
marque                            blanche.</p>
<p><img width=3D"20" height=3D"18" align=3D"absmiddle" alt=3D""
src=3D"http://www.2le.net/Newsletter/0506img/fleche.png" /> <a
href=3D"http://www.kiwi-backup.com/marque-blanche.html"
target=3D"_blank"><strong>En                            savoir sur l'offr=
e en
marque blanche</strong></a><br />                           <strong><img
width=3D"20" height=3D"18" align=3D"absmiddle" alt=3D""
src=3D"http://www.2le.net/Newsletter/0506img/fleche.png" /> <a
href=3D"http://www.kiwi-backup.com"
target=3D"_blank">www.kiwi-backup.com</a></strong>                       =
 =20
</p>
<p class=3D"spacer">&nbsp;</p>
<p><strong>Retrouvez comme toujours:</strong></p>
<p style=3D"text-align: center;"><a href=3D"http://www.2le.net"
target=3D"_blank"><img border=3D"0" alt=3D""
src=3D"http://www.2le.net/Newsletter/0106img/logo2le.png" /></a><br />   =
   =20
                   Les prestations d'h&eacute;bergement 2le</p>
<p style=3D"text-align: center;"><a href=3D"http://www.2le.net"
target=3D"_blank"><img border=3D"0" alt=3D""
src=3D"http://www.2le.net/Newsletter/0106img/logocastor.png" /></a><br />=
   =20
                      Castor, le framework <br />                        =
 =20
de d&eacute;veloppement de 2le</p>
<p style=3D"text-align: center;"><a href=3D"http://www.kiwi-backup.com/"
target=3D"_blank"><img border=3D"0" alt=3D""
src=3D"http://www.2le.net/Newsletter/0106img/logokiwi.png" /></a><br />  =
   =20
                    La sauvegarde en ligne de vos donn&eacute;es par
Kiwi-Backup</p></td>
                                            </tr>
                                        </tbody>
                                    </table>
                                    </td>
                                </tr>
                                <tr>
                                    <td><a href=3D"http://www.2le.net"
target=3D"_blank"><img width=3D"550" height=3D"36" border=3D"0" alt=3D""
src=3D"http://www.2le.net/Newsletter/0106img/pied-adresse.png" /></a></td=
>
                                </tr>
                            </tbody>
                        </table>
                        </td>
                    </tr>
                </tbody>
            </table>
            <div align=3D"center"><img width=3D"580" height=3D"18" alt=3D=
""
src=3D"http://www.2le.net/Newsletter/0106img/pied.png" />        </div>
            </td>
        </tr>
    </tbody>
</table><br /><br /><div class=3D"emailfooter">--<br />
Pour vous d=E9sabonner =E0 cette liste, visitez <a
href=3D"http://www.2le.net/lists/?p=3Dunsubscribe&uid=3Ddce9897917fca9f80=
d1af7d64bfc1417">ce
lien</a><br />
</div><br />
    <style type=3D"text/css">
.poweredphplist {font-family: arial, verdana, sans-serif;font-size : 10px=
;
font-variant: small-caps; font-weight : normal; padding: 2px;
padding-left:20px;}
a:link.poweredphplist,
a:active.poweredphplist,
a:visited.poweredphplist  {font-family: Arial, verdana, sans-serif;
font-size : 10px; font-variant: small-caps; font-weight : normal; color :
#666666; text-align : center; text-decoration : none; padding: 2px;}
a:hover.poweredphplist {color : #7D7B7B;}
</style>
    <span class=3D"poweredphplist">powered by <a
href=3D"http://www.phplist.com" class=3D"poweredphplist"
target=3D"_blank">phplist</a> v 2.10.2, &copy; <a
href=3D"http://tincan.co.uk/powered" target=3D"_blank"
class=3D"poweredphplist">tincan ltd</a></span></body></html>

Re: [PyOpenGL-Users] WGL package in PyOpenGL 3.0?

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

Daniel Rizzuto wrote:
> I'm looking for the WGL sub-package that used to be part of PyOpenGL 
> v2.0. I'm specifically looking for the OpenGL.WGL.EXT.swap_control 
> module. Is this still available in PyOpenGL v3.0?
>   
3.0 is still an early alpha.  WGL support is on the to-do list, mostly 
pending my (or someone else) having time to create the wrappers.

Enjoy yourself,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] WGL package in PyOpenGL 3.0?

[Daniel R. <ri...@ca...>]

I'm looking for the WGL sub-package that used to be part of PyOpenGL 
v2.0. I'm specifically looking for the OpenGL.WGL.EXT.swap_control 
module. Is this still available in PyOpenGL v3.0?

Thanks, Dan

-- 
____________________________________
Daniel Rizzuto, PhD
California Institute of Technology

http://www.its.caltech.edu/~rizzuto/
Office: (626) 395 8337
Mobile: (626) 676 5435
Fax:    (626) 795 2397

[PyOpenGL-Users] segmentation fault on debian

[altern <al...@gm...>]

hi

when i import OpenGL.Tk i get a segmentation fault on my Debian Sid 
desktop.  I am running python 2.4.4 and pyOpenGL 2.0.1.09-23

Maybe the pyOpenGL package hasnt been compiled with Tk support? just 
wondering ... Do i need to compile it myself?

thanks for tips

enrike