[Bf-committers] Blender 2.5 api proposal

[Toni Alatalo]

Note: I wrote this response earlier as immediate comments to Campbell's 
reply, but thought it got messy and was too tired so left it as a 
draft. Now that saw Campbell's summary, am now sending basically to 
hilight the point that, if I understood correctly, the RNA work is not 
about  to procedural manipulation of models / images / etc in Blender, 
and more about exposing the UI functions so that macro-like scripts can 
be made etc. So we should read this part of the summary:

"* No support for faster/direct access (numpy)"

as it being out of the scope now / for this work, but not that it'd 
somehow prevent adding such support if needed.

The original reply is below with some comments to the points you 
raised. Anyone do feel free to skip if not interested, it's largely 
just wondering about these things:

On Dec 1, 2008, at 2:38 PM, Campbell Barton wrote:
>> (change all of them in one py call).
> Your right, PyRNA does not give especially fast access.
(...)
> 2.5 wont make easier or harder, data structures are unchanged.

ok.

> Theo's example only worked because shape key buffers are an array of
> floats, this is not the case for most other areas of blenders mesh 
> storage.

if not sure how relevant an area meshes would be for this anyway, like 
said don't know about geom manipulation with them yet. ..  simple 
waters are one thing i've thought of testing (porting basically, or 
re-implementing the formula). now was recalling the voxel work being 
done in Blender recently, i wonder if that could be interesting.

> If blender was more python-centric we could make sure the data was
> structured in a way that Numpy could read easily.

i don't know if the issue is that much tied to python, as, like you are 
saying, it is largely about the data structures themselves .. whether 
something is an array of floats, or some structs or a linked list, or 
what. it's easy to see how another language could add support for the 
same array protocol actually, if that's the convern.

or do you mean that as blender is c centric, it is not a main concern 
that internal things would be structured for a 'scripting language', as 
the cpu intensive things are done in c anyway? and py is not used to 
implement core library stuff.. i guess that's not what you are saying, 
as a big value with the numpy support would be e.g. being able to make 
custom particle system behaviours.

> But this can be limiting too if we switched to tile based ImLib,
> access to image buffers would not be contiguous breaking Numpy access.

well i guess stuff like tiles shouldn't be too hard to deal with in a 
py lib nicely .. but good point.

haven't looked if/how to deal with other kinds of data structures there.

> Further, we would need to agree on including Numpy with blender for it
> to be truly useful average blender-heads.

hm. i didn't give any thought to that earlier, and now i'm not sure how 
would go about it .. i guess one way would be to experiment adding the 
support somewhere, test doing some things using it, and then look again 
if it looks good. it doesn't have to be useful for every user to start 
with, just people who are interested in it can install dependencies 
themselves (and ppl in the scientific python community are already 
using them..). also i haven't checked whether there some sort of a 
minimal distro of it.

then again, there is the proposal to add the type in the standard, but 
i don't know where that has gone recently .. 
http://numpy.scipy.org/array_interface.shtml .. dunno what that means 
w.r.t how to think about in blender dev.

> Personally I prefer to focus on really great high level python api
> that can do things like record user actions and play them back to
> create custom tools.

certainly fair enough,  am looking forward to seeing the nice things 
there :)

> If we want Numpy integration for compositor, this can be added as a
> irrespective of the 2.5 API, though I'd hold out for a GPU compositor
> :-)

indeed, but i'd still bet that doing custom things for large datasets 
(be it pixels, vertices, objects or particles or something else) on the 
cpu is needed too.

> - Campbell

~Toni