Let's say that a blender installer with EVERY single plugin is going to have these problems (from my point of view) :
1. BIG filesize
2. LONG MENU/BOX/WHATEVER with a huge list of the plugins (hard to find what you are looking for)
3. Old version of the plugins (some of them will change faster or after an official tree blender release)
4. Old list of plugins (maybe the function you are looking for its not in your plugin list).
5. Etc.
6. Easier to mantain the core of blender, something like apache the core changes like every three years, because all the action is in the mods.
My proposed idea
Online Plugin Manager
1. Ship the official blender tree with some *essential* plugins (dynamics, particles, etc). So the user will see in the plugin list something like LOCAL PLUGINS //// ONLINE PLUGINS.
2. Have an Online plugin list that:
a. Update itself (just the list of available plugins)
b. Allows user to see a description of the plugin and then if he wants to use it , download the plugin and automatically install it inside blender.
3. If the user clicks a plugin he already downloaded, the plugin manager will do a check *while* the plugin is running and report the user of any new versions.
4. try read the preferences of the old version.
5. keep the old version (maybe the one doesnt work perfectly) until the user clicks maybe an option called cleanup.
My idea is that is could be a mix between Perl CPAN (with moderators) and the winamp plugin page/download/install.
Just my .2 cents
[ plugin manager] technical feature suggestion
Moderators: jesterKing, stiv
I think unleashing a program onto a user with missing functionality out-of-the-box is a bad idea, seriously, do like debian and make $10 CDS with everything on it! The BF can do that!
I run linux and I can tell you that even with a DSL line its no picnic going out on the net for different apllications which are metaphorically the same as plugins, and redhat even has an update tool that links up with them automatically and makes downloading rpms fast and easy, but why do all this when a CD is right there?
I mean I'm for this idea in principle but only after nearly everyone has broadband or a fast connection to the internet.
I run linux and I can tell you that even with a DSL line its no picnic going out on the net for different apllications which are metaphorically the same as plugins, and redhat even has an update tool that links up with them automatically and makes downloading rpms fast and easy, but why do all this when a CD is right there?
I mean I'm for this idea in principle but only after nearly everyone has broadband or a fast connection to the internet.
the plugin system is very neat in a open source project because it requires only knowledge of the interface ie: the plugin implements an abstract class and is loaded from the client app (which in this case is blender as the whole app) from maybe a plugin menu or something other way..
if we allow that a plugin subsystem can have the same kind of access to geometry materials and menu creation that the python layer has (or is intended to have sometime) then we provide an alternate way to the "scripting way" of adding functionality, which could mean an speed up since plugins are compiled binaries
if we allow that a plugin subsystem can have the same kind of access to geometry materials and menu creation that the python layer has (or is intended to have sometime) then we provide an alternate way to the "scripting way" of adding functionality, which could mean an speed up since plugins are compiled binaries
-
SirDude
- Posts: 233
- Joined: Sun Oct 13, 2002 7:37 pm
- Location: University of Minnesota (USA)
- Contact:
Not that there isn't enough code floating around out there,
but I've uploaded the new plugin system I've been working on
if anyone wants to play with it/fixit. You can grab it here:
http://www.cs.umn.edu/~mein/blender/pluginsys.tgz
but I've uploaded the new plugin system I've been working on
if anyone wants to play with it/fixit. You can grab it here:
http://www.cs.umn.edu/~mein/blender/pluginsys.tgz
-
SirDude
- Posts: 233
- Joined: Sun Oct 13, 2002 7:37 pm
- Location: University of Minnesota (USA)
- Contact:
Its the start of a plugin system to replace/expand the current version.
(I did it before the source was released)
Here breifly what it does.
Expands plugins into following sections.
textures,sequencer,image/anim,3dfileformats hopefully makes it easy
to add others.
You have an environment variable path for each of the plugins.
So you specifiy a search path for plugins and when you try to load
a plugin of a certain name it looks through the path.
Download it give it a try and if your into coding fix/improve it and let me know
(I did it before the source was released)
Here breifly what it does.
Expands plugins into following sections.
textures,sequencer,image/anim,3dfileformats hopefully makes it easy
to add others.
You have an environment variable path for each of the plugins.
So you specifiy a search path for plugins and when you try to load
a plugin of a certain name it looks through the path.
Download it give it a try and if your into coding fix/improve it and let me know
In the past months of NaN, i had a regular contact with a group called "Blender League". They were planning to replace the Blender plugin system with a more general Python API system.
One of our engineers worked with them on the specs, and the first steps have been done in that direction.
For a cross platform tool like Blender, it always has been a big pain to make it running correctly among the platforms. Plugin coders typically only make their own OS working properly, so we've received a lot of complaints from users out there demanding us to fix the plugins they downloaded somewhere from the web.
For that reason I prefer to continue examining the Python approach. For example, we can make a built-in Python module (compiled) which does the calculations which require speed. Like matrix stuff or pixel operations.
That way, python scripts can be used for textures and image manipulation as well. And what about extending it with a render api, like an internal 'shading' language! Yummie!
One of our engineers worked with them on the specs, and the first steps have been done in that direction.
For a cross platform tool like Blender, it always has been a big pain to make it running correctly among the platforms. Plugin coders typically only make their own OS working properly, so we've received a lot of complaints from users out there demanding us to fix the plugins they downloaded somewhere from the web.
For that reason I prefer to continue examining the Python approach. For example, we can make a built-in Python module (compiled) which does the calculations which require speed. Like matrix stuff or pixel operations.
That way, python scripts can be used for textures and image manipulation as well. And what about extending it with a render api, like an internal 'shading' language! Yummie!
-
Cyberdigitus
- Posts: 46
- Joined: Tue Oct 29, 2002 3:27 pm
- Location: Belgium
-
nicholas_yue
- Posts: 8
- Joined: Sat Oct 26, 2002 7:41 am
I like the Python route too but also consider the following:ton wrote: For that reason I prefer to continue examining the Python approach. For example, we can make a built-in Python module (compiled) which does the calculations which require speed. Like matrix stuff or pixel operations.
That way, python scripts can be used for textures and image manipulation as well. And what about extending it with a render api, like an internal 'shading' language! Yummie!
(1) Everytime there is a modification to the main code, the Python interface has to be updated or else the plugin-system is out of sync.
(2) I am thinking of a fur dynamic plugin for character animation, with lots of hair interpolation and collision detection, what is the speed of Python?
(3) I am also thinking of a RIB export plugin. With a Python plug-in, do I have to get a Python RIB client? That would be additional work and debugging which means potentially longer delay in getting it up and running.
I think Houdini (http://www.sidefx.com) has a reasonable system where the SDK (plug-in) is written in C/C++ and its scripting system is separate (it has a Python interface too)
Cheers
--
Nicholas Yue
http://users.tpg.com.au/tmyue/
I understand that coders tend to code in their particular operating system. However I don't see why that should be a problem, as long as they post which operating system it functions on. A plug-in system would really expand Blender's customizability. I mean, why not make Blender into something that people can choose what they want it to do? Take me, I wouldn’t want to change the UI, but others would. I wouldn’t have any use for a plug-in that enables me to do so, so why have it in my system? I, on the other hand, would love to see reflections in the game engine and other such things, that may not function as well as POV or BMRT in rendering, but would be a great effect to have in the game engine. I’m sure most animators wouldn’t be interested in that though. The list could and would go on and on, probably hundreds of plug-ins would be created.
So how do you manage such chaos? Well, Gimp and Milkshape do something similar. Why have the ability to export to 165 different file formats, when you only need one? Just download what you need and install it in your application. See what I mean?
I know this is repeat, but modularizing programs seems to be the way of the future, don’t you think? Love to hear more comments here, please, thanks,
Love Ingie
So how do you manage such chaos? Well, Gimp and Milkshape do something similar. Why have the ability to export to 165 different file formats, when you only need one? Just download what you need and install it in your application. See what I mean?
I know this is repeat, but modularizing programs seems to be the way of the future, don’t you think? Love to hear more comments here, please, thanks,
Love Ingie