Regarding the Meta Project and the meeting this saterday

[Jorrit Tyberghein <Jorrit.Tyberghein@uz.kuleuven.ac.be>]

Hi,

As I unfortunatelly cannot attend to the meeting this saterday (due to not being
able to do IRC nor ICQ) I will try to say in a short mail what the current plans
for the Crystal Space project are. As the project manager of Crystal Space I'd
very much like to cooperate in some way with the PengiunPlay/Meta Project.

This mail serves just as a quick introduction to what we are doing at the Crystal
Space project. Look at it as 'discussion-bait' :-)

The phylosophy of Crystal Space is to split it into several more-or-less
independent layers (or libraries/toolkits):

    - Indoor 3D Engine
    - Landscape 3D Engine
    - The Physics Library
    - The Scripting Engine
    - ...

There are more but those four above are currently the most important and
the ones on which the most work is done. The Indoor 3D engine is very functional
(although far from finished). The Landscape 3D engine is only in a planning stage.
We know how to do most things and more importantly, we also know how to
interface the indoor engine with the landscape engine (using portals this interface
is going to be easy and smooth for the game player).

The physics library is currently being developed. The library will be a collection
of physical routines. Collision detection will be part of the 3D engine since that
depends too much on the internal structure of the engine. There will be one
abstract class (PhysicalProperties or something) which will be the only physics
class that the engine knows about. PhysicalProperties will be almost empty.
It will need to be filled in by the required physics model (which is not hardcoded
in the engine). So the physics and engine are kept as independent as possible.
Note that the physics library will be used from within the scripting engine as it
is the scripting engine that will control all physics (for utmost flexibility).

The scripting engine is being developed in steps. The first step will be to make
all important classes in the 3D engine COMpatible. Why COM? Because it
is standard, because it allows for plug-and-play enhancements and because
it allows to interface to Crystal Space from every language/program that
supports COM (like JAVA or Visual Basic). A common misconception is that
COM is microsoft only. Although most COM support can be found on Windows
this is not completely true. We plan to use COM for the interface between the
scripting engine and the 3D engine ON ALL platforms that Crystal Space
is ported too. That includes DOS and more importantly: Linux :-)

The next step in the scripting engine will be a VM (virtual machine). This will
be a general virtual machine not specific to the 3D engine. It will know how to
speak COM and thus can be used to drive any set of COM classes.

The last step is to write a C++ like language (ReAct) which will compile to the
VM. Why ReAct and not JAVA or C++? Well JAVA is still possible since you
can also access COM with JAVA. But ReAct will have the advantage that it
is specifically designed for games. For example, it will have language specific
event features and so on.

Greetings,

--
==============================================================================
Jorrit.Tyberghein@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

The Kappamaki, a whaling research ship, was currently researching the
question: How many whales can you catch in one week?
        -- (Terry Pratchett & Neil Gaiman, Good Omens)
==============================================================================