Extensible Architecture Proposal

Adding new features often requires changes to many files, as Blender was not initially designed to be extensible. When the codebase was small this worked well, but as it keeps growing it becomes harder and harder to manage.

The goal of this proposal is to make Blender more extensible and object-oriented. The first step is to make it easier for Blender developers to implement new features and understand the code.
https://wiki.blender.org/wiki/Source/Architecture/Extensibility

If the interface is well-defined and stable it can then later also be exposed to Python or C++. However I would like the focus of this document and discussion here to be on improving the internal architecture.

I think this is something we can work towards incrementally on code quality days and between other development. I’d love to hear some feedback from other developers about this, if this is the right direction, ideas about how we can approach this, etc.

29 Likes

I completely agree and support that project, this is indeed a goal we have been moving to for many years already, but on a very loose and slow and unorganized path… Seeing it properly formalized and pushed forward is great.

I agree that doing so incrementally is the way to go, I would just note that each ‘module’ step (BLO, DNA, RNA, etc.) should be properly defined (design & milestones) beforehand, and especially on a timeline aspect. While having some hybrid code (mix of old and new systems) is acceptable for a few months, we should be careful not to end up with partially implemented changes resting in code for years. :wink:

5 Likes

It’s definitely crucial, users continue to request numerous features and blender itelf needs to continue to add in functionality to maintain and Connie competency. Implementing this would cut a ton of time in trying to understand the code and help the developer get to more of what they want to acheive.