Two years ago, we scheduled the 2.6x period to have a “branch migration” focus. In the past years, we’ve seen the results of this work, with massive amounts of new tools and new editors in Blender.
All of 2.6x builds were meant to be (mostly) compatible with 2.5x though.
Since we’re running out of 2.6x numbers it’s really time to think of focus and projects for coming years. Below is a proposal I’d like to see discussed and reviewed here and on our mailing list(s).
The last 2.6x releases
- 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.
Blender 2.7x projects
For 2.7x projects we will allow forward and (minor) backward compatibility breakage. That means that by default, the 2.7x .blend files don’t have to read reliably in 2.6x or older. Backward compatibility stays crucial though, and should only be acceptable for big and important improvements. Changes can also be including a revision of UI layouts, naming of options, themes, and shortcut defaults.
However, for as long as we add breakage in Blender 2.7x versions, we could also try to keep the last 2.69 release updated with essential fixes.
This is also the perfect period to move to git for Blender coding.
A summary of projects or targets that fit this period:
- 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
Blender 2.8x projects
I propose to not wait with 2.8x versions as long as we did for 2.6x and 2.7x. It’s not needed to release every digit. At some moment in the near future, even while we still work on a first 2.70, projects for 2.8x could already get started.
For 2.8x we can target projects for bigger rewrites, with a lot of compatibility loss. Examples could be:
- 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 3.0 projects
For all 2.x projects we will stick to the existing C core, Blender files and data structures (DNA) and Blender’s scene/object/data methods as much as possible. It has its limits though – it’s a design from mid 90ies that survived very well but never was predicted to work 20 years already.
During the next few years we can collect in our wiki the issues we have, and the wishlists and design ideas for tackling this topic.
Blender Game Engine
With work being done on threaded drawing and updates, viewport (compositing) effects, unified physics, node based animation, and everything that’s currently real-time in Blender already, I also propose to refocus the current game engine to re-use much more of this work.
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.