This task is aimed to outline vision of how to move from current implementation of Blender Game Engine (BGE) to what we call “Interactive Mode”.
It is not to be seen as a design proposal, it only states our vision of how to move forward with the project as a whole.
When discussing the BGE, often the possibility of an interactive-mode has come up. So best we document what is meant by this.
Current state of BGE
Current code base of BGE is almost completely isolated from the rest of Blender code. On the one hand, it allows individual contributors to work more independently, but also leads to the following issues:
- The whole animation system is re-implemented in BGE.
- Has own transform system.
- Rendering has own implementation as well.
- Single threaded nature.
What we have as a result of this is that due to developer power, BGE has been stagnating for years now (with some occasional improvements). Not only feature-wise, but also bug-fixing wise.
This is not something we consider healthy for the future of Blender as the whole project, and solution here is needed.
Interactive mode is to be seen as a light-weight game engine, which is totally based on core features of Blender itself: such as, dependency graph, animation system, physics, draw manager. Some improvements to the animation and event system would need to be done, for example, logic system needs to be integrated into a dependency graph.
There are some more in-depth changes needs to be done, for example, decouple physics clock from animation clock. But all such changes will also make movie creation in Blender easier.
Downsides of interactive mode comparing to current BGE:
- We will lose compatibility with older .blend files created for old BGE. (Full compatibility will be lost anyway, due to new OpenGL requirement, at least).
- It may be less attractive for individual contributors that their engine is no longer a sandboxed code environment (where having different behavior can be done more easily, fewer integration issues).
We will have to start over with quite a few areas.
- At least initially, we won’t have anything as comprehensive as existing logic bricks, Python API physics access, library reloading, dome viewport... etc.
- Some operations in Blender are not as optimal as the BGE, adding new objects for example (although this could be resolved).
Benefits for game creators:
- All the improvements to shader system are immediately available for everyone.
- So all performance improvements for animation, object and scene animation are.
- No need to re-implement improvements on both Blender and BGE sides.
- Guaranteed multi-threading and threads scalability (this is what we pay a lot of attention in Blender core).
Benefits for movie artists:
- More sophisticated tricks for animation, where animation can be event-triggered.
- Independent physics will make it easier to do pre-rolls and investigation of how world reacts to dynamics without running full animation system.
Without a final design this is not very detailed. Adding this section because there is some confusion as to what interactive mode would include. We would expect the following features to be supported in early versions of interactive mode.
- Basic visual logic system (logic nodes?).
- Python scripting.
- Respond to events (physics collisions, keyboard, pointer).
- Export run-time (executable).
Use Cases / User Stories
Out of Scope