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 Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
