MediaToy Technical Summary
Last updated: September
9, 1999
anselm@openmediagroup.com
Topics
Overall
This document describes the current details of the MediaToy project ( the Googleplex Game ) and our plans and time-frames for the next version ( the authoring tool ). It is the only source of technical information about the project architecture (existing and upcoming) at this time.
As of August 15 we have built a lightweight game by integrating MathEngine and Java3D. This took about 3 months of 5 peoples time. It works well. The game features polygon accurate real time collision and is deeply physical with very satisfying natural behavior. This framework has gone through quite a few refinements and with some cleanup will be a good foundation for the authoring tool which we are doing next. We are currently on hiatus from this project until October 2 1999. Next we are going to write an authoring tool for March 1999 at the latest, and ideally a first rev should be done in January.
Code
Code standards
These issues can be elaborated over time. They are listed here because there may be many contributers. Most issues are enforced by Java anyway so this isn’t as much of a concern as in a C or C++ project.
Package Organization
The package organization is currently focused on the Googleplex game, it is:
The 'me' layer is the lowest layer. It is a Java wrapper for MathEngine with support for Java3D datatypes. It also introduces the set and group concepts.
The 'engine' layer is under active research, this is where we're playing with various ways of doing events, managing namespaces and basic shared operations. Right now we have some concepts which are definitely going to be obsolete - such as the 'mediascene' concept which will be replaced by an ASCII parsed world description.
The 'controllers' layer packages up the behaviors one sees in the game. This concept seems to be working well although passing a mediascene is unnecessarily heavy - it might be better to require explicit passing of whatever external services the given controller needs. There needs to be services that can enumerate the other objects in a scene.
The 'scene' layer should go away entirely and be replaced with ascii scripts that are loaded off disk. Rather than having a scene class there should just be a global namespace or directory service which is used to wire up related objects. For now however the scenes concept works well as a Java native mimic of the yet to be defined ASCII grammar.
The viewer layer is good in the sense that it is fairly distinct from the rest of the application, but there are some tensions with the camera. The world authoring tool will be up at this layer - it will be a shallow interface leveraged highly off of existing pieces and also off of the Java GUI builders etceteras
Building the project from scratch
See web site documentation on using WinCVS. Generally one unpacks everything into an ‘MeOMG’ directory. The Googleplex game is in the ‘mediatoy’ directory. Enter that directory and type make from a dos prompt.
Running the project
Enter the MeOMG/mediatoy/obj directory and type ‘java MeOMG.mediatoy.ui.Viewer’ from a dos prompt.
Bugs
Features we may add (in no particular order) to the Googleplex game are:
Web services that are broken and need attention:
Current and Upcoming Authoring Tool Design – Base Classes
Off-the-shelf Components
The Kernel layer is Java itself. In other games this would normally be written from scratch. The kernel layer provides basic system services such as garbage collection, object serialization, networking, reflection, RTTI (Run Time Typing) and thread support across multiple platforms.
The SceneGraph layer is Java3D. Polygon-rasterization and drawing layer is provided by Java3D on top of DirectX (for Windows 95) or OpenGL (for Windows NT and UNIX). It provides a high level abstraction of the properties of a 3d simulation. Geometrys, transformations, lighting and a host of specialized features such as billboards and camera control capabilities are provided by Java3D. Java3D also provides Behavior nodes which we use to implement our controller logic for game objects. One of our design goals is to have every single one of our game objects hanging off of the Java3D scenegraph rather than having a private database elsewhere. This will allow third party tools to tradverse our game state.
VRML is our graphics persistence format at the moment. We export VRML from SoftImage, Alias Maya and 3DSMAX. It works pretty well although there are some polygon ordering issues and it is a bit of a hassle to submit polygon strips to the collision detection. Java3D has support for loading VRML.
MathEngine to Java Bindings. We are not using the official MathEngine JNI bindings yet but are using our own. We will upgrade in the near future.
Sets and relationship Classes
This term doesn't quite map to the formal mathematical terms - rather the concept of 'set' is more like the concept of 'family' in a prototype based object composition system - see Kevo, Wittegenstein, Eleanor Rosch, George Lakoff.
Implemented but not in use yet. See MeOMG.mediatoy.me.sets. A set is a grouping of related objects. Becoming a member of a set implies acquisition of properties that that set is currently or later subject to. This concept is used throughout the simulation engine to define relationships for collision, forces and other interactions.
A relationship describes a relationship between two sets of objects. Relationships are specialized - when an object is added to a set that is a member of a relationship ( or multiple relationships ) those relationships are informed about the addition and may operate on the new member of the set in special ways.
The concept of sets and relationships is critical if one wants to get beyond explicit wiring up of individual relationships. When dealing with a simulation where objects come and go all the time, or enter the simulation in arbitrary order, it is important to have a more general kind of 'typing' or 'family association' that specifies the typical behavior of object instances.
MathEngine Bodies, Joints, Forces, World Classes
See MeOMG.mediatoy.me. The MathEngine physical body is what is acted upon in the simulation. It is the target of operations by joints and forces. It has mass, girth, location and orientation. Joints and Forces (as opposed to force fields) themselves could be considered relationships, however they are treated as atomic terms in the grammar since there is no particular incentive to use set relationships when only two specific bodies can participate. The MathEngine world and the CollisionSpace concept are wrapped up in side of a 'Space' class for convenience purposes.
Collision Models, Sets and Group Classes
Note: We are using a pre-release special-edition version of the collision library. The collision library is limited in our release to only allow 2048 polygons per object and 64 objects maximum. It will become a part of the official MathEngine release in the near future.
See MeOMG.mediatoy.me.collision. CollisionModels represent individual geometries. They may differ in shape from the geometry however. Typically they must be associated as well with a dynamic MathEngine body. This may change however.
CollisionSets may be associated with each other by a CollisionGroup. Member collision models of each set will now collide against each other when added to the same group. A set of force fields in a set will act upon the set of bodies that they are crossed with as well.
Through programmer habit over time common colloquial set will arise to define common relationships. There may often arise collision sets that collide the point of view or player against other dynamic objects, and there may be collision sets that collide static (i.e. immobile) objects against all dynamic objects.
The Collision group within MathEngine will be providing extensive documentation here.
ForceSets and ForceGroup Classes
Not implemented yet. ForceSets represent a set of forces and can be interacted with a set of bodies. Typically, like CollisionSets, these are registered with the Namespace registry and conventions arise as to their naming.
Particles ( MathEngine body + Geometry )
Particle Systems in the MediaToy are not implemented as a discrete module. Rather they are distributed through-out the overall functionality of the system. A particle itself is implemented as a convenience class that owns a TransformGroup and also owns a MathEngine physical Body. The benefit of this is that one almost always uses a TransformGroup in association with a body. Also by using this abstraction it is easier for controllers to operate on particles. The 'Space' class which abstracts a MathEngine world and collision is able to update particles if they are registered with it - however the usage pattern right now is not to do this because that update method doesn't consider spatial culling of distant particles. It is probably best to update particles by hand depending on the context or to let the particle system do it if they are particle system particles.
The particle effects instances themselves (such as rain, fireworks, sparks ) are implemented as just another controller (see Controllers). Each owns many small particles that it does work on. The particle system is driven over time by threaded execution. Currently there is no interpreted script language for the particle system other than Java itself (which is fine for most purposes). It can be used to generate rain, confetti, fireworks, sparks and l-system like trees and other recursive objects. The particle effects system relies heavily on the set concept, the particle concept and the geometry construction classes. It is actually quite shallow itself. By using the approach of relying on external forces it is possible for particles to interact with external forces, and for external game objects to interact with force fields spawned by the particle effects layer.
Below are some notes on L-Systems, something which exploits iteration to build natural looking objects. Augmented variations of L-systems can be used to form a grammer which compactly describes appealing behavior. This is useful for some particle effects such as trees or effects over time such as a fireball hitting the ground and exploding into shards. We implement an L-system like behavior with recursion simply by using Java for now. In fact L-Systems are a little bit over-glorified, they simply define a grammer with state and recursion, something which is a small subset of the functionality of a full blown procedural language such as Java. The value of the approach is it demonstrates the power of recursion, but implementation wise there are many other approaches.
Excerpted from the Fractint documentation:
If you look at a tree, it is not too hard to imagine that a branch of the tree looks very much like a smaller version of the whole tree. The L-system below uses this idea to model a (tumble?) weed.
Weed {Angle 50Axiom +++++++++++++x
x=f[@.5+++++++++x]-f[@.4-----------!x]@.6x}The symbols "+", "-", "f", "@", "[", "]", and "!" are reserved symbols in FRACTINT L-Systems. The symbol "x", on the other hand, has no graphic meaning for the FRACTINT L-System interpreter. "x" is just a cell that subdivides into the cells according to the string that follows "x=". The symbol "+" means "turn left 7.2=360/50 degrees". The symbol "-" means "turn right 7.2 degrees". The text line "Angle 50" tells FRACTINT how much a turn is, namely 360/50 degrees. The symbol "f" means "draw a line in the current direction". The symbols "[" and "]" work together. "[" means "remember the current graphics state, position, orientation, line length , etc." "]" means "set the graphics state back to the remembered state". The symbol "@" means "multiply the current line length by the amount following". Hence "@.5" means multiply the current line length by .5. The symbol "!" means "reverse the meaning of + and-". Now let's translate this L-system into English. The symbol "x" represents the weed. The Axiom line tells FRACTINT to turn the weed left 13*7.2=93.6 degrees. Since FRACTINT always begins oriented East, this command puts the weed just about upright. The replacement string for the weed x says draw a line (f), the stem of the weed. Next, shrink the weed by .5, turn left 9*7.2=64.8 degrees, draw the shrunken weed, and return to the stem ([@.5+++++++++x]). This draws the lowest branch of the weed. Next, turn right slightly (7.2 degrees) and draw another portion of the stem (-f). Continuing, shrink the weed by .4, turn right 11*7.2=79.2 degrees, reverse the meaning of right and left, draw the shrunken weed, and return to the stem ([@.4-----------!x]). Finally, draw the weed at .6 size (@.6x).
Particle Systems References:
Jeff Lander at www.darwin3d.com has a particle system. He recommends: For research, why not start with the original source. William Reeves while he was at Lucasfilm created the idea of particle systems. Here are the references to the original papers:
Reeves, William T., Blau, Ricki "Approximate and Probabilistic Algorithms for Shading and Rendering Structured Particle Systems" Computer Graphics (Proc. Siggraph) Vol. 19, No. 3, July 1985, pp. 313-322 Reeves, William T. "Particle Systems
A Technique for Modeling a Class of Fuzzy Objects" Computer Graphics (Proc. Siggraph) Vol. 17, No. 3, July 1983, pp. 359-376 David K. McAllister has a Particle System at http://www.cs.unc.edu/~davemc/Particle. He cites the following papers and parties:
Jonathan Leech and Russell M. Taylor II, "Interactive Modeling Using Particle Systems", Proceedings of the 2nd Conference on Discrete Element Methods, MIT, spring 1993, pp. 105-116.
Thanks to Mark Allen of NASA Ames Research Center for finding bugs, making suggestions and implementing the particle length attribute. Thanks to Jason Pratt of CMU Stage 3 research group (makers of ALICE) for adding the PDTriangle domain. This is a powerful feature that should have been there the whole time.
Geometry Construction Classes
See MeOMG.engine.Geom.java. There is a geometry construction class that builds geometry to specification. It can load up VRML files or make novel objects from scratch. It also provides support for building MathEngine collision surfaces around loaded or created geometries. This is going to be heavily augmented over time, although there is currently a tension as to where it belongs.
Controller Classes
See MeOMG.mediatoy.controllers. Controllers have thread of execution flow and can apply logic over time. They are designed to be spatially located. They often own particles or raw MathEngine bodies and joints and do additional work on them aside from whatever external forces the bodies are subject to. The term 'controller' is used differently than from simulation engineering industry. In the simulation industry this refers purely to logic, however in our context Controllers are drag and drop objects that may also implement graphics internally. Most of the application that users will perceive is imbedded in a wide variety of custom controllers. Currently controllers are standalone classes, this may change to become derived off of a BranchGroup and in this way the transforms and behaviors driving those transforms can be more closely related rather than being randomly dispersed in the scene relative to one another.
Persistence
The persistence layer is not yet specified. Currently we use Java itself.
Critiques of VRML:
Packages
A package is an abstract or non-formal concept of a clump of controllers, transforms and MathEngine objects. One can consider a 'scene' to be a package or a bunch of packages. This aspect of the engine is still being refined.
Scene
See MeOMG.mediatoy.scenes. A scene is a bunch of controllers or packages, and ultimately it may be a script instead. There is no formalism at this level yet because there is no need to manipulate multiple scenes simultaneously.
Sequencing and Scripting
See MeOMG.mediatoy.controllers. Scripts make things, sometimes on the fly, and can sleep for periods of time. They are a completely fundamental concept to this project and show up as a pattern over and over. All sequencing and scripting today is done directly in Java by hand. Java is an adequate scripting layer in itself, however it is not accessible to non-programmers. At some future date a more generally user accessible declarative form of Java will be used to define objects and their relationships to each other. This might be similar to BML or JavaBeans however the notation should be more clean and efficient.
Namespaces
See MeOMG.mediatoy.engine.database. An extremely simple but important chunk of code. Components architectures require directory services. For networking one also needs generalized directory services in order to find lobbies or players in those lobbies. A general directory is also a good place to manage miscellaneous environment variables and in this sense acts like a registry. Finally, a global namespace is a good way for event emitters and listeners to discover each other.
Object to object dataflow
A component based architecture should allow application neutral wiring of state change between objects. Objects can publish methods that specify arguments they emit or receive and these objects can be wired to each other. It is important to order the flow of data most efficiently. There is also a question of dataflow model: A pull dataflow model starts off with the displayable elements and ‘pulls’ on state changes from everything which is related to what is on the view. This is good for an authoring environment where elements not on the view are not important. A push dataflow model computes forward the state propagation from all user inputs, this is better for a simulation where the internal coherence of the simulation must be maintained regardless of observers.
Event support
See MeOMG.mediatoy.engine.eventhandler. Events and dataflow are distinct. Dataflow is synchronous with state refreshes of the system and are explicit between specified objects. Events are asynchronous and are usually anonymous, being received by classes of interested parties rather than a predetermined party. There are serious design defects in the Java implementation of event handling in that they force event relationships to be prematurely explicit and have a heavy emphasis on receiving events rather than discussing how to form emitters. The Java model is AWT centric and this makes sense for a user interface but does not make sense for a simulation. Audio sequencing, network ‘join’ and ‘kick’ events are examples of events. The entire simulation can be driven (started, stopped, levels changed) by events, and events form the glue of the application. Objects can signal critical phenomena (player selected quit) and suchlike in a way that allows modules to remain decoupled and this is critical to building granular reusable systems.