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

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

On Fri, Jan 22, 2010 at 16:36, Carlo Wood <[e-mail]> wrote:
> On Fri, Jan 22, 2010 at 11:13:46AM -0800, Meadhbh Hamrick wrote:
>> 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.
>>
>> 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.
>
> It is not true that the relative position of any two arbitrary
> regions is known. For example, some world could consist of
> of planets in solar systems and some would simply be too far
> apart to use coordinates in meters. Another example are
> the islands of private sims in SL.

are we saying the same thing?

in SL, we don't reckon the position of a region by it's relative
location to other regions, we reckon it relative to an absolute
coordinate system. i'm 99% certain that OpenSim does the same thing by
default.

in SL, the absolute position of a sim IS known, even if it's a single
island region.

that being said, it doesn't necessarily need to be this way.

> Hence, it makes more sense to limit coordinates to a Cartesian
> coordinate system relative to a given region, and be have
> a public service that maps region name pairs to a relative
> position vector v(name1,name2), or returning nil if they are
> not in the same space.

hmm.. this doesn't make more sense to me. having a "grid" or "virtual
world" with an origin and an extent that contains regions (each with
their own origins and extents) seems to be the simplest way to handle
this.

the reason i say this is that if i'm a viewer developer, and i have an
avatar that's standing close to a region border, i'm going to want to
be able to determine which regions intersect with my viewing cone.  it
just seems easier to code for me to have a big table of regions'
origins and extents.

at the end of the day, however, maybe we can get away with not
specifying an absolute coordinate system, but instead specify a
service that provides a list of regions that intersect with an agent's
viewing cone.

since the service that maps between absolute positions in the virtual
world and relative positions in a region would presumably know about
the region you're in, you could give it your location relative to the
origin of the region you're in, and if it needed to, it could
determine the global coordinates itself. heck, that might even be more
secure.

i would personally be a little wary about making this a service that
lives on a particular region host. but maybe there's a compelling
argument for the viewer to ask the particular region for the endpoint
to this service?

> The distance between {name1, v1}, where v1 = {x1,y1,z1},
> and {name2, v2} is then v(name1, name2) + v2 - v1.

but how do you get v(name1, name2)? do you store the offsets for each
pair of regions in a grid?

> That way a world is not obliged to have one single space
> where in every region must have a place.
>
> Also, putting every region in one region will likely
> lead to this 2D plane with regions and a z-coordinate
> with a range equal to that of each region: a flat world
> (like SL). I hope everyone knows that ANY example that
> breaks a protocol is prove that the protocol is wrong ;),
> so here it goes: someone might want to create "ring world"
> (http://en.wikipedia.org/wiki/Ringworld), where the
> rings exists of square regions, and the diameter of the
> ring is too large to really want to use it. Such a world
> could not very easily map it's world positions to a
> flat one (or even x/y/z, without getting really large
> and seemingly random numbers).

this is an example of using a cylindrical coordinate system.

or, you could simply cheat and build a special viewer that knows that
space is supposed to be cylindrical and have the viewer stitch
together the ends of a line of regions.

> A better approach therefore seems to be:
>
> A Cartesian coordinate system for one region at a time.
> A map from region names to a 2-dimensional *map* coordinates,
> where the map coordinates might have any arbitrary relationship
> to world coordinates (being irrelevant), including the
> notion that two regions might not be in the same space.

what if i wanted to have two regions, one on top of another? SL
doesn't do that now, but if we're going to allow ringworlds, shouldn't
we allow regions to sit atop each other?

> This would allow painting a map on a 2D surface (which can
> be used to explore and retrieve LM's from), but it would
> NOT allow to calculate the (real 3-D space) distance between
> points.
>
> 1.3. there may be two forms of location representation:
> map position (longitude/latitude) that give regions in a
> given space, a place on a map, and cartesian coordinates
> relative to the origin of a region (x,y,z).
>
>
> 1.4. the statement above (1.3) implies there is a public service
> available to map between the {space, longitude, latitude}
> "map coordinates" and points relative to a given region:
>
> {space, longitude, latitude} <---> {region name, x, y}
>
> --
> Carlo Wood <[e-mail]>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>