The Multi-Threaded Game Engine (MT Game)

I’ve been meaning to write this entry for quite a while now.  Ever since we released the first runnable version of 0.5, this MT Game thing has been hanging around and I’ve kept putting off writing about what it actually is, and how it fits into the Wonderland system.  Well wait no longer, let’s explore MT Game.


I joined the Wonderland team in the spring of 2008 with the task of replacing Java 3D as the rendering sub-system for the 3D client for Wonderland.  My background consists of working on just about every 3D technology at Sun over the past 20 years – including being implementation architect of Java 3D, so it was a good fit.  The decision, which I had consulted on, had already been made to use the Java Monkey Engine (jME) technology to replace Java 3D.  

I started asking around about what design work had been done up to that point on the new 3D client.  The answer was none – I had a blank slate.  Boy, were they in trouble.  :^)

I began by meeting with the company that we had worked with for a long time, and were already slated to build a state of the art avatar system for 0.5 – Immediate Mode Interactive.  We had some high level discussions about where game engines and 3D technologies were heading.  This led to some design goals for the underlying rendering and processing system.  They included:

  • Take advantage of the multi-core revolution that was happening on all client machines.
  • Support state of the art rendering techniques like dynamic shadows, portals, shaders, etc…
  • Support Collada as the model import format.
  • Make the system extensible and dynamic.
  • Support a high level object model for 3D objects.

Evaluating jME

With these design goals in mind, I started serious evaluation of the jME technology.  I quickly found there were a number of features that jME did not support.   First, was a lack of any processing model at all.  And, as the past year has evolved, we have now realized that jME not only does not have a processing model, it breaks very badly if any type of threading model is imposed on jME.  More on that later.  It also had no object model.  There was no way to assign higher level characteristics to 3D objects in the world.

After this initial evaluation of jME, it was clear that jME would not be the center of the 3D client, but instead be used as a collection of rendering and picking/collision utilities that would encapsulate data and be enveloped by a different technology.  That technology become MT Game.

MT Game Features

Every few weeks, I want to start publishing technical blogs about all the features of MT Game.  I will likely be doing that over here at my personal blog.   For this entry, I want to list its major features.  They are:

  • Component Based Architecture
  • Uniform Render Buffer System
  • Collada Model Import
  • Virtual Processing System
  • Input Processing
  • Collision System
  • Physics System
  • Shader Configuration/Loading/Level of Detail System
  • Geometry and Processor Level of Detail System
  • Pluggable RenderTechniques

Most of these systems were briefly explored in the technical session that I presented at JavaOne.  We just found out that this talk was one of the highest rated talks, and we won a JavaOne Rock Star award – pretty cool.  If you are interested, check out the slides from that talk.  

One of the other design goals that we had for MT Game was that it could be used independently from Wonderland.  We wanted it to be a standalone rendering and processing system.  The Wonderland 3D client sits on top of MT Game.  It adds a number of other features to the system – most notably networking.  Most of the time, Wonderland does a great job of hiding MT Game from the Wonderland developer, but once in a while it peeks through.

What about jME?

One question that many developers are likely asking is "How to I get my Java3D/jME content into this system?"  While every scenario is slightly different, I can give some general guidelines as to what content will move over cleanly, and what will likely be more work.

First is the 3D representation issue.  Content that is represented in a Java 3D scene graph or a jME scene graph moves over with very little effort.  Java 3D behaviors need to be rewritten to become MT Game processor components.  jME does have a form of user code callback’s in their Controllers, and as it turns out, will work with MT Game, but they don’t have nice threading properties.  Processor components are much more thread friendly.

Threading is by far the most troublesome aspect of moving jME content into MT Game.  jME assumes that all of it’s api calls will be made from a single thread – the thread that has the opengl context.  To support this, all jME calls must be made from a couple of key places in the MT Game system.  But that is a subject for another blog.

Finally, we don’t use any of the jME game frameworks.  We have our own set of threads – including the renderer thread.  All of the data is passed into the system via components.

Plans and Resources

To wrap up a very long post, I’ll simply say that we are almost done with MT Game features for 0.5, and that the big thing for 0.6 is to figure out how to fix the jME multi-threaded limitations.  If you would like to look more directly at MT Game, check out  There is even a programming guide over there – although I need to update it.

Thanks for reading,



5 Responses to The Multi-Threaded Game Engine (MT Game)

  1. Jim Laffey says:

    Thanks for your report and the work you are doing. I’m interested in potentially using wonderland for implementing a physical science course…..where students will learn about force and motion, etc…. So the "physics system" sounds very interesting. Can you say more about its potential and when it may be available as services in wonderland?

  2. Douglas Twilleager says:

    I will be doing a whole blog on the physics subsystem. So stay tuned for that. You may want to check out JBullet. That is the physics system that we have integrated, and that will show you what is possible. You can do that style of physics today, but it will be client side only. Having it networked is likely a 0.6 feature.

  3. Jim Laffey says:

    Thanks for the quick followup….I’m definitely staying tuned :)

  4. csstu says:

    i’m interested in do some animation in wonderland, with jme i just need to write a controller and add it to the Node, but in wonderland it seems that it does not work.
    then i use a Processor components of mtgame, in the commit method i call the updateGeometricState mothod of the Node, it really work when i just use a SpatialTransformer controller as a test,but when i try to use the same way to build a particles system,it does not work again.
    it could be ok, but it‘s not.i’m really confused about that. is there any way to overcome this problem?
    i’m still want to read more materials about mtgame,but what i got is just a simple short pdf file, which really bothers me.
    i’m not sure if i can contact you with e-mail since it seems that i will have more questions when learning about this, and if you send me a e-mail,it will be my honor.

  5. Douglas Twilleager says:

    By utilizing the ProcessorComponent the way you are, you will have the best chance of getting this to work. We don’t officially support jME controllers, but what you are doing should work.
    I have not looked into jME particle systems yet, so they may require more work.
    The best way to get questions answered is to use the project wonderland forums.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: