pyopengl-users

[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

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] 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] 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/

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.

[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.

[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.

[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/

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.

[Jack J. <Jac...@cw...>]

On Tuesday, Feb 4, 2003, at 00:00 Europe/Amsterdam, Mike C. Fletcher 
wrote:

> Strangely, that first post of Guido's is what gave me the impression 
> the buffer API was considered less than optimal for continued use.

Here's the full scoop:
1. Buffer objects are bad (mainly because of refcount problems and 
more).
2. The buffer API in general is a good idea, and it will stay, but
3. The multi-segment capability of the buffer API may go away (or may 
not be supported in future calls), as it was never used much anyway 
(most users of the buffer API will simply complain and stop if there is 
more than one segment).
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman