There seems to be thousands of people making blender addons and a lot of which would be amazing to be default in blender (like Node Wrangler and Node Preview to name a few) but it seems like no one is contributing code to Blender so their code can be included by default. Is there a technical or structural reason this isn’t done? We even have Goo Engine Blender for anime style blender where the creators say it would be unlikely that the Blender devs would accept their code to be available in Blender by default so they maintain a fork instead.
C code is a lot harder to write than Python
3 Likes
Both.
-
Blender doesn’t accept just any code that is contributed (nor should they, as it might change something that many people wish to stay as is).
-
Submitted code must follow particular formatting and other rules, to be considered for acceptance. Not all developers wish to code within those requirements.
-
Code review can take a very long time, months. Some people don’t want to dedicate time to coding, then wait weeks or months for the back and forth of approval, bring told to rewrite things differently, etc.
-
Blender may already be working on something that would deem a particular submission not needed, or soon to not work due to a future plan.
-
If a submission is accepted, Blender is basically agreeing to maintain that code for eternity. So obviously, they will carefully consider each submission before marrying it.
In the case of GooEngine, they’re coding things without worrying about how it might affect - or even break - Cycles. Which is fine for their userbase and studio needs, but not something that Blender would want in the main build. Could Goo follow all the points above, and get accepted into Main? In theory, yes… But they’ve nothing to gain by spending all the extra time, money and effort it would take.
5 Likes
Node Wrangler is an addon that is bundled in official release and free.
So, you can’t blame its developer not to contribute to official Blender.
It is clearly the opposite that is happening with all addons that are given for free.
Generally, if features are released as an addon and stay as is, during a long period ; there is a structural reason.
Cycles is an addon.
Because, except engine defining viewport and preview, default design is that user is choosing his render engines.
People who disagree have to fork Blender.
Lots of addons providing lots of customization may be seen as too much customization, for a default, for specific areas of software ; that may present no or a minimal interest for specific users.
If some features are used by everybody, that may be for few parts of it. They may become new features, at condition that manpower to maintain them increase and/or area is refactored to be less difficult to maintain.
At each refactor, it is not rare to see addons becoming obsolete, not for technical reason ; but just because they are no more needed.
Addon’s add some features and are embedded by the environment which was used to make those addons “addonable”… so there is some “safeguard”…
Really code changes need some by far more knowledge and understanding of the software archictecture…
…so very genrally speaking: the developers of blender itself are more software engineers and most addons are made because of the need of some artist… who tried the addon coding…
But of course as in everthing else in the world there are more shades than only black or white… and also some other dimensions but even the color analogy (…so more than “grey” ) is by far too simple to illustrate this… 
A small nitpick; Gitea’s code statistics show that Blender has technically become a C++ project. There is still some C code present, but it has been dwindling fast.
The only issue I have with this one is that we often do not have a timeline which justifies not committing the patch to provide an interim solution, even if it does not make deep changes that will interfere with other work (with an example being a patch that would’ve added high quality normals for shrink/flatten operations with nodes). The patch was not committed because a solution that would be more flexible and more integrated with the rest of nodes is coming, but months later no hints.
I know we can’t do that with all patches sitting in the tracker, but sometimes the gap between saying there will be an official solution and the solution arriving is a span of years.
True, but the specific C derivate isn’t terribly important, as C derivates and Python are at best second cousins at the closest measuring:
1 Like
Years ago, I spent a month or two trying to learn the basics of Forth before I lost interest. Looks like it was a solid choice to abandon that pursuit.
1 Like
Tracing Python’s lineage…
What is the distilling limit for JIT compiling of a language like Python? Can we boil it all the way down to Fortran and get addon speeds faster than Blender’s C++ tools?
While true, as always statistics can be a bit misleading, there’s quite a difference between a well designed piece of C++ code (Such as the geonodes or asset browser code) and whatever most of blenders codebase currently is. During the C->C++ conversion we essentially changed the extension to .cc fixed any build issues an called it day, in reality we’re still a lot closer closer to a C project that allows you to use classes than a nicely designed C++ project.
3 Likes
your answer , this a heavy pill to swallow especially for eevee and its missed potential …