Re: [ogpx] URI schema for virtual world locations?

[Meadhbh Hamrick <[e-mail]>]

and some comments.. discuss? or all we all good?

On Fri, Jan 22, 2010 at 11:13 AM, Meadhbh Hamrick
> 1. we're discussing the representation of locations within the virtual
> world as expressed in the protocol.
>
> 1.1. individual implementations may choose to define points in space
> using a representational system of their choosing, but the protocol
> will define at least one default representation that all systems
> should comprehend.

based on discussion on the list, i think the practical ramification of
this statement means "the protocol will represent points in the
virtual world using 3 64 bit IEEE 764 floats denoting the x,y,z
coordinates (in metres) in a rectangular coordinate system.

we do this because we don't want to force every implementation to
support a number of representational systems. points in space can be
represented in a number of ways. parsecs in a spherical coordinate
system would be an excellent representational system if we were
building a simulation of stars in a galaxy. but the main use case
we're thinking of is spaces for virtual people on people scales using
fixed, familiar coordinate system.

that being said, we could probably easily accommodate developers whose
use cases call for different coordinate systems in some ways. an
example was given where the "coordinate system" could be specified as
a parameter to a virtual world.

implementers should understand the ramification of this decision,
however. the more abstract the protocol, the more work implementers
will have to cover all conceivable situations. at the end of the day,
large parts of the protocol needs to be consumed by a client
application which will render a representation of the virtual world.
if you deploy a grid that specifies points in space using something
other than the default, you will greatly limit the ability of client
rendering software to make sense of the points you specify.

so... the primary use case (people on people scale) is pervasive
enough to select it as the default and to require users of other
representational systems to convert location references in the local
representational system to the network standard for use in the
protocol.

> 1.2. "locations within the virtual world" are represented as points in
> a multi-dimensional space. points are partitioned into "regions" for
> administrative and/or performance reasons.

IMHO, "locations within the virtual world" highlights the point that
the virtual world has a geometry that may be distinct from the
geometry of the hosts used to simulate it.

for example. imagine that you're at "infinity is full of stars" (
http://slurl.com/secondlife/Levenhall/76/204/22 ), and you're looking
into the Longfellow region immediately north of Levenhall. the
relationship between Longfellow and Levenhall is independent of the
relationship of the hosts on which they are simulated.

this is to insure that location references persist across the purely
administrative action of moving the region to a new simulator host.
from the point of view of an avatar in the virtual world,
Levenhall/76/204/22 should always have the same relation to
Longfellow/128/128/20 (assuming the position of these regions within
the virtual world is not changed.)

>
> 1.3. there may be two forms of location representation: absolute
> position within the virtual world (as denoted by a single point in
> space) or relative to the origin of a region.

Is this reasonable? Second Life frequently represents points at
<region name>/<x>/<y>/<z>. But the virtual world also defines an
"absolute space" into which regions are placed and it is possible to
convert between the two. The region-relative form is preferred because
it's relatively easy to convert between region name and FQDN of the
host simulating the region. Second Life residents are also socialized
to understand that the region is an important administrative entity.
Neither of these statements may be true of all VWRAP implementations.

> 1.4. the statement above (1.3) implies there is a public service
> available to map between points in the absolute space of the virtual
> world and points relative to a region.

Maybe the mapping between region and "space" should be the canonical
definition of a "grid" or a "virtual world" or an "instance." It does,
however, bring up the point again that in VWRAP, it's not illegal for
one region to exist in two virtual worlds. this is a policy decision
that is left to individual deployers.

it's easy to conceive of a situation where region A exists in "world
1" and "world 2". if the placement of regions inside a "grid" or
"world" is in inherent function of a virtual world, then it's possible
for region A to be adjacent to a different set of regions in the two
different worlds. that is, in world 1, region B may be directly north
of region A while in world 2, region C may be directly north of region
A.

the trust model we've been talking about defines a relationship
between an agent domain and a region domain. it's possible that User 1
who authenticates with agent domain 1 which has a trust relationship
with world 1 and User 2 authenticating against AD2 which has a trust
relationship with world 2 will see different things when they are both
present in region A and look north.

in other words, two people in the same place in "the" virtual world
may see radically different things under the same circumstances.
people should understand that this MAY not be a welcome outcome for
some participants.

proceed with caution.

> 4. the protocol must not REQUIRE a single service that maps between
> points relative to the origin of the "world" and points relative to
> the origin of an individual region.

i.e. - VWRAP should allow deployers to create a virtual world that is
independent of Second Life.