Heres my docs for getting numpy into blender

http://wiki.blender.org/index.php/Dev:2.5/Source/Python/API/Numpy_Bundle#Steps_to_Include_Numpy_in_Releases

CMake/Unix now has option to copy over numpy when installing python -
WITH_PYTHON_INSTALL_NUMPY

For other OS's we need them to be packaged, it might be easiest if we
include numpy in the python32.zip / tar

On Tue, Apr 24, 2012 at 9:56 AM, Toni Alatalo <[email protected]> wrote:
> On Apr 24, 2012, at 1:52 AM, Alex Fraser wrote:
>> I'm mostly interested in it as a way to speed up access to pixel data. To 
>> get that, wouldn't we need to have a stronger dependency on it, so that 
>> Image.pixels can return a numpy array?
>
> So as Campbell said it does not need changing datatypes in Blender core, when 
> accessors can be written in bpy api code.
>
> It has been done, for example Theo de Ridder demonstrated it with swarms of 
> fishes in BConf07:
> http://www.blender.org/community/blender-conference/blender-conference-2007/conference-proceedings/theo-de-ridder/
> NumPy introduction / Enabling interactive animations of swarms Interactive 
> visualisation of ambient sensor networks with Blender.
>
> """
> As a simple experiment to validate the relevance of numpy the interface of 
> Key.KeyBlock was extended with getBuffer() returning a r/w Python buffer 
> without copying the underlying keyverts in C. In numpy the different aspects 
> like positions, rotations, and scales of all subjects were represented as 
> single multi-dimensional matrices resulting in Python code without any loop!
> """
>
> He had the fishes in a duplivert setup where was using array access to push 
> new positions & orientations for the fishes to the shape key buffer. To run a 
> lot of fishes efficiently for a realtime simulation, but not in the GE but in 
> the 3d view instead. Bottleneck was the drawing code, but for the logic and 
> fast blender data use demonstrated numpy beautifully. Wasn't many lines of C 
> to put the accessors.
>
> I was curious about 2d compositing nodes then, have sometimes done similar 
> things with numpy in realtime with pygame. With Blender have been wondering 
> about mesh things, perhaps a simple water surface etc., perhaps modifiers. 
> But haven't been making noise about as haven't still gotten to test it with 
> Blender / in movie related use myself yet (work with games usually).
>
> Found an old post on this topic when was wondering about this :) 
> http://lists.blender.org/pipermail/bf-committers/2008-December/022275.html .. 
> Campbell figuring in early stages of the 2.5 py api, next to "Leave open the 
> option to use python 3.0" and "No languages other then python" there's also, 
> to reply my pondering then, "No support for faster/direct access (numpy)". 
> Things have developed since then, perhaps makes sense now, interesting times 
> :)
>
>> Also, given my interest in speed, I'd like to keep the option to move to 
>> pypy open. Perhaps that conflicts with my first point ;)
>
> Is sure interesting to see how the pypy effort goes, fun that it's already 
> attractive as a perf improvement for pure py things. There of course seems to 
> effort for numpy compatibility as well, 
> http://morepypy.blogspot.com/2011/10/numpy-funding-and-status-update.html -- 
> don't know anything about that. Anyhow it doesn't work for Blender yet 
> anyway, given what Campbell said (no c api).
>
>> Alex
>
> ~Toni
>
> _______________________________________________
> Bf-committers mailing list
> [email protected]
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers

Reply via email to