pyopengl-users

[PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andy Sy <an...@ne...>]

I've noticed that PyOpenGL has lagged behind the latest
OpenGL versions for sometime now.  Is the complexity of
SWIG to blame for this?

Would a different approach, say ctypes
(http://starship.python.net/crew/theller/ctypes/) or use
of the Python C API actually make things easier?

I took a look at Ruby's OpenGL interface (
http://www2.giganet.net/~yoshi/ ), and
interestingly, there's not much acrobatics that
need to be done.  There's a single 4,252 line C source
with a seemingly very simple way of wrapping C
OpenGL calls and that's it. (Could Ruby's C interface
really be that clean?!?)

Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andrew S. <str...@as...>]

I wrote a similar email about this some months ago. Some elements of the 
conversation:

Mike Fletcher responded that there's probably some unacceptable overhead 
with ctypes.  Part of the problem is mapping the versioning from C to 
Python.

In C, there are both compile-time and runtime versioning considerations: 
the headers you compile against may define certain functions that aren't 
available until a certain runtime version, so you'd better check before 
using them.  As the current package is built in Python, I think we have 
the lowest-common-denominator situation, where we basically assume only 
OpenGL 1.1 headers and thereby limit usage of any of the newer 
features.  Consequently, no runtime version checking seems to be 
required in general.  With the dynamic nature of Python, we could of 
course do something fancy that only exposes the functions and constants 
available for a certain version of OpenGL, but this may end up causing 
unnecessary confusion.  To expose recent OpenGL features in PyOpenGL, we 
have to consider what to do in the situation where someone with, say, 
OpenGL 1.4 headers compiles PyOpenGL to run on a maching with only  
OpenGL 1.1 libraries.  Maybe there is an elegant solution to this problem...

If someone (I don't have the time) embarks on a rewrite of PyOpenGL, 
that person may want to consider pyrex instead of SWIG.  Interesting tip 
about the ruby/OpenGL interface -- I'll have a look at that.

Cheers!
Andrew

Andy Sy wrote:

> I've noticed that PyOpenGL has lagged behind the latest
> OpenGL versions for sometime now.  Is the complexity of
> SWIG to blame for this?
>
> Would a different approach, say ctypes
> (http://starship.python.net/crew/theller/ctypes/) or use
> of the Python C API actually make things easier?
>
> I took a look at Ruby's OpenGL interface (
> http://www2.giganet.net/~yoshi/ ), and
> interestingly, there's not much acrobatics that
> need to be done.  There's a single 4,252 line C source
> with a seemingly very simple way of wrapping C
> OpenGL calls and that's it. (Could Ruby's C interface
> really be that clean?!?)
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andy Sy <an...@ne...>]

Andrew Straw wrote:

 > As the current package is built in Python, I think we have
 > the lowest-common-denominator situation, where we basically assume only
 > OpenGL 1.1 headers and thereby limit usage of any of the newer
 > features.  Consequently, no runtime version checking seems to be
 > required in general.  With the dynamic nature of Python, we could of
 > course do something fancy that only exposes the functions and constants
 > available for a certain version of OpenGL, but this may end up causing
 > unnecessary confusion.  To expose recent OpenGL features in PyOpenGL, we
 > have to consider what to do in the situation where someone with, say,
 > OpenGL 1.4 headers compiles PyOpenGL to run on a maching with only
 > OpenGL 1.1 libraries.  Maybe there is an elegant solution to this
 > problem...

Assuming the presence of Mesa might point to one possible
solution... I had the ff. exchange with Brian Paul before:

AS> Does this mean that even if OpenGL app uses a mix of
   > hardware supported and non-harware supported features,
   > instead of defaulting to pure software, Mesa will handle
   > the non-hardware supported portions of the pipeline while
   > the vidcard will still accelerate those portions which
   > it can?

BP> That's basically true.  If, for example, the application
   > uses a 3D texture, the driver will fallback to software
   > while rendering with the 3D texture, and return to hardware
   > rendering whenever possible.

AS> If so, then that's really cool, and will it be possible
   > to have the same behaviour for Window drivers?

BP> I'd expect Windows drivers to do the same thing.

Re: [PyOpenGL-Users] Should PyOpenGL's usage of SWIG be rethinked?

[Andy Sy <an...@ne...>]

http://www.river-bank.demon.co.uk/docs/sip/sipref.html

SIP may also be worth investigating as an alternative to
SWIG.


 > Andy Sy wrote:
 >
 >> I've noticed that PyOpenGL has lagged behind the latest
 >> OpenGL versions for sometime now.  Is the complexity of
 >> SWIG to blame for this?

Andrew Straw wrote:

> I wrote a similar email about this some months ago. Some elements of the 
> conversation:
> 
> Mike Fletcher responded that there's probably some unacceptable overhead 
> with ctypes.  Part of the problem is mapping the versioning from C to 
> Python.

[PyOpenGL-Users] 2D collision detection

[enrike <en...@al...>]

hi again

any one has some nice 2D collision detection algorithm? or maybe there 
is some website were to look for it?
I need to detect collisions between shapes and also points inside shapes.
I have done a very basic one but my maths are just way behind this task

thanks again


-- 
enrike