At the 2015 blender conference the attending developers sat down to discus things we as a group wanted the 2.8 project to be a software engineering perspective.  The things discussed below are intended to become effective with the 2.8 project and any changes in supported hardware will be kept as minimal as possible.

C++ 11 / C99

Blender is written in C, C++ and Python mainly. currently we use C++98, C89 and Python 3.4.

There is consensus to allow C++11 and C99 for the features that make sense and are supported by our current hosting compilers (Microsoft Visual Studio 2013 is the lowest common denominator here ).  This should let us write better code thanks to some stupid limitations being lifted but it will also need us to bump the platform requirements and in particular support for Mac OS X versions lower then 10.8 and Linux versions that ship with a glibc older then 2.14 would be dropped.


Currently blender uses OpenGL in a way that remains compatible with versions 1.4 of the standard. Over the last 20 years graphics hardware has evolved greatly and some of the concepts in accessing this hardware have also changes. In 2009 the OpenGL 3.2 standard was released that for the first time deprecated the old way of doing things. Today a lot of platforms even do not allow this old way of accessing the hardware and some disallow use of newer features when legacy calls are used (MacOS X is an example of this).

The developers universally agree that this will happen and is unavoidable. We also felt that this move away from immediate mode towards VBOs and GLSL will need to happen, regardless of the new viewport design. Antony Riakiotakis started this conversions, but there is a significant amount of work left, and it is unclear at this point how this is to be approached best.

This move will have some downsides, such as loss of hardware acceleration on early Intel i9xx cards. Any post-2008 Nvidia or AMD hardware should remain unaffected.


The Blender developers currently maintain 2 buildsystems (cmake and scons). Most of us use CMake, more than we use SCons, and collectively we feel that dropping one would free up a big enough amount of resources that the benefit would far outweigh the costs. There are buildsystem-specific bugs, it adds to difficulty of becoming a contributor, and the builds on both systems are currently inconsistent.

The remaining work lies mainly in supporting the linux release builds with cmake, and verifying the MacOS X release build against the scons version. Brecht and Martijn have volunteered to get this done.

Replacing or dropping code

There are various opinions on what parts of Blender are broken, hard to maintain, or lack a future. Mentioned were the sequencer, game engine, openimage-io, constraints, particle system, and OpenCollada. The only one we could reach some kind of consensus on is OpenCollada: the library and integration make up for 1/3 of the binary size of Blender, and we currently only have Gaia to maintain it (who was not present at the meeting). We decided to seriously consider dropping it for 2.8.

The particle system and constraints may need a complete overhaul.

The sequencer and game engine are in serious danger of removal, if we cannot come up with a good solution during the 2.8 project.

OpenNL was also discussed and it seems most of the usages could also be covered by the Eigen library.

Finally, it is good to remember that this discussion is about what could be good for Blender and the Blender developers from a software engineering perspective, and what could make it easier for us to deliver a better Blender. We make Blender for artists first, and in that sense this list cannot and should not be interpreted as a complete representation of the 2.8 project.