pyopengl-users

[PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Hello,

I've recently started using PyOpenGL as the framework for re-writing C/ 
C++ OpenGL wrappers around an large amount of research code in C.  Its  
been a pleasure to have something that allows such literal translation  
from the successful C/C++ OpenGL code to Python code; thanks for  
creating this!

The main hitch I've had is in using glDrawElements.  I've looked  
around for answers to this, and its clear that people people using  
PyOpenGL are using it with geometry that is created on the python  
side.  In my case, all the geometry information is created on the C  
side, and I want to control its display from Python.

The line that's causing problems is:

   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,  
lpld.indx + vertIdx)

where lpld.indx is a ctypes-created pointer to a buffer of unsigned  
ints allocated and filled in C, which causes this problem:

   Traceback (most recent call last):
     File "pgltDemo.py", line 118, in display
       pgltDraw(pgltObject, uva)
     File "pgltDemo.py", line 76, in pgltDraw
       GL_UNSIGNED_INT, lpld.indx + vertIdx)
   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'

because apparently pointer arithmetic games aren't quite so simply in  
Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",  
which removes the pointer arithmetic stuff, it segfaults.  I know that  
others have looked at this issue from the context of having array data  
that's created via numpy:

http://www.mail-archive.com/pyg...@go.../msg01356/t.py

I've tried many different iterations of things like this, and I get  
either python errors or segfaults.

Getting this to work with PyOpenGL would make a huge difference in how  
I can get research work done with python, so I've taken some type to  
put a self-contained example online:

http://people.cs.uchicago.edu/~glk/pglt/

This includes a C library the generates some geometry to render, and a  
ctypeslib-generated wrapper around the library.  pgltDemo.c contains a  
"pgltDraw()" function that shows how I'm currently doing things  
without (for display lists) and with vertex arrays.  pgltDemo.py  
contains the same function, but the vertex array code is broken.

Hopefully someone on this list will be able to spend a little time  
working with these examples, and figure out how to get my  
"pgltDemo.py" to work with vertex arrays.

Thanks very much,
Gordon

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Mads I. <mp...@co...>]

Gordon L. Kindlmann wrote:
> Hello,
>
> I've recently started using PyOpenGL as the framework for re-writing C/ 
> C++ OpenGL wrappers around an large amount of research code in C.  Its  
> been a pleasure to have something that allows such literal translation  
> from the successful C/C++ OpenGL code to Python code; thanks for  
> creating this!
>
> The main hitch I've had is in using glDrawElements.  I've looked  
> around for answers to this, and its clear that people people using  
> PyOpenGL are using it with geometry that is created on the python  
> side.  In my case, all the geometry information is created on the C  
> side, and I want to control its display from Python.
>
> The line that's causing problems is:
>
>    glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,  
> lpld.indx + vertIdx)
>
> where lpld.indx is a ctypes-created pointer to a buffer of unsigned  
> ints allocated and filled in C, which causes this problem:
>
>    Traceback (most recent call last):
>      File "pgltDemo.py", line 118, in display
>        pgltDraw(pgltObject, uva)
>      File "pgltDemo.py", line 76, in pgltDraw
>        GL_UNSIGNED_INT, lpld.indx + vertIdx)
>    TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>
> because apparently pointer arithmetic games aren't quite so simply in  
> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",  
> which removes the pointer arithmetic stuff, it segfaults.  I know that  
> others have looked at this issue from the context of having array data  
> that's created via numpy:
>
> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>
> I've tried many different iterations of things like this, and I get  
> either python errors or segfaults.
>
> Getting this to work with PyOpenGL would make a huge difference in how  
> I can get research work done with python, so I've taken some type to  
> put a self-contained example online:
>
> http://people.cs.uchicago.edu/~glk/pglt/
>
> This includes a C library the generates some geometry to render, and a  
> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a  
> "pgltDraw()" function that shows how I'm currently doing things  
> without (for display lists) and with vertex arrays.  pgltDemo.py  
> contains the same function, but the vertex array code is broken.
>
> Hopefully someone on this list will be able to spend a little time  
> working with these examples, and figure out how to get my  
> "pgltDemo.py" to work with vertex arrays.
>
> Thanks very much,
> Gordon
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>   
Using ctypes, I wrote the following interface to glMultiDrawElements:

# Interface to glMultiDrawElements
def multiDrawElements(mode, count, gl_type, index):
    """
    """
    # Set up interface for the call
    n_count = count.shape[0]
    libGL.glMultiDrawElements.restype  = ctypes.c_void_p
    libGL.glMultiDrawElements.argtypes = [ctypes.c_int32,
                                          ctypes.POINTER(ctypes.c_int32),
                                          ctypes.c_int32,
                                          
ctypes.POINTER(ctypes.c_int32)*n_count,
                                          ctypes.c_int32,
                                          ]

    # Set pointer to data in the count array
    count_ptr = count.ctypes.data_as(ctypes.POINTER(ctypes.c_int32))

    # Set array of pointers to the index array
    iptr = ctypes.POINTER(ctypes.c_int32)
    index_ptr = (iptr*len(index))(*[row.ctypes.data_as(iptr) for row in 
index])

    # Do the actual call to glMultiDrawElements
    libGL.glMultiDrawElements(int(mode), count_ptr, int(gl_type), 
index_ptr, n_count)

Then, using vertex arrays, I call glMultiDrawElements as follows:

multiDrawElements(GL_QUAD_STRIP, count, GL_UNSIGNED_INT, index)

You should be able to boil this down to a working example for 
glDrawElements(), whose arguments are a subset of the arguments to 
glMultiDrawElements.

Best regards,

Mads

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

On Jun 2, 2009, at 3:24 AM, Mads Ipsen wrote:

> Gordon L. Kindlmann wrote:
>> Hello,
>>
>> I've recently started using PyOpenGL as the framework for re- 
>> writing C/ C++ OpenGL wrappers around an large amount of research  
>> code in C.  Its  been a pleasure to have something that allows such  
>> literal translation  from the successful C/C++ OpenGL code to  
>> Python code; thanks for  creating this!

...
>> http://people.cs.uchicago.edu/~glk/pglt/
>>
...
>> Hopefully someone on this list will be able to spend a little time   
>> working with these examples, and figure out how to get my   
>> "pgltDemo.py" to work with vertex arrays.
>>
>> Thanks very much,
>> Gordon
>>
>>
>>
> Using ctypes, I wrote the following interface to glMultiDrawElements:
>
> # Interface to glMultiDrawElements
> def multiDrawElements(mode, count, gl_type, index):
>   """
>   """
>   # Set up interface for the call
>   n_count = count.shape[0]
>   libGL.glMultiDrawElements.restype  = ctypes.c_void_p
>   libGL.glMultiDrawElements.argtypes = [ctypes.c_int32,
>                                          
> ctypes.POINTER(ctypes.c_int32),
>                                         ctypes.c_int32,
>                                          
> ctypes.POINTER(ctypes.c_int32)*n_count,
>                                         ctypes.c_int32,
>                                         ]
>
>   # Set pointer to data in the count array
>   count_ptr = count.ctypes.data_as(ctypes.POINTER(ctypes.c_int32))
>
>   # Set array of pointers to the index array
>   iptr = ctypes.POINTER(ctypes.c_int32)
>   index_ptr = (iptr*len(index))(*[row.ctypes.data_as(iptr) for row  
> in index])
>
>   # Do the actual call to glMultiDrawElements
>   libGL.glMultiDrawElements(int(mode), count_ptr, int(gl_type),  
> index_ptr, n_count)
>
> Then, using vertex arrays, I call glMultiDrawElements as follows:
>
> multiDrawElements(GL_QUAD_STRIP, count, GL_UNSIGNED_INT, index)

Okay, this is interesting.  However, I'm confused about the types of  
the arguments that you're passing to multiDrawElements().  "count"  
looks like it must be a numpy array, since you're using .shape  
and .ctypes.data_as, right?  "index" is a 2-D numpy array, given your  
use of row.ctypes.data_as for row in index, right?

I agree that this is relevant, but I'm still stumped because my data  
is not coming from numpy.  Its coming from a C-allocated array that is  
being accessed via numpy.  There is no .data_as for me.  I don't quite  
understand the relationship between what .data_as returns, how  
pyopengl's use of ctypes handles that "pointer", and how to  
communicate the analogous information from array allocated in C,  
outside of numpy.

If you have any spare time, I'd be interested if you can tweak the  
call to glDrawElements in

http://people.cs.uchicago.edu/~glk/pglt/pgltDemo.py

so that it works; I've done everything I can to make a self-contained  
but non-trivial demonstration of the problem I'm having.

Thanks,
Gordon

>
>
> You should be able to boil this down to a working example for  
> glDrawElements(), whose arguments are a subset of the arguments to  
> glMultiDrawElements.
>
> Best regards,
>
> Mads
>
>
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Sorry for the excessive traffic ...

On Jun 2, 2009, at 5:35 AM, Gordon L. Kindlmann wrote:

> I agree that this is relevant, but I'm still stumped because my data
> is not coming from numpy.  Its coming from a C-allocated array that is
> being accessed via numpy.

being accessed via *ctypes*.

>  There is no .data_as for me.

This is the important point.

>  I don't quite
> understand the relationship between what .data_as returns, how
> pyopengl's use of ctypes handles that "pointer", and how to
> communicate the analogous information from array allocated in C,
> outside of numpy.
>
> If you have any spare time, I'd be interested if you can tweak the
> call to glDrawElements in
>
> http://people.cs.uchicago.edu/~glk/pglt/pgltDemo.py
>
> so that it works; I've done everything I can to make a self-contained
> but non-trivial demonstration of the problem I'm having.
>
> Thanks,
> Gordon

Gordon

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

hi,

usually you can create the array in python, and then give a pointer to the
C/C++/F0oLang

Generally easiest for my mind.  That leaves the memory management in python.

Or create the python buffers from your pointer.


Then create the slices in python, rather than using pointer arithmetic.

eg, new_array = array[vertIdx:]



cu,

On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann <gl...@uc...>wrote:

> Hello,
>
> I've recently started using PyOpenGL as the framework for re-writing C/
> C++ OpenGL wrappers around an large amount of research code in C.  Its
> been a pleasure to have something that allows such literal translation
> from the successful C/C++ OpenGL code to Python code; thanks for
> creating this!
>
> The main hitch I've had is in using glDrawElements.  I've looked
> around for answers to this, and its clear that people people using
> PyOpenGL are using it with geometry that is created on the python
> side.  In my case, all the geometry information is created on the C
> side, and I want to control its display from Python.
>
> The line that's causing problems is:
>
>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
> lpld.indx + vertIdx)
>
> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
> ints allocated and filled in C, which causes this problem:
>
>   Traceback (most recent call last):
>     File "pgltDemo.py", line 118, in display
>       pgltDraw(pgltObject, uva)
>     File "pgltDemo.py", line 76, in pgltDraw
>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>
> because apparently pointer arithmetic games aren't quite so simply in
> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
> which removes the pointer arithmetic stuff, it segfaults.  I know that
> others have looked at this issue from the context of having array data
> that's created via numpy:
>
> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>
> I've tried many different iterations of things like this, and I get
> either python errors or segfaults.
>
> Getting this to work with PyOpenGL would make a huge difference in how
> I can get research work done with python, so I've taken some type to
> put a self-contained example online:
>
> http://people.cs.uchicago.edu/~glk/pglt/<http://people.cs.uchicago.edu/%7Eglk/pglt/>
>
> This includes a C library the generates some geometry to render, and a
> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a
> "pgltDraw()" function that shows how I'm currently doing things
> without (for display lists) and with vertex arrays.  pgltDemo.py
> contains the same function, but the vertex array code is broken.
>
> Hopefully someone on this list will be able to spend a little time
> working with these examples, and figure out how to get my
> "pgltDemo.py" to work with vertex arrays.
>
> Thanks very much,
> Gordon
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Hello,

I'm aware that most users of PyOpenGL are creating their arrays on the  
python side.

In my case, I'd like to make use of a large set of pre-existing C  
libraries, which do what they do very well, and do it rapidly.  This  
includes extracting features from scientific data, and representing  
them as polydata, which I'd like to visualize from python.  Creating  
the buffers in python is not an option for me.  Copying the data into  
a python array, just so I can hand it back to PyOpenGL, which in turn  
goes back through ctypes to give it OpenGL, is going to incur a memory  
and performance cost that should be avoided.

I know that what I'm hoping to do is possible, somehow, because the  
underlying array data is already being used perfectly well to call  
glDrawElements from C.

I remain hopeful that someone on this list has the time and expertise  
to help me make this work.

Gordon

On Jun 3, 2009, at 5:44 AM, René Dudfield wrote:

> hi,
>
> usually you can create the array in python, and then give a pointer  
> to the C/C++/F0oLang
>
> Generally easiest for my mind.  That leaves the memory management in  
> python.
>
> Or create the python buffers from your pointer.
>
>
> Then create the slices in python, rather than using pointer  
> arithmetic.
>
> eg, new_array = array[vertIdx:]
>
>
>
> cu,
>
> On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann  
> <gl...@uc...> wrote:
> Hello,
>
> I've recently started using PyOpenGL as the framework for re-writing  
> C/
> C++ OpenGL wrappers around an large amount of research code in C.  Its
> been a pleasure to have something that allows such literal translation
> from the successful C/C++ OpenGL code to Python code; thanks for
> creating this!
>
> The main hitch I've had is in using glDrawElements.  I've looked
> around for answers to this, and its clear that people people using
> PyOpenGL are using it with geometry that is created on the python
> side.  In my case, all the geometry information is created on the C
> side, and I want to control its display from Python.
>
> The line that's causing problems is:
>
>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
> lpld.indx + vertIdx)
>
> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
> ints allocated and filled in C, which causes this problem:
>
>   Traceback (most recent call last):
>     File "pgltDemo.py", line 118, in display
>       pgltDraw(pgltObject, uva)
>     File "pgltDemo.py", line 76, in pgltDraw
>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>
> because apparently pointer arithmetic games aren't quite so simply in
> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
> which removes the pointer arithmetic stuff, it segfaults.  I know that
> others have looked at this issue from the context of having array data
> that's created via numpy:
>
> http://www.mail-archive.com/pyg...@go.../msg01356/ 
> t.py
>
> I've tried many different iterations of things like this, and I get
> either python errors or segfaults.
>
> Getting this to work with PyOpenGL would make a huge difference in how
> I can get research work done with python, so I've taken some type to
> put a self-contained example online:
>
> http://people.cs.uchicago.edu/~glk/pglt/
>
> This includes a C library the generates some geometry to render, and a
> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a
> "pgltDraw()" function that shows how I'm currently doing things
> without (for display lists) and with vertex arrays.  pgltDemo.py
> contains the same function, but the vertex array code is broken.
>
> Hopefully someone on this list will be able to spend a little time
> working with these examples, and figure out how to get my
> "pgltDemo.py" to work with vertex arrays.
>
> Thanks very much,
> Gordon
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity  
> professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like  
> Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the  
> latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

hi again,

or if you just want to whip up a c module...

the buffer interface is your friend:
    http://docs.python.org/dev/c-api/buffer.html


Check out the docs for this functions:
PyObject* PyBuffer_FromMemory(void *ptr, Py_ssize_t size)
PyObject* PyBuffer_FromReadWriteMemory(void *ptr, Py_ssize_t size)






On Wed, Jun 3, 2009 at 8:44 PM, René Dudfield <re...@gm...> wrote:
>
> hi,
>
> usually you can create the array in python, and then give a pointer to the C/C++/F0oLang
>
> Generally easiest for my mind.  That leaves the memory management in python.
>
> Or create the python buffers from your pointer.
>
>
> Then create the slices in python, rather than using pointer arithmetic.
>
> eg, new_array = array[vertIdx:]
>
>
>
> cu,
>
> On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann <gl...@uc...> wrote:
>>
>> Hello,
>>
>> I've recently started using PyOpenGL as the framework for re-writing C/
>> C++ OpenGL wrappers around an large amount of research code in C.  Its
>> been a pleasure to have something that allows such literal translation
>> from the successful C/C++ OpenGL code to Python code; thanks for
>> creating this!
>>
>> The main hitch I've had is in using glDrawElements.  I've looked
>> around for answers to this, and its clear that people people using
>> PyOpenGL are using it with geometry that is created on the python
>> side.  In my case, all the geometry information is created on the C
>> side, and I want to control its display from Python.
>>
>> The line that's causing problems is:
>>
>>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
>> lpld.indx + vertIdx)
>>
>> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
>> ints allocated and filled in C, which causes this problem:
>>
>>   Traceback (most recent call last):
>>     File "pgltDemo.py", line 118, in display
>>       pgltDraw(pgltObject, uva)
>>     File "pgltDemo.py", line 76, in pgltDraw
>>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>>
>> because apparently pointer arithmetic games aren't quite so simply in
>> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
>> which removes the pointer arithmetic stuff, it segfaults.  I know that
>> others have looked at this issue from the context of having array data
>> that's created via numpy:
>>
>> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>>
>> I've tried many different iterations of things like this, and I get
>> either python errors or segfaults.
>>
>> Getting this to work with PyOpenGL would make a huge difference in how
>> I can get research work done with python, so I've taken some type to
>> put a self-contained example online:
>>
>> http://people.cs.uchicago.edu/~glk/pglt/
>>
>> This includes a C library the generates some geometry to render, and a
>> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a
>> "pgltDraw()" function that shows how I'm currently doing things
>> without (for display lists) and with vertex arrays.  pgltDemo.py
>> contains the same function, but the vertex array code is broken.
>>
>> Hopefully someone on this list will be able to spend a little time
>> working with these examples, and figure out how to get my
>> "pgltDemo.py" to work with vertex arrays.
>>
>> Thanks very much,
>> Gordon
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Hello,

On Jun 3, 2009, at 5:55 AM, René Dudfield wrote:

> hi again,
>
> or if you just want to whip up a c module...
>
> the buffer interface is your friend:
>     http://docs.python.org/dev/c-api/buffer.html
>
>
> Check out the docs for this functions:
> PyObject* PyBuffer_FromMemory(void *ptr, Py_ssize_t size)
> PyObject* PyBuffer_FromReadWriteMemory(void *ptr, Py_ssize_t size)

Maybe I'm missing something about the value of this "PyBuffer", but  
ctypes is already providing everything I need to access the individual  
values in the C-allocated array.  That's how I'm currently drawing  
geometry without glDrawElements in

http://people.cs.uchicago.edu/~glk/pglt/pgltDemo.py

The values in the "norm", "xyzw", and "rgba" arrays are being accessed  
just fine.  The problem is finding a way to pass the correct pointer  
to these pre-existing buffers for glDrawElements.

> sure, but can those libraries let you pass in your own allocated data?
> Or are they not extensible in that way?  Many C libraries let you
> allocate the memory yourself, is why I asked.

The nature of the computation being implemented in the C library is  
that you don't know ahead of time how much geometry is going to be  
generated, so pre-allocation is not possible.  It represents a numeric  
search that may terminate sooner or later, depending on local data  
conditions.  The C library already handles dynamic reallocation as  
needed, and returns a buffer that is sized to fit the computation  
results.

> but, if you don't want to do it that way, or can't then you can create
> a buffer from a pointer+size, and then use it.

I'm sorry, I don't know precisely what you mean by this.

> Seems to be some ctypes wrappers here:
> http://svn.python.org/projects/ctypes/trunk/ctypeslib/ctypeslib/contrib/pythonhdr.py
>
> For the PyBuffer_FromReadWriteMemory function.  If you don't want to
> use a C module for it.

Again, I may be missing the point of this PyBuffer object, but I don't  
see how it answers the issue about how to pass the right kind of  
pointer to glDrawElements.

Would it be possible for you to indicate with some pseudocode how this  
would be used?

Thanks,
Gordon


>
>
>
>
>
>
>
> On Wed, Jun 3, 2009 at 8:44 PM, René Dudfield <re...@gm...>  
> wrote:
>>
>> hi,
>>
>> usually you can create the array in python, and then give a pointer  
>> to the C/C++/F0oLang
>>
>> Generally easiest for my mind.  That leaves the memory management  
>> in python.
>>
>> Or create the python buffers from your pointer.
>>
>>
>> Then create the slices in python, rather than using pointer  
>> arithmetic.
>>
>> eg, new_array = array[vertIdx:]
>>
>>
>>
>> cu,
>>
>> On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann  
>> <gl...@uc...> wrote:
>>>
>>> Hello,
>>>
>>> I've recently started using PyOpenGL as the framework for re- 
>>> writing C/
>>> C++ OpenGL wrappers around an large amount of research code in C.   
>>> Its
>>> been a pleasure to have something that allows such literal  
>>> translation
>>> from the successful C/C++ OpenGL code to Python code; thanks for
>>> creating this!
>>>
>>> The main hitch I've had is in using glDrawElements.  I've looked
>>> around for answers to this, and its clear that people people using
>>> PyOpenGL are using it with geometry that is created on the python
>>> side.  In my case, all the geometry information is created on the C
>>> side, and I want to control its display from Python.
>>>
>>> The line that's causing problems is:
>>>
>>>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
>>> lpld.indx + vertIdx)
>>>
>>> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
>>> ints allocated and filled in C, which causes this problem:
>>>
>>>   Traceback (most recent call last):
>>>     File "pgltDemo.py", line 118, in display
>>>       pgltDraw(pgltObject, uva)
>>>     File "pgltDemo.py", line 76, in pgltDraw
>>>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>>>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and  
>>> 'int'
>>>
>>> because apparently pointer arithmetic games aren't quite so simply  
>>> in
>>> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
>>> which removes the pointer arithmetic stuff, it segfaults.  I know  
>>> that
>>> others have looked at this issue from the context of having array  
>>> data
>>> that's created via numpy:
>>>
>>> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>>>
>>> I've tried many different iterations of things like this, and I get
>>> either python errors or segfaults.
>>>
>>> Getting this to work with PyOpenGL would make a huge difference in  
>>> how
>>> I can get research work done with python, so I've taken some type to
>>> put a self-contained example online:
>>>
>>> http://people.cs.uchicago.edu/~glk/pglt/
>>>
>>> This includes a C library the generates some geometry to render,  
>>> and a
>>> ctypeslib-generated wrapper around the library.  pgltDemo.c  
>>> contains a
>>> "pgltDraw()" function that shows how I'm currently doing things
>>> without (for display lists) and with vertex arrays.  pgltDemo.py
>>> contains the same function, but the vertex array code is broken.
>>>
>>> Hopefully someone on this list will be able to spend a little time
>>> working with these examples, and figure out how to get my
>>> "pgltDemo.py" to work with vertex arrays.
>>>
>>> Thanks very much,
>>> Gordon
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity  
>>> professionals. Meet
>>> the minds behind Google Creative Lab, Visual Complexity,  
>>> Processing, &
>>> iPhoneDevCamp as they present alongside digital heavyweights like  
>>> Barbarian
>>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>>> _______________________________________________
>>> PyOpenGL Homepage
>>> http://pyopengl.sourceforge.net
>>> _______________________________________________
>>> PyOpenGL-Users mailing list
>>> PyO...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the  
> latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

On Wed, Jun 3, 2009 at 8:53 PM, Gordon L. Kindlmann <gl...@uc...> wrote:
> Hello,
>
> I'm aware that most users of PyOpenGL are creating their arrays on the
> python side.
>
> In my case, I'd like to make use of a large set of pre-existing C libraries,
> which do what they do very well, and do it rapidly.  This includes
> extracting features from scientific data, and representing them as polydata,
> which I'd like to visualize from python.  Creating the buffers in python is
> not an option for me.  Copying the data into a python array, just so I can
> hand it back to PyOpenGL, which in turn goes back through ctypes to give it
> OpenGL, is going to incur a memory and performance cost that should be
> avoided.

sure, but can those libraries let you pass in your own allocated data?
 Or are they not extensible in that way?  Many C libraries let you
allocate the memory yourself, is why I asked.

but, if you don't want to do it that way, or can't then you can create
a buffer from a pointer+size, and then use it.


cheers,

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

Seems to be some ctypes wrappers here:
http://svn.python.org/projects/ctypes/trunk/ctypeslib/ctypeslib/contrib/pythonhdr.py

For the PyBuffer_FromReadWriteMemory function.  If you don't want to
use a C module for it.


cu,


On Wed, Jun 3, 2009 at 9:01 PM, René Dudfield <re...@gm...> wrote:
> On Wed, Jun 3, 2009 at 8:53 PM, Gordon L. Kindlmann <gl...@uc...> wrote:
>> Hello,
>>
>> I'm aware that most users of PyOpenGL are creating their arrays on the
>> python side.
>>
>> In my case, I'd like to make use of a large set of pre-existing C libraries,
>> which do what they do very well, and do it rapidly.  This includes
>> extracting features from scientific data, and representing them as polydata,
>> which I'd like to visualize from python.  Creating the buffers in python is
>> not an option for me.  Copying the data into a python array, just so I can
>> hand it back to PyOpenGL, which in turn goes back through ctypes to give it
>> OpenGL, is going to incur a memory and performance cost that should be
>> avoided.
>
> sure, but can those libraries let you pass in your own allocated data?
>  Or are they not extensible in that way?  Many C libraries let you
> allocate the memory yourself, is why I asked.
>
> but, if you don't want to do it that way, or can't then you can create
> a buffer from a pointer+size, and then use it.
>
>
> cheers,
>