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> >