[Bf-committers] Blender 2.5 api proposal
antont at kyperjokki.fi
Thu Dec 4 10:37:40 CET 2008
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.
> 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
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
> 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
More information about the Bf-committers