pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Python Qt OpenGL program: Xmu dependency

[Tom D. <td...@yo...>]

Jo Vermeulen wrote:
> 
> Which corrections?

#(added to terrainglview.py)
from OpenGL.GL import *

>>However it does suggest it has nothing to do with python, and probably 
>>Qt version/build related.
> 
> 
> Should I post this to the PyQt list?

It looks like your code wasn't getting to the module with the gl stuff.

Probably worth checking that pyqt works at all (without gl), and for 
that matter, that any qt applications work - try some of the qt 
examples.  You should also try a gl app. (e.g. glxgears).

Then you can work out if it's a GL, Qt or PyQt issue.

Re: [PyOpenGL-Users] bus error on gluNewQuadric()

[Dave P. <de...@bu...>]

On Fri, 22 Oct 2004, altern wrote:
> the only thing i changed is that i was actually creating the q =
> gluNewQuadric() as a to reuse it so that i dont do it everytime i create a
> circle. Now i put it into the drawing function and there is no problem. I
> guess osx didnt like to reuse the object and needs to create one new every
> time.

OSX's OpenGL implementation requires a GL context to exist before you can 
create a quadric; this also applies to Linux & probably other Unixes, 
Windows happens to be different and lets you create a quadric any time.

So, if you move your gluNewQuadric() call to happen _after_ you've opened 
a window (for instance, after calling glutCreateWindow), then it should be 
fine, and you'll only need to create it once.


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

Re: [PyOpenGL-Users] Python Qt OpenGL program: Xmu dependency

[Jo V. <jo...@lu...>]

Op do, 21-10-2004 te 15:51 -0700, schreef Hart's Antler:
> I'm having the same problems with Debian SID, even after apt-getting pyopengl, pyqt, pyqtgl and
> xmu.

Hmm maybe it's a Debian-specific problem?

Kind regards,

-- 
Jo Vermeulen <jo...@lu...>

Re: [PyOpenGL-Users] Python Qt OpenGL program: Xmu dependency

[Jo V. <jo...@lu...>]

Op vr, 22-10-2004 te 08:43 +1000, schreef Tom Dossis:
> Works fine (after a couple of minor corrections) on 2 of my systems.

Which corrections?

[snip]

> However it does suggest it has nothing to do with python, and probably 
> Qt version/build related.

Should I post this to the PyQt list?

Kind regards,

-- 
Jo Vermeulen <jo...@lu...>

Re: [PyOpenGL-Users] bus error on gluNewQuadric()

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

hi

well ... now its working.
the only thing i changed is that i was actually creating the q = 
gluNewQuadric() as a to reuse it so that i dont do it everytime i create 
a circle. Now i put it into the drawing function and there is no 
problem. I guess osx didnt like to reuse the object and needs to create 
one new every time.

so before i was doing something like this

quad = gluNewQuadric()

def drawCircle(inner, radius):
           global quad
           gluDisk(quad, inner, radius, 80, 1)

and now i am doing something like this

def drawCircle(inner, radius):
           quad = gluNewQuadric()
           gluDisk(quad, inner, radius, 80, 1)


thanks!



Tom Dossis wrote:
>>>> i am working on the OS X port of a program and I get a "bus error" 
>>>> caused by this opengl code (it didnt happen on Windows)
>>>> q = gluNewQuadric()
>>>>
>>> I have run into this same problem without PyOpenGL involved at all.  
>>> A Google search turned up this post:
>>>
>>> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html 
>>>
>>>
>>> By swapping the order of -lGL and -lGLU when linking, I was able to 
>>> fix the problem I had.
>>
>>
>> do you mean that on the imports i should swap the order of these 
>> instructions?
>>
>> from OpenGL.GL import *
>> from OpenGL.GLU import *
>>
>> I tried this and i get the same error. maybe i dont understand what 
>> you mean?
> 
> 
> Changing the python code won't make any difference.
> The link instruction above relates to building the pyopengl package.
> 
> It may be worthwhile to try the pyopengl Demo/NeHe/lesson18.py 
> referenced at the end of the page:
> http://pyopengl.sourceforge.net/documentation/manual/gluNewQuadric.3G.xml
> 
> At least this will remove wxpython from the equation.
> 
> Good luck.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 


-- 
enrike

Re: [PyOpenGL-Users] Python Qt OpenGL program: Xmu dependency

[Hart's A. <bha...@ya...>]

I'm having the same problems with Debian SID, even after apt-getting pyopengl, pyqt, pyqtgl and
xmu.
-brett

--- Tom Dossis <td...@yo...> wrote:

> > I'm started working on an terrain editor using OpenGL, Qt and Python. I
> > can't start the application, since it depends on Xmu, and can't find
> > this library (it is installed though). I'm using Debian GNU/Linux
> > unstable.
> > 
> > Here is the error message:
> > 
> > disabling TCL support
> > Unable to resolve Xmu symbols - please check your Xmu library
> > installation.
> > 
> > Maybe it has something to do with the Qt OpenGL bindings?
> > The (really small) source code can be found here:
> > 
> > http://lumumba.luc.ac.be/~jo/temp/terrain_code/terrain.zip
> 
> Works fine (after a couple of minor corrections) on 2 of my systems.
> 
> Running ldd on one of the qt provided examples (aclock) shows very 
> different results:
> 
> SuSE9.1
>          linux-gate.so.1 =>  (0xffffe000)
>          libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x4003f000)
>          libpng.so.3 => /usr/lib/libpng.so.3 (0x40728000)
>          libz.so.1 => /lib/libz.so.1 (0x40756000)
>          libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40768000)
>          libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40770000)
> 	...
> 
> SuSE9.0
>          libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x40036000)
>          libpng.so.3 => /usr/lib/libpng.so.3 (0x4075b000)
>          libz.so.1 => /lib/libz.so.1 (0x40789000)
>          libGLU.so.1 => /usr/lib/libGLU.so.1 (0x40798000)
>          libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x40816000)
>          libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40881000)
>          libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40897000)
> 	...
> 
> Also ldd for kfind also show similar differences.  Don't know why GL 
> (and Xmu) are being linked in for non GL qt apps.
> 
> However it does suggest it has nothing to do with python, and probably 
> Qt version/build related.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [PyOpenGL-Users] Python Qt OpenGL program: Xmu dependency

[Tom D. <td...@yo...>]

> I'm started working on an terrain editor using OpenGL, Qt and Python. I
> can't start the application, since it depends on Xmu, and can't find
> this library (it is installed though). I'm using Debian GNU/Linux
> unstable.
> 
> Here is the error message:
> 
> disabling TCL support
> Unable to resolve Xmu symbols - please check your Xmu library
> installation.
> 
> Maybe it has something to do with the Qt OpenGL bindings?
> The (really small) source code can be found here:
> 
> http://lumumba.luc.ac.be/~jo/temp/terrain_code/terrain.zip

Works fine (after a couple of minor corrections) on 2 of my systems.

Running ldd on one of the qt provided examples (aclock) shows very 
different results:

SuSE9.1
         linux-gate.so.1 =>  (0xffffe000)
         libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x4003f000)
         libpng.so.3 => /usr/lib/libpng.so.3 (0x40728000)
         libz.so.1 => /lib/libz.so.1 (0x40756000)
         libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40768000)
         libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40770000)
	...

SuSE9.0
         libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x40036000)
         libpng.so.3 => /usr/lib/libpng.so.3 (0x4075b000)
         libz.so.1 => /lib/libz.so.1 (0x40789000)
         libGLU.so.1 => /usr/lib/libGLU.so.1 (0x40798000)
         libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x40816000)
         libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40881000)
         libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40897000)
	...

Also ldd for kfind also show similar differences.  Don't know why GL 
(and Xmu) are being linked in for non GL qt apps.

However it does suggest it has nothing to do with python, and probably 
Qt version/build related.

Re: [PyOpenGL-Users] bus error on gluNewQuadric()

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

Tom Dossis wrote:
>>>> i am working on the OS X port of a program and I get a "bus error" 
>>>> caused by this opengl code (it didnt happen on Windows)
>>>> q = gluNewQuadric()
>>>>
>>> I have run into this same problem without PyOpenGL involved at all.  
>>> A Google search turned up this post:
>>>
>>> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html 
>>>
>>>
>>> By swapping the order of -lGL and -lGLU when linking, I was able to 
>>> fix the problem I had.
>>
>>
>> do you mean that on the imports i should swap the order of these 
>> instructions?
>>
>> from OpenGL.GL import *
>> from OpenGL.GLU import *
>>
>> I tried this and i get the same error. maybe i dont understand what 
>> you mean?
> 
> 
> Changing the python code won't make any difference.
> The link instruction above relates to building the pyopengl package.
> 
> It may be worthwhile to try the pyopengl Demo/NeHe/lesson18.py 
> referenced at the end of the page:
> http://pyopengl.sourceforge.net/documentation/manual/gluNewQuadric.3G.xml
> 
> At least this will remove wxpython from the equation.

So you mean that i have to compile myself pyopengl with the changes you 
mention? There is no other workaround this?

-- 
enrike

[PyOpenGL-Users] Python Qt OpenGL program: Xmu dependency

[Jo V. <jo...@lu...>]

Hello,

I'm started working on an terrain editor using OpenGL, Qt and Python. I
can't start the application, since it depends on Xmu, and can't find
this library (it is installed though). I'm using Debian GNU/Linux
unstable.

Here is the error message:

disabling TCL support
Unable to resolve Xmu symbols - please check your Xmu library
installation.

Maybe it has something to do with the Qt OpenGL bindings?

The (really small) source code can be found here:

http://lumumba.luc.ac.be/~jo/temp/terrain_code/terrain.zip

I hope someone can help me here. Thanks in advance!

Kind regards,

-- 
Jo Vermeulen <jo...@lu...>

Re: [PyOpenGL-Users] bus error on gluNewQuadric()

[Tom D. <td...@yo...>]

>>> i am working on the OS X port of a program and I get a "bus error" 
>>> caused by this opengl code (it didnt happen on Windows)
>>> q = gluNewQuadric()
>>>
>> I have run into this same problem without PyOpenGL involved at all.  A 
>> Google search turned up this post:
>>
>> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html
>>
>> By swapping the order of -lGL and -lGLU when linking, I was able to 
>> fix the problem I had.
> 
> do you mean that on the imports i should swap the order of these 
> instructions?
> 
> from OpenGL.GL import *
> from OpenGL.GLU import *
> 
> I tried this and i get the same error. maybe i dont understand what you 
> mean?

Changing the python code won't make any difference.
The link instruction above relates to building the pyopengl package.

It may be worthwhile to try the pyopengl Demo/NeHe/lesson18.py 
referenced at the end of the page:
http://pyopengl.sourceforge.net/documentation/manual/gluNewQuadric.3G.xml

At least this will remove wxpython from the equation.

Good luck.

Re: [PyOpenGL-Users] bus error on gluNewQuadric()

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

Patrick Hartling wrote:
> altern wrote:
> 
>> hi
>>
>> i am working on the OS X port of a program and I get a "bus error" 
>> caused by this opengl code (it didnt happen on Windows)
>> q = gluNewQuadric()
>>
>> anyone knows if this is a bug on pyOpengl under mac? i am opening the 
>> opengl canvas on a wx window. i am not sure if this could be part of 
>> the problem
> 
> 
> I have run into this same problem without PyOpenGL involved at all.  A 
> Google search turned up this post:
> 
> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html
> 
> By swapping the order of -lGL and -lGLU when linking, I was able to fix 
> the problem I had.


do you mean that on the imports i should swap the order of these 
instructions?

from OpenGL.GL import *
from OpenGL.GLU import *

I tried this and i get the same error. maybe i dont understand what you 
mean?






-- 
enrike

[PyOpenGL-Users] Screenshots, collection of...

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

I'm thinking it would be nice to have at least *some* graphics on the 
PyOpenGL site, so I'm wondering if people could forward me images of 
their projects that they would like to share.  I've put up a contact 
sheet for some OpenGLContext screenshots here:
    http://pyopengl.sourceforge.net/screenshots/context
with the idea being that /screenshots/ will be the place for the raw 
PyOpenGL screenshots.

I'll try to be judicious in what I include.  We don't want to have *too* 
many (if there's a lot from a single project, may just point to your 
project's screenshots page), and would prefer that they be "catchy" 
(after all, this is marketing :) ).  Would, for instance, love to 
replace those two red spheres in the OpenGLContext screenshots with 
something *interesting* demonstrating the smooth-shading feature.

Have fun all,
Mike

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

Re: [PyOpenGL-Users] bus error on gluNewQuadric()

[Patrick H. <pa...@in...>]

altern wrote:
> hi
> 
> i am working on the OS X port of a program and I get a "bus error" 
> caused by this opengl code (it didnt happen on Windows)
> q = gluNewQuadric()
> 
> anyone knows if this is a bug on pyOpengl under mac? i am opening the 
> opengl canvas on a wx window. i am not sure if this could be part of the 
> problem

I have run into this same problem without PyOpenGL involved at all.  A 
Google search turned up this post:

http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html

By swapping the order of -lGL and -lGLU when linking, I was able to fix 
the problem I had.

  -Patrick


-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3          | http://www.infiscape.com/

[PyOpenGL-Users] bus error on gluNewQuadric()

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

hi

i am working on the OS X port of a program and I get a "bus error" 
caused by this opengl code (it didnt happen on Windows)
q = gluNewQuadric()

anyone knows if this is a bug on pyOpengl under mac? i am opening the 
opengl canvas on a wx window. i am not sure if this could be part of the 
problem

thanks

-- 
enrike

[PyOpenGL-Users] PyOpenGL 2.0.1.09 bug-fix release available

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

You can find the release at the usual location:
    http://pyopengl.sourceforge.net

I've only tested the release on Win32 (my Linux install being a little 
messed up at the moment).  If some enterprising Linux user wants to 
compile and confirm operation on Linux that would be great.

Have fun all,
Mike

Release notes:

    INCOMPATIBLE CHANGE:

        glDrawPixelsXX fixes to use arrays specified with "natural"
    ordering,
        that is, a 200x100 pixel array is specified as an array with shape
        of (200,100,3), rather than (100,200,3).  This matches the
    semantics of
        the string form, and allows glGetPixels and glGetTextureLevel
    results
        to be passed directly in to glDrawPixelsXX.  If you need to use the
        previous form, set:
            array.shape = (array.shape[1],array.shape[0]) + array.shape[2:]
        before the call to glDrawPixels

    Fix bug with glGetTexLevel where width was queried twice instead of
    height,
    were also queried in the reverse order (see glDrawPixelsXX changes).

    Also fix off-by-one bug in the code to generate the glGetTexLevel array
    (for the dimensions, which would have resulted in unusable images
    had anyone
     been able to get past the previous bug).

    Memory leak fix for Numeric versions of _PyObject_FromArray

    Brian Leair's submitted versions of NEHE tutorials 13, 41-45 and 48

    Togl:

        Fix for yet more Togl building problems in modern Linux (Gentoo,
    Fedora Core)

        Avoid warning message if Togl is not set to build

    Added placeholder files for the directories used in building the
    documentation set.

    Use include and lib directories for compiling version-selector files,
    warn on failure to compile version selector.

    Support Python 2.4 distutils bdist_wininst, which now has the
    customisation
    point we need (and doesn't work with the old sub-class that produces the
                   customisation point for Python 2.3 and below)

    Print message to stderr on failure of a glu tessellation callback
    notifying
    the user of from where the traceback came.

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

[PyOpenGL-Users] gluUnProject() and glReadPixels()

[Ian K. <Ian...@rm...>]

I am using a glFrustum projection and am trying to convert mouse event (pixel) coordinates to model coordinates.

I am having problems getting the window Z coordinate.

As I understand, the Z coord is the depth buffer value expressed as a GLdouble with a range of 0-1.  0 being the near clip plane, and 1 being the far clip plane.  My model view is a single textured surface in the x-y plane at z = 0 (object coord) - a 2d map.

I have tried to used glReadPixels to get the win Z coord - but I can't get this function to return a GLDouble, hence gluUnProject doesn't like it.

Looking at the glReadPixels manpages there is a glReadPixelsd() - but pyhton doesn't like this too much.

z = glReadPixels(self.GetParent().xclick,300-self.GetParent().yclick, 1, 1, GL_DEPTH_COMPONENT, ???)
            
worldcoord = gluUnProject(self.GetParent().xclick,300-self.GetParent().yclick,z,model,projection,viewport)

I have looked at OpenGLContext briefly - would rather not use if my problem cam be solved without this module, but open to suggestions at this point!

Thanks

Ian

Re: [PyOpenGL-Users] Rectangle textures on Mac OS X

[Daniel H. <da...@bo...>]

Hi Mike,

Firstly - thanks for jumping all the way to doing this.

Looks like the extension has made it thro ARB approval.  I found the EXT 
version here:
http://developer.apple.com/graphicsimaging/opengl/extensions.html
specifically:
http://developer.apple.com/graphicsimaging/opengl/extensions/ext_texture_rectangle.html

It will be a little while before I can test this: my question was 
preempting some porting work, but I'll let you know if there are any 
troubles when I do.

Cheers,
Daniel



Mike C. Fletcher wrote:

> Daniel Heckenberg wrote:
> ...
> 
>> I've noticed that there doesn't seem to be support for 
>> GL_EXT_rectangle_texture in PyOpenGL at the moment.  I'm sure that it 
>> would be straightforward to add this somehow... it's just an 
>> additional target enum after all.  Is there a mechanism for checking 
>> for arbitrary extensions, or would it be easy to add this extension to 
>> those included in the OpenGL.GL.EXT module?
> 
> 
> Where are you reading about this extension?  AFAICT it doesn't show up 
> in the extension registry
>    http://oss.sgi.com/projects/ogl-sample/registry/index.html
> or in my copy of glext.h (downloaded today).
> 
> I see this:
>    
> http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt
> which I *assume* is what you want, and also these:
>    http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_rectangle.txt
>    
> http://oss.sgi.com/projects/ogl-sample/registry/NV/render_texture_rectangle.txt 
> 
> 
> I've just checked in a module providing the ARB extension.  Should show 
> up in the next PyOpenGL release (which, if I ever get the time, should 
> be showing up any day now).
> 
> BTW, list-peoples, if you have simple extensions like this that you need 
> wrapped, you can do the wrapping yourself and submit the module to me.  
> It's basically all just boilerplate with the particular defines involved 
> tacked onto the end of the file.  Functions/methods get a little more 
> involved what with the need to support dynamic loading, but simple 
> constants-only extensions are trivial to implement.
> I tend not to wrap anything I can't test, so (given the rather outdated 
> hardware I'm running) there's not much movement on the extensions these 
> days unless people want to work on it themselves.
> 
> Have fun,
> Mike
> 
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
> 
> 

Re: [PyOpenGL-Users] Rectangle textures on Mac OS X

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

Daniel Heckenberg wrote:
...

> I've noticed that there doesn't seem to be support for 
> GL_EXT_rectangle_texture in PyOpenGL at the moment.  I'm sure that it 
> would be straightforward to add this somehow... it's just an 
> additional target enum after all.  Is there a mechanism for checking 
> for arbitrary extensions, or would it be easy to add this extension to 
> those included in the OpenGL.GL.EXT module?

Where are you reading about this extension?  AFAICT it doesn't show up 
in the extension registry
    http://oss.sgi.com/projects/ogl-sample/registry/index.html
or in my copy of glext.h (downloaded today).

I see this:
    
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt
which I *assume* is what you want, and also these:
    http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_rectangle.txt
    
http://oss.sgi.com/projects/ogl-sample/registry/NV/render_texture_rectangle.txt

I've just checked in a module providing the ARB extension.  Should show 
up in the next PyOpenGL release (which, if I ever get the time, should 
be showing up any day now).

BTW, list-peoples, if you have simple extensions like this that you need 
wrapped, you can do the wrapping yourself and submit the module to me.  
It's basically all just boilerplate with the particular defines involved 
tacked onto the end of the file.  Functions/methods get a little more 
involved what with the need to support dynamic loading, but simple 
constants-only extensions are trivial to implement. 

I tend not to wrap anything I can't test, so (given the rather outdated 
hardware I'm running) there's not much movement on the extensions these 
days unless people want to work on it themselves.

Have fun,
Mike

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

[PyOpenGL-Users] Rectangle textures on Mac OS X

[Daniel H. <da...@bo...>]

Hi list,

I've noticed that there doesn't seem to be support for 
GL_EXT_rectangle_texture in PyOpenGL at the moment.  I'm sure that it 
would be straightforward to add this somehow... it's just an additional 
target enum after all.  Is there a mechanism for checking for arbitrary 
extensions, or would it be easy to add this extension to those included 
in the OpenGL.GL.EXT module?

Thanks,
Daniel

[PyOpenGL-Users] Sharing textures amongst multiple windows

[Daniel H. <da...@bo...>]

Hi All,

I'm wondering what is the best way of setting up multiple views of a 
scene in multiple windows using wxPython and PyOpenGL.

I've managed to hack this for Win32 using separate windows and rendering 
contexts using wglShareLists(), but it seems that a cross-platform 
solution may be possible using multiple windows that share a single 
rendering context.  I think that wx.glcanvas.GLCanvasWithContext() might 
be the method for this but I haven't been able to find an example or 
documentation (this is a wxPython issue, I know).

Any tips or examples would be appreciated.

Thanks,
Daniel

Re: [PyOpenGL-Users] Upcoming fix may cause minor incompatibility...

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

Just to expand a little on this:

    glDrawPixelsXX previously was working on the assumption that the
    graphics passed to it were stored such that array[0] was the first
    row.  This meant that if you did array.tostring() and passed the
    array dimensions in to glDrawPixels you would wind up with a trashed
    image (since Numpy packs arrays to strings from the lowest dimension
    up).  By switching to assuming that array[0] gives the first column
    of the image (that is, that the first dimension represents the index
    *into* the first row), we are basically using the natural order of
    the array and also making the two types of glDrawPixels calls match
    up as expected; so that array[20,30] is the pixel twenty from the
    right and 30 from the bottom, and dumping to a string and passing
    array dimensions works the same as passing in the array.

I've so far come across 1 instance of an incompatibility in 
OpenGLContext.  It actually turned out to be quite nasty (the 
work-around works fine, but figuring out how to eliminate the huge 
series of convolutions through which the code goes at the moment has 
been a bit of a pain...).

Have fun all,
Mike

Mike C. Fletcher wrote:

> I've just checked in changes on the 2.0.1 maintenance branch that fix 
> a bug in how glDrawPixelsXX (that is, all glDrawPixels calls which 
> take an array argument, rather than a string) operates.  The code was 
> previously (unintentionally) reversing the first and second arguments, 
> so that it would take (height,width) rather than (width,height) from 
> the array to decide how to render it.
>
> If you have any code that uses glDrawPixelsXX you will find that this 
> fix causes your code to stop working.  Solution is simply to use 
> properly-sized arrays (i.e. if you want an image 300x100 pixels wide 
> it's shape should be (300,100,depth), rather than (100,300,depth)).  
> If you can't make that change, then simply assigning array.shape = 
> (array.shape[1],array.shape[0]) + array.shape(2:])  will allow you to 
> continue operating as before.
>
> This bug does not affect string-based glDrawPixels calls.
>
> Enjoy yourselves,
> Mike

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

[PyOpenGL-Users] Upcoming fix may cause minor incompatibility...

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

I've just checked in changes on the 2.0.1 maintenance branch that fix a 
bug in how glDrawPixelsXX (that is, all glDrawPixels calls which take an 
array argument, rather than a string) operates.  The code was previously 
(unintentionally) reversing the first and second arguments, so that it 
would take (height,width) rather than (width,height) from the array to 
decide how to render it.

If you have any code that uses glDrawPixelsXX you will find that this 
fix causes your code to stop working.  Solution is simply to use 
properly-sized arrays (i.e. if you want an image 300x100 pixels wide 
it's shape should be (300,100,depth), rather than (100,300,depth)).  If 
you can't make that change, then simply assigning array.shape = 
(array.shape[1],array.shape[0]) + array.shape(2:])  will allow you to 
continue operating as before.

This bug does not affect string-based glDrawPixels calls.

Enjoy yourselves,
Mike

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

[PyOpenGL-Users] glCanvas and wxPaintDC

[Ian K. <Ian...@rm...>]

Using glcanvas I have implemented a crude map browser.  I am now trying to draw wxpython graphics onto the canvas, lines, rectangles etc - the endstate is to track mouse movements, but just a libe would be good for now.

Do I need to create a transparent bitmap and overlay this on top of the glCanvas ?

Is there an easier way?  Right now I am trying to draw to the wx.PaintDC (see code below) and not having much luck.  When I insert a draw command such as DrawLine the appication spins in an infinite loop.

I am using a glFrustum projection and varying the camera position to zoom and pan - I would track mouse movement with opengl lines but mapping opengl to window coords is difficult (possible ?)

Here is the code that spins me in a loop

def OnPaint(self, event=None):
        
        dc = wx.PaintDC(self) 
        self.DoDrawing(dc) #call to draw some shapes in pixel coord
        self.SetCurrent()    #set this canvas to recieve Opengl calls
        size = self.GetClientSize()   
        #glViewport( 0,0, *size )  #viewport fixed 
        self.DrawGL()   #call to draw opengl model
        #??need to confirm if I double buffer only opengl and/or wxpython??
        print"paint"
        self.SwapBuffers()
    
    def DoDrawing(self, dc = None): #draw wxpython graphics 
        if dc is None:
            dc = wx.Client(self)
        dc.BeginDrawing()
        pen = wx.Pen(wx.WHITE,4,wx.SOLID)
        dc.SetPen(pen)
        dc.DrawRectangle(10,10,300,300)  #does not like this
        print"draw here"
        dc.EndDrawing()

Ian Krepps
Ian...@rm...

Re: [PyOpenGL-Users] NeHe Lesson 6

[Alexander S. <scr...@lx...>]

Ian Krepps wrote:
> I am playing around with lesson6.py in the demo files (ported to PyOpenGL 2.0 by Tarn Weiser Burton, original source C based turtorial at nehe.gamedev.net).
> 
> When I replace the "NeHe.bmp" file with other bmp files (of similar size) I get the following error:
> 
> File "lesson6.py", line 76, in LoadTextures
>     glTexImage2D(GL_TEXTURE_2D, 0, 3, ix, iy, 0, GL_RGBA, GL_UNSIGNED_BYTE, image)
> OpenGL.GL.GLerror: [Errno 1281] invalid value
> 
>>Exit code: 1
> 
> 
> I have checked the manpages for glTexImage2D for the error INVALID_VALUE (I believe this is correct), but I am unable to figure out the source of the error.  
> 
> Has anyone else seen this problem ? Do I need to perform some error checks on the bmp format prior to calling glTexImage2D ? I am new to Opengl.
> An extract from the source code (lesson6.py is below)

Double-check if the bitmap width and height are powers of 2 and meet your 
OpenGL implementation's limits on texture size.

  --

./lxnt

[PyOpenGL-Users] rendering fonts using pygame

[fulko <vw...@fv...>]

Hello,

The font rendering problem kept me busy for some time now.

I tried to use OpenGLContext to draw various fonts in OpenGL under
Python, unfortunately without success. To solve the problem I started
to dissect the files in scenegraph/text, but without much result.

My goal is to select one TTF-file (e.g. arial.ttf), use the PyGame
library to render the font in a particular size (preferably
anti-aliased), and put the result in my OpenGL buffer.

This is my understanding of the process until now:

Pygamefont.py provides PyGameBitmapFont that can be used to create a
font object. Then createChar can be used to compile a display list for
each character desired.

Font.py seems to provide the routines to convert a string into a list
of display lists, and put these in the colour buffer.

My idea is changing the routines so I can do something like this:

x=PyGameBitmapFont('arial.ttf',20)
textstring='My Text'
lines=[]
for c in textstring:
    lines.append(x.createChar(c,'anti-aliased'))
BitmapFontMixIn.leftJustify(lines,pos)


I would like to make the code as lean as possible, so I can understand
the process and tune it to my needs. Am I on the right way?

Thanks,
Fulko