[Bf-committers] bf-extensions external scripts and inclusion of Exporter Framework
ideasman42 at gmail.com
Fri Oct 22 16:35:55 CEST 2010
On Fri, Oct 22, 2010 at 8:36 AM, mindrones <mindrones at gmail.com> wrote:
> -- intro --
> lately I've been discussing a lot in about distributing LuxBlend,
> YafaBlend, GameKit (and maybe Blendigo) in bf-extensions.
> It's bit tricky because of course these project are developed outside of
> bf-extensions svn and we don't want them to move on our svn for obvious
> reason. Also, some of these projects have a binary part which we don't
> want to distribute in an svn.
> After long discussions and many proposals we agreed that these projects
> dump their scripts (python text files) in bf-extensions svn in a folder
> called extern/, here
> This folder is not 'official' in the sense that it's not used for the
> release, but it will be used later to be able to distribute external
> projects scripts from within blender (more on this will come in later
> weeks, for now we're just setting up).
> LuxBlend and Blendigo, developed by Doug Hammond, need "Exporter
> Framework", aka "EF", also developed by Doug Hammond:
> 1) http://ef.beulahelectronics.co.uk/
> Campbell proposed that EF is included in blender so that other exporters
> can use it and I've been asked to write down a formal request for this.
> If this is fine for other developers here, we'd put the script in
> bf-blender/release/scripts/modules and Doug Hammond would maintain it
> (if he gets access to bf-blender of course).
Hi, looked into Doug Exporter Framework from Mercurial:
hg clone http://bitbucket.org/doughammond/exporterframework
>From reading over the source, my impression this is a quite high level
framework for wrapping configuration saving, property creation,
reporting, some file path utilities.
Since its well commented and being used for existing exporters I think
its ok to add into blender's modules dirs, Doug can get svn access and
My main concern is that having good render/exporter integration is
something that needs API development at a lower level,
Id like to look into a plug-in system & see how we can avoid having
python touching each vert/edge/face.
So I'm fine to bundle this exporter framework with blender, but I
rather hold off presenting this as blenders default exporter system
until we have taken time to look into what a good api for exporters
should look like.
Doubt this will be a problem, and I'm sure Doug's developments will be
valuable but IMHO we have a way to go before we can properly integrate
I haven't been able to work on much API development for over a year
because of blender projects (funnily enough), durian & now the tracker
At some point I hope to have time to work in this area though.
More information about the Bf-committers