pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] Re: [wxPython-users] Multiple wxGLCanvas in one process

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

I sit corrected.  I played around with stopping and starting that 
test-case with the external buttons, but never thought to check the 
keyboard/mouse event bindings.  This does appear to be something weird 
going on at the wxPython level.  In particular, the context windows 
appear to not properly restrict certain types of events to the context 
to which they are applied.  That is, if you do this:

            EVT_LEFT_DOWN( self, self.wxOnMouseButton )
            EVT_RIGHT_DOWN( self, self.wxOnMouseButton )
            EVT_MIDDLE_DOWN( self, self.wxOnMouseButton )
            EVT_LEFT_UP( self, self.wxOnMouseButton )
            EVT_RIGHT_UP( self, self.wxOnMouseButton )
            EVT_MIDDLE_UP( self, self.wxOnMouseButton )
            EVT_MOTION( self, self.wxOnMouseMove )

as OpenGLContext does, where self is a wxGLCanvas-derived class, you do 
get the mouse-events registered, but *all* of the contexts direct their 
events to the last-created context AFAICS... that is, the different 
context windows appear to share a single dispatch table, so the last 
context to call EVT_* will be the only one with active callbacks.  Same 
problem shows up for keyboard bindings (EVT_KEY_DOWN, EVT_KEY_UP, EVT_CHAR).

That would *seem* to be a wxPython bug (there's nothing OpenGL specific 
here, the window is getting passed a Python function to call, that 
function just happens to manipulate the OpenGL context(s)).

BTW, the EVT_PAINT, EVT_SIZE, and EVT_ERASE_BACKGROUND events *do* 
appear to be properly routed, it's just the keyboard/mouse events that 
appear to be shared among the contexts.

Sorry for the wasted bandwidth all, this should be discussed on wxPython 
list after all.

Have fun,
Mike

Mike C. Fletcher wrote:

> Can't really give much help without considerably more information 
> (such as *what* is showing up as shared between the contexts).  It's 
> definitely possible to run multiple OpenGL contexts within a wxPython 
> application, at least in my limited testing.  I've attached a script 
> which creates two independent OpenGLContext contexts within the same 
> frame.  OpenGLContext is fairly anal about making sure everything 
> occurs within SetCurrent calls, but you say you're doing that already.

...

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

[PyOpenGL-Users] Re: [wxPython-users] Multiple wxGLCanvas in one process

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

Can't really give much help without considerably more information (such 
as *what* is showing up as shared between the contexts).  It's 
definitely possible to run multiple OpenGL contexts within a wxPython 
application, at least in my limited testing.  I've attached a script 
which creates two independent OpenGLContext contexts within the same 
frame.  OpenGLContext is fairly anal about making sure everything occurs 
within SetCurrent calls, but you say you're doing that already.

That said, I very seldom actually create multiple contexts, so they 
don't get tested much by *me*, so there may be an error in how PyOpenGL 
is handling the contexts (e.g. it may have an error in the array-pointer 
management).  (Would be helpful to know PyOpenGL version, platform, and 
graphics card for tracking down such a problem, (a test-case showing the 
problem tends to make debugging & fixing go much faster too ;) )).

BTW, probably best to ask these kinds of questions on the PyOpenGL list, 
as OpenGL isn't really a *common* thing (AFAIK) in which wxPython people 
specialise, (and most likely this is going to be an OpenGL (possibly 
usage) error, rather than anything to do with wxPython).

Good luck,
Mike

Luc Bourhis wrote:

> I've run into an insoluble problem with wxPython (2.5.x release). I 
> have created a widget containing 2 instances of classes derived from 
> wxGLCanvas: they seem to share at least part of the OpenGL context. I 
> do call SetCurrent in a timely manner, first thing after catching the 
> "paint" and the "resize" event, before any actual drawing or resizing. 
> But it is still rather obvious there is interference between the both 
> of these instances.
>
> Any pointer? I cannot find any reference to such an issue on the 
> mailing lists.

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

Re: [PyOpenGL-Users] tessellation example

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

You don't actually need much of OpenGLContext. The 
OpenGLContext/scenegraph/polygontessellator.py module is only dependent 
on the utilities module, which is just providing very low-level 
operations such as cross and dot products, and the vertex module, which 
is just a trivial modeling of a vertex.

With the polygontessellator module, the code to tessellate a polygon is 
that seen in OpenGLContext/tests/glu_tess.py, to wit:

        for type, vertices in self.tess.tessellate( vertices, 
forceTriangles=0 ):
            glNormal( 0,0,-1 )
            glBegin( type )
            for v in vertices:
                glVertex2dv( v.point )
            glEnd()

Though there's more to it to actually use each vertex's colour, normal, 
etceteras, but that's all pretty straightforward, they're just 
attributes of the vertex object.

There's also a method tessContours which allows for defining 
multiple-contour shapes, such as those between two map contour lines.  
Anyway, just reading the polygontessellator module should give you just 
about everything you need to do tessellation.

Good luck,
Mike

Fulko van Westrenen wrote:

>Hello,
>
>I wrote a geographical-map display-system. The whole thing works
>very nice, but needs a major improvement. At the moment all areas
>only have the boundaries drawn, and I would like to have them filled.
>Tessellation seems the answer, and glu my friend. I looked it up in
>the red_book, but that was far too complex for me. Then I studied
>OpenGLContext; very hard for me to rewrite for my needs.
>
>Does someone have a clean and _simple_ example-program that converts
>a list of funny shaped polygons (like shorelines) into a list of
>convex polygons?
>
>Thanks for any help.
>
>Fulko
>  
>
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] tessellation example

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

Hello,

I wrote a geographical-map display-system. The whole thing works
very nice, but needs a major improvement. At the moment all areas
only have the boundaries drawn, and I would like to have them filled.
Tessellation seems the answer, and glu my friend. I looked it up in
the red_book, but that was far too complex for me. Then I studied
OpenGLContext; very hard for me to rewrite for my needs.

Does someone have a clean and _simple_ example-program that converts
a list of funny shaped polygons (like shorelines) into a list of
convex polygons?

Thanks for any help.

Fulko


-- 
Fulko van Westrenen

Re: [Soya-user] Re: [PyOpenGL-Users] problem with soya's usage of OpenGL

[Christopher A. <ra...@tw...>]

Mike C. Fletcher wrote:

Thanks for the help, Mike! I don't know if you remember, but I think we 
met at PyCon this year; I was rambling about how horrible the scene is 
for open source 3d game engines with you and Tamer ;)

> We don't do anything particularly fancy in the wrapper for glGetString, 
> here's what it looks like for the generated OpenGL 1.1 wrapper from 
> PyOpenGL 2.0.1.08:
> 
[snip C code]

Here's the C code that's being generated from pyrex from that snippet I 
showed in my post:

   char (*__pyx_v_gl_vendor);
   /* ... */
   int __pyx_2;
   /* ... */

   /* "/home/radix/Projects/soya/init.pyx":307 */
   __pyx_v_gl_vendor = ((char (*))glGetString(GL_VENDOR));

   /* "/home/radix/Projects/soya/init.pyx":308 */
   __pyx_2 = (__pyx_v_gl_vendor == 0);
   if (__pyx_2) {
     /* etc */


So the (__pyx_v_gl_vendor == 0) is ALWAYS true, no matter WHAT I pass to 
glGetString (I tried random numbers like 9999), and glCheckError is 
NEVER returning an error code. Are all of those (implicit) casts reasonable?

I also checked that the value of GL_VENDOR is expected; it's the same as 
PyOpenGL.GL.GL_VENDOR.

>  From the docs: 
> (http://pyopengl.sourceforge.net/documentation/manual/glGetString.3G.xml)
>            GL_INVALID_OPERATION is generated if glGetString is executed 
> between the
>            execution of glBegin and the corresponding execution of glEnd.
> 
> I'd confirm that you are not calling this within those functions.  

I checked with Jiba, as well as the soya source code, and indications 
are that it's not being called between glBegin and glEnd.

 > That
> and an invalid enum (feature-name) are the only two listed errors, and a 
> 0 (NULL) return value apparently only occurs on error.  Could your 
> GLenum somehow be suffering from an off-by-one or similar error such 
> that it's giving you lots of "invalid enum" errors across many parts of 
> the API?

Something might be going wrong with my error checking code, since no 
matter what I pass to glGetString, I'm not getting any errors.

I should mention that this code is working for other people; but I don't 
know if any of those other people are using the implementation of OpenGL 
provided by NVidia's proprietary Linux drivers (anyone?).

Thanks for the help, I'll flail around at the problem some more.


-- 
  Twisted | Christopher Armstrong: International Man of Twistery
   Radix  |          Release Manager,  Twisted Project
---------+           http://radix.twistedmatrix.com/

Re: [PyOpenGL-Users] problem with soya's usage of OpenGL

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

We don't do anything particularly fancy in the wrapper for glGetString, 
here's what it looks like for the generated OpenGL 1.1 wrapper from 
PyOpenGL 2.0.1.08:

static PyObject *_wrap_glGetString(PyObject *self, PyObject *args) {
    PyObject *resultobj;
    GLenum arg1 ;
    GLubyte *result;
    PyObject * obj0  = 0 ;
   
    if(!PyArg_ParseTuple(args,(char *)"O:glGetString",&obj0)) return NULL;
    arg1 = (GLenum) PyInt_AsLong(obj0);
    if (PyErr_Occurred()) return NULL;
    {
        result = (GLubyte *)glGetString(arg1);
        if (GLErrOccurred()) return NULL;
    }
    {
        if (result)
        {
            resultobj= PyString_FromString(result);
        }
        else
        {
            Py_INCREF(resultobj = Py_None);
        }
    }
    return resultobj;
}

I can't see anything there which is markedly different from your 
approach.  PyOpenGL is fairly minimal wrt what it sets up for contexts.  
AFAIK we aren't doing anything funky with initialising our reference to 
OpenGL, leaving the context-creation work to the GUI libraries as much 
as possible, (though I should note that that stuff would all have been 
written by someone else, so it could be we spend thousands of lines of 
code on it somewhere and I've just missed it during maintenance).  We do 
some minimal stuff such as defining functions for retrieving the current 
context under OpenGL 1.0, but I doubt that's relevant.

 From the docs: 
(http://pyopengl.sourceforge.net/documentation/manual/glGetString.3G.xml)
            GL_INVALID_OPERATION is generated if glGetString is executed 
between the
            execution of glBegin and the corresponding execution of glEnd.

I'd confirm that you are not calling this within those functions.  That 
and an invalid enum (feature-name) are the only two listed errors, and a 
0 (NULL) return value apparently only occurs on error.  Could your 
GLenum somehow be suffering from an off-by-one or similar error such 
that it's giving you lots of "invalid enum" errors across many parts of 
the API?

Seems your check_gl_error() isn't picking up the failure for some 
reason, but that doesn't solve the base problem.

Good luck,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] problem with soya's usage of OpenGL

[Christopher A. <ra...@tw...>]

Hello soya-user, hello pyopengl-users. This message isn't _totally_ 
relevant to pyopengl-users, but it's not unlikely that you guys have the 
requesite knowledge to help me fix this problem.

I've been trying to get Soya3d 
(http://home.gna.org/oomadness/en/soya/index.html) working for a while, 
but it's got problems with initialization. Soya3d talks to the OpenGL 
API directly with Pyrex. The problem is that a bunch of the calls it's 
making to OpenGL are returning NULL, while PyOpenGL calls to the same 
functions are returning expected values. At first we thought this was a 
problem with the way Soya was initializing GL (It uses SDL_Init to 
accomplish this), like it wasn't properly waiting for the OpenGL system 
to be initialized before it was making the calls. But to disprove that, 
I wrote this bit of Pyrex code:


.. inside of soya's init() function...
   from OpenGL import GL
   print "PyOGL:", GL.glGetString(GL.GL_VENDOR)
   my_dump_info()

cdef void my_dump_info():
   cdef char* gl_vendor
   gl_vendor = <char*> glGetString(GL_VENDOR)
   if gl_vendor == NULL:
     print "OGL: Wargh glGetString returned NULL"
     check_gl_error()
   else:
     print "OGL:", PyString_FromString(gl_vendor)


GL.glGetString was returning the expected "NVIDIA Corporation", but the 
direct call to the C glGetString is still returning NULL. The call to 
check_gl_error does a glCheckError, but that's returning GL_NO_ERROR. 
The same thing happens for stuff like glGetIntegerv.

So the only conclusion I can draw here is that somehow the PyOpenGL 
interface is calling these functions in a way that's different from 
pyrex's direct calls to them. I tried reading through the source of 
PyOpenGL but the SWIG stuff wasn't elucidative. It just seems like the 
wrappers are pretty direct. Does PyOpenGL involve some kind of different 
context that it might use where a direct call to the C interface wouldn't?

-- 
  Twisted | Christopher Armstrong: International Man of Twistery
   Radix  |          Release Manager,  Twisted Project
---------+           http://radix.twistedmatrix.com/

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

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

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

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

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

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

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

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2004-07-18 20:48

Message:
Logged In: YES 
user_id=34901

2.0.1.08 has the binary installer.

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

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

Message:
Logged In: YES 
user_id=34901

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

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

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

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

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

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

[PyOpenGL-Users] Minor bug-fix release 2.0.1.08 available

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

You can get it here:

    http://pyopengl.sourceforge.net/
    
http://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035

Release notes:

This is a minor bug-fix release based on the PyOpenGL 2.0.1-maint branch 
in CVS.  The biggest user-visible change is likely that the Win32 
binaries include Togl, (the dev-2_1 revision of the Togl build mechanism 
has been back-ported, so it's much easier to build Togl now).  For Linux 
peoples, builds out-of-the-box on Gentoo, and likely Fedora Core2.

    * Backport of dev-2_1 Togl build fixes
    * glMap1d/glMap1f fix for parameter reference in the typemap
    * Added __init__.py to da demo.
    * Fix for systems where a SWIG version > 1.3.13 is installed.

I've built and tested against Python 2.4a1 as well, and all seems to be 
fine there, but I can't generate a bdist_wininst due to what appears to 
be a 2.4 distutils bug.

Enjoy yourselves,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

Re: [PyOpenGL-Users] OpenGLContext-2.0.0b2.win32-py2.3.exe problems

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

Daniel Heckenberg wrote:

>Hi Mike,
>
>----- Original Message ----- 
>From: "Mike C. Fletcher" <mcf...@ro...>
>  
>
>>If you could try
>>running each of wxcontext.py (will likely fail due to a missing/bad
>>bitmap), glutcontext.py, and pygamecontext.py and report which of those
>>is producing the error it should help me narrow down where the error is.
>>
>>Of course, if the error is actually in PyOpenGL, then they should all
>>fail.  The error itself *looks* like a problem with PyOpenGL which
>>OpenGLContext just happens to be triggering.  Still shouldn't happen,
>>and they're both my projects, so I'd like to track it down.
>>    
>>
I haven't been able to reproduce the error on a Win98 laptop or a Win2K 
workstation.  The binary distribution seems to work fine on both of them.

Will keep trying,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] Using Trackball

[John M. <jo...@jo...>]

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

Is there any examples of how to use OpenGL.Trackball? All it says is
that you supply 2 points to the trackball, and then you use .matrix to
get the rotation matrix out.

But what points do you supply? Does it only rotate around the (0,0,0)
axis, so you need to do your own translations, etc? (I assume it has
to). At that point, when do you do the translation for an object?

Etc, etc. I've tried using it, but it usually looks really bad. Like it
will rotate, but it distorts the image as it goes, that sort of thing. I
haven't tried a lot lately, but I was hoping that I could have an
example to go off of.

Thanks,
John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA9u3QJdeBCYSNAAMRAkbsAKCXST/D40T90THOa8rALKAq+1Tn7QCfUZKx
ZiFOxxweB2ftblhFaH3/bn8=
=w9rq
-----END PGP SIGNATURE-----

Re: [PyOpenGL-Users] Problem with PyOpenGL and Python 2.3

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

Mike Pentney wrote:
...

>PyOpenGL-2.0.1.07.py2.3-numpy23.exe
>Numeric-23.1.win32-py2.3.exe
>glut32.dll (version 3.7)
>
>When I try to run an OpenGL script (for example, "openGLDemo.py" included
>with the PythonWin distribution), Python crashes with an application error
>(a memory access violation). Python also spits out a few exceptions, the
>first of which is:
>
>ImportError:  No module named numarray.libnumarray
>  
>
You will need to install NumArray as well, which is a follow-on project 
to Numpy.  The machine on which the binary installer was built had 
NumArray installed, and for some silly reason that alters the *Numpy* 
installation such that anything linked against Numpy on that machine has 
a (pointless) dependency on NumArray.  C is such a silly thing that way.

>Any ideas? Am I using the wrong version of "numpy"?
>  
>
Numpy is fine, you just need to add NumArray to the mix.

HTH,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] Problem with PyOpenGL and Python 2.3

[Mike P. <mik...@ph...>]

Hi,

I'm trying to get PyOpenGL up and running on my Windows XP (Home edition)
system. I'm using the ActiveState PythonWin version 2.3.2, and I've
downloaded and installed the following packages:

PyOpenGL-2.0.1.07.py2.3-numpy23.exe
Numeric-23.1.win32-py2.3.exe
glut32.dll (version 3.7)

When I try to run an OpenGL script (for example, "openGLDemo.py" included
with the PythonWin distribution), Python crashes with an application error
(a memory access violation). Python also spits out a few exceptions, the
first of which is:

ImportError:  No module named numarray.libnumarray

Any ideas? Am I using the wrong version of "numpy"?

Many thanks for any help you can give me.

Mike Pentney.

p.s. you'll have guessed that I'm new to Python, but so far I'm very
impressed. I can't wait to start implementing real projects! (I'll be
especially pleased to get away from Visual Studio .net  :-)

Re: [PyOpenGL-Users] OpenGLContext-2.0.0b2.win32-py2.3.exe problems

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

Hi Mike,

----- Original Message ----- 
From: "Mike C. Fletcher" <mcf...@ro...>
> If you could try
> running each of wxcontext.py (will likely fail due to a missing/bad
> bitmap), glutcontext.py, and pygamecontext.py and report which of those
> is producing the error it should help me narrow down where the error is.
>
> Of course, if the error is actually in PyOpenGL, then they should all
> fail.  The error itself *looks* like a problem with PyOpenGL which
> OpenGLContext just happens to be triggering.  Still shouldn't happen,
> and they're both my projects, so I'd like to track it down.


wxcontext.py fails with "invalid image"

glutcontext.py causes the crash i experience with the examples

pygamecontext.py fails with
"Pygame Parachute Traceback:
  File "C:\PYTHON23\Lib\site-packages\OpenGLContext\renderpass.py", line
691, in
 getProjection
Fatal Python error: (pygame parachute) Segmentation Fault"

Thanks for looking into this,
Daniel

Re: [PyOpenGL-Users] OpenGLContext-2.0.0b2.win32-py2.3.exe problems

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

Daniel Heckenberg wrote:
...

>However, I've had a few troubles when trying to get OpenGLContext to work.
>I've only tried the recent binary package... and I'm using it with the
>latest available binary installs of Python, PIL, PyGame, Numarray and
>PyOpenGL.  I also have Numeric 23.1 installed.
>  
>
Everything there sounds fine.

>The symptoms:
>- had to install PyDispatcher (not listed as a dependency)
>  
>
I've just added it, will show up the next time I refresh the web-site.

>- can't find a suitable FontTools binary (and I don't have VC++ 6.0)
>  
>
I'll look into finding someone to build a FontTools binary.  IIRC it's 
only a tiny little pyd that's written in C to speed up the equivalent 
Python code.

>- PyOpenGL seems to work fine
>  
>
I'm assuming you're trying the PyOpenGL demos.  They don't really do all 
that much compared to what OpenGLContext is doing, so OpenGLContext will 
tend to find errors the demo doesn't (that's one of the major purposes 
of OpenGLContext, actually).

>- wxPython's OpenGL widget seems to work fine
>
>But when I try to start any of the OpenGLContext samples I get a crash as
>soon as the OpenGL window appears.  The MS debugger tells me:
>"Unhandled exception at 0x10017d74 (GL__init___.pyd) in python.exe:
>0xC0000005: Access violation reading location 0x00000007."
>
>Any hints as to where I'm going wrong?
>  
>
Not really, that's a very generic error message.  I don't really have 
time to track it down today, but I'll try installing on my sister's 
machine to see if I can duplicate the problem... probably be the weekend 
before I can get some time free to work on it though.  If you could try 
running each of wxcontext.py (will likely fail due to a missing/bad 
bitmap), glutcontext.py, and pygamecontext.py and report which of those 
is producing the error it should help me narrow down where the error is.

Of course, if the error is actually in PyOpenGL, then they should all 
fail.  The error itself *looks* like a problem with PyOpenGL which 
OpenGLContext just happens to be triggering.  Still shouldn't happen, 
and they're both my projects, so I'd like to track it down.

Have fun,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] OpenGLContext-2.0.0b2.win32-py2.3.exe problems

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

Hi all,

I'm just getting started with python and am working on a project with python
and openGL (on win32 so far).  I'm doing a fast sweep of different ways of
managing an openGL context and have managed to get a number of different
things to work.

However, I've had a few troubles when trying to get OpenGLContext to work.
I've only tried the recent binary package... and I'm using it with the
latest available binary installs of Python, PIL, PyGame, Numarray and
PyOpenGL.  I also have Numeric 23.1 installed.

The symptoms:
- had to install PyDispatcher (not listed as a dependency)
- can't find a suitable FontTools binary (and I don't have VC++ 6.0)
- have installed other listed dependencies (GLUT, wxPython, win32all,
MXTextTools, SimpleParse, TTFQuery)
- PyOpenGL seems to work fine
- wxPython's OpenGL widget seems to work fine

But when I try to start any of the OpenGLContext samples I get a crash as
soon as the OpenGL window appears.  The MS debugger tells me:
"Unhandled exception at 0x10017d74 (GL__init___.pyd) in python.exe:
0xC0000005: Access violation reading location 0x00000007."

Any hints as to where I'm going wrong?

Many thanks,
Daniel

Re: [PyOpenGL-Users] Swig 1.3.19 Patch and Fedora Core 2 RPM

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

And now replying to it...

The dev-2_1 branch in CVS has already been moved to using SWIG 1.3.21.  
There is also a minor patch posted to the list a few weeks ago which 
allows for building on Gentoo, and I assume, Fedora Core 2 (though the 
person who reported the Fedora Core 2 failure never actually reported 
back on whether everything was working, the fact that they were getting 
to the point where WGL was missing on Linux suggests it worked) merely 
by skipping the SWIG generation step (as was originally intended in the 
code).

I'll take a look at the patches to see if there's anything I missed in 
the 1.3.21 conversion.

Have fun,
Mike

Mike C. Fletcher wrote:

> Forwarding this to the group...
>
...

> Here is a swig 1.3.19 patch and FC2 RPM and SRPM:
> http://sgce.cbse.uab.edu/pyopengl/
>
> You'll also find the RPM spec and patch files.  I didn't get the FC1
> RPMs to build... But they shouldn't be too far off if someone wants to
> work on it.

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] Swig 1.3.19 Patch and Fedora Core 2 RPM

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

Forwarding this to the group...

Subject:
PyOpenGL Swig 1.3.19 Patch and Fedora Core 2 RPM
From:
"David H. Johnson" <dh...@ua...>
Date:
Mon, 12 Jul 2004 10:34:19 -0500

To:
pyo...@li..., pyo...@li...


Hi Everyone,

After about 2 weeks of obsessive compulsive building and packaging...

Here is a swig 1.3.19 patch and FC2 RPM and SRPM:
http://sgce.cbse.uab.edu/pyopengl/

You'll also find the RPM spec and patch files.  I didn't get the FC1
RPMs to build... But they shouldn't be too far off if someone wants to
work on it.  Togl patches weren't included so togl support isn't there. 
However that could be installed separately.  I would also be interested
to see if the patch enables swig1.3.19 based compilation on other
systems.  The patch isn't the cleanest in the world.  Getting the
GLUT.py and GLE.py files to go where they're supposed to was a blatant
hack.  Other things tried to keep up with the general setup scheme. 
Another semi-hack was having the modules named _modname so the target
.so's would be _modname.so as swig 1.3.19 makes all .py calls to
_modname by default.

I think the package requirements below are correct, but I'm not
positive...

FC2 packages needed for the RPM:
python-2.3.3-6
freeglut-2.2.0-11
tix-8.1.4-96.1
tkinter-2.3.3-6

FC2.dag packages needed for the RPM:
python-imaging-1.1.4-1.1.fc2.dag
python-numeric-23.1-0.1.fc2.dag

Development packages needed to compile PyOpenGL w/ patch:
python-devel-2.3.3-6
freeglut-devel-2.2.0-11
xorg-x11-devel-6.7.0-5
swig-1.3.19-6.1

And to compile the RPMS:
rpm-build-4.3.1-0.3

Hope everyone finds this useful.

--David

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] Re: [wxPython-users] wxpython and thread(with OpenGl)

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

Antony Hodgson wrote:

> Hi Mike,
>
> Thanks for your very informative reply.  I'll take the liberty of 
> jumping in with a couple of comments that will hopefully clarify what 
> my student, Ali, is trying to do.
>
> First, we're both pretty new to dynamic 3D graphic rendering, so I'm 
> probably not understanding what the right way to do things is.  Our 
> application is in computer-assisted surgery - we will ultimately have 
> 3D representations of complex objects such as bones (ie, thousands of 
> polygons) moving around in space in real time as an intraoperative 
> tracking system reports their positions in space.  OpenGL seemed a 
> natural way to handle this (VTK is obviously an option as well).  We 
> considered Inventor and Performer, but the Python bindings to those 
> are not as mature yet, so we were reluctant to embrace them at this 
> point.

Okay, given your parameters, I think I can state categorically that what 
you *don't* want is to render in a background thread.  What you want is 
to use a retained-mode rendering system (characterised by their use of 
"scenegraphs").  Your I/O thread would update the scenegraph.  Most 
(all?) scenegraph engines already have the logic built-in to handle this 
kind of interaction.

To elaborate slightly, when you alter the scenegraph's model of your 
scene, the scenegraph checks to see if the GUI thread is already 
rendering.  If it is, the scenegraph simply sets a flag that the GUI 
thread will check on completion of the current rendering-pass which 
says, in essence "render again when you're finished", otherwise it tells 
the GUI thread to begin rendering.  Your background thread can therefore 
make dozens of changes during a single rendering pass and the rendering 
engine will just pick them all up the next time it traverses the scenegraph.

You can see what that kind of code looks like in OpenGLContext's Context 
base class (OpenGLContext being a pure-Python retained-mode scenegraph 
engine).  It's not horrifically complex for simple cases, but that's all 
OpenGLContext will handle.  More advanced scenegraph engines are 
designed so that they actually queue up the changes while the main GUI 
thread is rendering and only after the current frame has completed do 
they do any updates.  This is the *proper* way to do the work, but it 
tends to make the implementations more difficult to follow, as every 
interaction needs to follow the Command pattern.

If you can be sure that your updates (that is, the actual changing of 
the scenegraph data-structures) can run fast enough not to cause 
rendering hiccups, you would likely be best to queue up events to be 
rendered in the GUI thread just before the rendering simulation runs 
(you'll see that pattern in OpenGLContext's Context as well, it's the 
"normal" game-developer's pattern).  This avoids "scenegraph tear" 
(where you've updated the scenegraph while rendering it so that part of 
the scene reflects one state, and part the other).

Regarding size of the models.  The limiter with PyOpenGL is likely to be 
the complexity of the scene more than the number of polygons in any 
given object (within the limits imposed by hardware).  PyOpenGL, when 
using the array-drawing primitives, isn't really affected by the size of 
the arrays (it just passes the Numpy arrays to the C-level rendering 
code), but scenegraph engines have to do a lot of bookkeeping to 
properly render complex scenes.  Even with raw PyOpenGL, though, I'd 
expect to have to write some C code to get acceptable performance and 
response times for something as intense as virtual surgery.  I honestly 
don't think you'd get the kind of reliable performance you'd need to 
imagine putting a human life on the line with it.

Inventor is a very mature scenegraph engine, by the way.  Pivy is 
basically just a thin wrapper around it (little or no Python code 
running in the event loop), so you will likely find that it can handle 
almost anything you're going to throw at it (I've never used it myself, 
just going from conversations with the author).  SGI's old Performer 
library (which would compile the scenegraph down into a sort of polygon 
soup, rather than keeping it structured) was what used to be used for 
this kind of work, but hardware has advanced enough that a 
scenegraph-based engine is likely more suitable, particularly for 
highly-interactive work.  Not sure how well it embeds in wxPython, however.

I wouldn't suggest using OnIdle for rendering.  Keep to using EVT_PAINT 
wherever possible, the road-most-travelled is a good thing for 
performance in 3D graphics.

Oh, for your network I/O, you might want to consider using asynchronous 
operations instead of a thread, if you can keep your entire app 
single-threaded you'll likely get the best possible performance and 
reliability.  Twisted does, IIRC, have modules for serial-port access.

HTH,
Mike

BTW, setting reply-to to the PyOpenGL list, as we've ventured rather 
away from wxPython topics.

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
  blog: http://zope.vex.net/~mcfletch/plumbing/

[PyOpenGL-Users] tutorial

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

hi

anyone can recomend some tutorial for pyopenGL? i am interested on 2D.
I cannot run the opencontext as it doesnt like python 2.3

thanks


-- 
enrike

Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andy Sy <an...@ne...>]

http://www.river-bank.demon.co.uk/docs/sip/sipref.html

SIP may also be worth investigating as an alternative to
SWIG.


 > Andy Sy wrote:
 >
 >> I've noticed that PyOpenGL has lagged behind the latest
 >> OpenGL versions for sometime now.  Is the complexity of
 >> SWIG to blame for this?

Andrew Straw wrote:

> I wrote a similar email about this some months ago. Some elements of the 
> conversation:
> 
> Mike Fletcher responded that there's probably some unacceptable overhead 
> with ctypes.  Part of the problem is mapping the versioning from C to 
> Python.

[PyOpenGL-Users] PyOpenGllcontext: VRML scenegraph not rendered

[A. P. <pu...@on...>]

The system I am working with: WIN2K SP4 using
PyOpenGl 2.0.0.44, PyOpenGlContext 2.0.0.b1  both bin-installed
Boa 0.2.8, Python 2.2.3, wxpython 2.4.2.4,

Most of the dlivered tests and demos work only the tests using scenegraph
(vrml) leave the output window totally dark. There is only one example
(cubeback_rot.py) where the background (which is non standard VRML) allows
the small cube to be seen (front surface in white the other in dark grey).
If the background is omitted  the cube vanishes also and in the dark window
nothing is seen. But also with background there are strange effects. The
background turns sometimes in black. It depends on the angle one looks on
the background. When the view rotates there is allways a flickering of the
walls.

But the most significant thing is: the scenegraph are not seen. It seems as
if scenegraph items are not rendered. Maby they are switched off. Can't find
the switch to have the scenegraph beeing rendered.

Thanks, Alfred

[PyOpenGL-Users] Problem Using Threads With wxPython and OpenGL

[ali o. <beh...@ya...>]

Hi all,
 
We're trying to write an application where we render an image to an OpenGL window.  When we do this all in the main program thread, all is fine, but when we try to call the drawing code in a thread (so as to allow the main thread to go back to processing UI events), the rendering code no longer works.  The code is shown below, along with instructions for switching between the single-threaded and multi-threaded versions.  Does anyone have any ideas about why this is happening or if there's another way we can achieve our goal?
 
Thanks,
 
Ali Omidvar
 
 
# Use this code as is to run the single-threaded version.  Hitting a key should
# cause a triangle to appear and move across the screen with every key press.
#
# To run the multi-threaded version, uncomment the lines starting with ## and
# comment out line 40 as indicated.  To revert to single-threaded, comment out
# all lines ending with ## and class MyDraw(Thread)
import wx
from OpenGL.GL import *
from OpenGL.GLUT import *
from OpenGL.GLU import *
##from threading import Thread ##
from wx import glcanvas # why doesn't wx.glcanvas work?
class FPFrame( wx.Frame ):
    
    def __init__(self, parent, id, title):

        wx.Frame.__init__( self, parent, wx.ID_ANY, title, size = (400, 400),
                    style=wx.DEFAULT_FRAME_STYLE|wx.NO_FULL_REPAINT_ON_RESIZE)
        self.panel = wx.Panel(self, -1, size=(200,200), style=wx.SIMPLE_BORDER)
        
        # when panel has focus, send character event to FPFrame handler OnChar
        wx.EVT_CHAR( self.panel, self.OnChar )
        
        self.Show( True )
        # do initial OpenGL scene rendering
        self.GLS = TestGLScene( self.panel )
        
##        self.myDraw = MyDraw(self) ##
    def OnChar(self,event):
        
        self.GLS.DrawGeometry()  # comment this out when switching to threaded version
##        if not self.myDraw.isAlive(): ##
##             self.myDraw = MyDraw( self ) ##
##             self.myDraw.start() ##          
 
##################################################3        
# comment this class out for the single-threaded version
##class MyDraw(Thread):
##    
##    def __init__(self, frame):
##        Thread.__init__( self )
##        self.frame=frame
##        
##    def run(self):  
##        self.frame.GLS.DrawGeometry( )

################################
class TestGLScene( glcanvas.GLCanvas ):
    def __init__( self, parent ):
        glcanvas.GLCanvas.__init__( self, parent, -1,size=(200,200) )
        self.i = 0
        dc = wx.ClientDC(self)
    def DrawGeometry( self ):
        self.SetCurrent()  
        # define the scene for OpenGl  
        glClearColor( 0.0, 0.0, 0.0, 1.0 )
        glClearDepth( 1.0 )
        glDepthFunc( GL_LESS )
        glEnable( GL_DEPTH_TEST )    
        glShadeModel( GL_SMOOTH )
        glMatrixMode( GL_PROJECTION )
        glLoadIdentity()     
        gluPerspective( 45.0, 1, 0.1, 100.0 )
        glMatrixMode( GL_MODELVIEW )  
        glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT )
        glLoadIdentity()      
        glTranslatef( -1.5, 0.0, -6.0 )
        glClear( GL_COLOR_BUFFER_BIT )
        # draw a triangle with left corner at x
        GLDrawTriangle( self.i )
        self.i += 1
        
        self.SwapBuffers()
        print 'Swapped buffers'

# draw an equilateral triangle with left corner at (x,0,0)
def GLDrawTriangle( x ):
    print x
    V = [ [ x, 0, 0 ], [ x+2, 0, 0 ], [x+1, 1, 0 ] ]
    GLDrawVertices( V )
    
#draw a polygon with the points in the V
def GLDrawVertices( V ):
    glBegin( GL_POLYGON )
    for item in V:
        glVertex3f( item[0], item[1], item[2] )
    glEnd()
    print "Drew vertices" # this gets called when running multithreaded, but
                          # drawing does not happen

app = wx.PySimpleApp()
frame = FPFrame(None, -1, "Localizer Display")
app.MainLoop()


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andy Sy <an...@ne...>]

Andrew Straw wrote:

 > As the current package is built in Python, I think we have
 > the lowest-common-denominator situation, where we basically assume only
 > OpenGL 1.1 headers and thereby limit usage of any of the newer
 > features.  Consequently, no runtime version checking seems to be
 > required in general.  With the dynamic nature of Python, we could of
 > course do something fancy that only exposes the functions and constants
 > available for a certain version of OpenGL, but this may end up causing
 > unnecessary confusion.  To expose recent OpenGL features in PyOpenGL, we
 > have to consider what to do in the situation where someone with, say,
 > OpenGL 1.4 headers compiles PyOpenGL to run on a maching with only
 > OpenGL 1.1 libraries.  Maybe there is an elegant solution to this
 > problem...

Assuming the presence of Mesa might point to one possible
solution... I had the ff. exchange with Brian Paul before:

AS> Does this mean that even if OpenGL app uses a mix of
   > hardware supported and non-harware supported features,
   > instead of defaulting to pure software, Mesa will handle
   > the non-hardware supported portions of the pipeline while
   > the vidcard will still accelerate those portions which
   > it can?

BP> That's basically true.  If, for example, the application
   > uses a 3D texture, the driver will fallback to software
   > while rendering with the 3D texture, and return to hardware
   > rendering whenever possible.

AS> If so, then that's really cool, and will it be possible
   > to have the same behaviour for Window drivers?

BP> I'd expect Windows drivers to do the same thing.

Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andrew S. <str...@as...>]

I wrote a similar email about this some months ago. Some elements of the 
conversation:

Mike Fletcher responded that there's probably some unacceptable overhead 
with ctypes.  Part of the problem is mapping the versioning from C to 
Python.

In C, there are both compile-time and runtime versioning considerations: 
the headers you compile against may define certain functions that aren't 
available until a certain runtime version, so you'd better check before 
using them.  As the current package is built in Python, I think we have 
the lowest-common-denominator situation, where we basically assume only 
OpenGL 1.1 headers and thereby limit usage of any of the newer 
features.  Consequently, no runtime version checking seems to be 
required in general.  With the dynamic nature of Python, we could of 
course do something fancy that only exposes the functions and constants 
available for a certain version of OpenGL, but this may end up causing 
unnecessary confusion.  To expose recent OpenGL features in PyOpenGL, we 
have to consider what to do in the situation where someone with, say, 
OpenGL 1.4 headers compiles PyOpenGL to run on a maching with only  
OpenGL 1.1 libraries.  Maybe there is an elegant solution to this problem...

If someone (I don't have the time) embarks on a rewrite of PyOpenGL, 
that person may want to consider pyrex instead of SWIG.  Interesting tip 
about the ruby/OpenGL interface -- I'll have a look at that.

Cheers!
Andrew

Andy Sy wrote:

> I've noticed that PyOpenGL has lagged behind the latest
> OpenGL versions for sometime now.  Is the complexity of
> SWIG to blame for this?
>
> Would a different approach, say ctypes
> (http://starship.python.net/crew/theller/ctypes/) or use
> of the Python C API actually make things easier?
>
> I took a look at Ruby's OpenGL interface (
> http://www2.giganet.net/~yoshi/ ), and
> interestingly, there's not much acrobatics that
> need to be done.  There's a single 4,252 line C source
> with a seemingly very simple way of wrapping C
> OpenGL calls and that's it. (Could Ruby's C interface
> really be that clean?!?)
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users