Last update: December 31, 2009
This language is an interchange messaging format between virtual reality simulators running into modern complex virtual world systems, where different simulators run neighbouring or intertwined scenes, or simulators are hosting objects or characters which are included in a scene running on another simulator. This makes that each simulator needs to know the internal state of other simulators.
It is also assumed here that the character viewing the scene is hosted by a simulator in his Character Hosting Company (which may be the only one able to simulate it).
In the case of the reduced WEM architecture, the Character Hosting Company contains a small simulator which hosts the character of the user, into scenes which are hosted by several other simulators. In this way the viewer needs to know the behaviour and description of each object, whichever simulator is actually hosting it.
In the case of the plain WEM architecture, the 2D rendering of the scene is also done on a machine of the Character Hosting Company, and only a video is sent to the user. There are plenty of technical and legal reasons to do so, not the least being to avoid copyrighted elements to be sent away on the Internet.
In either way, we can think at the viewer as being just the Character Simulator, which will need to receive a description of the scenes in which the character moves, and inform these scenes of what the character is doing. A similar need arises when several simulators run neighbouring or intertwined scene, or when they exchange objects.
So basically each simulator sends messages telling all the others what the object it handles is doing, and expect warning messages from other simulators as what this object or character is encountering some obstacle or interaction which may require a modification of its behaviour.
However it is physically impossible to do this at each time frame, because of transmission delays and differing frame rates.
So an emitting simulator handling an object will send, not just the actual position of this object, but a «trajectory», which is a prediction of the future behaviour of this object it is handling. Technically this trajectory is an animation (an interpolator in VRML/X3D) that the receiving simulator (or viewer) will run. This animation is a table of position keys indexed with time, that the receiver will interpolate at its own frame rate. If the receiving simulator foresees a collision or interaction with one of its own objects, then it will send to the emitter a warning that a new trajectory is needed, starting from a given time. This time is called an inflexion point. Then it is up to the emitter to calculate a new trajectory starting from the inflexion point, after the reactions of the object it handles.
So basically a Kailye message will associate trajectories to objects, with some other commands telling how this information is to be used.
For this purpose, the Kailye messages will have to run on an high speed internet link with a fast protocol, while the objects themselves and their bulky description files, textures, sounds, etc. will be available on ordinary http:// locations, where only the viewer will need to download them, for the rendering of the scene.
A basic interoperability feature of the Kailye language is that resources, objects, simulators, as even characters are identified with their URI (URL). In this way, any information on them, such as a position or orientation, is passed as a parameter into the querry string (between ? and #) of this URL. And trajectories have the same syntax than usual parameters, save that the trajectory will be a table indexed with time, instead of just one position value. For instance the common: position=x,y,z parameter will be just a peculiar case of a: position=t1,x1,y1,z1;t2,x2,y2,z2;t3,x3,y3,z3... trajectory. In this way, usual 3D parameters, non-Kailye parameters and even custom parameters can be mixed with Kailye parameters in the same message and in the same URL. So they can be used by Kailye systems and non-Kailye systems as well, without losing information.
Continuation: 2 - Basic structure of a Kailye message