[Bf-committers] Blender 2.5 api proposal

[Toni Alatalo]

I agree with Cambpell and Joe that dropping the old api in 2.50, but 
helping with a py written Blender module with functions people are 
familiar with, is probably the way to go. People depending on existing 
scripts that are not ported can stick to 2.4x in the time being.

Without knowing the 2.50 work well but based on the reading have done 
in the wikis etc. the plans seem good to me otherwise too.

One concern I have is PyRNA's ability to support NumPy, i.e. 
fast/direct access to memory buffers like the positions of all vertices 
of a mesh, all particles of a particle system, or the values of all 
pixels in a compositing node, to process them efficiently from py 
(change all of them in one py call).

I am not a great expert there, but recently got more experience by 
writing a real-time thing with pygame & numpy for an artist friend 
where am manipulating all pixels individually with numpy ops, and after 
got the hang of it found it a great way to work. So am still guessing 
that it'll be a killer feat for at least compositing nodes, but 
possibly for 3d things too (would be fun to try to manipulate mesh 
geoms, but afaik there is no tool yet that supports that (unless 
pyopengl directly somehow?)).

As Theo de Ridder told and showed us in the 2007 conf, all that's 
needed to enable numpy manipulation is to implement the minimal Python 
buffer protocol on the c side, which basically is just returning a 
pointer to the array. It was revised for Python 3000, which is also 
backported to 2.6 and documented in 
http://docs.python.org/c-api/objbuffer.html .. the current 2.5.2 docs 
at http://www.python.org/doc/api/bufferObjects.html tell more about the 
usage. For those who were not there, Theo had added buffer access to 
shape keys, so he could animate a swarm of fishes swimming by having 
the fishes as dupliverts and manipulating the keybuffer directly in 
memory using numpy. I asked Jahka and the particles in a particle 
systems are there similarily as a continuous memory chunk, so the same 
could be done there.

For something that is not a buffer but e.g. a linked list, I guess it 
may still make sense to implement an interface to numpy in c, in order 
to not iterate on the py side (which is slow) but just define the 
operations there, and iterate in native code instead. But I haven't 
looked into that yet .. dunno if exposing even something like 
scene.objects as a numpy array might be interesting for some cases? (at 
least if Blender is restructured internally so that it'd support 
hundreds of thousands of objects more efficiently ;)

So my 2 cents from outside of the inner loop is that please don't make 
it difficult to use numpy, but consider where it'd be good to support - 
thank you :) .. and do note that the support for it is *optional*, it 
does not add any runtime dependencies (that's how pygame does it too - 
the surfarray module works if you have numpy installed, but you can 
ignore it otherwise).

~Toni