Massive Update

I've been working with Tommi Laukkanen on a universal protocol for virtual worlds. It will be the second version of CICP, as well as the next version of Tommi's protocol, SETP... so for now we are calling it SETP/CICPv2. My main contribution so far has been much of the language in the Domain Model. Jon Watte of Forterra has been contributing as well. I'm very excited about the effort. Visit the SETP wiki to see what we are up to... go to the domain model page. I'm going to paste the whole page at the bottom of this blog post, too.

Green Phosphor has a new website designed for us by Derek Au, one of the brightest programmers I know... who has abandoned programming for pottery, specifically brilliant porcelain constructions he has been making in China. I feel very fortunate to have him on board.

Just over a week ago Green Phosphor completed the filing of two patent applications. One covers our gateway between a virtual world and an analytical database; this is the IP that we are building our for-profit business around. The other app covers CICP, and we will always give that one away for free. Trolls beware, this patent app will hopefully end up protecting some very valuable open source technology: a flexible, efficient, cross-platform protocol for sharing interactive content within bubbles of simulated spacetime.

---

Domain Model

This page is a place to define the key entities of distributed virtual environments and SETP/CICPv2 protocol.

Theoretical Entities
-----------------------

Shared Spacetime

The overall goal of our protocol is to enable multiple participants to experience a shared, simulated, spacetime. Mathematically a spacetime is a four-dimensional continuum. We constrain this continuum such that the time dimension only moves forward and is constantly incremented by some sort of clock synchronization among the participants. We also may constrain this continuum such that there are a finite number of positions between two given points rather than an infinite number. This means it is not necessarily a continuum in the formal sense of the word.

Multiple shared spacetime bubbles may exist, and need not exist within the same coordinate system. A spacetime bubble may exist within a region of another spacetime bubble. A spacetime bubble may also border another spacetime bubble. Spacetime bubbles may also overlap.


Participant

Participants are entities which are able to perceive aspects of the simulation and/or have an effect on aspects of the simulation. Participant types are: humans, daemon processes, artificial intelligence scripts and applications.


Injection

Process where participant adds an object it owns to a spacetime bubble.


Ejection

Process where participant removes an object it owns from a space time bubble.


Object

An object is an atomic unit of content. An object's effect on a spacetime may be comprised of multiple types and occurrences of content, but is treated such that either the entire object exists within a given spacetime, or none of it exists. If a spacetime is assumed to have a boundary, and some object overlaps that boundary, the object can still be expressed in terms of the coordinate system of that spacetime and as such is considered to exist fully within that spacetime.

Injection commands are executed against individual objects. Update and ejection commands may be executed against individual objects or groups of objects.

Every object affecting a given spacetime belongs to a participant in that spacetime. If a program issues an injection command, placing an object into a spacetime, that program is a participant in that spacetime. If the program is a human interface, the human using the human interface is considered a participant.


Interaction

Interaction is an event where one object changes the state of another object. Without interactions it could be thought that all objects have their private spacetime. Participants use their avatar as a proxy when interacting with objects they do not own.


Avatar

An avatar is an object which is used to represent the identity of its owning participant.


State

Object external state can be observed and internal state is not immediately visible. State could
be categorized the same way as interactions. External states which are expressed with the protocol and internal states which are simulated but with entirely different model.


Content

Content is anything which can be perceived in the spacetime. Content only exists as a part of an object. Map can consists of one or more objects. All participation in a shared spacetime involves content. This includes images or textures, three-dimensional shapes, audio, fog, and light; it also includes changes occurring to any of these. Content may be injected into a spacetime, updated within a spacetime, ejected from a spacetime, or perceived within a spacetime. Injection, update, or ejection of content is performed via the protocol, by use of a command; perception of content is indicated via the protocol by receipt of an event. Injection, update, and ejection of content all result in perception events.


Awareness

Objects have awareness bounds. However they are defined geometrically, the awareness bounds indicate a region of space within a spacetime. If this region of space is affected by other objects, via injection, update, or ejection commands, events representing those effects will be sent to the participant responsible for the object. Objects may be defined with an empty awareness bounds, indicating that no events should be received.

Upon issuing an injection command for an object, a participant will receive events which correspond to all objects which were already affecting the spacetime within the awareness bounds of the new object.


Observation

An event where object observes another object inside its awareness bounds.


Migration (Teleporting / SimCrossing )

Process where objects teleport from one bubble to another. Teleporting can be seamless if bubbles overlap.


Visibility

Visibility is an attribute which reflects whether object or state can be observed through the spacetime. If transparent bottle is empty the state is visible as it can be observed with the mechanisms of the spacetime. If the state has to be inquired in an interaction it is not visible.


Appearance

When object is added to the world it appears. Objects and participants need to be aware of these events.


Disappearance

When object is removed from the world it disappears. Objects and participants need to be aware of these events.


Architecture Entities
--------------------------

Bubble (Simulation / Sim)

A volume of space simulated over time.


Cloud of Bubbles (Cluster / Grid)

A group of linked bubbles simulating distributed spacetime located in the same or separate bubble servers.


Bubble Server (World Server / Simulation Server)

A bubble server is a program which handles command and event processing for a spacetime. The bubble server is responsible for determining which events go to which participants, based on the awareness bounds and update coordinates of the objects the participants place into the spacetime. The bubble server may be essentially a messaging hub that is spatially aware only in terms of rough bounds and is not expected to perform physics simulation or collision detection. Bubble server will also contain object daemon (artificial active participant) injecting long lived persistent objects. Other daemon could be a physics daemon.


Human Interface / User Interface (Viewer/Browser/Client)

A human interface is a piece of software which uses the protocol and a user interface to enable a human to participate in a shared spacetime.


Subscription

Participants may inject objects which have a subscription capability. This means that other participants may receive updates involving that object directly from the owning participant. This can be useful to avoid network bottlenecking of a server; it is also useful when object updates take the form of a stream such as video or audio. The world server need not understand or process a particular video stream if the participant generating it streams it directly to all the other participants.

It has been suggested by Jon that subscription mechanisms and peer to peer streams could be defined in a separate protocol. - Tommi

I agree with this as well. All the SETP/CICPv2 protocol needs to do is allow an object to publicize the fact that it has a subscription capability and where to get it. --ark


Collision Detection

There should be a capability for a server module or special participant to handle collision detection for objects and trigger events based on that; it should also be possible for participants to handle their own collision detection.

It has been suggested by Jon that owning participant should always handle collision detection of an object. Another view point is that the bubble provides fundamental laws like collision detection. If several bubbles (sims from different providers) overlap then the bubble which is the primary bubble for an object (first point of injection) executes collision detection for that object. - Tommi

Reply: Collision detection is part of simulation of an object. Whether an object is squishy or hard, collides as a convex hull, sphere, mesh, or something else is part of the definition of the object. What the object does when colliding is part of the simulation (for example, does it bounce, or stick, or explode, or turn on a light, or ...). If you want to support simulating an object on a host other than the host that initially injected the object, then you'd have to also support injection and transfer of behavior, which is a Hard Problem and hasn't actually ever been solved well. Thus, an object is owned by its injector, its simulation is handled by its injector, and the lifetime of the object is constrained by the lifetime of the injector(!) If two injectors want to negotiate transfer of ownership separately from the protocol, and remove/re-inject the object (or perhaps more elegantly, allow transfer of ownership), then that's fine, but not necessarily part of this particular protocol.

I figure that since the bubble server has to be able to figure out the overlapping of awareness bounds and physical bounds of objects in order to do its job, why not enable it to also serve the participants with a basic collision (overlap of physical bounds and physical bounds) detection service. Objects have to somehow define their rough physical bounds to the bubble server anyway for awareness detection... the key is to keep it rough and simple. I am willing to ditch the idea of participants delegating collision detection for their objects to other participants; too complicated. Must eject and re-inject instead. --ark


Interaction Options for an Object

Every object may have interaction options which the owning participant has defined for it. Another participant may choose to activate on of these interaction options, which results in an event being sent to the owning participant; the owning participant is then expected to do something and update the object to reflect what is has done.

A human interface should allow a human to indicate a desire to interact with an object, and then display to the human the list of interaction options for that object. The human should then be able to select one, thereby triggering that event to the object's owner.

Understanding Things

People often want fancy looking graphs that change with time. They want movement and activity. They want algorithms which analyze streams of data in real time and make decisions in microseconds.

Meanwhile I find that looking at one static 3d graph of net oil consumption/production for over a year now still doesn't get old. The more I look at it the more I understand about what's been going on in the world over the last 40 years.

Where is the long-term strategic thought? We all know that we have become a culture of sound bites and quick fixes. Now that is biting us in the ass. How are we supposed to "compete" with China when we're only worried about the next election cycle, and when our financial strategies are all based on shuffling risk and betting on never-ending growth, with ever-finer granularity?

Arkowitz

Open Source

We are preparing a reference implementation of a CICP adapter for Second Life; when it is ready we will be releasing that along with the lg3d-wonderland adapter as Open Source.

Arkowitz

Lindquist's Theory

Life is a process which is able to thwart the Uncertainty Principle.

A computer program (logical (mathematical) construct!) as well is a way to adapt and reoptimize a prediction mechanism based on input (sense) over time (process).

The answer to the problem of the observed, the instrument, and the observer... is that the observer is the instrument.

Indeed, God does not play dice with the Universe. God created (is) life.