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.
Background
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 mtgame.dev.java.net. There is even a programming guide over there – although I need to update it.
Thanks for reading,
Doug.
Posted by wonderlandvw 
For one of the days of training, we met at the MDA offices in the futuristic Fusionopolis building. This was quite a high-tech facility with interesting architecture. They had a well-appointed demo room in which we saw a demo of a project called 
The China portion of the trip was a bit more focused. In Beijing, Jon met up with a group of other Sun employees involved with China Innovation Program for Students (CHIPS) program. This article provides an overview of the program:
