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

From: Cenji Neutra <[email-masked]>
Date: Sat, 14 Mar 2009 22:23:57 -0400

> From: Jon Watte <[email-masked]>
[...]
> 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)

---

From: Jon Watte <[email-masked]>
Date: Sat, 14 Mar 2009 22:01:58 -0700

> by being able to 'see into' a 'foreign' region under a LESS-style

There is nothing that prevents LESS from connecting separate seamlessly 
zoning systems. However, and this is important, you cannot enforce a 
single topology on all virtual worlds. For example, Second Life is a 
flat space, cut into squares of 256x256 meters. OLIVE is a round planet, 
cut into segments that might be thousands of miles across, and 
irregular, or might be as small as a 50x50 meter square. Other worlds 
are built of separate rooms where you "zone" between them (a la 
EverQuest). Making the entire metaverse one unified space with no 
teleport is provably impossible (unless you legislate that a single 
topology is all you can use).

For example, a lot of our customers like the real Earth as their 
topology. The closer we can get to using something like MS Virtual 
Earth, or Google Earth, or something of even higher resolution, as our 
topology, the happier our customers will be. You should check out the MS 
virtual cities -- some of them are quite nice, for consumer-grade data! 
However, even there, the City of Tokyo, if they used an OLIVE system for 
planning, would probably want to do totally different things with the 
same coordinate space as the Godzilla MMO game... Hence, each world 
needs to decide where and how it connects to other topologies, and which 
parts allow seamless zoning vs teleport-only.

> for true P2P VWs where there are no 'servers'.  In that case the

I agree. The P2P worlds have not shown themselves capable of scaling to 
really big sizes across the Internet yet, although there is lots of 
research into the area. When I present the LESS model, I typically 
mention that P2P clients look like other peer hosts -- or you may use a 
gateway, and introduce the gateway as one peer on the P2P network (there 
are some good examples of this from the past).
Also, with P2P, the question of trust is thornier than when you peer 
with a defined set of partners. Compare the internet backbones: AT&T, 
Sprint, Qwest and Verizon may very well peer traffic to each other, but 
they won't let J. Random Nerd off the street into their network centers 
to do the same, both because it's quite problematic, and because it 
really isn't necessary.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Thu, 19 Mar 2009 08:11:55 +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 <[email-masked]>wrote:

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>