Removed for now

And what pray tell do you want to do about it?

You must have never had the need to really “change” Maya, like rewriting the UI or other of its inner workings. Because then you would really appreciate the “endless” level of control when able to access all code of a program. C++ API is good for “bolting on” features but doesnt allow nearly as much as full open source Blender does. And then theres the Blender Python API, which might not offer high speed, but in my eyes offers deeper integration than Maya API (like drawing OpenGL inside the viewport).
So its really sort of a tradeoff you have to make. And adding a C API to Blender, which is already open source, would be like carrying water to the sea.
And then you can build only a “slim” version of Blender (without big features) for testing of code. And recompiling the source file you are changing and relinking then really doesnt slow down development much at all.

Do note my (limited) experience with Maya C++ API dates from years ago.

new bad thing discovered in blender :frowning:

Any yet it has been working for years. Blender has improved steadily. New, usable versions come out quite regularly. New features are added and old ones are improved… I’m not really clear what your definition of “will_never_work” is.

Back in the bad old days, compilers were slow resource hogs, and often broke more than they compiled. Folks looked on compiling a program with dread. But it’s been at least a generation (human years, not dog or computer years) since compilers became fast and robust enough that it made more sense to re-compile a program even for something trivial such as using compiler tools to find spelling errors in the code. But, people being how they are, I’m sure that “Oh! God! NO! Anything but recompile!” attitude is still out there.

Blender does need some kind of “native code” addon support. I have done numerous things in python that involve brute force operations on large numbers of vertices, edges, faces, and other attributes… one word. SLOW!!!

If Blender got even the most basic native addon support such as mesh data access for making simple tool operators, it would be a great step in the right direction. From there, native modifier addons, etc.

Unfortunately I have no idea if, when or ever this would come to Blender. I assume this would require extending the addon system and the development of a native plugin interface API. No small feat, but as the competition shows (and countless other creative software suites), clearly not impossible. Many of them have both native plugins as well as scripting support.

Your last point is a good one. Recompiling the whole program just to change one thing is pretty extreme. Especially if all you need to do is add a simple tool with performance dependent code.

— Ease development for addon developers: no need to recompile all of Blender, build hacks etc.
— Ease of use by artists: artist does not need to have many versions of Blender and switch between them all the time.

On a lighter note, let me fix your last point for you:

Lets face facts - this “recompile the whole program and distribute the whole program just to add a single icon for a custom tool” will never be tolerated. This is just insane.

Orinoco, you’re missing the point. The problem is not the compilation process itself, but the fact that any change that requires you to touch the C codebase needs a new program binary.

You can’t expect people to carry around dozens of different blender builds, nor can you expect them to learn how to patch and compile Blender.

You also can’t expect commercial vendors to patch Blender in order to make it usable for them, but that point is kind of moot when the GPL prevents you from linking proprietary code in most forms, anyway.

Of course, there are isolated cases where users/vendors go out of their way and do these things, but that doesn’t change the fact that it sucks.

The problem with the API isn’t necessarily that it isn’t C based, but that it is inefficient and limited. Projects such as numpy show that you can have very high performance by just using Python as a glue for native libraries. It’s also possible to use OpenCL or even llvm from Python. The key is to have efficient access to the data structures, not having them hidden behind an inefficient wrapper.

I’ve been saying for a while that a C/C++ plugin API would do wonders for Blender development. Python is so very limited in terms of speed, and I’m not convinced that the hassle of using something like cython would even bring it up to par. Scripting as a whole within Blender needs a lot of attention. And as others have pointed out, having to sit through a 10 minute+ compile every time you touch the C code of Blender isn’t something most people have the patience for.

While I agree that C/C++ plugins would indeed revolutionize what could be done and how fast it could work, a thread like this will not help anything.

Generalizing - folk who have experience outside of blender have the knowledge and ideas of how to make blender better, but their annoying “why is blender not like maya” rants just piss people off and thus everything they say is either ignored or taken as an insult. Folk who have only ever used blender will be defensive about how what we have now is good enough, and the ignorant would even try to argue that it’s better.

There’s nothing really to argue here. Faster and more robust possibilities of scripting would obviously be better, there is no reason why this would be a bad thing. The only issue is, as always, someone really smart has to code this and make it possible. And at the present moment, it seems like the average blender user is more concerned about why RMB is to select and why the Toolbar Tabs are terrible/badly-designed/great/important than with actual production issues like the lack of speed and possibilities of plugins.

Scripters/coders like us would love this C/C++ API. But others don’t care and would rather have smoke in cycles, a better game engine, quicker renders, alembic cache support, a supposedly more intuitive UI, or a magic “make awesome animation” button. The truth is, all the devs already know what people want, ranting about it doesn’t change a thing.

Ironicly, that seems to have been a rant of my own :slight_smile:

A number of people have made the claim that being able to write an operator in C/C++ would suddenly make the operation significantly faster than doing the same thing in Python. There are very, very few places where simply switching to C/C++ would bring significant performance improvements.

For example:

I added the underline. When you brute force large sets, then it takes a long time. The way you get significant speedups is by using a smarter algorithm. In most cases on modern hardware, when you notice that something is ‘slow’ the slowness is dominated by the complexity of the algorithm that is being run.

Just writing something in C/C++ is not a magic bullet that will get massive performance gains. If that were true then why not write everything in assembler?

I native plugin system for Blender could be a good thing. I doubt that it would provide the speedups that most people think that it would.

I agree,actually I’m saying this since 5 years at least.
The lack of a plugins system is the real weak point of Blender.

In fact there used to be a plugin system for Blender for textures and video effects.

it was never used much, so was not ported to the 2.5x code base.

Well, you asked if the lack of a C/C++ API will hide away Blender in the shadows forever.

To note, Blender will always be the shadows in the eyes of some because even if you had a full-fledged C API, you will still not be able to hook proprietary solutions like Realflow onto it because of the GPL. The only way then to truly get Blender out of the shadows then would be for a full re-licensing of Blender to something like the Apache2 or MIT and you’d pretty much have to completely remove Ton from the Blender project in favor of a new leader who’s more commercial-friendly for that to start happening.

I think Ton has made it clear what the benefits of GPL are. Remember that third party tools could potentially create effectively closed source resources and blend files which removes the benefits of GPL. You are then locked to a commercial plugin. As Ton has stated before, commercial income can come from support fees, selling assets and other business models.

@AceDragon: This will never happen. You will never get the permission from every developer, to relicense Blender. :wink:


I added the underline. When you brute force large sets, then it takes a long time. The way you get significant speedups is by using a smarter algorithm. In most cases on modern hardware, when you notice that something is ‘slow’ the slowness is dominated by the complexity of the algorithm that is being run.

Complexity has nothing to do with how fast something actually performs, but how it scales. If a Python implementation is 20x slower than a C implementation with the same complexity, it will always be 20x slower, no matter if your input is small or large.

For large N, a 20x overhead will always be relevant, even for algorithms with sublinear or constant complexity. If a 20x overhead doesn’t matter to you, then complexity probably doesn’t matter either.

If complexity is a concern, why would I not implement the “smartest” (or most adequate) algorithm in the first place?

Just writing something in C/C++ is not a magic bullet that will get massive performance gains. If that were true then why not write everything in assembler?

It depends on what you’re writing. The step from Python Interpreter to compiled C can be enourmous, the step from C to asm likely won’t be. Have you ever considered what actually need to happen, just to add two numbers in Python? And what happens if you add two numbers in C (and in ASM)?

Of course, if your bottleneck is hashtable lookups, you probably wont gain that much from using C.

I native plugin system for Blender could be a good thing. I doubt that it would provide the speedups that most people think that it would.

Learn how these things work, you’ll figure out why people want this.

Well, one of the only alternatives then would be to code vast upgrades to some of Blender’s existing systems so they can at least match the power of popular commercial plugins (like the fluid system (Realflow), particles (Thinking Particles, Pyrocluster ect…), rigid body physics (Pull Down it, Rayfire), hair (Yeti Fur, Shave & a Haircut), and the ability for those to work and interact with each other).

For things like this I wish blender would work a bit more like other open source projects.
If there are people who want/need a C-API, then they should implement it and put it up for review.

This is a question I wanted to ask myself. It always bothered me why Blender isn’t plugin based. The current system doesn’t seem to be good neither for developers or artists. Also, the benefits of a plugin based system for artists is HUGE, way more than just speed gains. Maybe it’s not requested more here because most don’t realize how important it is.

I find it rather unbelievable having to have specific Blender versions sometimes for a single tool. Which can lead to very annoying and frustrating cases where 2 very useful tools might be split into two separate Blender versions and you can’t have both at the same time.

Say someone develops a new powerful fluid simulator, it’s going to exist in it’s own Blender branch. And another developer creates a powerful meshing tool, again, on it’s own branch. So you wind up with 2 Blenders, and you can’t (AFAIK) bring a particle fluid simulation from Blender A to mesh it with Blender B. I guess the only solution is having a patch for one of the branches and patch the other one and compile it. This sounds like a lot of work for an artist. It’s very inefficient but possible and some do it, but we can’t expect everyone to be able to.

Another side effect is that some tools simply die because the developer stopped the development and no one else takes the time to recompile it.

It’s probably a monumental task but I wonder how much work it is to develop a plugin system for Blender. Not that I’m expecting that to happen, though. :slight_smile:

Are there any other obvious problems (licensing etc.) with having a C/C++ API and a plugin system other than huge development time needed to implement it? btw. when I was going through the source code doing small tweaks here and there for my purposes it seemed to me that the 2.5 transition has left the C API as a possibility in the architecture?