pyopengl-users

[PyOpenGL-Users] mixing C++ and python w/ opengl

[Philip W. <pwi...@gm...>]

Is it okay to draw stuff with pyopengl then call into C/C++ with ctypes and
then draw from there, directly with opengl C API?  Any gotchas as far as
mixing things up like this?  Does anyone does this, did it work for you?

The reason we are considering this is we have a Python/Tk app.  It draws a
bunch of geometry/textures with pyopengl.  The Python app has a C extension
which contains a bunch of data in C.  Now we want to start drawing this
geometry.  Rather than pull it into Python and then push it back with
pyopengl, it seems like we could just draw it from C, if that is allowed.

Let me know if this seems like a bad idea in general!  Thanks.

-Philip

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Christopher B. <Chr...@no...>]

On 1/25/11 2:22 PM, Philip Winston wrote:
> Is it okay to draw stuff with pyopengl then call into C/C++ with ctypes
> and then draw from there, directly with opengl C API?

yep -- you can do this.

You may want to try using Cython, rather than raw C. Some googling 
should tern up some notes on this. In particular I believe Sturla Molden 
put out a *.pxi file for OPenGL:

http://groups.google.com/group/cython-users/browse_thread/thread/adc1495342da0779

In fact, at least some of PyOpenGL is written with Cython.

> Rather than pull it into Python and then push it
> back with pyopengl, it seems like we could just draw it from C, if that
> is allowed.

well, I don't know that I'd do it for this reason -- if you pull/push 
the data as numpy arrays, you can do all that without data copying, so 
keeping it in Python may be fine.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Philip W. <pwi...@gm...>]

>
> You may want to try using Cython, rather than raw C.


We've been meaning to investigate Cython.  We use C/C++ libraries and ctypes
today.  One advantage of C is that other C/C++ programs can use the
libraries.  But I'm interested in trying Cython just to learn about it.

> Rather than pull it into Python and then push it
> > back with pyopengl, it seems like we could just draw it from C, if that
> > is allowed.
>
> well, I don't know that I'd do it for this reason -- if you pull/push
> the data as numpy arrays, you can do all that without data copying, so
> keeping it in Python may be fine.
>

You might be right.

How do you completely avoid the copy?  I do something really simple/dumb
when right now when I need to return an array from C to Python.  I do use
numpy, but I do the allocation in Python and then hand the empty array to C
to copy the values into.

I saw some stuff about defining an allocator but it looked complicated.

I wonder if my simplistic approach if the copy would hurt me.  I wonder if I
should be using a better no-copy approach instead.

Anyway probably I should start by keeping drawing in Python and if/when I
measure a real performance problem consider pushing it to C.  This is how we
operate with other stuff, resorting to C only to solve a specific
performance issue.

-Philip

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Alejandro S. <as...@gm...>]

On Tue, Jan 25, 2011 at 9:48 PM, Philip Winston <pwi...@gm...> wrote:

> You may want to try using Cython, rather than raw C.
>
>
> We've been meaning to investigate Cython.  We use C/C++ libraries and
> ctypes today.  One advantage of C is that other C/C++ programs can use the
> libraries.  But I'm interested in trying Cython just to learn about it.
>

I definitely recommend it. I used Cython to expose the core classes of an
in-house render engine I was developing in C++ to Python code and I can say
it was a breeze.

All you have to do is write a simple wrapper around your C/C++ code and a
pyx file that will compile your wrapper into a shared object. You can then
import the compiled .so from Python.

Wrapping C++ was a little more complicated than pure C, as objects had to be
used as opaque types in version 0.12, but now that version 0.13 is out, C++
support has been vastly improved.

Once you have your Cython module compiled, you can create an OpenGL
window/panel from Python code and the draw calls in your C/C++ code will
automagically work :)

Good luck!
Alejandro.-


>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>


-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Dirk R. <dir...@gm...>]

	Hi All,

On 01/26/2011 08:40 AM, Alejandro Segovia wrote:
>
> I definitely recommend it. I used Cython to expose the core classes of an
> in-house render engine I was developing in C++ to Python code and I can say it
> was a breeze.
>
> All you have to do is write a simple wrapper around your C/C++ code and a pyx
> file that will compile your wrapper into a shared object. You can then import
> the compiled .so from Python.
>
> Wrapping C++ was a little more complicated than pure C, as objects had to be
> used as opaque types in version 0.12, but now that version 0.13 is out, C++
> support has been vastly improved.
>
> Once you have your Cython module compiled, you can create an OpenGL window/panel
> from Python code and the draw calls in your C/C++ code will automagically work :)

to throw another option in the mix: we've done similar things using 
boost::python. We have a set of core rendering classes that do the slow stuff 
(iterate through long loops and pass the data to OpenGL) and the UI (PyQT) and 
OpenGL setups are done in Python.

Mixing PyOpenGL and C/C++ is no problem at all and works very well. I haven't 
used the C++ interface for Cython, but boost::python is very, very easy to use.

Just my $.02

	Dirk

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

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

On 11-01-25 06:48 PM, Philip Winston wrote:
...
>
>     > Rather than pull it into Python and then push it
>     > back with pyopengl, it seems like we could just draw it from C,
>     if that
>     > is allowed.
>
>     well, I don't know that I'd do it for this reason -- if you pull/push
>     the data as numpy arrays, you can do all that without data copying, so
>     keeping it in Python may be fine.
>
>
> You might be right.
>
> How do you completely avoid the copy?  I do something really 
> simple/dumb when right now when I need to return an array from C to 
> Python.  I do use numpy, but I do the allocation in Python and then 
> hand the empty array to C to copy the values into.
By default, numpy arrays only copy if they need to have their 
data-format changed.  There's a flag in OpenGL.__init__ which, if set on 
import, will raise errors when that copying occurs.  You can do the same 
by registering an array data-format handler for your C-provided types, 
but Numpy is probably a better/easier option.  Under the covers, 
PyOpenGL is examining the type of the numpy array and, if it is 
compatible, just pulling out the data-pointer from the underlying memory 
area.  Your data-array class could do the same thing, but again, it is 
probably easier to just use Numpy for this kind of work.
>
> I saw some stuff about defining an allocator but it looked complicated.
>
> I wonder if my simplistic approach if the copy would hurt me.  I 
> wonder if I should be using a better no-copy approach instead.
Moving the drawing to C/C++ is certainly supported and easy if you 
already have the C/C++ rendering code.  Avoiding copying is *always* a 
good approach to speeding things up.
> Anyway probably I should start by keeping drawing in Python and 
> if/when I measure a real performance problem consider pushing it to C. 
>  This is how we operate with other stuff, resorting to C only to solve 
> a specific performance issue.
Sounds like a good plan.  Good luck,
Mike

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