Re: [mmox] One more time: The LESS model vs the Generic Client model

Morgaine <morgaine.dinova@googlemail.com> Thu, 19 March 2009 08:11 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7BE28C0F1 for <mmox@core3.amsl.com>; Thu, 19 Mar 2009 01:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Level:
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_43=1]
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 drQ2XAO3TbDa for <mmox@core3.amsl.com>; Thu, 19 Mar 2009 01:11:12 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 7E06A3A6987 for <mmox@ietf.org>; Thu, 19 Mar 2009 01:11:11 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 4so90951eyf.31 for <mmox@ietf.org>; Thu, 19 Mar 2009 01:11:55 -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:cc:content-type; bh=UuWY2KA46Rs0IPWtfO19qn5c+tymsJtde8YXCUZE1og=; b=S/DlPD9Fva+rVwH+EahvkTaOroaEg0W2oTTmZ8BaAU5L0nczhqIMThCxgbmToeR9fe RGMkS0uM5ZujzfhaiG20jqfxKHAysGu5mxOMbD8mUX544LAzSBaa/QFicuw4v2PYDmlY YMfGnoFAAgYJKHDMHfv2DG1UkfyCZwLtC0Bwo=
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 :cc:content-type; b=SExaDWI7lZuNhB9EEjQvdoLodRd2rQNcVW7yqSOV9imarO0u0H30gx8zZstIeclPjC nertnP8yEK20X3BwYntNE2r5lWCAKMSutLazics9maxqtyM3ZpJgcsHA6RDkOduAP6pU TgLxZEkIe9xhGJmiluAbey90myMh6Y9Rx/urY=
MIME-Version: 1.0
Received: by 10.210.42.13 with SMTP id p13mr1685117ebp.26.1237450315801; Thu, 19 Mar 2009 01:11:55 -0700 (PDT)
In-Reply-To: <b76a7f90903141923w5d97bb3cn61cbb1714d5692d9@mail.gmail.com>
References: <b76a7f90903141923w5d97bb3cn61cbb1714d5692d9@mail.gmail.com>
Date: Thu, 19 Mar 2009 08:11:55 +0000
Message-ID: <e0b04bba0903190111h359bfa09oa148c6afaeb2c241@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Cenji Neutra <cenji.neutra@gmail.com>
Content-Type: multipart/alternative; boundary="0015174bea248027200465745a17"
Cc: mmox@ietf.org
Subject: Re: [mmox] One more time: The LESS model vs the Generic Client model
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2009 08:11:13 -0000

Cenji, that's quite an interesting preference for travel continuity you have
there.  I happen to prefer the opposite, but in virtual worlds there is
often a way to satisfy conflicting requirements simultaneously.  I was
wondering how this might be achieved.

If a world owner makes her world accessible only by teleport or via a
specific in-world portal that you cannot walk or fly to, the direct approach
is barred, but maybe an indirect approach is still possible.

What does region adjacency actually mean?  It means that:

   1. the objects, terrain and avatars in the next world can be seen from
   this one;  and
   2. the transition from this world to the next one does not create a
   visible interruption.

Both of these requirements can be met for a "teleport-access-only" world
under certain conditions.  Point #2 is "trivial" to meet if the viewer
sources are under community control, since we can prevent a visual
interruption at the code level if there is no technical need for one.  And
the actual need for an interruption can be eliminated if point #1 is met.
So this boils down to addressing point #1 only.


So how can we arrange to make this possible?  Here is one way:


   1. In the protocol, decouple the ability to request region data from the
   action of teleporting to that region.  This allows you to preload the area
   behind a transition boundary in your current zone with data for the remote
   zone.
   2. Create your own staging region, which could be either a private
   anteroom within your own viewer or part of a public metaverse gateway region
   (based on Opensim for example).
   3. Select some boundary edge within your staging region, and "place" the
   remote region at that edge by preloading the visible area beyond that
   boundary using a protocol request of the type mentioned in #1.
   4. Place a transition trigger or invisible portal at the boundary to the
   area that you preloaded in #2.
   5. When you pass through the transition point, there should be an
   illusion of continuity if your preload was effective and if your viewer was
   adequately programmed to avoid the "zoning" discontinuity.  Since the pre-
   and post-transition scenegraphs should be mostly identical after a full
   preload, the two regions are in effect contiguous in space, from your
   perspective.


Note that as long as you retain the region data for your staging region,
your viewer can at any time place a virtual portal at the point of entry to
any new world after entering it, so you can retrace your steps back out of
remote regions with full portal-type continuity at any time.

I described in a recent
post<http://www.ietf.org/mail-archive/web/mmox/current/msg01171.html>two
simple protocol requirements which make many different kinds of world
transition possible, including yours.  The essential ingredient is access to
region data being decoupled from the notion of teleport, so that remote
views can be preloaded locally.


It is worth underlining the "User Experience" requirement that your post
also highlights*:

**Eliminate the extremely irritating "zoning" experience*.

"Zoning" with visible interruption is really just an artifact of poor VW and
client design.  Enshrining it in the MMOX protocol(s) is technically
unnecessary and would be an expression of policy instead of mechanism.


Morgaine.








On Sun, Mar 15, 2009 at 2:23 AM, Cenji Neutra <cenji.neutra@gmail.com>wrote:

> > From: Jon Watte <jwatte@gmail.com>
> [...]
> > 1. a seamless click-to-teleport experience, no matter where the
> destination
>
> In my personal use of SL, I typically don't go anywhere I can't
> walk/drive/fly/rocket-pack.  For me, the introduction of 'private
> islands' in SL that are privately owned but usually publically
> accessible, but only via teleport from the mainland due to being
> non-contiguous with the mainland, was the worst change in SL's
> development.  I still await the day when that is 'fixed' and I can
> again fly everywhere (for non-SLers, it historically wasn't always
> possible to teleport anywhere in SL as it is now either).
>
> Just pointing out that an inter-op protocol that only supports
> *teleporting* between spaces hosted by different 'native'
> providers/grids may not be very valuable to people who share my
> preference.  I imagine that no additional difficulties would be raised
> by being able to 'see into' a 'foreign' region under a LESS-style
> interop model though.
>
> My only other comment is that even a LESS-style interop protocol may
> have to be supported by some VW viewers directly initially - such as
> for true P2P VWs where there are no 'servers'.  In that case the
> viewers would have to speak LESS to interoperate with grids like
> SL/OLIVE/etc but otherwise only need to speak the protocol of their
> peers.
>
> -David.
> (Cenji Neutra inSL)
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>