Patches vs Plugins

@Uncle Entity, its just how dynamic linking works, symbols are resolved. Its not related to makefiles. I could even not include the header and have this line instead.
extern void BLI_convertstringframe(char *name, int frame);

All it needs is the function definition to compile the code, Ofcourse loading the module outside of blender would fail (as in a normal python interactive session or script), it has to be in the same process as blender.

@Cyborg Dragon, it wouldnt slow down blender development, why would you want to write a plugin and maintain it externally?, its much nicer if its in blender by default, then you can tell people who to use your tools without having to go download some file for their OS - 32/64bit etc. It means you get updates and builds for all OS’s with no effort, if its distributed with blender (as a plugin or integrated) users can always access without hassle.

I agree with ideasman on the issues with a plug-in API, while this is actually what made most commercial software so powerful because they have that API, well also the money to fund it.

But I can also understand many users who feel that over the past years great tools emerged as a patch but than never were included, such as the bass relief node, which I think is a fantastic addition.

Maybe something could be done with that or improved in this area.
However I also know this all depends on manpower to code it.

@ cekuhnen,
very true.

@ CD, i think your missing the point here.

Plus wouldn’t this slow down Blender development (in a way of features getting into SVN itself) because people might rather make users download 50 plugins rather than coding them as patches and this possibly seeing them with every Blender build?

That’s what everyone, even me!, is trying to avoid.
How to best handle them, from a coding & user perspective.
So everyone can get the most benefit.
People will write scripts & 3rd party plugins & patches.
There will be lots of them, from very simple to very complex.

@ ideasman,
Thanks again for your considerable input in this thread.

it wouldn’t slow down blender development

It would be good for Blender development.

why would you want to write a plugin and maintain it externally?

he he, people will be doing it.
If we like it or not…

its much nicer if its in blender by default

Mostly, that’s true.
But not always & when dealing with volumes of extras, hardly practical.
Not everything will need to be in Blender.
Not everything will be accepted.
Some individual 3rd party plugins will be too big (file size) to include in Blender.

then you can tell people who to use your tools without having to go download some file for their OS - 32/64bit etc. It means you get updates and builds for all OS’s with no effort, if its distributed with blender (as a plugin or integrated) users can always access without hassle.

yes, that’s true & very important.
Individual, larger projects will handle this themselves i think, as they do now.

A Plugin API or a non destructive way to add patches to Blender?

Thanks again for everyone’s great input.
This has been really very helpful.:slight_smile:

@Meta-Androcto, agree, this more more a generalization to explain how it wouldn’t be an advantage to maintain a lot of code outside blender (at least to the point where it would hurt blender dev). there are of-course cases where it would be preferred.

I’d like to commit this external module stuff but I dont really have a finished external module, Id like to write an OBJ parser in C++ as an experiment but not getting around to it :S, Could also make the BGL module external as an example.

So… say we get external python modules that can do what they like… then what? - Is anyone interested in writing some py/c/plugins?

One thing I didnt think of in my last post is that this could be a path to a stable plugin api. Once the py/c/plugins are added (which is fairly simple and I have tested locally), someone could define funtions inside blender for defining a new node/modifier/texture etc. These functions could be considered a plugin api and have headers for modules to include, be documented etc.

@ideasman42,
Not sure about anybody else but I intend on including python modules with MOSAIC for the geometry export stuff. The exporter will be fully functional without them but if complied/installed they’ll be automatically used. One thing that’s caused a lot of complications in the current exporter is all the manual workarounds to speed up exporting in Python, with modules I can greatly simplify the design while still offering production quality speed. I think this is a perfect solution as Blender itself is visually driven in Python which in turn calls C modules, I’m not sure everyone is getting how powerful this could be!

Anyway thanks for the example code, got it working and will use it as a reference latter :wink:

I was wondering why you couldn’t write a node and then call register_node(new_node) through python since AFAICT blender doesn’t care how it gets into the node list, I suspect that behavior was designed in from the start.

The shader rewrite should also get this for free since it’s going to be based on nodes as well.

Don’t think it’d be too hard to structify the modifers based on what I saw when I was poking around in there a while back…maybe a proposal for The Powers That Be™ to look over is in order.

@WHiTeRaBBiT, glad you ‘get’ it, we could include your C modules with blender and then you’d not have to worry about distribution.

@Uncle Entity, I guess you could, but we need to have nodes NOT using (int) ID’s when saving in files.

And as for the powers that be, some good plugin as a modifier/node/tex may be enough of an example to prove this is useful, we can see if these can be a recommended method for making plugins.

interesting approach ideasman42

this could also be done with cython like this


cdef extern from "BLI_path_util.h" nogil:
    int BLI_convertstringframe(char *path, int frame)

cdef extern from "stdio.h" nogil:
    void printf(char *theStr, ...)

#C
def ctestme():
    cdef char *foo = "Hello##"
    BLI_convertstringframe(foo,10)
    printf("%s
", foo)

#python
def testme():
    cdef char *foo = "Hello##"
    BLI_convertstringframe(foo, 10)
    print(bytes.decode(foo))

:o I downloaded several promissing plugins in 2.49 and in 2.5… But where do those appear?:spin: They are in the plugins folder… and then? I just can’t find nor see no changes on my screen :no:
Is there any sign or listing of the usable plugins to be seen in the UI? If yes, please, tell me where: some are so appetizing :eyebrowlift::cool:

Is there a step by step “how to” tutorial showing the way things go when trying to use a plugin script?
That would be nice.

almux,
Blender 2.5 is a wip.
there’s important changes to the api coming up quite soon.
so there’s not much going on in the way of docs, except for ideasman42’s thread.
http://blenderartists.org/forum/showthread.php?t=177461
there’s also some other good 2.5 info in other threads in the python section of the forum.

Great. Of course lots are on. I personnaly depend on “built builds” as i’m a user absolutely ingnorant about all APIs, python goodies, special compilations and such. Therefore i feel quite puzzled when things are “de-incarnated”… :o