[Bf-committers] Proposal/Potential Roadmap for Blender/BGE Integration

[Mitchell Stokes]

I'm all for some better integration between Blender and the BGE. I've
posted an article on my blog detailing how I think we should take our first
steps toward better integration:
http://mogurijin.wordpress.com/2013/06/21/towards-tighter-blender-and-bge-integration/

Below is the full blog post for everyone's convenience:

In Ton’s recent blog post, he discussed a roadmap for Blender 2.7, 2.8 and
beyond, which included a more tighter integration between Blender and the
BGE. While this initially caused quite the stir in the BGE community with
some thinking this meant dropping the BGE entirely, I see it more as a
desire to get the two to share more code. Blender has smoke, fluids and
particles, why shouldn’t we use those in the BGE? Too slow? Then lets speed
them up and make Blender users happier in the process. The way I see it,
the BGE can benefit from new features in Blender and Blender can benefit
from performance improvements from the BGE. But, how do we get there?
That’s what I aim to discuss in this article.

Sharing Blender Data

The first major problem that needs to be tackled is how the BGE handles
Blender data. Currently, one of the BGE’s major design decisions is to
never modify Blender data. While the BGE does modify Blender data in a few
places (most notably lights), we’ve mostly stuck to this design principle,
which has helped prevent numerous bugs and potentially corrupting users’
data. However, in doing so, we’ve had to recreate most of Blender’s data
structures and convert all Blender data to BGE data. This also limits how
we can interact with existing Blender tools. Blender has a lot of powerful
mesh editing tools, but we can’t use those in the BGE because they require
a Blender Mesh object while the BGE has a RAS_MeshObject, and using the
original Blender Mesh would cause that data to change.

If we want a tighter integration between Blender and the BGE, we need to
allow the BGE to have more direct control over Blender data. This means we
need to find a way to allow the BGE to modify and use Blender data without
changing the original data. The most obvious method is to give the BGE a
copy of all of the data and then just trash the copy when the BGE is done.
However, I think there is a bit more elegant solution to the problem. If
you look at the existing code base, you can see that the Blenderplayer
actually doesn’t have to worry about modifying Blender data as long as it
never saves the Blendfile it reads. Only the embedded player has issues
because it is using the Blender data already loaded in Blender. So, why not
have the embedded player read from disk like the Blenderplayer? When the
embedded player starts, the current Blendfile could be saved to disk and
then loaded by the BGE. There are some details that have to be worked out
here though, such as where do we save the file? A temporary location (e.g.,
/tmp)? That will cause path issues in larger games. Instead, I see two
feasible locations: the original file or the original file appended with a
“~”. The first would behave like a compiler would, you save before running
your program, and is the approach I prefer. However, this changes the
current behavior, which might upset some users.

A more long term solution to the problem of modifying Blender data is to
drop the embedded player. As I mentioned before, the Blenderplayer doesn’t
run into issues using Blender data since it doesn’t share a memory space
with Blender. And, since the Blenderplayer supports being embedded into
other applications, we can still have games running in what appears to be
the viewport. In other words, we would not lose features! Some benefits to
this approach:

  * Get rid of a lot of code (the whole source/gameengine/BlenderRoutines
folder)
  * A lot less duplicate code
  * Smaller Blender runtime size (all BGE code would only be in the
Blenderplayer, and not Blender)
  * Playing the game in the viewport and the Blenderplayer would be
guaranteed to be the same (right now small differences exist)
  * The ability to modify Blender data without breaking Blender
  * A BGE crash won’t affect Blender since they will be in separate
processes (like Chrome tabs)

However, there are some downsides, which include:

  * It will be more difficult to affect the BGE from Blender. At the moment
this isn’t a problem, but if we want some goodies like Unity offers with
adjusting the game using the editor while the game is running, we’d need to
develop some inter-process communication protocol to get Blender and the
BGE communicating.
  * We currently don’t allow embedding on OS X. I’m not sure if this is a
limitation of OS X itself, or a lack of development effort on our part.

Using Blender Data

So, we’ve got some ways to minimize the issues of the BGE using Blender
data, but what do we do with it? First off, I’d start to clean up the BGE
code to use DNA data as storage and then shift the focus of the various BGE
classes to act as wrappers around that storage. Where possible, the member
functions of those classes could delegate to the various Blender kernel
(BKE) functions. Once that is done, we can look into what Blender goodies
we can start adding to the BGE using these new classes.

Viewport Drawing

While the BGE and Blender already share a fair amount of viewport drawing
code (especially in GLSL Mode), this area could be much improved. The first
task here is to get all of the OpenGL (and any calls to bf_gpu) into the
Rasterizer, and only the Rasterizer. This requires moving material and
lighting data out of Ketsji and into the Rasterizer. Once this is done, we
can worry about how the BGE handles it’s drawing. The Rasterizer should
have two modes (possibly implemented as two Rasterizers): fixed function
pipeline and programmable pipeline. To do this, I would propose dropping
Singletexture and making Multitexture code the basis for the fixed function
Rasterizer, while GLSL mode would be the basis for the programmable
Rasterizer. The programmable Rasterizer could have an OpenGL minimum of 2.1
as Ton suggested for his proposed roadmap, but I’d keep the fixed function
Rasterizer as compatible with older hardware as possible.

After we have the Rasterizer cleaned up, we can start offloading as many
tasks as possible from the Rasterizer to the bf_gpu module, which the
viewport code also uses. The more we can put into this module, the more
Blender and the BGE can share viewport drawing. Ideally, the Rasterizer
would not have any OpenGL code and would rely entirely on bf_gpu,
maximizing code reuse and sharing.

Conclusion

Using the ideas outline in this article, we’d have two main points of
interaction between Blender and the BGE: BKE and bf_gpu. We could certainly
look into more ways to increase integration between Blender and the BGE,
but what I have discussed here will give us more than enough work for the
foreseeable future. Also, please note that this is only a proposal and a
listing of ideas, and by no means a definitive plan. Discussion and
feedback is much encouraged and appreciated.

--Mitchell Stokes