Blender roadmap for 2.7, 2.8 and beyond

I am a big proponent of Blender so I am always quite interested in how it is going to develop.  Recent releases have been all about bringing a number of projects that have been in the works for years back into the fold.  Functionality like BMesh and the Cycles renderer are now part of the core package and Blender is vastly improved as a result.  Now that most of that work is complete, Blender started looking toward the future and released their roadmap of upcoming features.

 

The nutshell version:

2.6x

  • For 2.68 and 2.69 we strictly keep compatibility and keep focusing on stability for Blender.
  • Anything potentially unstable or breaking compatibility should go to a 2.7 branch
  • If needed, we can do a couple of 2.69 updates (a b c d) to merge in bug fixes only.

 

2.7

  • Move to OpenGL 2.1 minimal (means: UI/tools can be designed needing it, like offscreen drawing)
  • Depsgraph refactor, including threaded updates
  • Fix our duplicator system, animation proxy (for local parts of linked/referenced data)
  • Redesign 3D viewport drawing (full cleanup of space_view3d module)
  • Work on cpu-based selection code for viewport
  • Sequencer rewrite
  • Asset manager, better UI and tools for handling linkage
  • Python “Custom Editor” api (including better Python support for event handlers, notifiers).
  • UI: refresh our default

 

2.8

  • New “unified physics” systems, using much more of Bullet, unification of point caches (Alembic).
  • Particle nodes (could co-exist for a while with old particles though)
  • Nodification of more parts of Blender (modifiers, constraints)
  • Game engine… (see below)
  • OpenGL 3.0?

 

Blender Game Engine

Or more radically worded: I propose to make the GE to become a real part of Blender code – to make it not separated anymore. This would make it more supported, more stable and (I’m sure) much more fun to work on as well.

Instead of calling it the “GE” we would just put Blender in “Interaction mode”. Topics to think of:

  • Integrate the concept of “Logic” in the animation system itself. Rule or behavior based animation is a great step forward for animation as well (like massive anims, or for extras).
  • Support of all Blender physics.
  • Optimizing speed for interactive playback will then also benefit regular 3d editing (and vice versa)
  • Singular Python API for logic scripting
  • Ensure good I/O integration with external game engines, similar to render engines.

What should then be dropped is the idea to make Blender have an embedded “true” game engine. We should acknowledge that we never managed to make something with the portability and quality of Unreal or Crysis… or even Unity3D. And Blender’s GPL license is not helping here much either.

On the positive side – I think that the main cool feature of our GE is that it was integrated with a 3D tool, to allow people to make 3D interaction for walkthroughs, for scientific sims, or game prototypes. If we bring back this (original) design focus for a GE, I think we still get something unique and cool, with seamless integration of realtime and ‘offline’ 3D.

 

All told, nothing earth shattering, but one heck of a big change in store for Blender game engine.

Art News Applications


Scroll to Top