Re: PyOpenGL: numpy dependency?

Giovanni Bajo wrote:
> On Sun, October 29, 2006 15:30, Mike C. Fletcher wrote:
>
>   
>> At the moment it's not easy_install packaged.  If you're running a
>> setup.py develop version, then cvs up in the directory will get you there.
>>     
>
> OK. Would it be sufficient to release a new alpha version and do a
> 'setup.py register'?
>   
It would be sufficient, but I haven't had time to test this release 
noticeably.  Without testing, doing a register could potentially make 
anyone trying to download the system get a non-functional version.  I'd 
suggest following the instructions on the developer's page to get a CVS 
version if you want to test with the pre-release changes:

    http://pyopengl.sourceforge.net/ctypes/development.html
>>> OK. I guess you want it fixed as ctypes is an implementation detail of
>>> PyOpenGL
>>> after all, don't you?
>>>
>>>       
>> I'm not all that worried about it.  Lists/tuples are *far* less
>> efficient than numpy or ctypes arrays.  The ctypes arrays behave much
>> like lists-of-numbers or lists-of-lists-of-numbers, but are more
>> efficient, especially if you're going to pass the data back in.  That
>> said, yes, would be nice to see it go all the way, just for completeness.
>>     
>
> Thinking *exclusively* of OpenGL matrices, you probably want to manipulate
> them with some matrix class. So, either you pass in numpy matrices (and
> want numpy matrices back), or you probably have your custom matrix class
> (like in my case), convert it to a Python list-of-numbers, and want a
> list-of-numbers back to convert it to my custom format. I think converting
> back and forth 16 values is not going to be performance sensitive in most
> situations.
>   
In those situations (a custom array-storage format) you should be 
creating a format handler.  The handler can just extract the 
data-pointer from your custom format (assuming it has such) and pass 
that in directly.  Even if you don't have a raw data-pointer in your 
format, being able to avoid the intermediate list/array objects should 
speed it up considerably.

Copying 16 values is *very* expensive, you wind up creating (for a list) 
16 integer/float objects and (at least) 5 list objects, 5 array objects 
plus all of the logic of figuring out if the values are the right 
lengths.  If you're doing that 1 or 2 times per frame no big deal, but 
if you are using this for every array in your application you're 
imposing rather a lot of overhead.

Making the list handler more efficient (and complete) would be a good 
thing.  It could likely be better with a better copying algorithm.  Feel 
free to play with it.  (It's in the arrays/lists.py module).

Have fun,
Mike

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


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net