[Bf-committers] Some Ideas for a Blender Plugin System

[François T.]

- Cython does not have as much performance as pure C/C++
- Python is still the best choice for prototyping and pipeline stuff
- C/C++ API can be used for better performance without having the nightmare
to dive into Blender core code to just add one modifier

Most of the modifier we are developping in Maya are first done in Python,
but then it is port to C++ for performance matter. Same approach would be
nice in Blender.

Of course we can modify Blender code and recompile it but :
- this is low level coding compare to the use of an API
- can make future merge more complicated for a studio

And in some cases like sharing code for importer/exporter in alembic, fbx
would be more easier if it was done as a plugin rather than being embeded
in our blender build

2015-11-04 14:44 GMT+01:00 Diego Gangl <dnicolas at gmail.com>:

> Hi all,
>
> What would be the benefit of doing this, instead of expanding the python
> api?
>
> The only case I can think of is doing really complex computations or
> working with large sets of data, and you already have three options for
> that:
>
> - Use numpy (for some things)
> - Use Cython
> - Start a process from python and communicate with pipes
>
> A plugin/module system might sound great on paper, but I think it would be
> a nightmare of corner cases.
>
>
>
>
>
>
>
>
>
>
>
>
> 2015-11-04 4:58 GMT-03:00 Sybren A. Stüvel <sybren at stuvel.eu>:
>
> > On Tue, Nov 03, 2015 at 08:04:03PM +0100, matmenu wrote:
> > > 2) Do you have a proof for this claim? I mean, modifier/operator
> > > combinations already lead to bugs, I don't see why having them as
> > > plugins/modules would make those problems arise more often?
> >
> > I don't understand your reasoning. To me it reads like "we get bugs
> > now, so why would we get more when we complicate the software?" In the
> > current situation there is a fixed set of functionality in C++
> > (ignoring precompiler directives). In the case of a plugin structure,
> > not only do we have the same set of functionality, but also situations
> > where that functionality is only partially loaded. More different
> > possible situations -> more complex -> more bugs.
> >
> > > 3) That's true, but then the user decide to install this module, so
> > > he will report the bug to the original dev
> >
> > This is only true if the bug is trivial to to identify by end-users.
> > Plenty of bugs won't be. Think about double-free bugs, where the first
> > free is performed in the plugin. A crash may happen when Blender
> > itself frees the pointer, and thus any traceback (if that's shown at
> > all) will indicate a problem in Blender, not the plugin.
> >
> > > 4) Also true, but we now have a buildbot that can make builds on
> > > demand for all supported OS. It could be used further by
> > > module/plugin devs and avoid having to ship a compiler with Blender.
> >
> > AFAIK FreeBSD is not built by this system. Furthermore, allowing
> > arbitrary third party code to be run on a BI/BF-hosted machine is an
> > invitation for trouble. This already happens, but through the Git
> > repository, so at least it's only done by people that have been vetted
> > by receiving commit access.
> >
> > --
> > Sybren A. Stüvel
> >
> > http://stuvelfoto.nl/
> > http://stuvel.eu/
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
>
>
> --
> --
> Diego Gangl - sinestesia.co
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier