Re: [ogpx] Decoupling simulation services from land for VWRAP scalability

Morgaine <morgaine.dinova@googlemail.com> Mon, 22 March 2010 17:13 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1B53A6942 for <ogpx@core3.amsl.com>; Mon, 22 Mar 2010 10:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=-1.153, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYqSbrAMjSaB for <ogpx@core3.amsl.com>; Mon, 22 Mar 2010 10:13:01 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E31C73A6970 for <ogpx@ietf.org>; Mon, 22 Mar 2010 10:13:00 -0700 (PDT)
Received: by wwg30 with SMTP id 30so2370580wwg.31 for <ogpx@ietf.org>; Mon, 22 Mar 2010 10:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=aiDPCDWOupwzNmpEVGXDX9qe/C8BzSyhLxAWN/dnHg8=; b=nvsWEbLBtwGY/NyXD71oUFewatFjfnWi2VtFScSaaXnSW3ICyARcsetcM9t46vcopg Qnx1n73gyW2r5ifPWpn1MtIp7hkkqKL1FNoflKWEk6DxSP0Qbvp/7N7VeTsYQgyyyCiG Fu13FcqVHqf8EJ2yMiKNvcLxtXxlON+7mEXhc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=T4Wd0qCUf1e6Y89tiUWowaLbWiKgKxx3ssAS8NP370wd3G1pXKAGMzRgmezAlcXiYO AdLpws9R+kJx4aW7ZaO8DHawFTqX1A/C55djgXN+8oEQpdwdFluA/tz0LjVVusrRXrtM JK3KhJxWvWN3PDMEa6iWtsZ6TGMzl4tWHM4tY=
MIME-Version: 1.0
Received: by 10.216.85.74 with SMTP id t52mr308152wee.208.1269277995244; Mon, 22 Mar 2010 10:13:15 -0700 (PDT)
In-Reply-To: <20100322145750.GA28284@alinoe.com>
References: <e0b04bba1003111033s6289daf7tc477fb1a4315085e@mail.gmail.com> <20100322145750.GA28284@alinoe.com>
Date: Mon, 22 Mar 2010 17:13:15 +0000
Message-ID: <e0b04bba1003221013x2213e91ah2b35325fcacec1bc@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="0016e6db24d1071ba0048266d07a"
Subject: Re: [ogpx] Decoupling simulation services from land for VWRAP scalability
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 17:13:03 -0000

Indeed Carlo, although your scenario of rogue viewer breaking the laws of
physics doesn't arise in my proposed decoupling of simulation services,
because only the *AGENT simulation* is performed by the *agent* locally ---
for example, control of mannerisms, emotes and in general anything that
doesn't affect the physics of the region.

The *ENVIRONMENT simulation* is a service chosen by the *region*, not by the
agent, so a rogue viewer cannot break the laws of physics --- the position
and bounding box of the agent in the region are still controlled by the
region, even if the region chooses the region simulation to run in an
external simulation service.

It's quite easy to express the current SL and Opensim pose and animation
mechanism as a simple example of an agent simulation service --- they work
in exactly the required way already, decoupled from the region simulation.
However, they currently operate in "batch mode", controlled by sending
pre-packaged animation files to all participants.

The next step for *agent simulation* beyond sending pose and animation files
is to define a range of parametrized agent actions which the agent can
perform on agent state, and let the region notify other participants in the
vicinity when they occur.  This doesn't impact on the physics simulation at
all.

The best thing about all this is that the VWRAP protocol wouldn't have to
know any of the details of agent simulation --- it would merely provide a
way for the region to gain access to the agent's agent simulation, ie.
obtain a cap for it.  Once the region has the cap, it can then proxy the
state of the agent simulation transparently to other participants.

It's worth mentioning that this is backwards compatible with the current
pose and animation system, making it very easy to implement an agent
simulation service in practice.  From there it is a small step to
fine-grained agent simulation, a major boon to the machinima community, and
a great leap for expressivity in virtual worlds.


Morgaine.






=================================

On Mon, Mar 22, 2010 at 2:57 PM, Carlo Wood <carlo@alinoe.com> wrote:

> It is possible to move "policy" (like 'have to follow the rules of
> physics')
> to the viewers, and enforce it based on statistics: Assume that most
> viewers
> are the official implementation and react predictably, and simply let
> the viewers 'vote' to establish who is breaking that policy.
>
> For example, 6 avatars are in a room. 5 run approved viewers, one is using
> a rogue viewer. The one with the rogue viewer walks through a wall. The
> other 5 detect this and (automatically) inform the server that this viewer
> broke the accepted policy. The server bans the rogue viewer. That leading
> by itself to keeping the number of rogue viewers small and hence the
> system working.
>
> On Thu, Mar 11, 2010 at 06:33:41PM +0000, Morgaine wrote:
> > MXP has "perfect scalability" proportional to the number of actors in a
> region,
> > because it has no centralized simulation.  Instead it employs the notion
> of
> > "participants" that each do their own simulation locally, plus central
> "hubs"
> > which reflect or replicate the contribution of each participant to all
> other
> > participants in the shared space.
> >
> > It should be noted that while MXP's hubs are
> > conceptually a shared resource, they are stateless and hence present no
> > practical barrier to achieving high scalability in the simulation.
>  (Limits to
> > actual scaling imposed by network bandwidth continue to apply of course.)
> >
> > Although MXP's local participant simulation is hugely scalable in this
> way, it
> > clearly lacks an essential ingredient that we have come to expect of VWs,
> > namely environmental simulation / physics in the shared space.
>
> --
> Carlo Wood <carlo@alinoe.com>
>