Ok, so I read thru this whole post and I think I understand the conversation. Here’s my 2 cents.
Blender at one point in time (v2.4x, Big Buck Bunny) had python constraints. They were never added back in the in the big 2.5x rewrite because of the headaches they caused the devs back then.
I don’t want to talk politics, and I don’t know who Richard Stallman is. I do know there has been talk before about changing blender’s license, but to do that, everyone that ever contributed code to blender had to agree to it. Or something like that…
That’s the kind of statement which made me reply to your previous post. We know this to be true for Blender. We don’t know anything beyond that (at least it is not something he constantly mentions that would be well known).
When talking about a third party, using hyperboles is incredibly dishonest.
For historical reasons, adding such an API is difficult. Blender was not designed as an extensible software. Rather adding new functionality often requires making changes across many files and modules, and internal APIs are often designed for specific usage rather than being general purpose enough as a public API for plugins.
While work is ongoing to improve the Blender implementation in this regard, realistically, adding support for a C++ plugin API is unlikely to happen anytime soon.
I think you guys overthink it. It seems to be both: C++ API would probably not align with open source ideals very well, but it would also be technically difficult and require enormous amount of resources to implement and maintain. If it was a trivial thing to do, I think it would be a different story, but it’s not and there are other arguments against it so we will not see it any time soon.
Why? It’s one of the reasons in this context. It’s being compared to Autodesk’s products. Autodesk does have more than 100 times bigger income. Do you honestly believe that would change nothing? If Blender Foundation suddenly had 100 times more money?.. That’s a lot. A lot of “side projects” could be done, I don’t see why C++ API couldn’t be one of them.
A C++ API isn’t strictly necessary, what’s needed is buffer information in their Python API to make passing data from Blender to a C++ addon faster. Copying data from Blender is the major bottleneck in my experience.
I don’t use Maya mainly because my client wants me to use Blender. Maya is also really expensive, both for me and the people who I work with.
I’ve looked into hacking the Blender source. I even did once - and I contributed a patch which sat for months with no attention being paid to it before being finally rejected. Which is not so unusual for large open source projects, but is none the less still demoralizing.
Also, the Blender code base is quite complex. Even if I did commit to hacking it, it would be quite the effort, even for a small change.
The nice thing about an API is that it greatly simplifies the process. Instead of having to figure out how to create a whole new component and figure out how to create bindings for it, you can just call a bunch of functions supplied by the project. This not only makes things easier for you, but for the Blender developers to who have to worry about your embedded extension having some weird side effect that messes up some other part of Blender or taking the Blender project off in a whole new direction that the core team doesn’t want.
Given the Python API is already mature, I’d think that much of the work has already been laid for a C++ extension. You can use the RNA system to generate bindings for C++ and then just need to worry about compiling the dlls. Or maybe have some C++ to interpreted code transfomer so you don’t have to deal with binaries.
Anyhow, I’m looking into Python’s numba library. Hopefully this can give me the speed boost that I need.
I haven’t done patching Blender for a quite while, but the best way I found for finding out how to go about was to find a similar patch and just look at the git diff for that patch.