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
>