more content to mirror - Githubissues

in particular this:

Domain Model Abstract Entities

Spacetime

The overall goal of our protocol is to enable multiple participants to experience shared spacetime. Mathematically spacetime is a four-dimensional continuum. We constrain this continuum so that the time dimension only moves forward and both time and space are divided to discrete steps.

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.

Object

An object is an atomic unit from the protocol perspective. Effect of an object on 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 bubble is assumed to have a boundary and some object overlaps that boundary then the object can still be expressed in terms of the coordinate system of that spacetime bubble and as such it is considered to exist fully within that spacetime.

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

Avatar

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

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.

State

Object external states are visible and can be observed in the 3d environment where as internal state is not visible.

Visibility

Visibility is an attribute which reflects whether object or state can be observed through the spacetime. If bottle is transparent then filled/empty state is external and 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.

Perception Volume

Objects have perception bounds which reflect the volume of interest. However they are defined geometrically, the perception 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 zero perception range, 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.

Perception

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

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.

Appearance

When object becomes visible it appears.

Disappearance

When object becomes invisible from the world it disappears.

Interaction

Interaction is atomic event where one object changes the state of another object. Without interactions it could be argued that all objects have their private spacetime.

Handover

Process where objects migrate from one bubble to another. Handover can be seamless if bubbles overlap.

Architecture Entities

Bubble (Simulation / Sim)

A spherical or cubic volume defining spherical spacetime. Bubbles may overlap.

Bubble Cloud (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.

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.

MoysheBenRabi / setp

more content to mirror #1