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

["Hurliman, John" <[e-mail]>]

The obvious use cases I can think of that would fall within a "Second Life like world" would be a world that uses a single coordinate system to describe positions in the world and has no concept of individual regions (or from another perspective, every simulation node simulates a portion of a single very large region) and a true 3D world that has regions that exist above and below other regions instead of the flat SL world. If I'm reading this right, both of those models would be supported, so I'm still +1 on this.

John

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Meadhbh Hamrick
> Sent: Friday, January 22, 2010 5:49 PM
> To: Joshua Bell
> Cc: [e-mail]
> Subject: Re: [ogpx] URI schema for virtual world locations?
> 
> 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.
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx