pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Pointer functions copying memory.

[Shane H. (Techgame) <sha...@te...>]

I like the idea of python code doing the Numeric conversions, so things 
can be changed by the user in a straightforward manner.  In essence, I 
set OpenGL.GL.contiguous to my own callable, in which I can raise an 
error if I so choose.  =)  This solves both concerns in a nice way.

+1

Perhaps this same hibred approach can be used in other areas -- 
simplifying the SWIG wrappers, while maintaining the more sophisticated 
behavior in Python?

Thanks,
-Shane

Mike C. Fletcher wrote:
 > Hmm, lots of users don't really care if there's a little inefficiency if
 > it means they can get on with their lives (premature optimisation and
 > all that), they just want to see if what they're doing is doing what
 > it's supposed to, and having an error raised for what is essentially a
 > Numeric Python internal bookkeeping difficulty would mean their
 > (perfectly functional as-of-now) code just won't work.  A warning might
 > be possible, but even then, it seems a bit much.
 >
 > BTW, Here's a function that does the work of converting any given array
 > to a contiguous Numeric Python array:
 >
 > try:
 >    import Numeric
 > except ImportError:
 >    def contiguous( source ):
 >        """Place-holder for contiguous-array function, just returns 
argument
 >
 >        This is only visible if Numeric Python is not installed
 >        """
 >        return source
 > else:
 >    def contiguous( source, typecode=None ):
 >        """Return source as a contiguous Numeric Python array"""
 >        if isinstance( source, Numeric.ArrayType):
 >            if source.iscontiguous() and (typecode is None or
 > typecode==source.typecode()):
 >                return source
 >            else:
 >                return Numeric.array(source,typecode or source.typecode())
 >        elif typecode:
 >            return Numeric.array( source, typecode )
 >        else:
 >            return Numeric.array( source )
 >
 > I'm considering adding that to OpenGL.GL.__init__.py .  But would
 > appreciate feedback regarding it first (particularly whether it's
 > solving the problems with speed that gabor was noticing).  It should be
 > possible to simply call contiguous before storing your arrays and have
 > no copying overhead imposed (as long as the data-types for array and
 > pointer match, of course).  I'll add notes to this affect to the docs as
 > well if we go this route.
 >
 > I had considered having the gl*Pointer functions _return_ the contiguous
 > array, but I don't like messing with the OpenGL API just to deal with a
 > quirk of Numeric.
 >
 > Enjoy all,
 > Mike
 >

Re: [PyOpenGL-Users] Pointer functions copying memory.

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

Hmm, lots of users don't really care if there's a little inefficiency if 
it means they can get on with their lives (premature optimisation and 
all that), they just want to see if what they're doing is doing what 
it's supposed to, and having an error raised for what is essentially a 
Numeric Python internal bookkeeping difficulty would mean their 
(perfectly functional as-of-now) code just won't work.  A warning might 
be possible, but even then, it seems a bit much.

BTW, Here's a function that does the work of converting any given array 
to a contiguous Numeric Python array:

try:
    import Numeric
except ImportError:
    def contiguous( source ):
        """Place-holder for contiguous-array function, just returns argument

        This is only visible if Numeric Python is not installed
        """
        return source
else:
    def contiguous( source, typecode=None ):
        """Return source as a contiguous Numeric Python array"""
        if isinstance( source, Numeric.ArrayType):
            if source.iscontiguous() and (typecode is None or 
typecode==source.typecode()):
                return source
            else:
                return Numeric.array(source,typecode or source.typecode())
        elif typecode:
            return Numeric.array( source, typecode )
        else:
            return Numeric.array( source )

I'm considering adding that to OpenGL.GL.__init__.py .  But would 
appreciate feedback regarding it first (particularly whether it's 
solving the problems with speed that gabor was noticing).  It should be 
possible to simply call contiguous before storing your arrays and have 
no copying overhead imposed (as long as the data-types for array and 
pointer match, of course).  I'll add notes to this affect to the docs as 
well if we go this route.

I had considered having the gl*Pointer functions _return_ the contiguous 
array, but I don't like messing with the OpenGL API just to deal with a 
quirk of Numeric.

Enjoy all,
Mike

Shane Holloway (Techgame) wrote:

> I would prefer that PyOpenGL raise an exception instead of copying 
> memory.  Providing a continious Numeric array is the responsibility of 
> the calling code, in my eyes, as the helpful copying is usually not 
> wanted in the longer term.  It would also be important to give 
> examples in the documentation of how to restructure the Numeric object 
> to make the call work as intended.
>
> Thoughts?
>
> I tryed implementing this, but got quickly lost in the SWIG macros. 
> Made me run back to python ;)
>
> -Shane Holloway

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

[PyOpenGL-Users] PyOpenGL 2.0.1.02 (alpha) available (minor bug fix release)

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

As Rene felt people were being held back by not having the texture 
compression bug fix, I have just released version 2.0.1.02 of PyOpenGL. 
 There are two bug fixes in this release, one for the ARB texture 
compression extension, and one for the double-free bugs in GLU 
tesselator and quadratic objects.  As well, an HPUX configuration file 
has been added.

Distributions are available off the homepage (source-code-only at the 
moment):
    http://pyopengl.sourceforge.net/

Enjoy yourselves,
Mike

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

Re: [PyOpenGL-Users] Pointer functions copying memory.

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

Strangely, that first post of Guido's is what gave me the impression the 
buffer API was considered less than optimal for continued use.  That is, 
it seems to be considered broken, and there are a number of proposals to 
fix it, but the API as it stands is suboptimal and fragile (likely to 
cause memory access failures).  The buffer object is just more broken :) .

As you (Thomas) are certainly more involved in C-level Python 
programming, I will defer to your understanding.

I'm still not sure that the buffer API can be used for the OpenGL array 
functions.  OpenGL takes a contiguous memory array, which it copies to 
the OpenGL engine.  As far as I can see, there is no support for objects 
which override iteration to point to methods/functions.  If we are 
simply using the buffer API to copy into a contiguous memory array... 
well... the Numeric Python version is already doing that, and causing 
the slowdown.

Of course, I may simply be misunderstanding something, happens all the time,
Mike

Thomas Wouters wrote:

>On Mon, Feb 03, 2003 at 12:39:26PM -0500, Mike C. Fletcher wrote:
>  
>
>>The biggest problem I see is that the buffer API is loosely considered 
>>deprecated.
>>    
>>
>
>I don't believe this is the case. Buffer *objects* (which the 'buffer'
>builtin function / constructor returns) are somewhat-slilently deprecated,
>but I don't believe the actual buffer API is. I haven't been paying
>attention to python-dev lately, but all discussions I recall were about
>buffer objects, not the API, and I have seen no-one complain about the API
>itself (at least not all negatively :) For instance this posting by Guido:
>
>http://mail.python.org/pipermail/python-dev/2000-October/009974.html
>
>And this more recent discussion:
>
>http://mail.python.org/pipermail/python-dev/2002-June/026018.html
>
>>From the PEP (Python Enhancement Proposals) list, I see a proposal to
>more-or-less replace buffer objects by a 'bytes' object, and to extend the
>buffer API with 'locking' (actually a different API that gives more control
>to the acted-upon object.) No buffer API deprecation, silently or not.
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Pointer functions copying memory.

[Thomas W. <th...@xs...>]

On Mon, Feb 03, 2003 at 12:39:26PM -0500, Mike C. Fletcher wrote:

> The biggest problem I see is that the buffer API is loosely considered 
> deprecated.

I don't believe this is the case. Buffer *objects* (which the 'buffer'
builtin function / constructor returns) are somewhat-slilently deprecated,
but I don't believe the actual buffer API is. I haven't been paying
attention to python-dev lately, but all discussions I recall were about
buffer objects, not the API, and I have seen no-one complain about the API
itself (at least not all negatively :) For instance this posting by Guido:

http://mail.python.org/pipermail/python-dev/2000-October/009974.html

And this more recent discussion:

http://mail.python.org/pipermail/python-dev/2002-June/026018.html

From the PEP (Python Enhancement Proposals) list, I see a proposal to
more-or-less replace buffer objects by a 'bytes' object, and to extend the
buffer API with 'locking' (actually a different API that gives more control
to the acted-upon object.) No buffer API deprecation, silently or not.

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Re: [PyOpenGL-Users] Pointer functions copying memory.

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

I didn't know the buffer api was dying.  Glad to find
out now.

Maybe we could get the thing to raise an exception, or
print a warning if prefered.  It would raise every
time there is memory copied.  The exception should
definitely be an option, defaulting to not raising. 
Something like OpenGL.raise_error_on_memory_copy = 1

Or maybe we could get it to do that in debugging mode?


Your suggestion of a function to return a contiguous
array to the user could be good.  So they could save
it for future passes of the same data.

Some opengl functions can use stride arguments.  eg
most of the gl*Pointer functions.  So maybe we could
do some automagical things for eg glVertexPointerd(x)
to use the correct stride if possible.


ps, the float versions of these functions are often
quite faster, if you are careful with numeric casting.



 --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
The biggest problem I see is that the buffer API is
> loosely considered 
> deprecated.  BTW I could've sworn that we were
> already using the 
> PyArray_ functions to get contiguous array
> pointers...
> 
> See the NUMERIC_PyObject_As macro in
> interface_util.c, as far as I'm 
> aware, this should be getting used everywhere. 
> However, if I understand 
> the mechanism behind the 
> (PyArrayObject*)PyArray_ContiguousFromObject(source,
> TYPECODE | 
> SAVESPACEBIT, 0, 0); function, it's going to do a
> copy of the source 
> array is not contiguous, which would give us the
> copying overhead we're 
> seeing.
> 
> What I would prefer to see (instead of using a
> pseudo-deprecated API, or 
> using functions to access the non-contiguous array
> (which likely won't 
> work for OpenGL, as I believe it requires a true
> contiguous array)) is a 
> function that, given a Numeric array, returns a
> contiguous version of 
> that array to Python (or raises a memory error if
> it's not possible). 
>  That should, if I understand correctly, make
> further 
> PyArray_ContiguousFromObject calls on the
> _resulting_ array null 
> operations.  The "problem" being that the current
> code doesn't modify 
> the Python pointer to the array to point to the new,
> contiguous array 
> (and obviously it shouldn't do so in the middle of
> an OpenGL call), so 
> the effort isn't saved between rendering passes.
> 
> Just my thoughts,
> Mike
> 
> 
> Rene Dudfield wrote:
> 
> >Hi,
> >
> >I had a look at the pointer functions and it
> appears
> >they copy memory before passing it to the gl
> function,
> >making them quite slow.
> >
> >I was thinking of using the buffer api instead.
> >
>
>http://python.org/doc/current/api/bufferObjects.html
> >
> >Not sure if numeric supports it.  If it doesn't
> I'll
> >use the PyArray_ContiguousFromObject functions.
> >
> >
> >Any thoughts on this?  Any compatibility problems
> with
> >the buffer api?
> >
> >  
> >

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

Re: [PyOpenGL-Users] Pointer functions copying memory.

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

The biggest problem I see is that the buffer API is loosely considered 
deprecated.  BTW I could've sworn that we were already using the 
PyArray_ functions to get contiguous array pointers...

See the NUMERIC_PyObject_As macro in interface_util.c, as far as I'm 
aware, this should be getting used everywhere.  However, if I understand 
the mechanism behind the 
(PyArrayObject*)PyArray_ContiguousFromObject(source, TYPECODE | 
SAVESPACEBIT, 0, 0); function, it's going to do a copy of the source 
array is not contiguous, which would give us the copying overhead we're 
seeing.

What I would prefer to see (instead of using a pseudo-deprecated API, or 
using functions to access the non-contiguous array (which likely won't 
work for OpenGL, as I believe it requires a true contiguous array)) is a 
function that, given a Numeric array, returns a contiguous version of 
that array to Python (or raises a memory error if it's not possible). 
 That should, if I understand correctly, make further 
PyArray_ContiguousFromObject calls on the _resulting_ array null 
operations.  The "problem" being that the current code doesn't modify 
the Python pointer to the array to point to the new, contiguous array 
(and obviously it shouldn't do so in the middle of an OpenGL call), so 
the effort isn't saved between rendering passes.

Just my thoughts,
Mike


Rene Dudfield wrote:

>Hi,
>
>I had a look at the pointer functions and it appears
>they copy memory before passing it to the gl function,
>making them quite slow.
>
>I was thinking of using the buffer api instead.
>
>http://python.org/doc/current/api/bufferObjects.html
>
>Not sure if numeric supports it.  If it doesn't I'll
>use the PyArray_ContiguousFromObject functions.
>
>
>Any thoughts on this?  Any compatibility problems with
>the buffer api?
>
>  
>
...

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

[PyOpenGL-Users] Pointer functions copying memory.

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

Hi,

I had a look at the pointer functions and it appears
they copy memory before passing it to the gl function,
making them quite slow.

I was thinking of using the buffer api instead.

http://python.org/doc/current/api/bufferObjects.html

Not sure if numeric supports it.  If it doesn't I'll
use the PyArray_ContiguousFromObject functions.


Any thoughts on this?  Any compatibility problems with
the buffer api?



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

Re: [PyOpenGL-Users] openglcontext 2.0 problem

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

 --- gabor <ga...@re...> wrote: > hi,
> 
> 1.
> i've created a simple app using testcontext. my
> render method looks like
> this:
>         def Render(self, mode = 0):
>                 BaseContext.Render(self,mode)
>                 glDisable(GL_CULL_FACE)
> 
>                 t = time.time()
>                 for trilist in self.tris:
>                        glVertexPointerd(trilist )
>                       
> glEnableClientState(GL_VERTEX_ARRAY);
>                        glDrawArrays(GL_TRIANGLES,
> 0,len(trilist))
> 
>                 t = time.time() -t
> 
>                 print "renderTime",t *

Try this?

if self.tris:
    glEnableClientState(GL_VERTEX_ARRAY);

for trilist in self.tris:
    glVertexPointerd(trilist )
    glDrawArrays(GL_TRIANGLES,  0,len(trilist))

if self.tris:
    glDisableClientState(GL_VERTEX_ARRAY);

If it's not much faster then, maybe one of these
functions is copying the memory each time.

How long is trilist usually?

Does glVertexPointerf work for you?



> 1000.0,"milliseconds"
> 
> i'm rendering around 1500-2000 wireframe triangles
> this way, and it's
> too slow... i got renderTime around 37
> miliseconds..., that means around
> 30fps...
> 
> if i do it with the gl functions commented out i got
> aroun
> 0.007 miliseconds...
> 
> does that rendering take so long?
> 
> then i replaced that glVertexpointer code with:
> 			glBegin(GL_TRIANGLES)
>                         for v in trilist:
>                                
> glVertex3f(v[0],v[1],v[2])
>                         glEnd()
> 
> and it renders in around 28 miliseconds... it's
> faster ?!?!?!?!?!?!
> 
> what am i doing wrong?
> 
> 
> 2.
> a have meshes defined as list of triangles... i need
> to do be able to
> pick a triangle of it with the mouse... in the past
> i used glUnproject
> to get the mouse coords, and then doing the
> intersection math...
> is there something on OpenGLContext2 that i could
> use for this?
> 
> thanks,
> gabor
> 
> 

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

[PyOpenGL-Users] openglcontext 2.0 problem

[gabor <ga...@re...>]

hi,

1.
i've created a simple app using testcontext. my render method looks like
this:
        def Render(self, mode = 0):
                BaseContext.Render(self,mode)
                glDisable(GL_CULL_FACE)

                t = time.time()
                for trilist in self.tris:
                       glVertexPointerd(trilist )
                       glEnableClientState(GL_VERTEX_ARRAY);
                       glDrawArrays(GL_TRIANGLES, 0,len(trilist))

                t = time.time() -t

                print "renderTime",t * 1000.0,"milliseconds"

i'm rendering around 1500-2000 wireframe triangles this way, and it's
too slow... i got renderTime around 37 miliseconds..., that means around
30fps...

if i do it with the gl functions commented out i got aroun
0.007 miliseconds...

does that rendering take so long?

then i replaced that glVertexpointer code with:
			glBegin(GL_TRIANGLES)
                        for v in trilist:
                                glVertex3f(v[0],v[1],v[2])
                        glEnd()

and it renders in around 28 miliseconds... it's faster ?!?!?!?!?!?!

what am i doing wrong?


2.
a have meshes defined as list of triangles... i need to do be able to
pick a triangle of it with the mouse... in the past i used glUnproject
to get the mouse coords, and then doing the intersection math...
is there something on OpenGLContext2 that i could use for this?

thanks,
gabor

[PyOpenGL-Users] Debian packages of PyOpenGL 2.0.0.44

[Thomas W. <th...@xs...>]

Just FYI, I created some Debian packages for PyOpenGL 2.0.0.44. They're
stock 2.0.0.44 except for the inclusion of Togl 1.6 (CVS from last week) for
the Tcl/Tk 8.4 support. The packages are built for Python 2.1, 2.2 and 2.3,
against unstable, and I haven't tested them on stable or testing machines.
The Togl packages aren't available for python2.1 because of its differing Tk
version.

The i386 binary packages (python<version>-opengl2 and python<version>-togl)
as well as the source package (python-opengl2) are available at:

deb http://www.xs4all.nl/~thomas/debian ./
deb-src http://www.xs4all.nl/~thomas/debian ./

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

[PyOpenGL-Users] OpenGLContext 2.0.0a4 available...

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

I have just released the fourth alpha of OpenGLContext 2.0.0.  You can 
get it from the regular spot:

    http://pyopengl.sourceforge.net/context/

Enjoy yourselves,
Mike


Release notes:

This is likely the last 2.0.0 alpha release.  The major improvement
over the previous alpha is preliminary support for instantiating
prototyped nodes (that is, actually creating and displaying the
internal scenegraph for those nodes), and the associated support
for ROUTE statements between fields (not yet between events). 
This feature has resulted in a considerable amount of restructuring
in the vrml package, along with some cleanup and refactoring.

There are only a small number of features still plan for version
2.0.0, mostly dealing with individual scenegraph nodes which I still
want to include, and those will likely be finished before the first
beta release.  There are still a large number of bugs and lots of
room for optimization, and that will be my focus during the beta period.

Change log:

PROTOs:

    Initial support for prototyped nodes added, which
    allows for loading a wider swath of VRML content. No
    support for EXTERNPROTO as-of-yet.

    Refactored vrml.vrml97.prototypes into vrml.route and
    vrml.vrml97.script modules

Events:

    Partial rework of the mouse-events API to allow the
    events to be handled during the event-cascade,
    addition of support for event-cascade deferal of event
    processing to eventhandler mix-in and Context classes.

    Addition of support in the event base class for tracking
    visited node/field combinations, calling of base-class
    initializer from the sub-class initializer's.

    ROUTEs are now active for fields

    IS mappings now work for PROTO fields (sub-class of ROUTE)

    Introduction of Event class in the vrml package, should
    become the base-class for OpenGLContext.events.event

Cleanup of bugs in Shape,  Switch and WGLFont where corner-
cases were not properly caught (e.g. no geometry, whichChoice
out-of-bounds, no text on a line)

IndexedFaceSet:
   
    Reworked generation code extensively, now supports
    colour-per-face and normal-per-face modes of VRML97

    Added a few sanity checks as well.

PixelTexture node added.

Preliminary Cylinder and Cone implementations.

Stub implementations of LOD, Inline and Billboard nodes.

Fix for transparent-geometry rendering (depth-buffer-testing
enabled).

Consolidated vrml.node and vrml.vrml97.node into vrml.node
Moved fieldtypes to vrml package instead of VRML97 package

Made default testing-context preference-sequence wx, Pygame,
then GLUT

Made all Bindable types also act as Children, since they are
present in the scenegraph hierarchy.

Fix for parsing hexidecimal-encoded SFImage fields (as seen
in PixelTextures).

Work-around for Python 2.2.2 calling of receiver methods in
dispatcher.

Considerably more robust getField implementation in
protofunctions

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

Re: [PyOpenGL-Users] Request for help for updating OpenGL view

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

Hi,

  does the robot move every frame?

If not you could simply not flip the back buffer,
until it moves.  

Or maybe you could limit the frame rate to say 30fps,
and sleep for the rest of the time.


How are you drawing it?  glBegin/glEnds use up a bit
of processing power looping through all the data. 
Whereas drawing arrays will use your graphics card
instead of the cpu if the card is a recent one.  Even
without a t&l card avoiding loops in python can speed
things up a lot.  So try and avoid  the glBegins/ends
if you are using them.


If none of that helps maybe you could make an example
of your code without the robot attached ;)  So that we
could play with it a bit.  Of course I'm sure it's
much more fun with a robot.



 --- "Douglas S. Blank" <db...@br...> wrote: >
PyOpenGL-users,
> 
> I was wondering if someone could point me to some
> example code, or give me
> some hints. Here's what I need to do:
> 
> I have a GUI that has one Python thread updating
> some values (a robot's
> sensors actually), and I'd like to have an OpenGL
> view of the robot updated as
> often as possible without stressing the computer too
> much. The OpenGL should
> draw the robot and sensors, but also allow
> rotating/zooming/etc the view of
> the robot via the mouse, or programmatically.
> 
> I have a hacky version working that uses the
> do_AutoSpin method, but sets
> xspin and yspin to 0 so that it doesn't really spin
> it, but it does update the
> window:
> 
>    def refresh(self):
>       self.win.autospin = 1
>       self.win.xspin = 0
>       self.win.yspin = 0
>       self.win.after(500, self.win.do_AutoSpin)
> 
> Besides being hacky, this has some problems:
> 
>  1. it uses about 98% of a CPU
>  2. If you change the view (rotate/zoom the robot)
> in the OpenGL window, you
> have to run the above refresh() method again
> 
> Can any help point me to the proper way of having
> this functionality?
> 
> Thanks in advance!
> 
> -Doug
>  

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

Re: [PyOpenGL-Users] Request for help for updating OpenGL view

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

I'm assuming you're using Tkinter with Togl (because that's the only 
auto-spin functionality I'm aware of). What you'll want to do is trigger 
redraws:

    When the robot changes values (if the robot is always changing 
values, then just ignore updates more recent than the maximum frame-rate 
would suggest (there are more professional ways, involving timers, but 
if the robot is always changing, it doesn't really matter)).
    When the window changes size/shape.
    When the user requests a viewing-position change (these will likely 
be mouse-generated callbacks, so you normally don't worry about them).

Most GUI libraries have something simple like window.Refresh() to cause 
a window to refresh it's contents (including the OpenGL windows).  I 
don't remember the Tk version's name.

You can find code in OpenGLContext that does multiple-thread negotiation 
(though it doesn't discard update requests to enforce a maximum 
frame-rate) using standard threading primitives (Locks, Events, 
etceteras).  It supports dropping CPU use if there's no pending renders 
under wx and GLUT (not Pygame, however). Particularly, see the 
context.py module, with focus on:
    Context.setupThreading,
    Context.triggerRedraw,
    Context.shouldRedraw, and
    Context.drawPoll.
That code appears to work (though slowly (it uses entire-scenegraph 
locking, which causes pretty high rates of blocking)) under GLUT, 
Pygame, and wxPython, but hasn't had extensive testing even there.  I 
haven't used Tkinter more than glancingly in... well... it's been a 
while :) , so you can imagine how much testing it's had there ;) .

There are people who've apparently used Twisted (asynchronous event 
framework) with PyOpenGL, that might be useful for your task instead of 
threading, but I've got nothing to go on other than that the Twisted 
project describes it in their testimonials.

Hope that's some help,
Mike

Douglas S. Blank wrote:

>PyOpenGL-users,
>
>I was wondering if someone could point me to some example code, or give me
>some hints. Here's what I need to do:
>
>I have a GUI that has one Python thread updating some values (a robot's
>sensors actually), and I'd like to have an OpenGL view of the robot updated as
>often as possible without stressing the computer too much. The OpenGL should
>draw the robot and sensors, but also allow rotating/zooming/etc the view of
>the robot via the mouse, or programmatically.
>
>I have a hacky version working that uses the do_AutoSpin method, but sets
>xspin and yspin to 0 so that it doesn't really spin it, but it does update the
>window:
>
>   def refresh(self):
>      self.win.autospin = 1
>      self.win.xspin = 0
>      self.win.yspin = 0
>      self.win.after(500, self.win.do_AutoSpin)
>
>Besides being hacky, this has some problems:
>
> 1. it uses about 98% of a CPU
> 2. If you change the view (rotate/zoom the robot) in the OpenGL window, you
>have to run the above refresh() method again
>
>Can any help point me to the proper way of having this functionality?
>
>Thanks in advance!
>
>-Doug
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Request for help for updating OpenGL view

[Douglas S. B. <db...@br...>]

PyOpenGL-users,

I was wondering if someone could point me to some example code, or give me
some hints. Here's what I need to do:

I have a GUI that has one Python thread updating some values (a robot's
sensors actually), and I'd like to have an OpenGL view of the robot updated as
often as possible without stressing the computer too much. The OpenGL should
draw the robot and sensors, but also allow rotating/zooming/etc the view of
the robot via the mouse, or programmatically.

I have a hacky version working that uses the do_AutoSpin method, but sets
xspin and yspin to 0 so that it doesn't really spin it, but it does update the
window:

   def refresh(self):
      self.win.autospin = 1
      self.win.xspin = 0
      self.win.yspin = 0
      self.win.after(500, self.win.do_AutoSpin)

Besides being hacky, this has some problems:

 1. it uses about 98% of a CPU
 2. If you change the view (rotate/zoom the robot) in the OpenGL window, you
have to run the above refresh() method again

Can any help point me to the proper way of having this functionality?

Thanks in advance!

-Doug

-- 
Douglas S. Blank,       Assistant Professor         
db...@br...,          (610)526-6501
Bryn Mawr College,  Computer Science Program
101 North Merion Ave,  Park Science Building
Bryn Mawr, PA 19010 dangermouse.brynmawr.edu

Re: [PyOpenGL-Users] OpenGLContext 2.0.0a3 available...

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

The easiest, cleanest, and most-likely-to-remain-usable optimisation 
would probably be adding frustum culling.

Texture/OpenGL state sorting would be doable, but I'm guessing it'd make 
the code quite hairy.  VRML semantics are that rendering order within a 
grouping node is irrelevant, so it's certainly not particularly 
difficult to imagine doing it and still allowing you to load VRML97 
content.  I'd guess doing simple change-minimisation would be 
considerably easier (e.g. track whether the current texture is a given 
Texture object), but I'm not sure it would actually cause a speed-up 
given that you'd be doing it in Python code.

Level-of-Detail support would be useful for content that supports it.

I would need to do some profiling to give any certain answers, but I'd 
guess providing display-list implementations would provide a speed-up 
for static IndexedFaceSets.  The opposite would be true (array-based 
implementations would speed-up) for dynamic (non-static) IndexedLineSet 
and PointSet objects (such as seen in the particle-system demo).

More advanced approaches, such as minimising the size of IFS arrays by 
converting to triangle-strips would probably be a good idea too.

Enjoy,
Mike

Rene Dudfield wrote:

>Very cool.  Looks like you are making quite a bit of
>progres on this :)
>
>
>I was reading through your "OpenGLContext Rendering
>Process" visitor doc, and was wondering how hard it
>would be to implement some of the rendering
>optimizations 
>  eg rendering sorted by texture/opengl state, or
>maybe culling geometry?
>
>Do you think they could be added whilst still keeping
>the code fairly simple/clean?
>
>
>
>
> --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
>I've just released OpenGLContext 2.0.0a3 for
>  
>
>>PyOpenGL 2.0.1.  The 
>>2.0.0a3 release includes far more documentation,
>>(particularly in-module 
>>docstrings), a number of bug-fixes in various
>>modules, and a re-worked 
>>node/field structure.
>>
>>There will probably be at least 1 more alpha release
>>before beta 1 (I'm 
>>considering adding support for prototyped nodes).
>>
>>See the release notes (readme.txt) for details on
>>changes.
>>
>>    http://pyopengl.sourceforge.net/context/
>>
>>Enjoy yourselves,
>>Mike
>>
>>    
>>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Users mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>  
>

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

Re: [PyOpenGL-Users] OpenGLContext 2.0.0a3 available...

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

Very cool.  Looks like you are making quite a bit of
progres on this :)


I was reading through your "OpenGLContext Rendering
Process" visitor doc, and was wondering how hard it
would be to implement some of the rendering
optimizations 
  eg rendering sorted by texture/opengl state, or
maybe culling geometry?

Do you think they could be added whilst still keeping
the code fairly simple/clean?




 --- "Mike C. Fletcher" <mcf...@ro...> wrote: >
I've just released OpenGLContext 2.0.0a3 for
> PyOpenGL 2.0.1.  The 
> 2.0.0a3 release includes far more documentation,
> (particularly in-module 
> docstrings), a number of bug-fixes in various
> modules, and a re-worked 
> node/field structure.
> 
> There will probably be at least 1 more alpha release
> before beta 1 (I'm 
> considering adding support for prototyped nodes).
> 
> See the release notes (readme.txt) for details on
> changes.
> 
>     http://pyopengl.sourceforge.net/context/
> 
> Enjoy yourselves,
> Mike
> 

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

[PyOpenGL-Users] OpenGLContext 2.0.0a3 available...

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

I've just released OpenGLContext 2.0.0a3 for PyOpenGL 2.0.1.  The 
2.0.0a3 release includes far more documentation, (particularly in-module 
docstrings), a number of bug-fixes in various modules, and a re-worked 
node/field structure.

There will probably be at least 1 more alpha release before beta 1 (I'm 
considering adding support for prototyped nodes).

See the release notes (readme.txt) for details on changes.

    http://pyopengl.sourceforge.net/context/

Enjoy yourselves,
Mike

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

[PyOpenGL-Users] Updated web-site

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

I've just uploaded a slightly fresher version of the web-site.  It's not 
a particularly radical change, and it still doesn't have a screenshots 
area, but it does have the build/install, nehe and py2exe tutorial 
links, as well as updated pydocs for OpenGLContext.

    http://pyopengl.sourceforge.net/

I'm working on getting the docbook-based manual re-converted, but it's 
looking like that will be a while, as neither the saxon processor or 
4Suite is able to do the transformation at the moment.

Suggestions welcome,
Mike

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

Re: [PyOpenGL-Users] gluPickMatrix and glPointSize

[Peter P. <pa...@cs...>]

Hi Rene,

I actually found the answer in the OpenGL advanced notes after some
searching. Note the starred section.

"The OpenGL selection method determines that an object has been hit if  it
intersects the view volume. Bitmap and pixel image primitives will  generate
a hit record only if a raster positioning command is sent to  the pipeline
and the transformed position lies within the viewing volume. To generate hit
records for any point within a pixel image or bitmap, a bounding rectangle
should be sent rather than the image, and selection testing performed on the
interior of the rectangle. ****Similarly, wide lines and points will be
selected only if the equivalent infinitely thin line or small point would be
selected. To facilitate selection testing of wide lines and points, proxy
geometry representing the true footprint of the primitive should be used
instead****"

Pete

Re: [PyOpenGL-Users] gluPickMatrix and glPointSize

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

 --- pa...@cs... wrote: > I have a question
about the effect of glPointSize
> and glLineWidth on 
> picking. I have code that is able to return a
> hitlist for polygons on 
> the screen for a one pixel picking box. When I try
> to pick points and 
> lines, it also works fine. When I change the point
> size or the line 
> width, however, the picking no longer works for
> points and lines 
> unless I pick the exact center of the points and
> lines.
> 
> I could have sworn that picking is an operation that
> is applied after 
> rasterization in the OpenGL pipline. Can anyone
> explain this behavior 
> to me? Is there a work around?
> 
> Thanks,
> Pete
> 

One work around might be to draw multiple parallel
lines instead?

Do you have the code?  Maybe it is an issue with your
opengl implementation?

Which opengl implementation do you use?


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

[PyOpenGL-Users] gluPickMatrix and glPointSize

[<pa...@cs...>]

I have a question about the effect of glPointSize and glLineWidth on 
picking. I have code that is able to return a hitlist for polygons on 
the screen for a one pixel picking box. When I try to pick points and 
lines, it also works fine. When I change the point size or the line 
width, however, the picking no longer works for points and lines 
unless I pick the exact center of the points and lines.

I could have sworn that picking is an operation that is applied after 
rasterization in the OpenGL pipline. Can anyone explain this behavior 
to me? Is there a work around?

Thanks,
Pete

Re: [PyOpenGL-Users] true type fonts

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

This is taken from OpenGLContext/tests/glprint.py , the major difference 
I can see is that it generates the display-lists before trying to fill 
them with wglUseFontBitmaps(...)

        self.base = glGenLists(96)                                # 
Storage For 96 Characters
        wgldc = wglGetCurrentDC()
        dc = win32ui.CreateDCFromHandle( wgldc )
        ## pitch and family value
        f = win32ui.CreateFont(
            {
                'italic': None, #use of None is required, 0 doesn't work
                'underline': None, #use of None is required, 0 doesn't work
                'name': 'Times New Roman',
                'weight': 700,
                'height': 20,
            }
        )
        dc.SelectObject(
            f
        )
        wglUseFontBitmaps(wgldc, 32, 96, self.base)    # Builds 96 
Characters Starting At Character 32
        # f is deleted here, if it is deleted before the display-lists
        # are created they will just use the default font!

I only have one machine to test on, so it's possible that too will fail 
on some machines, but I'm pretty sure you want the glGelLists call 
regardless.

You can also find sample code in NeHe tutorials #13 and #14, and the 
OpenGLContext/scenegraph/text package. Also note that there's no decent 
way to get font metrics that I've found for the bitmap versions of fonts 
using WGL. If anyone finds one I'd like to include that functionality in 
OpenGLContext/scenegraph/text.

Good luck,
Mike

Sean Riley wrote:

>Here is some code I used to get true type font working. This took a while to
>figure out...
>
>handle = 55
>
>def createFont(fontName, fontSize):
>   props = {"name":fontName,
>            "height":(int)(fontSize),
>            "charset":0, "weight":1,
>            "pitch and family":18}
>
>   pf = win32ui.CreateFont( props )
>   hdc = wglGetCurrentDC()
>   pdc = win32ui.CreateDCFromHandle(hdc)
>
>   old = pdc.SelectObject(pf)
>   result = wglUseFontBitmaps(hdc , 0, 255, handle)
>   if not result:
>         print "ERROR!"
>   pdc.SelectObject(old)
>
>def drawText(text, pos, color):
>    glColor4ub( color[0], color[1], color[2], color[3] )
>    glRasterPos2i(position[0], position[1])
>    glListBase(handle)
>    glCallLists(text)
>
>This fails on some machines though, when trying to create the truetype
>font... I
>dunno why.
>
>---------------------------------
>"I'm not as interested in being witty as I am in being clear", Scott Meyers
>Sean Riley
>MrR...@ya...
>  
>

[PyOpenGL-Users] true type fonts

[Sean R. <mrr...@ya...>]

Here is some code I used to get true type font working. This took a while to
figure out...

handle = 55

def createFont(fontName, fontSize):
   props = {"name":fontName,
            "height":(int)(fontSize),
            "charset":0, "weight":1,
            "pitch and family":18}

   pf = win32ui.CreateFont( props )
   hdc = wglGetCurrentDC()
   pdc = win32ui.CreateDCFromHandle(hdc)

   old = pdc.SelectObject(pf)
   result = wglUseFontBitmaps(hdc , 0, 255, handle)
   if not result:
         print "ERROR!"
   pdc.SelectObject(old)

def drawText(text, pos, color):
    glColor4ub( color[0], color[1], color[2], color[3] )
    glRasterPos2i(position[0], position[1])
    glListBase(handle)
    glCallLists(text)

This fails on some machines though, when trying to create the truetype
font... I
dunno why.

---------------------------------
"I'm not as interested in being witty as I am in being clear", Scott Meyers
Sean Riley
MrR...@ya...

[PyOpenGL-Users] PyOpenGL 2.0.1.01 (alpha) and OpenGLContext 2.0.0a1

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

This is just to let people know that both projects have just released 
new alpha versions.  PyOpenGL's release is currently source-only, so 
you'll need a compiler to check it out.  These are early alphas, so I 
would only suggest using them for testing, rather than trying to use 
them for anything you care about.

BTW, new (partially finished) home-page for OpenGLContext is now up at:
    http://pyopengl.sourceforge.net/context/

I'll try to work on the main site sometime in the next week or two.

Enjoy yourselves,
Mike

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