Seeking Advice on C++ Development in Blender for a Maya Tool Developer

Contributing to Blender
1

Hello,

I am a solo technical artists with the Qt framework and C++ skills. For a long time now, I have been contemplating the right time to transition from Maya to Blender, and I find myself still considering it. My primary concern revolves around C++ based plugin development in Blender.

The features I aim to develop involve real-time interactive custom manipulators. My goal is to significantly enhance the functionality of soft selection and enable real-time manipulation of multiple objects and keyframes simultaneously, suitable for modern animation and rigging workflows. I have successfully implemented similar functionalities in Maya using C++. I am keen to replicate these advanced tools within Blender and showcase my technical skills in that environment as well.

However, the most significant hurdle I perceive is the build process.

The tools I intend to create would likely suffer from performance bottlenecks if implemented solely in Python, making them difficult to use comfortably. This is because my plugin involves manipulating multiple controllers concurrently and caching numerous matrices across multiple frames, all at once.

In Maya, developing C++ plugins doesn’t necessitate rebuilding the entire application. Furthermore, even with version changes, plugins generally remain compatible as long as one consults the API patch notes.

From what I understand, Blender primarily supports Python scripting for addons. To achieve the low-level access, memory optimization, and real-time performance I require through C++, it seems necessary to build the entire Blender program from source. This aspect presents the biggest challenge for me.

I am still deliberating on this matter. Perhaps I am overcomplicating the issue? If I were to learn the build process and how to maintain my own custom version of Blender, would adding C++ functionality become less problematic?

Alternatively, as a developer aiming for tools with highly optimized C++ memory access and excellent real-time usability, is it perhaps too early for me to engage deeply with the Blender development community?

Developing C++ plugins in Maya felt relatively straightforward. If I were to maintain a custom Blender build, I worry about whether such a version could be shared with others, and whether I would need to research and implement the build process anew with every Blender version update. These potential complications are causing significant hesitation.

Although I am still working primarily within Maya, I have a strong desire to transition to Blender and become an active participant in its community. I am sharing these thoughts hoping for some perspective or advice.

Thank you for your time and any insights you might offer.

12 Likes
2

Your idea is great. I really hope that developers like you can join Blender’s headquarters and make Blender better and better.

1 Like
3

Blender doesn’t have a plugin C++ API and won’t have one anytime soon (if ever). For writing native code, I would encourage you to consider contributing to the Blender project directly. See Blender Developer Handbook - Blender Developer Documentation.
If that’s not something you are interested in and would rather work on addons/plugins, then I’m afraid you won’t find much help on this forum.

4 Likes
4

Hey,
Just purely out of curiosity why not though?

5

https://developer.blender.org/docs/handbook/new_developers/faq/#can-a-c-plugin-api-be-added

1 Like
6

Thank you for the answer. I’ll start learning how to build Blender and manage commits.

4 Likes
8

From a pure user perspective, native integration and improvements in Blender are super apreciated, if it’s something as performance dependent as soft selection and manipulation tools.

If you feel comfortable trying to get into contributing to core blender, the community really apreciates this. :heart:

4 Likes
9

Hi there.

You might be interested in looking at the FLIP fluids project. It appears to use a hybrid Python/C++ model: the engine is C++, the UI is Python.

I don’t fully understand the codebase but it looks like it uses ctypes to link the Python and C++ code.

The downsides to this approach is that there is no access to the private Blender API and there is a lot of Python ‘glue’ code necessary to make the two worlds cooperate.

10

You are right to hesitate.

To get your feet wet, and to get into working with the C++ side of Blender, indeed compiling and working your own build is the way to go - and if it is core architecture you want to develop - even more so required. There is no “mid”-end to work the back-end - only a front end and that is python and compiled libraries with something like “cython” or others (some addons do this).

I have worked with forks for public and studio builds with custom operators and an alternative GUI paradigm, and help distribute an independent one of thus - and this requires weekly work for reliable deployment.

Fundamentals:

Here are the fundamentals to get to developing the source for your needs:

  1. Learn to branch/fork your own version of Blender (gitflow)
  2. Learn to compile it reliably in the OS’s you need
  3. Learn to rebase merges and get into a routine of doing it weekly, more necessary the more developed things are with the source
  4. Compile with provided solutions to “iron out” any variables for troubleshooting

Once you have those ok, then learn how to work the source code in manageable reviewable pieces.

  1. Learn how to make a task, commit to it, then request a pull in the Blender tracker
  2. Or alternatively do it in your own tracker (smaller bites gets the elephant eaten, keep them small and often) - cleaner commits make life easier down the line
  3. Think of deployment: where, how, to whom.

Developing to Blender with your credentials with a branch of Blender, this will get you street cred to get features into Blender quickly the more you do it, I don’t have much street cred - and my own build is 4300 commits ahead of Blender, so it’s out of scope to merge many things to main (and has an incompatible vision) so we distribute that build independently and/or deploy weeklies internally for work. But with some work, maintaining your own fork to develop source based features is doable, but you need to cover your base “maintenance” needs - or else your source code changes can grow old VERY QUICKLY.

Tips:

  1. Get used to rebase merges, and try do them weekly to stay relevant (merge the main to your fork merge branch, get compiling with debugging and conflict resolving, then pull the merge branch to your main once green). If these are not done weekly and you have deep core changes (or not so deep), you never know when a refactor may hit and your code may break or be irrelevant very quickly, so stay up to speed with the future of Blender at all times… (Example, a custom modifier interface change, and right now the uiLayout code is changing so the custom modifier won’t draw and the build won’t compile anymore)
  2. Get your build environment reliably working by installing the third-party dependencies for HIP (tricky, don’t use the official ROCm, cause it’s outdated), Optix and Cuda. All of these need environment variables not mentioned in official documentation (assumed). These don’t update often, but usually in January they will (VSC on Windows occassssionally, perl, lib submodules, etc). Be prepared for monthly or yearly troubleshooting of dependencies and keep track of Blender commit logs (hundreds of commits per week) to make sure you’re not caught out. Reason being: local builds are faster than buildbots in most cases, and the dependencies often aren’t available for buildbots - so iteration on local builds is quicker.
  3. Use the Make Lite, Full, Debug and Release builds to help develop quickly and/or with official setups and less “variables” or margin of build error. (Lite is quick, Debug is relatively quick, Full is feature complete but not as GPU heavy, and Release has everything on par with a Blender distribution - longest build)
  4. Get super used to Gitflow and think ahead… sometimes things update there from the repo and catch you red-handed, like LFS being implemented out of the blue and your local repo doesn’t have it enabled or the tests folder integrates to the main and no-longer a sub-module but you have a lingering empty submodule now - and then you’ll have to debug and troubleshoot on that front - and clean up files or libs - etc. Basically be clean.
  5. Fork the main, as forking any LTS branch or official release branch will ultimately be “easier” but in the future, it will not work nor compile nor have future proof features nor code, most often regressing all your work - ultimately giving your work a “shelf life”, which on studio crunch, can be devastating. Catching up once you do upgrade to the main source after branching from a branch or catching up to future release branches, it will be one hella large job with many headaches. It’s hard enough maintaining or keeping up to speed with weekly rebasing from main with only a few hundred commits vs thousands of breaking commits in one sitting once you jump around forking from branches to branches. Stay close to the trunk (main) for a smoother ride.
  6. Distribution can be either a zip build for internal deployment, or learn also how to build installers, buildbots, etc. Up to you, here Blender could do that chunk if you’re doing it directly with and for Blender - so you have that going for you (ei, they buildbot builds for your pull requests). About work queue: if you go directly with the source repo, the pull requests queue is usually 500+ with staff of 30, so be prepared to… wait for revisions (unless it’s a high priority bug fix). Internal trackers and internal deployment and builds can help fast-track things if you need it in work then and there, but then you’d have to think of distribution. Mac unfortunately can not be VM’d so if you do want to support it, you’d need the hardware or someone who has it.
  7. Short and sweet, and modular, make your commits and pulls digestable and biteable.

I’ve been doing this a few years now, with a fork that has reliably lasted nearly a decade - I’m still a novice, but this is some of the fundamental things I’ve gleaned out of experience, for both an independent audience and sometimes studio builds - and occaaaaasionally something worth pushing upstream.

My best advice, if you are serious about making a C++ optimized operators and need to get it integrated into the GUI with the python front-end (interface) and C++ interfacing (to get tooltips, and integration of the operator/s into a new API for python) - then join the bandwagon of people already thinking of distribution, build bots, gitflow, etc. Either an independent fork that does this already (faster approval and deployment, allows for experimentation), or directly with the Blender folks (super clean code support and revisions, and better infrastructure and audience for deployment) - maintaining your own fork is no joke, and it’s often with all the tech art I also try to do - sometimes the hard job is ultimately keeping your code alive for the future and not doing feature development at all!!!

So your instinct is right, but it might be a worthy adventure with either thousands or millions of people benefiting from the effort.

Good luck!

2 Likes