[Bf-committers] extension clause

Campbell Barton ideasman42 at gmail.com
Thu Nov 18 01:48:18 CET 2010

On Wed, Nov 17, 2010 at 10:40 PM, Ivailo Stoimenov <kisolre at gmail.com> wrote:
> A have some questions...
> Which part of Blender will an extension use?
> If it just has access to an API which provides user data (mesh data,
> materials and such) and a way to return some processed data to Blender so
> this extension is independent work.
> If it doesnot use some or Blenders internal libs (render calls, modifier
> code, ...) it depends of the data and not Blender itself.
> And the data is not GPL... so where is the problem?

This is true, right now you can use ctypes to dump blender arrays into
an external file, image buffers, verts, faces etc,
run functions on these with an external process and return the data
into blender.

This could work for proof of concept cases or some tools with limited scope,
blender has lots of useful functions for dealing with its own data
which you loose access to, or have to re-implement.
So you end up with a primitive environment.

It could work in specific instances, for example render exporting
could have an api which used an external processes, but this basically
means some developer writes a new api (most likely BSD licensed),
which uses no blender code and duplicates a limited set of blenders
API functionality.

So if a company wants to hire a developer to do this they can but you
can see how re-writing this functionality isn't something volunteers
are motivated to do in their spare time.

Quite a few of these libraries from ILM, Diseny and Sony are BSD, not GPL.
OpenShading language, PTEX, OpenEXR for eg are BSD licensed.

- Campbell

More information about the Bf-committers mailing list