Subject: Re: [mmox] mmox Digest, Vol 1, Issue 36

From: William George <[email-masked]>
Date: Tue, 17 Feb 2009 10:21:08 -0500

I didn't think my point was correctly interpreted.

Imagine the early days of he automobile or railways? There were no real
standards committees in those days, but one could image how they would
operate.

Do we worry about what happens to the blacksmiths and stable hands? I
suggest a quick google for the term "Luddite" and one can see how the social
aspects _must_ trail the technology.

My position is that we should assume that objects _will_ be transferred
between worlds/grids and that as an _owner_ of said property I will retain
some kind of "rights of usage". I would also expect these objects to operate
in some consistent manner across these worlds. I see this as an important
part of interoperability, if not the main charter.

There has to be some technical discussion concerning some form of
authentication, and possibly even authorization, but lets not get mired in
detail to protect the virtual blacksmith's "rights" to cobble their prim
horseshoes.

---

From: Charles Krinke <[email-masked]>
Date: Tue, 17 Feb 2009 08:21:24 -0800 (PST)

Perhaps another way to perceive of interoperability between various worlds & grids is similar to international travel between countries.

There could be argued that there is a subset of items that one owns that are commonly carried through airport security which would include modest clothes, avatar attachments such as hair and some personal items. But, that would not include a 747. Also, some form of a wallet and identification documents is appropriate.

So, if we were to concentrate on the smallest reasonable subset of items that can be reasonably carried between worlds and grids first, perhaps a consensus can be arrived at.

Charles

________________________________
From: William George <[email-masked]>
To: [email-masked]
Sent: Tuesday, February 17, 2009 7:21:08 AM
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 36

Imagine the early days of he automobile or railways? There were no real standards committees in those days, but one could image how they would operate.

Do we worry about what happens to the blacksmiths and stable hands? I suggest a quick google for the term "Luddite" and one can see how the social aspects _must_ trail the technology. 

My position is that we should assume that objects _will_ be transferred between worlds/grids and that as an _owner_ of said property I will retain some kind of "rights of usage". I would also expect these objects to operate in some consistent manner across these worlds. I see this as an important part of interoperability, if not the main charter.

There has to be some technical discussion concerning some form of authentication, and possibly even authorization, but lets not get mired in detail to protect the virtual blacksmith's "rights" to cobble their prim horseshoes.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Wed, 18 Feb 2009 09:43:38 +0900

I agree,  with the pre-requisite for authentication and see that as
being a
  "User" Services Account per-grid.

With regards object transfer,  I personally see each "grid of regions"
as being
  an own-domain and only items "attached" to be transferred with the
character.

This opens the market for having "suitcase" attachments,

the only items that I see as being standalone crossing between grid
regions would be
  automated bot programs,  and these need not keep the standard "AV".

And limitation of transfer based based on ownership and complexity.

Some things like scripts need to be hosted seperately for transfer to
happen safely,
  to allow the region server a mechanism of limiting any harmful effects
without loss
  of function in transfer.

Also this would limit the loss of content and state issue that is
currently present.

--

With regards imagining like the early automobiles or early railways...
certainly...

However anything external to the AV or "detached" status may be blocked
or
  otherwise have a substitute based on the new "grid" environments
theme.

I can imagine an Egyptian ferry being switched for an Italian taxi from
Venice,
  or even a really big "leaf" if changing region to somewhere of an
entirely different scale.

switching grids need not keep scale,  but the only thing needed to be
kept would be some
  kind of central "airport" style mechanism that allows for being a
"door" between the grids.

Or do we allow anyone with permissions on two or more grids to
"Teleport" to any location
  on a target grid entirely seperate from the former.

--Idea--
What about splitting the Asset&Inventory services into having "User
Storage" and
   "Region Storage"... anything free-floating is on region storage (grid
local) and anything
   in "User Storage" is potentially cross-grid capable.

However the first thing to cross grids apart from an AV for presence is
going to be messaging
  from what I understand there is several backend options needing some
kind of
  standard "Message" base able to be encoded for IM & Email, 

I would request UTF8 encoding for this style of message(address:content)
delivery
  then we can push towards having standardized i18n/i10n support with
least effort.
--Idea--

I remember a description of early LL teleporting needing a "hub"
location.

 Why not allow unrestricted p2p teleports within the same grid of
regions and when needing
  to transfer across regions using a special region on both grids with a
"door" and key setup?

This would allow a basic operational setup of something akin to Airport
security with regards
  firewalling and also provide a "safe zone" with information about grid
connections.

Information about other grids need not be limited here,  but it would be
a start for some kind
  of standard to develop without requiring to push untested features to
all regions in any grid

Sincerely,
  Jeremy

---

From: Ann Otoole <[email-masked]>
Date: Tue, 17 Feb 2009 18:18:28 -0800 (PST)

My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset system) over followed by initialization of the avatar using the mesh and textures for baking. Leave attachments for the future (if they ever become needed at that point since most people will not look back with real meshes and textures done right).

Just a thought towards making ubiquitous interop materially feasible in the next couple of years anyway.

For the IP thing the license would obviously be for the avatar mesh holder to wear/use anywhere in the metaverse.

________________________________
From: Kajikawa Jeremy <[email-masked]>
To: [email-masked]
Sent: Tuesday, February 17, 2009 7:43:38 PM
Subject: [mmox] User Accounts / "Object" Transfer.

--

--Idea--

Sincerely,
  Jeremy

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 13:37:49 -0800

Ann Otoole wrote:
> My opinion is that interop would be best served through a standard 
> mesh and texture subsystem on all grids and teleport between grids 
> consists of transferring the mesh and associated textures (if not 
> already present in the target grid asset

What end-user value does "teleport between grids" solve?

In my opinion, that feature is very un-interesting, as it requires lots 
of engineering, and gives very little value, compared to lower-hanging 
fruit like physical spaces shared across interoperating servers.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Wed, 18 Feb 2009 13:55:59 -0800 (PST)

Dear Jon:

I tend to agree with your direction. Although my personal work has involved OpenSim and SecondLife, I too, would like to see a standard evolve that considers a consensus among many virtual worlds implementations.

To to that, we first have to find the lowest common denominator between the set of virtual worlds to be considered and see if we can get a consensus on at least *one* point to start moving forward.

And, no matter what happens in this group, we also have to consider that representatives from several virtual worlds are reading what we say here and evolving their logic in a way that suits their perception of where the whole industry is going.

So, it behooves us to find that lowest common denominator and see if we can create a useful specification to avoid wasting any of our time. I have to believe that there exists a subset of the SecondLife OGP and HyperGrid notions that can at least form a basis to start building. If not, perhaps someone can propose such a basis.

Charles

________________________________
From: Jon Watte <[email-masked]>
To: Ann Otoole <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, February 18, 2009 1:37:49 PM
Subject: Re: [mmox] User Accounts / "Object" Transfer.

Ann Otoole wrote:
> My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset

In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers.

Sincerely,

jw

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

---

From: Suzy Deffeyes <[email-masked]>
Date: Wed, 18 Feb 2009 16:04:31 -0600

On Wed, Feb 18, 2009 at 3:37 PM, Jon Watte <[email-masked]> wrote:

> Ann Otoole wrote:
>
>> My opinion is that interop would be best served through a standard mesh
>> and texture subsystem on all grids and teleport between grids consists of
>> transferring the mesh and associated textures (if not already present in the
>> target grid asset
>>
>
> In my opinion, that feature is very un-interesting, as it requires lots of
> engineering, and gives very little value, compared to lower-hanging fruit
> like physical spaces shared across interoperating servers.
>
>
Hi Jon,

Thanks for offering a perspective outside the Second Life / OpenSim bubble.

Can you elaborate on " physical spaces shared across interoperating servers
" and what you mean by that?

Suzy Deffeyes
IBM

---

From: Lawson English <[email-masked]>
Date: Wed, 18 Feb 2009 15:08:54 -0700

Jon Watte wrote:
> In my opinion, that feature is very un-interesting, as it requires 
> lots of engineering, and gives very little value, compared to 
> lower-hanging fruit like physical spaces shared across interoperating 
> servers.
>
> Sincerely,
>
> jw
>

The OGP solution, at least for SL<=>OpenSim, actually makes TP a special 
case of the shared physical space.

In theory, at least with SL and OPenSim, if two grids shared trust for 
object sharing and supported the same TP protocol they could share the 
same visual/relative-physical space as well.

It's the simplest possible scenario to implement it--sharing between two 
worlds where one was designed to be compatible with the other and the 
other is making an attempt to meet the first halfway--but it's a model 
that might be workable for less SL-centric worlds as well.

At the least, I could see TP via Croquet and SL/Open Sim via a portal 
using the OGP protocol as a model. Not sure that Croquet supports shared 
visual borders outside the portals so the larger issue may not apply anyway.

L.

---

From: Charles Krinke <[email-masked]>
Date: Wed, 18 Feb 2009 14:13:43 -0800 (PST)

Dear Lawson:

This is starting to get really interesting. I did have a conversation with the Croquet folks about such a shared space teleport on their Java newsgroup a couple of months ago and their feeling was "Thats great, Charles, shouldnt be too difficult, how about if we assign you to write the Croquet side". So, nothing much came of the conversation.

But, ... if it turned out that a small team might like to see if they can actually prototype such a gateway, whether there is visibility through the portal or not, this in itself might head the whole group in a very interesting direction.

Charles

________________________________
From: Lawson English <[email-masked]>
To: Jon Watte <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, February 18, 2009 2:08:54 PM
Subject: Re: [mmox] User Accounts / "Object" Transfer.

> In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperatin…

The OGP solution, at least for SL<=>OpenSim, actually makes TP a special case of the shared physical space.

In theory, at least with SL and OPenSim, if two grids shared trust for object sharing and supported the same TP protocol they could share the same visual/relative-physical space as well.

It's the simplest possible scenario to implement it--sharing between two worlds where one was designed to be compatible with the other and the other is making an attempt to meet the first halfway--but it's a model that might be workable for less SL-centric worlds as well.

At the least, I could see TP via Croquet and SL/Open Sim via a portal using the OGP protocol as a model. Not sure that Croquet supports shared visual borders outside the portals so the larger issue may not apply anyway.

L.

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 16:24:58 -0800

I think the lowest common denominator may be aiming too low -- we need 
to deliver actual value to actual end users paying for that value, or 
the whole effort is moot.

However, that being said, I'm prepared to throw a stake in the ground: 
You cannot migrate behavior.
If behavior is authored for system X, then system Y will not be 
reasonably expected to perform that behavior at full fidelity. For 
example, behavior could be written in Java for Wonderland, or Python for 
Qwaq or Panda3D, or C++ and XPath for OLIVE. There simply is no way that 
every virtual world will be capable of emulating the execution 
environment of each other virtual world (here's a case where X3D broke 
down -- it specified an execution environment, that didn't actually suit 
anyone's needs).

Thus, to make an object appear in a "remote" world, that object needs to 
be, at a minimum, simulated in the "home" world, and information about 
the outcome of that simulation (animations played, movements performed, 
sounds generated, interactions caused, etc) should be transmitted over 
the interoperability channel.

Sincerely,

jw

Charles Krinke wrote:
> So, it behooves us to find that lowest common denominator and see if 
> we can create a useful specification to avoid wasting any of our time. 
> I have to believe that there exists a subset of the SecondLife OGP and 
> HyperGrid notions that can at least form a basis to start building. If 
> not, perhaps someone can propose such a basis.

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 16:37:15 -0800

Suzy Deffeyes wrote:
> Can you elaborate on " physical spaces shared across interoperating 
> servers " and what you mean by that?

Let's assume organization A builds a space. Let's assume organization B 
builds furniture. Now, they want to have a meeting, and see how the 
furniture works in the space. The easiest way to accomplish this is to 
make organization A users log into the organization A virtual world 
(like they always do), and organization B users log into organization B 
virtual world (like they always do), and make arrangements such that 
some room/area/island within the two organizations is shared -- whatever 
comes to that space from A, also shows up in B, and vice versa. This 
allows A to publish its space, and B to bring the furniture to that 
space, without either having to disconnect from their regular virtual 
world (buddy list, unified messaging, inter-office collaboration, etc).

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Thu, 19 Feb 2009 02:06:43 +0000

> Thus, to make an object appear in a "remote" world, that object needs to be,
> at a minimum, simulated in the "home" world, and information about the
> outcome of that simulation (animations played, movements performed, sounds
> generated, interactions caused, etc) should be transmitted over the
> interoperability channel.

This is a nice way of looking at the problem. So far, everyone has
assumed we send whole objects together with scripts, a very SL-centric
approach. Of course, one big problem is this:
1 - VW A has Cool Object X
2 - User A on VW A sends Cool Object X to user B on VW B
3 - User B on VW B rez's it (and let's assume they're both utterly
different types of world)
4 - VW B's servers talk to VW A and ask VW A to simulate the object

What happens in step 4 if VW A's servers are down?

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 21:45:50 -0800

> What happens in step 4 if VW A's servers are down?

How can the user even be available to interoperate if VW A server is down?

Think of it like cell phones. If I call you, and you don't have your 
cell phone on (not "logged in" to "your system"), or your cell phone 
operator has an outage ("server down"), then how can I call you? I can't.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Thu, 19 Feb 2009 07:39:16 +0000

On Wed, Feb 18, 2009 at 9:37 PM, Jon Watte <[email-masked]> wrote:

> After perception of the world around you, travel is the next most important
form of interaction with the world.  Teleport is simply instantaneous
travel, and teleport between grids is simply instantaneous travel between
worlds in different organizational domains.  How can it possibly be
uninteresting and give little value to travel to distant places in virtual
space?  ;-)

I expect that you meant something *completely* different to the above.  :-)
  Are we hitting an ambiguity in terminology of some kind here?

Morgaine.

---

From: Gareth Nelson <[email-masked]>
Date: Thu, 19 Feb 2009 08:17:26 +0000

I think a better analogy is, if I have a phone and send a picture to
you using the builtin camera, then I turn my phone off. Suddenly your
phone can't access the picture (of course in reality we send the whole
picture to you).

On Thu, Feb 19, 2009 at 5:45 AM, Jon Watte <[email-masked]> wrote:
> Think of it like cell phones. If I call you, and you don't have your cell
> phone on (not "logged in" to "your system"), or your cell phone operator has
> an outage ("server down"), then how can I call you? I can't.
>
> Sincerely,
>
> jw
>
>

---

From: Jesrad <[email-masked]>
Date: Thu, 19 Feb 2009 12:38:16 +0100

I'd say the same can be said of anything related to any object but not
being the object itself: just as the "script" of an object should be
communicated between grids as an external reference, so should the 2D
or 3D representation, the sound/stream, the text stream, etc.

E.g. I drive my virtual car through a portal to another grid: the
information exchanged is just a stack of references: a ref to its 3D
representation (CAPS ?), a ref to the running script, a ref to the
Agent Domain (for ownership, controls, access rights, whatever), a ref
to the source grid, etc... all of those to be accessed by the
destination grid.

That stack of references, at the MetaGrid level and in itself, "is"
this virtual car owned by me at this place and time and is
interoperable to the extent that the VWs can handle these types of
references (and their respective clients can display them, but that's
something else). A translation table can be established at the object
level for supplying different refs to different grids (I have 3D
models in mind here), maybe that makes one more reference in the
stack.

In this view the only interoperability that needs to be coordinated
between the VWs, is that of uniformity of access, like with a
standardized API.

The problem I see here is that in this model, internal scripts for
objects need to be accessed uniformly, too. When my car bumps into
something and is scripted for that event, both grids need to be
capable of calling the right event handler.

On Thu, Feb 19, 2009 at 1:24 AM, Jon Watte <[email-masked]> wrote:
>
> I think the lowest common denominator may be aiming too low -- we need to
> deliver actual value to actual end users paying for that value, or the whole
> effort is moot.
>
> However, that being said, I'm prepared to throw a stake in the ground: You
> cannot migrate behavior.
> If behavior is authored for system X, then system Y will not be reasonably
> expected to perform that behavior at full fidelity. For example, behavior
> could be written in Java for Wonderland, or Python for Qwaq or Panda3D, or
> C++ and XPath for OLIVE. There simply is no way that every virtual world
> will be capable of emulating the execution environment of each other virtual
> world (here's a case where X3D broke down -- it specified an execution
> environment, that didn't actually suit anyone's needs).
>
>> So, it behooves us to find that lowest common denominator and see if we
>> can create a useful specification to avoid wasting any of our time. I have
>> to believe that there exists a subset of the SecondLife OGP and HyperGrid
>> notions that can at least form a basis to start building. If not, perhaps
>> someone can propose such a basis.
>

---

From: Kajikawa Jeremy <[email-masked]>
Date: Thu, 19 Feb 2009 21:23:46 +0900

But any transfer of objects outside being part of the AV itself I would
consider to be
  either subject to breakage or likely to come across with dataloss in
function.

this also reads to me as requiring the following...

Each "System" is developed independently and a common library is
developed (akin Java)
 for a write-once run-anywhere specification where the backends use each
systems local
 implimentation of any given functionality,  and also the requirement of
specific support.

How many developers actually use Java/Python/... as cross-platform
development,

currently WoW has LUA for scripting the client,  SL has LSL and this is
scripting independent
 of the client and running on the server as well as "attachment" scripts
for extending the AV
 functionality with client-side UI presence.

Therefore I suggest a middle-path... allow each system to select its own
scripting language,
  and only require a "common library" of functionality presence with
cross-binding option.

That way anyone who impliments anything can rely on the functionality at
scripted level
 remaining stable on the originating grid, (LSL already has C# and C
language editions)

I see the interoperability needing support from those systems making it
available.

I do see one point of contention that will break this occuring,  what to
support first?

How about presence alone and simply do not provide any mechanism for
import/export
  of materials across worlds that are containing any "script" or
executable content.

disconnect that into an own server and make the functions required
follow the KISS rule,
  the more that is applied the more successfully available interop will
become. 

For now scripting will have to be "future"...basic shapes and "look" on
objects need to
 follow getting AV transfer occuring without the entire legal mess
considering...

 Guild Wars and some other games dont licence the engine but instead the
content,
  and this content would need to have downgraded editions available for
non-licensed
  viewing so some kind of system<->system remapping WILL occur
somewhere.

---

From: Jesrad <[email-masked]>
Date: Thu, 19 Feb 2009 14:04:16 +0100

> I see the interoperability needing support from those systems making it

Yes, that's what I was talking about: the common protocol is really a
standard remote-API that VWs should conform to when communicating with
clients - a conveyor of relevant information but not the information
itself. By making an object a pure stack of references (one reference
per Grid service to be used) then the format of these references and
the external object they point at can be expanded upon very easily
afterwards.

Furthering this view, a VW then does just one minimal function:
connecting the dots. A Grid becomes little more than a router for the
relevant references/info, in this model. Some Grids may internally
host the objects refered to (the 3D data, the sound files ,etc...) and
apply access control, while some others might depend entirely on
external hosting (we could have clients that fetch textures through
plain HTTP, references could even point to local files for games that
have static content) and let the client end handle authentication, but
in the bigger picture then it's only the end clients and the
hosts/sources that are being connected together through the grids,
while these underlaying grids affect the content very little: they'd
be acting on the connection only.

The bare minimum a VW does, then, is transmitting just the presence
signal between congruent entities, so each of them knows "who's there"
depending on this "there". Additional functions and signals can be
internally hosted and/or signalled on a per-grid basis, like with MIME
codes for the Web. That makes the interoperability protocol into some
sort of service location and discovery protocol, I think.

> How many developers actually use Java/Python/... as cross-platform

Javascript ? Flash ? I think they owe their heavily cross-platform
usage more to the market they're used in, than to any special
characteristic they may have as languages. And that this market
resembles VWs more than the general professional software industry
does, so I don't see why we shouldn't expect the same for VW
scripting.

---

From: Morgaine <[email-masked]>
Date: Thu, 19 Feb 2009 15:36:54 +0000

On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte <[email-masked]> wrote:

> furniture works in the space. The easiest way to accomplish this is to make
> organization A users log into the organization A virtual world (like they
> always do), and organization B users log into organization B virtual world
> (like they always do), and make arrangements such that some room/area/island
> within the two organizations is shared -- whatever comes to that space from
> A, also shows up in B, and vice versa. This allows A to publish its space,
> and B to bring the furniture to that space, without either having to
> disconnect from their regular virtual world (buddy list, unified messaging,
> inter-office collaboration, etc).
>
> Unfortunately, that's non-scalable, particularly along the complexity axis.

It works fine in your example because you have only two parties wishing to
share a space and hence there is only one space to simulate, but try to
extrapolate from there to see where it leads.  If your organization A has N
users, and those N users wish to take part in N different worlds (which is
asymptotically likely if N << total number of worlds), then your
organization A must now simulate N different worlds.  For large N, this
places a colossal load on organization A, even if the individual shared
spaces are minimally populated.  To coin a common phrase by analogy, you're
undertaking to "simulate the Internet". ;-)

What's more, very few platform optimizations will be possible since the N
worlds are all different, and this also means that the scalability of each
shared space will be severely constrained as well.  And as if that were not
bad enough, the N worlds that your users visit tomorrow will not necessarily
be today's N worlds, so for (N << total number of worlds) your local cache
will need to grow almost without limit if it's to work at all.

Even if organization A's machinery were powerful enough to support N
radically different worlds through shared-space simulations though, they
still couldn't do it, because in the general case the simulation code for a
given world will not be available.  The world simulation is the "secret
sauce" of many virtual worlds, and from a business perspective it is quite
likely to be their product differentiator and they will be loathe to share
it.  But even if it were freely available, the portability of one
organization's simulation code to another organization's machinery is far
from guaranteed with today's software technology, not to mention the
management of upgrades for something this complex across organization
boundaries.

Now contrast that shared-space architecture to today's more prevalent one.
Organizations A and B(1)...B(N) design their own worlds in accordance with
their particular visions, and each world is tailored to their own optimized
hardware.  Now in the case when the N users of organization A travel to
those N different B worlds, organization A has no world simulation load for
active users at all (it just sends out data to the N worlds).  Instead, some
number of foreign users from the B worlds will arrive and need to be
supported.  However, they are supported in organization A's own world
simulation, which is highly optimized by design and hence carries none of
the complexity/scalability problems mentioned above in the shared-space
approach.  Foreign world simulations never need to be supported.

In the Internet-like metaverse model of unlimited and extremely diverse
worlds, I really don't see the shared-space approach as being at all viable,
because diversity is its enemy.  In some severely constrained corporate
settings it might be quite usable (and even efficient for standardized
worlds), but this does not seem to be a generally scalable model for an
evolving metaverse.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Thu, 19 Feb 2009 07:55:45 -0800 (PST)

Dear Morgaine:

That could very well be. Shared spaces may or may not be achievable in the near term.

That sort of gets us back to figuring out what we "do" wish to accomplish. 

Are we here to seek consensus and modify the already existing and deployed OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim is appropriate for this group? Are there other protocols to consider?

So, I have to ask, as I am getting confused with all the e-mails flying around and like many, I have lots of things to concentrate on. So:

"What are we here for and what do we hope to accomplish?"

Charles

________________________________
From: Morgaine <[email-masked]>
To: Jon Watte <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Thursday, February 19, 2009 7:36:54 AM
Subject: Re: [mmox] User Accounts / "Object" Transfer.

Let's assume organization A builds a space. Let's assume organization B builds furniture. Now, they want to have a meeting, and see how the furniture works in the space. The easiest way to accomplish this is to make organization A users log into the organization A virtual world (like they always do), and organization B users log into organization B virtual world (like they always do), and make arrangements such that some room/area/island within the two organizations is shared -- whatever comes to that space from A, also shows up in B, and vice versa. This allows A to publish its space, and B to bring the furniture to that space, without either having to disconnect from their regular virtual world (buddy list, unified messaging, inter-office collaboration, etc).
Unfortunately, that's non-scalable, particularly along the complexity axis.

It works fine in your example because you have only two parties wishing to share a space and hence there is only one space to simulate, but try to extrapolate from there to see where it leads.  If your organization A has N users, and those N users wish to take part in N different worlds (which is asymptotically likely if N << total number of worlds), then your organization A must now simulate N different worlds.  For large N, this places a colossal load on organization A, even if the individual shared spaces are minimally populated.  To coin a common phrase by analogy, you're undertaking to "simulate the Internet". ;-)

What's more, very few platform optimizations will be possible since the N
worlds are all different, and this also means that the scalability of
each shared space will be severely constrained as well.  And as if that were not bad enough, the N worlds that your users visit tomorrow will not necessarily be today's N worlds, so for (N << total number of worlds) your local cache will need to grow almost without limit if it's to work at all.

Even if organization A's machinery were powerful enough to support N radically different worlds through shared-space simulations though, they still couldn't do it, because in the general case the simulation code for a given world will not be available.  The world simulation is the "secret sauce" of many virtual worlds, and from a business perspective it is quite likely to be their product differentiator and they will be loathe to share it.  But even if it were freely available, the portability of one organization's simulation code to another organization's machinery is far from guaranteed with today's software technology, not to mention the management of upgrades for something this complex across organization boundaries.

Now contrast that shared-space architecture to today's more prevalent one.  Organizations A and B(1)...B(N) design their own worlds in accordance with their particular visions, and each world is tailored to their own optimized hardware.  Now in the case when the N users of organization A travel to those N different B worlds, organization A has no world simulation load for active users at all (it just sends out data to the N worlds).  Instead, some number of foreign users from the B worlds will arrive and need to be supported.  However, they are supported in organization A's own world simulation, which is highly optimized by design and hence carries none of the complexity/scalability problems mentioned above in the shared-space approach.  Foreign world simulations never need to be supported.

In the Internet-like metaverse model of unlimited and extremely diverse worlds, I really don't see the shared-space approach as being at all viable, because diversity is its enemy.  In some severely constrained corporate settings it might be quite usable (and even efficient for standardized worlds), but this does not seem to be a generally scalable model for an evolving metaverse.

Morgaine.

---

From: Jesrad <[email-masked]>
Date: Thu, 19 Feb 2009 17:35:14 +0100

> That sort of gets us back to figuring out what we "do" wish to accomplish.

The way I see it, we're trying to figure out how the "language" that
different VWs could use to exchange their common types of data.

So first we should be figuring out what data types and features are
common to the VWs/MMOGs targeted. Obvious ones (2D/3D representation,
identity referal + authentication, experience/level/gold/L$ account,

Then we classify these data types into a few major supertypes that
each correspond to a basic grid service (can they be optional or not
?), a bit like how the Agent Domain includes IM, L$ and inventory: WoW
players also have IM, gold, and inventory, and that can be considered
the "WoW Agent Domain".

In this way we can design containers for each supertype, seperately.
The basic, universal operation of a VW (connecting the dots, see
previous message) dictates the logic of the protocol, while the data
types dictate the content/streams it transports. The idea is that each
supertype of data may be supplied by different grids at the same time,
so each shall regroup only the features and data subtypes that mandate
each other: you're supposed to be able to login in your SL account
then enter the OSGrid, while retaining your SL L$ balance.

Tentative adoption plan:

Step 1: Existing VW are expected to encapsulate their own protocols
into this common grid protocol, as an additional layer on their
existing protocols

E.g. sending an object to the viewer becomes contained in the
supertype container for "object".

Step 2: Support for different data format can be added between this
new layer and the existing ones, for each set of grid server + client:
at this step, for example, it becomes possible to display previously
unsupported 3D models, or to hear the . We'll have to figure out where
the conversion is done (at the source or end-point or gateway ?)

E.g. you download/buy an add-on for the SL viewer that lets it render
the WoW avatar model it may receive in an "object" supertype container
instead of the usual SL definition, by reading the static data it
refers to.

Step 3: at this point there is already basic interoperability, which
can be expanded upon by switching to common format for the actual data
transmitted. Specific exchanges between VWs can be set up to allow
more interoperation (like an exchange between L$ and WoW gold so you
can pay L$ in WoW and vice-versa).

If we devise a "native" format for "common denominator" data types,
step 3 would be the time where VWs switch to this native format from
their previous incompatible ones.

This whole proposal assumes there IS a basic, universal operation that
all VWs/MMOGs do respect.

On Thu, Feb 19, 2009 at 4:55 PM, Charles Krinke <[email-masked]> wrote:
> Are we here to seek consensus and modify the already existing and deployed
> OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim is
> appropriate for this group? Are there other protocols to consider?
>
> So, I have to ask, as I am getting confused with all the e-mails flying
> around and like many, I have lots of things to concentrate on. So:
>

---

From: Morgaine <[email-masked]>
Date: Thu, 19 Feb 2009 18:09:41 +0000

Jon, after reading your other posts, I think that you may have been
referring to your "shared-spaces" idea when you questioned the value of
"teleport between grids", as I can't see any other architecture being
discussed.

However, if that's the case then I don't understand the point being made,
because shared-spaces seems to be a "teleport only" architecture.  The only
means by which a user can go from one shared space to another is by
teleport, since shared spaces do not have topological relationships to each
other, from your description.

If you ignore the local simulation for a moment, then what happens when one
of your users changes from one local shared space to one belonging to a
different provider is very similar in implementation to the usual separate
worlds case:  the agent appears in the space at the remote end.   Adding a
local simulation on top of that doesn't really change the matter.  That's
teleport between grids, plus a local accelerator.

And perceptually from the users' perspective, the model suggests that they
too see a teleport occurring every time that they change their shared space
to one operated by a different world provider.  This looks like perfectly
ordinary "teleport between grids" to them too.

Morgaine.

On Thu, Feb 19, 2009 at 7:39 AM, Morgaine <[email-masked]>wrote:

>> After perception of the world around you, travel is the next most
> important form of interaction with the world.  Teleport is simply
> instantaneous travel, and teleport between grids is simply instantaneous
> travel between worlds in different organizational domains.  How can it
> possibly be uninteresting and give little value to travel to distant places
> in virtual space?  ;-)
>
> I expect that you meant something *completely* different to the above.
> :-)   Are we hitting an ambiguity in terminology of some kind here?
>
> Morgaine.
>

---

From: Charles Krinke <[email-masked]>
Date: Thu, 19 Feb 2009 10:26:32 -0800 (PST)

Both good points, JHurliman and Morgaine.

I think the punch line is we are not talking about a theoretical implementation that might be, but rather a practical implementation that is already deployed and in use by thousands of folks and this deployment is growing every day.

We are concerned with whether the avatar landing manifests as a cloud of fog, an amorphous gray character, an ANPC, a Ruth or even a tourist with a camera about its neck. We are also concerned with ensuring that the first person and various third person scenes are consistent with each other.

Getting the teleport presence consistent between virtual worlds is a moving target as various groups work seperately and then interface occaisionally. And getting this teleport prescence consistent is the pre-requisite to then having attachments, scripts, huds, AO, inventory and other features work functional in cross-world teleporting, or as some folks say 'Interop'.

Charles

Sent: Thursday, February 19, 2009 10:09:41 AM

Jon, after reading your other posts, I think that you may have been referring to your "shared-spaces" idea when you questioned the value of "teleport between grids", as I can't see any other architecture being discussed.

However, if that's the case then I don't understand the point being made, because shared-spaces seems to be a "teleport only" architecture.  The only means by which a user can go from one shared space to another is by teleport, since shared spaces do not have topological relationships to each other, from your description.

If you ignore the local simulation for a moment, then what happens when one of your users changes from one local shared space to one belonging to a different provider is very similar in implementation to the usual separate worlds case:  the agent appears in the space at the remote end.   Adding a local simulation on top of that doesn't really change the matter.  That's teleport between grids, plus a local accelerator.

And perceptually from the users' perspective, the model suggests that they too see a teleport occurring every time that they change their shared space to one operated by a different world provider.  This looks like perfectly ordinary "teleport between grids" to them too.

Morgaine.

On Thu, Feb 19, 2009 at 7:39 AM, Morgaine <[email-masked]> wrote:

After perception of the world around you, travel is the next most important form of interaction with the world.  Teleport is simply instantaneous travel, and teleport between grids is simply instantaneous travel between worlds in different organizational domains.  How can it possibly be uninteresting and give little value to travel to distant places in virtual space?  ;-)

I expect that you meant something completely different to the above.  :-)   Are we hitting an ambiguity in terminology of some kind here?

Morgaine.

---

From: Meadhbh Hamrick (Infinity) <[email-masked]>
Date: Thu, 19 Feb 2009 12:06:25 -0800

the draft charter is the best guide for what we're hoping to achieve.

you can find a copy at http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter

the things to remember here are:

	a. we're not trying to solve the problem of interoperability between  
every existing virtual world. at least not in the near term.
		- and... by extension... we're not trying to specify a general- 
purpose virtual world application stack that would enable a single  
client application to interoperate with any virtual world.

	b. we're not trying to solve the general problem of "what is a  
virtual world." i would refer you to the VWR and MPEG-V groups for that.

	c. we're trying to build a flexible, extensible application layer  
wire protocol used for virtual world interoperability. but the  
protocol we define here may need to be augmented by an  
"interoperability profile"
		- in other words, we're defining mechanism, not policy. for example,  
second life and opensim now have a "one simulator per 256m square  
region." we may not want to enshrine this in the protocol (i mean...  
what does this mean in the context of a virtual world like EVE  
Online?) instead, we should put this in an interoperability profile.  
the profile would reference the ogp base documents, but add  
implementation details required for proper presentation of the virtual  
world, but not required for the definition of the wire protocol.

	d. OGP is not what Second Life currently uses. OGP was originally  
conceived as being the AWG's "next generation" virtual worlds  
protocol. (the AWG being a technical architecture working group with  
Linden, IBM and OpenSIm contributors) for what it's worth... we  
demonstrated interoperability last summer between systems managed by  
linden lab and various partner systems using open sim and PyOGP.

	e. SL OGP (the OGP drafts that were written last summer) is not a  
complete body of work. there's still a lot of stuff to add. part of  
linden's motivation for participating in an IETF process is to  
continue to develop this protocol in a forum where we get maximal  
involvement from the internet community.

	f. HyperGrid is pretty darn'd cool, IMHO. and there's nothing in it  
that would eliminate it from consideration by this group. I believe  
John Hurliman is trying to define it in draft form to be considered at  
the upcoming face to face in san francisco. even if we don't have a HG  
draft for that meeting, i am confident it will attract considerable  
attention on the mailing list, and honestly, we're months (if not  
years) away from turning any internet drafts into RFCs.	
		- if you've been following the HG discussion, you may have seen talk  
about the difference in trust models between OGP and HG. but... if we  
can create an abstract trust model that allows implementers to pick  
"OGP" or "HG" trust, i think we could easily define the wire protocol  
for both traditional OGP and HG users.

so... to recap...

	* we're about application layer wire protocol
	* we're about interoperability between current or near future  
implementations
	* we're NOT blessing Second Life's existing protocol as an official  
standard
	* it's entirely possible application developers using MMOX protocols  
would need to define an "interoperability profile," which defines how  
MMOX applies to their application.
		* in other words, "we define mechanism, not policy."

On Feb 19, 2009, at 7:55 AM, Charles Krinke wrote:

> Are we here to seek consensus and modify the already existing and  
> deployed OGP protocol of SecondLife? Are we here to see if HyperGrid  
> from OpenSim is appropriate for this group? Are there other  
> protocols to consider?
>
> So, I have to ask, as I am getting confused with all the e-mails  
> flying around and like many, I have lots of things to concentrate  
> on. So:
>
> Let's assume organization A builds a space. Let's assume  
> organization B builds furniture. Now, they want to have a meeting,  
> and see how the furniture works in the space. The easiest way to  
> accomplish this is to make organization A users log into the  
> organization A virtual world (like they always do), and organization  
> B users log into organization B virtual world (like they always do),  
> and make arrangements such that some room/area/island within the two  
> organizations is shared -- whatever comes to that space from A, also  
> shows up in B, and vice versa. This allows A to publish its space,  
> disconnect from their regular virtual world (buddy list, unified  
> messaging, inter-office collaboration, etc).
>
> It works fine in your example because you have only two parties  
> wishing to share a space and hence there is only one space to  
> simulate, but try to extrapolate from there to see where it leads.   
> If your organization A has N users, and those N users wish to take  
> part in N different worlds (which is asymptotically likely if N <<  
> total number of worlds), then your organization A must now simulate  
> N different worlds.  For large N, this places a colossal load on  
> organization A, even if the individual shared spaces are minimally  
> populated.  To coin a common phrase by analogy, you're undertaking  
> to "simulate the Internet". ;-)
>
> What's more, very few platform optimizations will be possible since  
> the N worlds are all different, and this also means that the  
> scalability of each shared space will be severely constrained as  
> well.  And as if that were not bad enough, the N worlds that your  
> users visit tomorrow will not necessarily be today's N worlds, so  
> for (N << total number of worlds) your local cache will need to grow  
> almost without limit if it's to work at all.
>
> radically different worlds through shared-space simulations though,  
> they still couldn't do it, because in the general case the  
> simulation code for a given world will not be available.  The world  
> simulation is the "secret sauce" of many virtual worlds, and from a  
> business perspective it is quite likely to be their product  
> differentiator and they will be loathe to share it.  But even if it  
> were freely available, the portability of one organization's  
> simulation code to another organization's machinery is far from  
> guaranteed with today's software technology, not to mention the  
> management of upgrades for something this complex across  
> organization boundaries.
>
> Now contrast that shared-space architecture to today's more  
> prevalent one.  Organizations A and B(1)...B(N) design their own  
> worlds in accordance with their particular visions, and each world  
> is tailored to their own optimized hardware.  Now in the case when  
> the N users of organization A travel to those N different B worlds,  
> organization A has no world simulation load for active users at all  
> (it just sends out data to the N worlds).  Instead, some number of  
> foreign users from the B worlds will arrive and need to be  
> supported.  However, they are supported in organization A's own  
> world simulation, which is highly optimized by design and hence  
> carries none of the complexity/scalability problems mentioned above  
> in the shared-space approach.  Foreign world simulations never need  
> to be supported.
>
> In the Internet-like metaverse model of unlimited and extremely  
> diverse worlds, I really don't see the shared-space approach as  
> being at all viable, because diversity is its enemy.  In some  
> severely constrained corporate settings it might be quite usable  
> (and even efficient for standardized worlds), but this does not seem  
> to be a generally scalable model for an evolving metaverse.
>
> Morgaine.

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 19 Feb 2009 13:36:38 -0700

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Meadhbh Hamrick
>Sent: Thursday, February 19, 2009 12:06 PM
>To: Charles Krinke
>Cc: [email-masked]
>you can find a copy at
>http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter
>
>- and... by extension... we're not trying to specify a general-purpose
>virtual world application stack that would enable a single client
>application to interoperate with any virtual world.
>
>
>b. we're not trying to solve the general problem of "what is a virtual
>world." i would refer you to the VWR and MPEG-V groups for that.
>
>c. we're trying to build a flexible, extensible application layer wire
>protocol used for virtual world interoperability. but the protocol we
>define here may need to be augmented by an "interoperability profile"
>what does this mean in the context of a virtual world like EVE Online?)
>instead, we should put this in an interoperability profile. the profile
>would reference the ogp base documents, but add implementation details
>required for proper presentation of the virtual world, but not required
>for the definition of the wire protocol.
>
>conceived as being the AWG's "next generation" virtual worlds protocol.
>(the AWG being a technical architecture working group with Linden, IBM
>and OpenSIm contributors) for what it's worth... we demonstrated
>interoperability last summer between systems managed by linden lab and
>various partner systems using open sim and PyOGP.
>

At the first AWG meeting in September 2007, it was made clear that Linden Lab had already defined the architecture of OGP, and the purpose of the AWG was to refine and implement this protocol. I'm not sure that demonstrating compatibility between three codebases that all speak the Second Life protocol could be categorized as interoperability.

>linden's motivation for participating in an IETF process is to continue
>to develop this protocol in a forum where we get maximal involvement
>from the internet community.
>
>f. HyperGrid is pretty darn'd cool, IMHO. and there's nothing in it that
>would eliminate it from consideration by this group. I believe John
>Hurliman is trying to define it in draft form to be considered at the
>upcoming face to face in san francisco. even if we don't have a HG draft
>for that meeting, i am confident it will attract considerable attention
>on the mailing list, and honestly, we're months (if not years) away from
>turning any internet drafts into RFCs.

I don't know where you got the idea that I'm creating a HyperGrid proposal, but I don't think anyone is pretending that merging two administrative domains with some clever backend coding is interoperability. See my post at http://software.intel.com/en-us/blogs/2009/02/18/approaching-virtual-world-interoperability/ for the longer explanation of why OGP and HyperGrid are the same solution with different default settings, and why neither actually address interoperability.

>* we're NOT blessing Second Life's existing protocol as an official

That's not the question anyone is asking. The important question is: "Is the scope of MMOX limited to OGP, or mandating the discussion of OGP? Are virtual world interoperability proposals that are not compatible with OGP outside of the scope of MMOX?" We can either stop talking about MMOX as a working group for OGP, or put it in writing that that's the case and people who are not interested in OGP can save themselves the trouble.

> ...

---

From: David W Levine <[email-masked]>
Date: Thu, 19 Feb 2009 16:15:50 -0500

[email-masked] wrote on 02/19/2009 03:36:38 PM:

John Hurliman wrote: 
> That's not the question anyone is asking. The important question is:
> "Is the scope of MMOX limited to OGP, or mandating the discussion of
> OGP? Are virtual world interoperability proposals that are not 
> compatible with OGP outside of the scope of MMOX?" We can either 
> stop talking about MMOX as a working group for OGP, or put it in 
> writing that that's the case and people who are not interested in 
> OGP can save themselves the trouble.

This is a BOF with the explicit purpose of working towards a charter which 
answers that question.
There is no charter, nor formal scope at the moment. That said.... 

The goal is an open process, with propels bringing proposals. Linden Lab 
has brought the OGP work
and some ancillary documents to the table. They represent one place to 
mine for understanding of what we need.
Croquet, (and more specifically, in many ways, QWAQ) offer a very 
different starting point. Collada has a huge amount
of material about edge of system import/export models. Jon Watte, from 
Forterra brings another set of perspectives. The OpenSim community clearly 
has insight based on working within the broad "Second Life" model, as do 
other virtual world vendors. Our goal is not to constrain input, but to 
encourage it. 

I have a much longer post forthcoming trying to frame my sense of what it 
means to do a broad standard in the space, but let me be very clear. I 
don't think MMOX is about taking any one input and enshrining it as a 
standard.  The BOF is, specifically about sorting out a charter and a 
shared vision of what we can productively do. If anyone is saying MMOX is 
about turning OGP into an IETF standard, they are confused. The OGP work, 
represents one concrete input into the process.

The whole point of a BOF, and getting people together is to get a broad 
set of inputs, and participants. At the same time, there is a need to 
avoid "boiling the ocean" and pick off concrete, low hanging fruit we can 
work on within a broader context we define. The BOF won't be about doing 
that work, the BOF will be about creating a shared sense of the scope  of 
the work, and working towards a charter with language that describes that 
shared goal. 

Note that in general, the IETF approach is to use face to face 
opportunities to bash out hard issues, and the mailing list and off line 
discussion between face to face meetings to drive details, get concrete 
proposals together and figure out both areas of consensus and difference. 
The current discussion, about what is in scope, and what is not, seems 
exactly right to help us have a productive BOF and capture some good 
language to seed the charter discussion. 

- David W. Levine 
~ Zha Ewry (ISL)

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 13:42:52 -0800

Morgaine wrote:
> instantaneous travel, and teleport between grids is simply 
> instantaneous travel between worlds in different organizational 
> domains.  How can it possibly be uninteresting and give little value 
> to travel to distant places in virtual space?  ;-)
>
> I expect that you meant something /completely/ different to the 
> above.  :-)   Are we hitting an ambiguity in terminology of some kind 
> here?

Let's think about this: I'm in my office. I'm connected to the office 
virtual world, where we do training, collaboration, meetings, etc. I 
have my office buddy list, I have my office document server, my office 
system conforms to all regulatory compliance necessary for my particular 
line of business (Sarbanes-Oxley, Freedom of Information Act, Clean Food 
Act or what have you). Maybe my system ties into corporate phone and 
video conferencing systems, too, allowing someone on a cell phone to 
participate in meetings, audio-only.

Now, my buddy who uses Qwaq web forums and I want to meet. If my client 
were to disconnect from my office system, and re-connect to his Qwaq 
system, I'm suddenly losing all of the features provided by the office 
system, and my communication is now subject to his regulatory compliance 
(or not). This, in itself, is a non-starter for many larger 
organizations. But it doesn't end there!

Because the Qwaq system is not connected to my "home" system, I can't 
have a sales guy out in the field call into this meeting using a cell 
phone, because the user I'm visiting doesn't have a cell phone gateway 
on his system. Or, if he did, the sales guy would have to hang up and 
dial another number, just because I teleported away.

What if I have an interactive object I want to use? Qwaq can only run 
objects written to their API, which is largely Python. If mine is 
written for Wonderland, in Java, then the object won't work once I've 
re-connected my client to his system. That would be sad.

What UI do I get when I'm connected to the Qwaq system? Should my client 
suddenly understand arbitrary UI systems from arbitrary providers? Do I 
have to learn a new UI for each system I want to connect to? Do you want 
to standardize the UI used by all clients of all systems?

Interoperating between the back-end systems, at the semantic level, 
nicely side-steps most of these problems. In fact, each back-end system 
becomes a virtual world service provider much like an e-mail provider 
like GMail provides your e-mail service. Once you learn the capabilities 
of your given VWSP, you can use that interface and those capabilities no 
matter whom you visit.

Note that visiting other people is still totally supported -- but, using 
this model, you get more capabilities, and the makers of virtual world 
software have to do less work, and agree on a smaller set of standard 
protocols. In my view, that's the only model that could end up working 
out well.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 13:48:40 -0800

> capable of calling the right event handler.

You're assuming that every virtual world that wants to interoperate will 
use the Second Life scripting language, with the Second Life event 
model. This is not unlike how VRML was specified. It didn't work out so 
well :-)

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 13:59:16 -0800

I disagree. See below:

> simulate, but try to extrapolate from there to see where it leads.  If 
> your organization A has N users, and those N users wish to take part 
> in N different worlds (which is asymptotically likely if N << total 
> number of worlds), then your organization A must now simulate N 
> different worlds.  For large N, this places a colossal load on 
> populated.  To coin a common phrase by analogy, you're undertaking to 
> "simulate the Internet". ;-)
>

Not at all. Note that the actual simulation of each object happens on 
the "home" sim server of that object. Only telemetry is sent to other 
servers. I'm assuming forwarding telemetry is "cheap" whereas simulation 
of objects is "expensive" -- previous technical history shows that that 
is true. Thus, a virtual world service provider will undertake to 
provide simulation capacity for a user and N objects, and that's how 
many objects the user can put into the world. Some servers might be on 
an "all you can eat, and damn the lag" plan; others may be very metered 
and charge by the CPU-second. That is all up to policy, not mechanism.

If people from 8 different virtual world service providers meet in one 
physical space ("my room"), then there will be 8 copies of "my room" 
temporarily running on the greater internet, but each of those copies 
just simulate one user in that room. The cost of physical space ("my 
room") is very cheap, compared to the cost of managing an active, 
simulated user. Each server will connect to 7 peer servers, and send the 
telemetry data for the one user it simulates, and receive interactions 
from those 7 peers for things that affect that one user.

> users visit tomorrow will not necessarily be today's N worlds, so for 
> (N << total number of worlds) your local cache will need to grow 

Luckily, bandwidth between well connected servers is not a problem. You 
can purge the cache when it gets big, and just pull down the asset when 
you need it. Compare to YouTube, or MSN, or any other large service 
provider. That's not a problem.

> they still couldn't do it, because in the general case the simulation 
> code for a given world will not be available.  The world simulation is 
> the "secret sauce" of many virtual worlds, and from a business 
> perspective it is quite likely to be their product differentiator and 
> they will be loathe to share it.  But even if it were freely 
> available, the portability of one organization's simulation code to 
> another organization's machinery is far from guaranteed with today's 
> software technology, not to mention the management of upgrades for 
> something this complex across organization boundaries.
>

My proposal specifically says that simulation code stays on the home 
server, and only interactions (the "result" of simulation) is shared to 
other servers. I agree that no other system can work.

> Foreign world simulations never need to be supported.
>

I agree! If you think my proposal requires that, I don't understand how 
that came across. Could you find the part where you thought I was 
suggesting that and point it out, so I could clarify it?

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 14:15:02 -0800

Morgaine wrote:
> However, if that's the case then I don't understand the point being 
> made, because shared-spaces seems to be a "teleport only" 
> architecture.  The only means by which a user can go from one shared 
> space to another is by teleport, since shared spaces do not have 
> topological relationships to each other, from your description.
>

They may or may not -- that's up to each hosting system. If the hosting 
system has the geometry for the Earth as its reference, then I get to 
Paris from London by swimming, and then walking. If it turns out that 
only the Eiffel Tower observation deck is currently being shared to 
another system, then only when I'm in that part would I be visible to 
outside users.

Clearly, you can't enforce a single topology for all systems, but you 
still want to allow users of one system to be able to interact with 
people in other systems, even if they have different topologies, so I 
think topology has to be system dependent, and not specifically part of 
the specification (other than as used to identify the shared coordinate 
space to use for the session).

> If you ignore the local simulation for a moment, then what happens 
> when one of your users changes from one local shared space to one 
> belonging to a different provider is very similar in implementation to 
> the usual separate worlds case:  the agent appears in the space at the 
> remote end.   Adding a local simulation on top of that doesn't really 
> change the matter.  That's teleport between grids, plus a local 
> accelerator.
>
> And perceptually from the users' perspective, the model suggests that 
> they too see a teleport occurring every time that they change their 
> shared space to one operated by a different world provider.  This 
> looks like perfectly ordinary "teleport between grids" to them too.

The difference starts after that. How can you make sure that the 
features and user interface that the local user is used to, is still 
available after going into the other space? How can you make sure that 
objects that the local user own can be used while in the other space? 
How can you avoid having to dictate both user interface and simulation 
language for any participating system?

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 14:36:29 -0800

> * we're about interoperability between current or near future 

Implementations of what? OLIVE has a gateway in use by various customers 
since 2005. It uses DIS, HLA, and a variety of other protocols, 
depending on what system it's talking to. I'd be happy to talk more 
about that system, and how that can grow. It's a currently implemented 
system in commercial use, which seems like a good place to start.

Or do you want to use the Second Life system just because it's Second 
Life, even if it's not currently implemented or in current commercial use?

> * in other words, "we define mechanism, not policy."

That's like saying "E-mail exchange should be done using MIME encoded 
data on port 25" without specifying SMTP. That's neither interoperable 
nor vendor neutral.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 19 Feb 2009 16:12:16 -0800

On Feb 19, 2009, at 2:36 PM, Jon Watte wrote:

> Implementations of what? OLIVE has a gateway in use by various  
> customers since 2005. It uses DIS, HLA, and a variety of other  
> protocols, depending on what system it's talking to. I'd be happy to  
> talk more about that system, and how that can grow. It's a currently  
> implemented system in commercial use, which seems like a good place  
> to start.

DIS and HLA are "a bit complex" and were designed to provide services  
that were vaguely different from what we're aiming at here. I don't  
think we're interested in simulating just a battlefield of tanks. i  
think what we're thinking about is a wire protocol that does not carry  
a specific semantic load and is less declarative and more  
proscriptive. that is to say.. DIS and HLA appear to be useful mostly  
to the degree that they allow different defense contractors to specify  
conceptual interfaces between components in an augmented reality  
training simulation @ the NTC. While I like the idea of extending DIS,  
HLA and IEEE-1278 to include PDU family for avatar dance animations,  
flexi hair attachments, manticore attacks and controlling attack ships  
off the shoulder of orion, creating such a catalog of PDU families  
would be pretty time consuming by itself.

> Or do you want to use the Second Life system just because it's  
> Second Life, even if it's not currently implemented or in current  
> commercial use?

again.

we are not proposing the existing second life protocol for  
standardization. i think we've said that several times.

we would like to develop a protocol or protocol framework that is  
"widely usable."

>> * it's entirely possible application developers using MMOX  
>> protocols would need to define an "interoperability profile," which  
>> defines how MMOX applies to their application.
> That's like saying "E-mail exchange should be done using MIME  
> encoded data on port 25" without specifying SMTP. That's neither  
> interoperable nor vendor neutral.

i think you have it backwards. in the RFC1822 context, defining  
mechanism but not policy would mean... you define things like

	* an protocol interaction begins with a HELO message
	* you MAY include extended authentication messages
	* you then use MAIL FROM: and RCPT TO: to declare the sender and  
receiver of a message
	* assuming there are no errors, use DATA to declare the start of  
message
	* messages begin with headers, then the body of the message, careful  
using periods or the word "From" at the beginnings of lines
	* etc., etc.

then the policy, which would include constraints on its use would be  
something like...

	* WE like to receive SMTP traffic on port 25 of the machine listed in  
the MX record of our root domain.
	* there's this thing called MIME, if you're a client, you'll probably  
want to understand the concept of a MIME type

i think there is a long history of using SMTP and MIME in a vendor  
neutral and interoperable fashion.

-cheers
-meadhbh

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 20 Feb 2009 09:13:44 +0900

boiling this down...

Each user has own server that has the "room" layout imported from the
materia services,
  and lets the user client render it...

any *changes* that occur by one or more people are forwarded to the
other copies,
  and incoming changes are applied as they arrive.

I can see a "generic core" platform requirement here...

a triple server for core functionality...

1: Identity Authentication and by extension "permissions",
  recognising the individual and recognising groups.

2: Location, Location, Location.
  Recognising the boundary of a server showing a region where 1 or more
  Identities may be "present"
  Recognising non-Identity "Objects"

3: Representation of Objects,
  Everything is presented as a 3d object or group of objects
(object-linking)
  (an AV is simply an object group with an Identity attached)
  (bots in this case become independent of client operations and can run
entirely on-system)

and there is 2 requirements I can see for "inter operability".

Allowance of "presence" based on cross-connect agreement between any 2
systems,
  with a "representation" object able to be mapped into the hosting
system you are visiting.

for those that are reading this...

Im not considering the AV or anything "in the virtual world" as special
case

it is either a fixed part of the location (location physical map) or 
 an independent object within the space on the server providing
"location".

Identity is provided by the service the client logs into,

and Interoperability in this case becomes the capability to "visit" a
non-home location,

similar to leaving the house and going to the mall or further travel in
the real world.

where the object can be represented is upto the allowed complexity
during transfer

Does anyone have any questions about this or do I need to clarify this
further? 

Because I am also taking into account that any given system is not going
to share
  all content (who says that any object is going to be able to cross any
boundary?)

I began the above by trying to think of the lowest common denominator on
any given
  service from the user view and simplify by occams razor further.

the only other item to account for is some kind of messaging between
systems.

and I do hope that both emulation of non-native AND conversion of data
options
 are both avoided where possible (each comes with unwanted occurences)
  non-native emulation would result in needing a proxy+plugin mechanism
 for allowing a native server to be launched on the localhost and a
plugin
 for systemA systemB conversion (data-loss due to communications?)

---

From: Jesrad <[email-masked]>
Date: Fri, 20 Feb 2009 11:39:17 +0100

> You're assuming that every virtual world that wants to interoperate will use
> the Second Life scripting language, with the Second Life event model. This
> is not unlike how VRML was specified. It didn't work out so well :-)

That's not exactly what I meant: I'm saying that ANY interoperability
between various VMs used for acting out the behaviour of a given VW
object will require at least some uniformity, be it at the user
interface or the simulator interface. Either the simulator software
translates its native user inputs into compatible RPC for the target
script and converts its return values, or the client does (with the
grid then merely transporting the data in a uniform way).

Or so I think.

On Thu, Feb 19, 2009 at 10:48 PM, Jon Watte <[email-masked]> wrote:
> You're assuming that every virtual world that wants to interoperate will use
> the Second Life scripting language, with the Second Life event model. This
> is not unlike how VRML was specified. It didn't work out so well :-)
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Fri, 20 Feb 2009 11:59:01 -0800

Meadhbh Hamrick (Infinity) wrote:
> proscriptive. that is to say.. DIS

Agreed. That's why I think that the final solution will not be strictly 
based on DIS (and clearly not on HLA). However, I mention these 
protocols, because DIS has been extremely successful, and solves pretty 
much the same problem we're trying to solve, but in a narrower scope. 
Meanwhile, HLA has had a rocky history trying to solve the same problem; 
largely exactly /because /it is "mechanism, not policy" (or, in your 
words, proscriptive, not declarative). In HLA, you can theoretically 
support a number of object models (known as FOMs). This leads to virutal 
systems that are supposedly interoperable, not actually being able to 
interoperate, because semantics were left as an exercise for the reader.

I think that learning from this past is crucial for any future virutal 
worlds standards effort.

> we would like to develop a protocol or protocol framework that is 

Me too! However, a number of people on this list have said that they 
believe the forums' goal is to standardize OGP and LLSD. I'd like 
everyone to agree that that's *not* the goal, and then stop talking 
about it.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 20 Feb 2009 15:01:59 -0800

Well, I can contribute a number of protocols that are also in widespread 
use. However, I don't think that would be useful, because any protocol 
that assumes too much about the source architecture will necessarily be 
improperly slanted, or too watered down to be useful for anything real.

Maybe it hasn't been clear, but every proposal I have made here has not 
been based on how OLIVE works (I could happily describe that, too, but I 
don't think most other systems would accept our internal model as "the" 
standard). My proposals have all been made based on my experience 
integrating a variety of systems, and being involved in the innards of 
several multiplayer online systems (be they games or other things). I 
believe that that's the right approach to take: Look at what the 
industry at large is doing, where it's going, and design based on that. 
Starting with one particular technology is, I think, a mistake -- but if 
that's what we want to do, please let me write up the OLIVE TVP protocol 
and propose that as an alternative protocol for discussion. It certainly 
has a lot of attractive qualities, like doing time sync, being 
bit-packed, being input-synchronous (and thus 10 to 100 times as compact 
as state-based protocols), etc.

I believe there are two ways to go

1) Look at OGP and LLSD, and/or other existing protocols that have been 
or will be suggested, and then suggest removal of anything that's not 
applicable/appropriate, and suggest addition of anything that seems 
necessry.

2) Actually start out with the core principles: what are we trying to 
standardize? Then look for appropriate protocols, if they exist, or 
design new ones, if they don't.

I believe OGP and LLSD may be a fine match for the Linden Labs / Second 
Life AWG, but from experience I think they are very poor matches to a 
wider VW interoperability field.

Sincerely,

jw

Charles Krinke wrote:
> Well, since the draft proposal is for OGP and LLSD, it seems unlikely 
> that we would stop talking about either.
>
> In fact, I would like to know more about OGP and LLSD on this list as 
> we move forward in trying to standardize some protocols that are in 
> wide spread use.
>
> Charles
>
> ------------------------------------------------------------------------
> *From:* Jon Watte <[email-masked]>
> *To:* Meadhbh Hamrick (Infinity) <[email-masked]>
> *Cc:* Charles Krinke <[email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Friday, February 20, 2009 11:59:01 AM
> *Subject:* Learning from the past; focusing on the future
>
> > DIS and HLA are "a bit complex" and were designed to provide 
> services that were vaguely different from what we're aiming at here. I 
> don't think we're interested in simulating just a battlefield of 
> tanks. i think what we're thinking about is a wire protocol that does 
> not carry a specific semantic load and is less declarative and more 
> Agreed. That's why I think that the final solution will not be 
> strictly based on DIS (and clearly not on HLA). However, I mention 
> these protocols, because DIS has been extremely successful, and solves 
> pretty much the same problem we're trying to solve, but in a narrower 
> scope. Meanwhile, HLA has had a rocky history trying to solve the same 
> problem; largely exactly /because /it is "mechanism, not policy" (or, 
> in your words, proscriptive, not declarative). In HLA, you can 
> theoretically support a number of object models (known as FOMs). This 
> leads to virutal systems that are supposedly interoperable, not 
> actually being able to interoperate, because semantics were left as an 
> exercise for the reader.
>

---

From: Jon Watte <[email-masked]>
Date: Fri, 20 Feb 2009 17:00:16 -0800

Charles Krinke wrote:
> Well, are we going to find that each virtual world is unwilling accept 
> any of any other virtual worlds technical decisions? Unfortunately, 
> that is the impression I get from this.
>
> This reminds me of the Beta vs VHS history. Beta was argued to be the 
> technically superior technology (and it actually was), but so many 
> folks adopted the VHS technology that Beta faded into obscurity. The 
> point being that the superior technology is trumped by the market's 
> adoption of any particular technology.
>
> So, we can spend our time arguing that *our* technology is the 
> *superior* one and never give an inch. Or, alternatively, we can 
> figure out some way to work together.

Great points!

I have never intended that the OLIVE base technology be the basis for 
interoperability. Instead, I have over several years done a fairly large 
survey of various virtual world technologies, and of what's worked 
before, to come up with a "common denominator" type approach to how 
virtual world interoperability can actually be made to work. This is a 
design from first principles, if you will. That is what I'm arguing for 
here.

By contrast, OGP seems like it is a mixture of things that came out from 
the SL AWG, motivated by what was easier to implement on top of existing 
SL-specific technology, plus removing specificity in certain cases, 
which leads to a protocol that is both not a good "common denominator" 
for the entire industry, and not declarative enough to enable "from 
scratch" interoperability by just reading the protocol specification and 
implementing it. That's what I have against it -- merits, not sources.

Here are a few ground rules that I have come to conclude will be 
necessary for wide acceptance:

- User identity is provided by an identity provider, which may be the 
"home" world of the user, or some other provider. Users should not need 
identity tied to the specific world they want to visit. Some worlds may 
choose to not accept certain specific credentials, just like certain 
real-world stores may not accept Candian dollars for payment. The market 
will work out a few major credential systems in the end (such as OpenID, 
perhaps). As long as each system is accessed uniformly, the specifics of 
the back end don't matter.

- Geometry is based on regular meshes, possibly with LOD switches and 
lower-resolution physics meshes/proxies/hulls. I understand that this 
may be a sticking point for the SL-derived worlds (or do they actually 
support arbitrary meshes as an option now? I haven't kept up.)

- Texturing is based on a regular Phong model with various defined 
texture maps (because HLSL vs GLSL vs some-other-SL are each of them not 
suitable on their own). Turns out, once you have the possibility of 
gloss maps, normal maps, emission maps, opacity maps, diffuse maps and 
ambient maps, you have 90% of the "look" of any one technology, which is 
about as good as you can hope for through interoperability.

- Telemetry (entity movement) needs to be sent on a 
position/orientation/velocity basis, with dead reckoning. Delta 
compression and lower update rates can be used to keep bandwidth usage 
in check. This is a big difference for OLIVE, because we are 
input-synchronous, similar to City of Heroes or Age of Empires. However, 
again, this is the common denominator and experience speaking.

- Animating objects need to use a common, widespread interchange format, 
using named animation clips and skeletal animation. Morph deformation is 
likely too big a payload to make sense, at least in the early stages. 
COLLADA is a good format for this, but there are other possibilities 
(FBX, X3D and X come to mind). I think that making at least one format 
required is a good idea, because that ensures a minimum level of 
interoperability is always present.

- Simulation and script execution for a given object needs to be done on 
the "home" system for that object, because objects may be constructed 
assuming wildly disparate execution environments (X3D with JavaScript; 
Prims with SL Script, C++ with XML, Java with JSR 184, etc).

- Objects need to be marked up with simple, well defined possible 
interactions, so that a user interface can be generated on each client 
based on those interactions. Interactions are typically "set this 
property to this value" or "execute this command." Such interactions 
need to be forwarded to the server that runs the object in question. 
Similarly, specific interactions ("emote animation," "collision," 
"damage," "two-party animation," "flight" etc) need to be defined.

- Non-time-critical requests should go over HTTP and/or HTTPS, using 
XML-RPC or a similarly well understood protocol.

- Time-critical and high-bandwidth data (such as entity telemetry and 
user inputs) should be sent using explicit (separate) schema, and binary 
representation, for the same reason that we don't send streaming video 
as XML, or mark each pixel with a color space identifier.

Note that the majority of those ground rules are actually not how OLIVE 
(or Second Life, or Kaneva, or any one other system) works internally. 
That's fine -- these rules are designed to be as easy as possible to 
translate to each participating system, while still being rich enough to 
provide useful interoperability.

Now, I would appreciate it if we could take these points, and argue the 
necessity or not of each of the points, with concrete examples that each 
apply to at least two world technologies. Similarly, if I have somehow 
mis-understood something, and OGP actually provides for all of these 
points, I'd like to be made aware of what my misunderstandings are so I 
can correct them!

Sincerely,

jw

---

From: Ann Otoole <[email-masked]>
Date: Fri, 20 Feb 2009 17:25:32 -0800 (PST)

ODBC works for databases. (yes some of you cringed at the sight of that acronym but it does serve the example purpose)
ODBC was the reason I was able to construct a heterogeneous database hub in a simplistic manner that did not cause any of the target databases to have to support anything beyond a connection with the rights necessary to collect the data required at the time it was required. Therefore I was able to build the hub in a manner that did not cause any additional cost overhead by the various database teams. Oracle, SQL Server, Informix, DB2, and even some wretched access data file "databases" were supported simultaneously.

Why can't (or wouldn't) there be the necessary adapter/plug in approach used that accommodates the portions a world can accommodate? If your world will support OLIVE, Croqet, and SL then your world's equivalent of a presence system has those adapters a client can connect to on their respective ports. If all worlds are to be supported then all plugins are availableon a respective port. This approach allows for newer or as yet undiscovered "worlds" to become part of the universe if they develop the necessary open grid data connectivity adapter.

Jon's list goes beyond what might be required for a data transmission format standard since once the necessary data is transferred to render then, as Jon pointed out, the positional data streaming uses a different format which also needs to be defined. If a data conversion adapter strategy is used then how a client renders is irrelevant if the data for rendering has been converted to the local rendering system's requirements. Once in then the local world's rules apply as far as everything else goes. The scripting aspect is interesting in all this. A question begging for attention is poorly writtten scripts and whether or not you even want them entering your world space. Thus why my first contribution to the list suggested use of real meshes and supporting texture bakes and absence of any SL style attachments.

So Jon's list is a good start for hammering out data translation schemas. 
This is actually where mailing lists start to be a bummer since we can't actually "see" the various avatar entity skeletons and their differences in a common medium. 
I'm not sure every world will open source their systems so we can even see this information for all worlds either.

________________________________
From: Jon Watte <[email-masked]>
To: Charles Krinke <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Friday, February 20, 2009 8:00:16 PM
Subject: Re: [mmox] Learning from the past; focusing on the future

Charles Krinke wrote:
> Well, are we going to find that each virtual world is unwilling accept any of any other virtual worlds technical decisions? Unfortunately, that is the impression I get from this.
> 
> This reminds me of the Beta vs VHS history. Beta was argued to be the technically superior technology (and it actually was), but so many folks adopted the VHS technology that Beta faded into obscurity. The point being that the superior technology is trumped by the market's adoption of any particular technology.
> 
> So, we can spend our time arguing that *our* technology is the *superior* one and never give an inch. Or, alternatively, we can figure out some way to work together.

Great points!

I have never intended that the OLIVE base technology be the basis for interoperability. Instead, I have over several years done a fairly large survey of various virtual world technologies, and of what's worked before, to come up with a "common denominator" type approach to how virtual world interoperability can actually be made to work. This is a design from first principles, if you will. That is what I'm arguing for here.

By contrast, OGP seems like it is a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology, plus removing specificity in certain cases, which leads to a protocol that is both not a good "common denominator" for the entire industry, and not declarative enough to enable "from scratch" interoperability by just reading the protocol specification and implementing it. That's what I have against it -- merits, not sources.

Here are a few ground rules that I have come to conclude will be necessary for wide acceptance:

- User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter.

- Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.)

- Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability.

- Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking.

- Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present.

- Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc).

- Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined.

- Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol.

- Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier.

Note that the majority of those ground rules are actually not how OLIVE (or Second Life, or Kaneva, or any one other system) works internally. That's fine -- these rules are designed to be as easy as possible to translate to each participating system, while still being rich enough to provide useful interoperability.

Now, I would appreciate it if we could take these points, and argue the necessity or not of each of the points, with concrete examples that each apply to at least two world technologies. Similarly, if I have somehow mis-understood something, and OGP actually provides for all of these points, I'd like to be made aware of what my misunderstandings are so I can correct them!

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Fri, 20 Feb 2009 18:00:20 -0800 (PST)

Well, I think the place we are at is that neither SecondLife, nor OpenSim, nor Fortrerra is likely to substantially change their sim architecture. In this particular case, OpenSim is using OGP and is using HyperGrid. Both work. Both are continuing to be developed. So this is not a theoretical discussion, but rather both are actual implementations which are deployed.

So, to me, the debate about creating a new architecture is somewhat moot.

I would say the way we can make progress is to accept that we all have ongoing projects and see if there is a way to define a charter for this working group to define interop between existing architectures (and future architectures) as we move forward.

As I look at this whole thing, my hope for it is see a minimal number of changes to our client<->sim communication in order to keep compatibility with SecondLife and hopefully add interop compatibility with Croquet, Wonderland, perhaps Fortrerra, and others.

Charles Krinke

________________________________
From: Jon Watte <[email-masked]>
To: Charles Krinke <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Friday, February 20, 2009 5:00:16 PM
Subject: Re: Learning from the past; focusing on the future

Great points!

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 20 Feb 2009 21:59:53 -0800

Charles Krinke wrote:
> Well, I think the place we are at is that neither SecondLife, nor 
> OpenSim, nor Fortrerra is likely to substantially change their sim 
> architecture.

Agreed. The internal architecture of each system won't likely change.

> In this particular case, OpenSim is using OGP and is using HyperGrid. 
> Both work. Both are continuing to be developed. So this is not a 
> theoretical discussion, but rather both are actual implementations 
> which are deployed.
>

Right; let's just all use the Forterra architecture.

No, wait, that doesn't make sense, because implementing the Forterra 
architecture is a lot of work for everyone else. Let's all use the 
Multiverse architecture!
Ah, but that doesn't make sense, because implementing the Multiverse 
architecture is a lot of work for everyone not Multiverse.

Do you see where I'm getting at? While you can interoperate with other 
technologies based on the original Second Life design, you're not going 
to be able to interoperate with any other system if that's the direction 
you choose. (I would like to point out that the charter for the group 
says that it is explicitly about designing a new protocol, not rubber 
stamping any existing approach).

Like it or not, a "common denominator" approach that picks the overall 
easiest implementation (i e, min(sum(map(implementation_cost, 
everyone)))) is most likely to prevail (in the greater world, as opposed 
to the narrower Second Life derived subculture).

> I would say the way we can make progress is to accept that we all have 
> ongoing projects and see if there is a way to define a charter for 
> this working group to define interop between existing architectures 
> (and future architectures) as we move forward.
>
> As I look at this whole thing, my hope for it is see a minimal number 
> of changes to our client<->sim communication in order to keep 
> compatibility with SecondLife and hopefully add interop compatibility 
> with Croquet, Wonderland, perhaps Fortrerra, and others.

In my proposal, there is zero, or close to zero, change in client <-> 
sim communication, because the interop happens through gateways between 
sims. And I'm convinced that sims need to talk to sims, because that's 
the only way that objects with behaviors can be simulated in a way that 
every other object with behaviors can be cognizant of the object in the 
environment.

So, given the points that I enumerated, it would be useful if you could 
enumerate what your opinion is on each point:

This is a concrete set of ground rules, that I propose we adapt as 
guiding principles. If you want to reject some or all of the rules, then 
I'd like to hear specific arguments (I believe that I've mostly included 
the arguments /for/ the rules in the rule descriptions themselves).

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sat, 21 Feb 2009 07:49:18 +0000

> Not at all. Note that the actual simulation of each object happens on the
> "home" sim server of that object. Only telemetry is sent to other servers.

Aha! :-)  Good, I badly misunderstood your previous description, sorry:
clearly the idea of simulating all the other worlds with which your users
interact would be a non-starter on many grounds, so I'm glad to hear that
those simulations are left to the remote systems.

But notice that since your local system sensibly does not perform a
simulation of the remote worlds in your local shared space, then the
"telemetry" that you are sending to those remote worlds is really very
similar to the data interchange in the model espoused by Linden Lab and
Opensim.  In their case, in-world objects belonging to one of their users
are forwarded to the remote grid currently being visited by that user, while
the user's client directly controls the more interactive aspects of avatar
presence.

You describe your system as follows:

> temporarily running on the greater internet, but each of those copies just
> simulate one user in that room. The cost of physical space ("my room") is
> very cheap, compared to the cost of managing an active, simulated user. Each
> server will connect to 7 peer servers, and send the telemetry data for the
> one user it simulates, and receive interactions from those 7 peers for
> things that affect that one user.
>
Hang on, there are no copies of your room simulated by those 7 other
providers:  you made that clear to avoid my point about local simulation not
being scalable --- those 7 other worlds would have to have access to your
own world simulation code to be able to simulate your room, since your room
is a different world to theirs and in the general case has its own special
rules and physics.

So what you must mean is not that your room is simulated by those other 7,
but that they send you their objects  (including their avatars) for you to
manage within your own room simulation (and you send them telemetry in
return), since they do not have access to your world simulation code.
Presumably the scheme is symmetrical, so that when you wish to join them in
one of their shared rooms, you have to send your avatar and objects there
too, since you do not have access to the world simulation code of their
rooms either.  Those objects they receive from you are then managed by them
within their own individual world simulations.   If so, that is exactly what
the Linden Lab and Opensim models do as well.

You've made it clear that the internal behaviour of the objects in your room
is always processed within the objects' home environment of your room (I
believe), so in LL/Opensim terminology this would mean that the "scripts" of
objects always execute in their home world.  In other words, any objects you
take with you when you visit remote shared rooms have internal behaviour
controlled by your home world but external behaviour controlled by the
remote world simulations.  You haven't described any internal/external
behaviour split that way, but it's a necessary conclusion given that you
also deny that everyone has to run everyone else's world simulation.

Apart from the local execution of object behaviours, which has not yet been
defined for SL/Opensim interop, this seems almost identical to their model.

If my analysis above is incorrect, then I'd most appreciate you shedding a
bit more light on the shared space paradigm, and how it would operate in a
metaverse with potentially unbounded virtual world simulation diversity.

Morgaine.

On Thu, Feb 19, 2009 at 9:59 PM, Jon Watte <[email-masked]> wrote:

> Not at all. Note that the actual simulation of each object happens on the
> "home" sim server of that object. Only telemetry is sent to other servers.
> I'm assuming forwarding telemetry is "cheap" whereas simulation of objects
> is "expensive" -- previous technical history shows that that is true. Thus,
> a virtual world service provider will undertake to provide simulation
> capacity for a user and N objects, and that's how many objects the user can
> put into the world. Some servers might be on an "all you can eat, and damn
> the lag" plan; others may be very metered and charge by the CPU-second. That
> is all up to policy, not mechanism.
>
> temporarily running on the greater internet, but each of those copies just
> simulate one user in that room. The cost of physical space ("my room") is
> very cheap, compared to the cost of managing an active, simulated user. Each
> server will connect to 7 peer servers, and send the telemetry data for the
> one user it simulates, and receive interactions from those 7 peers for
> things that affect that one user.
>
> Luckily, bandwidth between well connected servers is not a problem. You can
> purge the cache when it gets big, and just pull down the asset when you need
> it. Compare to YouTube, or MSN, or any other large service provider. That's
> not a problem.
>
> that came across. Could you find the part where you thought I was suggesting
> that and point it out, so I could clarify it?
>
> Sincerely,
>
> jw
>
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 00:13:52 -0800

um. jon. are we reading the same documents? there are no published OGP  
specs that cover most of the items you list below, so i'm wondering  
how you came to the conclusion that OGP is "a mixture of things that  
came out from the SL AWG, motivated by what was easier to implement on  
top of existing SL-specific technology." ?

On Feb 20, 2009, at 5:00 PM, Jon Watte wrote:

> Charles Krinke wrote:
>> Well, are we going to find that each virtual world is unwilling  
>> accept any of any other virtual worlds technical decisions?  
>> Unfortunately, that is the impression I get from this.
>>
>> This reminds me of the Beta vs VHS history. Beta was argued to be  
>> the technically superior technology (and it actually was), but so  
>> many folks adopted the VHS technology that Beta faded into  
>> obscurity. The point being that the superior technology is trumped  
>> by the market's adoption of any particular technology.
>>
> I have never intended that the OLIVE base technology be the basis  
> for interoperability. Instead, I have over several years done a  
> fairly large survey of various virtual world technologies, and of  
> what's worked before, to come up with a "common denominator" type  
> approach to how virtual world interoperability can actually be made  
> to work. This is a design from first principles, if you will. That  
> is what I'm arguing for here.
>
> By contrast, OGP seems like it is a mixture of things that came out  
> from the SL AWG, motivated by what was easier to implement on top of  
> existing SL-specific technology, plus removing specificity in  
> certain cases, which leads to a protocol that is both not a good  
> "common denominator" for the entire industry, and not declarative  
> enough to enable "from scratch" interoperability by just reading the  
> protocol specification and implementing it. That's what I have  
> against it -- merits, not sources.
>
>
> - User identity is provided by an identity provider, which may be  
> the "home" world of the user, or some other provider. Users should  
> not need identity tied to the specific world they want to visit.  
> Some worlds may choose to not accept certain specific credentials,  
> just like certain real-world stores may not accept Candian dollars  
> for payment. The market will work out a few major credential systems  
> in the end (such as OpenID, perhaps). As long as each system is  
> accessed uniformly, the specifics of the back end don't matter.
>
> - Geometry is based on regular meshes, possibly with LOD switches  
> and lower-resolution physics meshes/proxies/hulls. I understand that  
> this may be a sticking point for the SL-derived worlds (or do they  
> actually support arbitrary meshes as an option now? I haven't kept  
> up.)
>
> texture maps (because HLSL vs GLSL vs some-other-SL are each of them  
> not suitable on their own). Turns out, once you have the possibility  
> of gloss maps, normal maps, emission maps, opacity maps, diffuse  
> maps and ambient maps, you have 90% of the "look" of any one  
> technology, which is about as good as you can hope for through  
> interoperability.
>
> - Telemetry (entity movement) needs to be sent on a position/ 
> orientation/velocity basis, with dead reckoning. Delta compression  
> and lower update rates can be used to keep bandwidth usage in check.  
> This is a big difference for OLIVE, because we are input- 
> synchronous, similar to City of Heroes or Age of Empires. However,  
> - Animating objects need to use a common, widespread interchange  
> format, using named animation clips and skeletal animation. Morph  
> deformation is likely too big a payload to make sense, at least in  
> the early stages. COLLADA is a good format for this, but there are  
> other possibilities (FBX, X3D and X come to mind). I think that  
> making at least one format required is a good idea, because that  
> ensures a minimum level of interoperability is always present.
>
> - Simulation and script execution for a given object needs to be  
> done on the "home" system for that object, because objects may be  
> constructed assuming wildly disparate execution environments (X3D  
> with JavaScript; Prims with SL Script, C++ with XML, Java with JSR  
> 184, etc).
>
> interactions, so that a user interface can be generated on each  
> client based on those interactions. Interactions are typically "set  
> this property to this value" or "execute this command." Such  
> interactions need to be forwarded to the server that runs the object  
> in question. Similarly, specific interactions ("emote animation,"  
> "collision," "damage," "two-party animation," "flight" etc) need to  
> be defined.
>
> - Time-critical and high-bandwidth data (such as entity telemetry  
> and user inputs) should be sent using explicit (separate) schema,  
> and binary representation, for the same reason that we don't send  
> streaming video as XML, or mark each pixel with a color space  
> identifier.
>
>
> Note that the majority of those ground rules are actually not how  
> OLIVE (or Second Life, or Kaneva, or any one other system) works  
> internally. That's fine -- these rules are designed to be as easy as  
> possible to translate to each participating system, while still  
> being rich enough to provide useful interoperability.
>
> Now, I would appreciate it if we could take these points, and argue  
> the necessity or not of each of the points, with concrete examples  
> that each apply to at least two world technologies. Similarly, if I  
> have somehow mis-understood something, and OGP actually provides for  
> all of these points, I'd like to be made aware of what my  
> misunderstandings are so I can correct them!
>
> Sincerely,
>
> jw
>

---

From: Morgaine <[email-masked]>
Date: Sat, 21 Feb 2009 09:40:25 +0000

On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte <[email-masked]> wrote:

> lower-resolution physics meshes/proxies/hulls. I understand that this may be
> a sticking point for the SL-derived worlds (or do they actually support
> arbitrary meshes as an option now? I haven't kept up.)
>

We're defining mechanism, not policy, so there is no possible sticking point
for Linden Lab if the interop standard provides for interchange of meshes as
is so widely required.  LL are free to not implement meshes if they choose
not to do so, that's all.   I believe that such a decision would impact on
their business, but it is not up to me (nor us) to make that call.

By the same token, if we define interchange of SL-like "primitive" objects
to be in the standard, then anyone who wants to benefit from the
acceleration and standardized behaviour of such primitives is free to
implement them (the Opensim worlds certainly will), but nobody is
*required*to do so.

Mechanism, not policy.

Morgaine.

---

From: Morgaine <[email-masked]>
Date: Sat, 21 Feb 2009 15:04:58 +0000

> So, to me, the debate about creating a new architecture is somewhat moot.

Very moot. :-)

Indeed, it puzzles me why the debate has even arisen, since creating a new
architecture has not been proposed by anyone.  The draft charter has made it
clear that the goal is much simpler and less prescriptive, and very
vendor-neutral after some iterations.

As this issue of architecture keeps coming up, I'll just reiterate a
paragraph that I wrote for Jon which came out better than I expected.  It
shows the narrow but still helpful avenue we are pursuing towards interop,
devoid of any prescriptive implementations and certainly no new
architectures:

"*In my own words and very much off the cuff, we are defining a protocol
that allows entirely different virtual worlds to access and exchange data
objects that are meaningful across a large spectrum of world types.  This is
achieved by limiting the protocol to common concepts such as login (for
identity), location, teleport, travel, avatars, and messaging, as well as
offering an extensible set of common 3D objects as building blocks that can
be exchanged.  It is a strongly abstracted approach, as independent of
actual implementation details as we can make it, because there is no other
way to embrace the current diversity of worlds let alone the future one.*"

I don't think that I can improve on that.  But no doubt others can. ;-)

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 10:12:44 -0800

Ideally, every company from the following list of 11 should be represented:
http://cleverzebra.com/book/virtual-worlds/166

Note that the fact that we have users not involved in the actual 
technical work does not mean that that's the best structure for actual 
standards documents. Users are crucial when doing requirements gathering 
(which is what we're doing now), but once the "this bit goes there" work 
starts, I believe implementation considerations are going to weigh much 
heavier.

Sincerely,

jw

Charles Krinke wrote:
> It seems to me that we become more strong and useful by finding one or 
> more representatives from other virtual worlds. It appears to me that 
> we have a significant (and vocal) presence from LL, OpenSim and 
> Fortrerra. I believe we have an interested party from Croquet, 
> although I would like to hear more from the Croquet folks to 
> understand how interop can help them.
>
> We need to find a way to involve folks from Wonderland and Wow amongst 
> others. It doesnt matter if it is a representative from "Blizzard" so 
> much as at least one or two user representatives. After all, we have 
> user representatives from SecondLife and OpenSim on this channel, so 
> we have a precendent.
>
> So, how to we get some more virtual worlds into this furball so we can 
> discuss the group charter and find a way to "interop" a bit.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 10:45:29 -0800

Morgaine wrote:
>     If people from 8 different virtual world service providers meet in
>     one physical space ("my room"), then there will be 8 copies of "my
>     room" temporarily running on the greater internet, but each of
>     those copies just simulate one user in that room. The cost of
>     physical space ("my room") is very cheap, compared to the cost of
>     managing an active, simulated user. Each server will connect to 7
>     peer servers, and send the telemetry data for the one user it
>     simulates, and receive interactions from those 7 peers for things
>     that affect that one user.
>
> providers:  you made that clear to avoid my point about local 
> simulation not being scalable --- those 7 other worlds would have to 
> have access to your own world simulation code to be able to simulate 
> your room, since your room is a different world to theirs and in the 
> general case has its own special rules and physics.
>

Maybe it's a matter of nomenclature? There has to be a shared, 
registered (in the sense of "everyone agrees that the ground is at local 
height Z at this point") static world geometry. Everybody loads the same 
static world geometry. This is not "simulated," per se, as it just sits 
there as a big collision mesh. Things like wind strength and gravity and 
viscosity (for underwater scenes, say) needs to be agreed on (or 
accepted but ignored) by all the participants. This is why I believe 
that the proper model is that one system "hosts" the particular "room" 
(or area, or island, or planet) for a given interoperability scenario. 
That system provides the static geometry and parameters to the other 
systems on contact (or, more likely, references to the resources that 
make up those things).

This means that special physics; say a spherical harmonic description of 
localized gravity; won't affect other objects. A simulator could choose 
to send force interactions to the other (remote) objects if it wishes, 
but that would necessarily include some latency.

> So what you must mean is not that your room is simulated by those 
> other 7, but that they send you their objects  (including their 
> avatars) for you to manage within your own room simulation (and you 
> send them telemetry in return), since they do not have access to your 
> world simulation code.  Presumably the scheme is symmetrical, so that 
> when you wish to join them in one of their shared rooms, you have to 
> send your avatar and objects there too, since you do not have access 
> to the world simulation code of their rooms either.  Those objects 
> they receive from you are then managed by them within their own 
> individual world simulations.   If so, that is exactly what the Linden 
> Lab and Opensim models do as well.
>

I send telemetry and mesh/proxy information. I do not send behavior. 
Behavior is simulated only on the home world.

Additionally, the "host" for the system provides the static geometry and 
"ground rules" description. Each host does as well as it can with those 
rules. If some system doesn't implement gravity, then the entities from 
that host won't have gravity. Again, we want to get to the 90% case, 
without complicating things too much.

I think there is a bit of a communication gap here. An "object," to me, 
is the full monty: behavioral code, context within the simulation 
system, assets, user input, etc. That's not what gets sent. What gets 
sent is, perhaps, a "proxy."

> internal behaviour controlled by your home world but external 
> behaviour controlled by the remote world simulations.  You haven't 
> described any internal/external behaviour split that way, but it's a 
> necessary conclusion given that you also deny that everyone has to run 
> everyone else's world simulation.
>

The only external acts on "my" objects are those that get sent from the 
remote worlds using "interactions." "Interactions" are defined, and 
typically include "collision" or "force" or "user X triggered command Y" 
and perhaps "is set on fire" or "takes 20 points slashing damage" 
(clearly, different classes of systems need different supersets of 
defined interactions). Note that it's up to the home server to actually 
apply the interaction, or discard it, and to update the proxy objects 
that everyone else sees with the appropriate property changes on the object.

> If my analysis above is incorrect, then I'd most appreciate you 
> shedding a bit more light on the shared space paradigm, and how it 
> would operate in a metaverse with potentially unbounded virtual world 
> simulation diversity.

There will always be effects that are specific to a given world, and 
can't really be transported to everyone. For example, the Blue Mars 
people use the Far Cry engine, which gives them certain render 
capabilities that most other worlds don't have. In the interoperability 
scenario, those features will be missed for non-Blue-Mars participants. 
Similarly for simulation: the common core of gravity, wind and viscosity 
(as found in most physics simulation packages) will be shared and 
understood, whereas more esoteric features will either not be 
understood, or will be shared using lower-level defined interactions, 
rather than simulation code.

As technology moves on, and things that were "special" become 
"commonplace," those features will start becoming specified in 
extensions to the standard, and finally be folded into some later 
required core. That's how these things work in any other long-lived 
standard (B/W TV, followed by color TV, followed by closed captioning, 
followed by Stereo, ...).
Sometime in the distant future, we'll find that the entire model is no 
longer sufficient -- perhaps all computation is expressed in terms of 
JVM code, or the x86 with virtualization is the prevailing computing 
paradigm. At that point, we need a new standard -- just like 
digital/HDTV is finally replacing analog TV.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 10:50:30 -0800

Meadhbh Hamrick (Infinity) wrote:
> came out from the SL

Things like "Rez avatar" is SL specific -- how a particular user comes 
to life in a particular system is up to that system, not something that 
interoperability actually needs to concern itself with.

I also said "it doesn't specify enough," because all those things I 
enumerated, I believe have to be specified for useful interoperability 
to be achieved. More "SL-specific" parts are where the white space is 
filled in by something like OpenSim, using existing SL protocols.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 11:02:22 -0800

Morgaine wrote:
>
>
> On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     and lower-resolution physics meshes/proxies/hulls. I understand
>     that this may be a sticking point for the SL-derived worlds (or do
>     they actually support arbitrary meshes as an option now? I haven't
>     kept up.)
>
>
> We're defining mechanism, not policy, so there is no possible sticking 
> point for Linden Lab if the interop standard provides for interchange 
> of meshes as is so widely required.  LL are free to not implement 
> meshes if they choose not to do so, that's all.   I believe that such 
> a decision would impact on their business, but it is not up to me (nor 
> us) to make that call.
>
> By the same token, if we define interchange of SL-like "primitive" 
> objects to be in the standard, then anyone who wants to benefit from 
> the acceleration and standardized behaviour of such primitives is free 
> to implement them (the Opensim worlds certainly will), but nobody is 
> /required/ to do so.

I think that's taking too much policy out of the equation. We need to 
define a minimum policy that any interoperating world will accept, so 
that an interoperating system will actually work. Defining just empty 
pipes, and letting people fill them with whatever, doesn't lead us 
anywhere closer towards actual, useful, working interoperability.

Compare to MPEG 4: there are a few "profiles" defined, where any device 
that claims to support a given profile, knows that it can play back any 
content authored for that profile. And, this is important, there is a 
minimum profile that anything has to implement; if you want your content 
to be universally useful, then you author to that profile.

Personally, I believe that regular meshes with physics proxies are that 
minimum profile, because that most closely matches how most if not all 
of the distributed simulations in the world do things.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sat, 21 Feb 2009 20:18:01 +0000

On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte <[email-masked]> wrote:

> minimum profile, because that most closely matches how most if not all of
> the distributed simulations in the world do things.
>

I'm afraid we have to do better than that.  There is huge interest in what
we call Limited Capability Clients (*LCC*s), which are typically gadget-type
devices such as cellphones or PDAs used as virtual world clients, but they
could in principle be absolutely anything, even scripted objects within a
world itself.   These tiny clients only pick those parts of a virtual world
service that they need and no more --- indeed, quite often they could not
cope with more.

Support for such LCCs is important, both for flexibility and for
accessibility.  Typical use cases for LCCs are audio-only clients for
attending live concerts in-world without needing visual presence, or braille
clients for attending in-world textual lectures.  LCCs with hardware able to
display 3D visuals may choose to restrict download to only certain classes
of object to avoid overload (or just to save bandwidth costs), and disabling
meshes can easily be forseen as a requirement.

So no, there is no minimum profile.  This is one reason why LL/AWG took a
capability-based approach to resource access, potentially allowing clients
to pick and choose what is sent to them, although that work has not borne
fruit yet.  In our work here, we will have to take the needs of LCCs into
account as well.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Sat, 21 Feb 2009 12:31:11 -0800 (PST)

That is a very good point, Morgaine.

As we consider the notion of interop between virtual worlds, having each sim, region, grid or *whatever* be able to supply its capabilities or "CAPS" to use the LL notion to such LCC devices will certainly enhance the ability to use something like a cell-phone to have a limited prescence in SecondLife, OpenSim and others.

So, perhaps as we move forward, specifiying the login steps for virtual worlds in this working group along with the responses to build up the capabilities for a particular session could be very interesting.

What we need to do is specify those steps and capabilities and let the client and server negotiate a connection consistent with each capability that both the client and the server advertise to each other.

Those capabilities that are mutually agreed to, can be used for a client and a server in a particular virtual world. Those which are not agreed to between the client and the server, by definition, cannot be used.

Charles Krinke

________________________________
From: Morgaine <[email-masked]>
To: Jon Watte <[email-masked]>
Cc: Charles Krinke <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Saturday, February 21, 2009 12:18:01 PM
Subject: Re: [mmox] Learning from the past; focusing on the future

Personally, I believe that regular meshes with physics proxies are that minimum profile, because that most closely matches how most if not all of the distributed simulations in the world do things.

I'm afraid we have to do better than that.  There is huge interest in what we call Limited Capability Clients (LCCs), which are typically gadget-type devices such as cellphones or PDAs used as virtual world clients, but they could in principle be absolutely anything, even scripted objects within a world itself.   These tiny clients only pick those parts of a virtual world service that they need and no more --- indeed, quite often they could not cope with more.

Support for such LCCs is important, both for flexibility and for accessibility.  Typical use cases for LCCs are audio-only clients for attending live concerts in-world without needing visual presence, or braille clients for attending in-world textual lectures.  LCCs with hardware able to display 3D visuals may choose to restrict download to only certain classes of object to avoid overload (or just to save bandwidth costs), and disabling meshes can easily be forseen as a requirement.

So no, there is no minimum profile.  This is one reason why LL/AWG took a capability-based approach to resource access, potentially allowing clients to pick and choose what is sent to them, although that work has not borne fruit yet.  In our work here, we will have to take the needs of LCCs into account as well.

Morgaine.

---

From: Lawson English <[email-masked]>
Date: Sat, 21 Feb 2009 15:32:36 -0700

Jon Watte wrote:
>> We're defining mechanism, not policy, so there is no possible 
>> sticking point for Linden Lab if the interop standard provides for 
>> interchange of meshes as is so widely required.  LL are free to not 
>> implement meshes if they choose not to do so, that's all.   I believe 
>> that such a decision would impact on their business, but it is not up 
>> to me (nor us) to make that call.
>>
>> the acceleration and standardized behaviour of such primitives is 
>> free to implement them (the Opensim worlds certainly will), but 
>> nobody is /required/ to do so.
>
>
> Compare to MPEG 4: there are a few "profiles" defined, where any 
> device that claims to support a given profile, knows that it can play 
> back any content authored for that profile. And, this is important, 
> there is a minimum profile that anything has to implement; if you want 
> your content to be universally useful, then you author to that profile.
>
> Personally, I believe that regular meshes with physics proxies are 
> that minimum profile, because that most closely matches how most if 
> not all of the distributed simulations in the world do things.
>
> Sincerely,
>
> jw
>

"Most" by company count, but not necessarily by user count (unless you 
count the closed garden gameworlds) and certainly not by asset-count.  
There's more plywood boxes in SL than there are objects in the rest of 
the multiverse, I suspect.

L.

---

From: Charles Krinke <[email-masked]>
Date: Sat, 21 Feb 2009 14:56:11 -0800 (PST)

Yes, I would have to agree with you Lawson. But, perhaps in doing interop, we can have a capabilities message that defines whether the world one is teleporting to has mesh or prim capabilities. That would allow us to have a way to tailor the client and server performance a bit to accomodate the differences.

There are a considerable number of users in SecondLife and quite a few businesses using SecondLife, so the "prim" notion is not unreasonable for an interop protocol. However, as time goes on, it is also entirely reasonable that meshes may reign supreme.

Charles Krinke
OpenSim Core Developer
OSGrid Director

Sent: Saturday, February 21, 2009 2:32:36 PM

Jon Watte wrote:
> Morgaine wrote:
>> 
>> 
>> On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> We're defining mechanism, not policy, so there is no possible sticking point for Linden Lab if the interop standard provides for interchange of meshes as is so widely required.  LL are free to not implement meshes if they choose not to do so, that's all.   I believe that such a decision would impact on their business, but it is not up to me (nor us) to make that call.
>> 
>> By the same token, if we define interchange of SL-like "primitive" objects to be in the standard, then anyone who wants to benefit from the acceleration and standardized behaviour of such primitives is free to implement them (the Opensim worlds certainly will), but nobody is /required/ to do so.
> 
> 
> I think that's taking too much policy out of the equation. We need to define a minimum policy that any interoperating world will accept, so that an interoperating system will actually work. Defining just empty pipes, and letting people fill them with whatever, doesn't lead us anywhere closer towards actual, useful, working interoperability.
> 
> Compare to MPEG 4: there are a few "profiles" defined, where any device that claims to support a given profile, knows that it can play back any content authored for that profile. And, this is important, there is a minimum profile that anything has to implement; if you want your content to be universally useful, then you author to that profile.
> 

"Most" by company count, but not necessarily by user count (unless you count the closed garden gameworlds) and certainly not by asset-count.  There's more plywood boxes in SL than there are objects in the rest of the multiverse, I suspect.

L.

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 15:10:14 -0800

Morgaine wrote:
>
>
> On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte <[email-masked] 
>     that minimum profile, because that most closely matches how most
>     if not all of the distributed simulations in the world do things.
>
>
>
> I'm afraid we have to do better than that.  There is huge interest in 
> what we call Limited Capability Clients (*LCC*s), which are typically 
> gadget-type devices such as cellphones or PDAs used as virtual world 
> clients, but they could in principle be absolutely anything, even 
> scripted objects within a world itself.   These tiny clients only pick 
> those parts of a virtual world service that they need and no more --- 
> indeed, quite often they could not cope with more.
>

I knew this would come up, but I had to stop typing somewhere :-) I 
think it's fine for such clients to discard various kinds of data (or, 
rather, not request it), and for the services that serve those clients 
to synthesize something like an avatar for the more-capable clients they 
interact with.

What I explicitly, specifically, do not wish, is for something like the 
data geometry interchange format to be loosely specified along the lines 
of: "You can choose an aggregation of prims, OR you can choose a regular 
mesh -- either is fine." That would end up with world A doing only 
prims, and world B doing only geometry, and they not being able to 
interoperate, even though they both claim to support the 
interoperability standard.

Similarly, for voice chat, I think it is required that we say "you must 
support at least codec C, and may additionally support codecs X, Y or Z" 
-- else, again, you may find yourself not being able to "get there from 
here," even though the systems involved claim to be interoperable.

I want profiles to be there to guarantee a high level of "plug and 
play." In my opinion, it's fine to define "if you do geometry, you MUST 
do meshes, but you COULD also do prims." Theoretically, it could be the 
reverse, but given that 99% of the 3D technology on Earth is mesh based, 
that would be a bit of cart-before-the-horse if we're looking for 
"common ground" consensus.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Sat, 21 Feb 2009 16:15:47 -0700

Charles Krinke wrote:
> Yes, I would have to agree with you Lawson. But, perhaps in doing 
> interop, we can have a capabilities message that defines whether the 
> world one is teleporting to has mesh or prim capabilities. That would 
> allow us to have a way to tailor the client and server performance a 
> bit to accomodate the differences.
>
> There are a considerable number of users in SecondLife and quite a few 
> businesses using SecondLife, so the "prim" notion is not unreasonable 
> for an interop protocol. However, as time goes on, it is also entirely 
> reasonable that meshes may reign supreme.

My understanding is that prims save bandwidth, while meshes can be 
tailored to more efficiently use client-side resources. For a 
globe-trotting avatar that is constantly downloading new scenery, prims 
might be more efficient. For someone  who plans on staying mostly in one 
world, meshes probably win hands down (assuming an efficient caching 
system in the client) .

Lawson

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 16:19:05 -0800

Lawson English wrote:
> globe-trotting avatar that is constantly downloading new scenery, 
> prims might be more efficient. For someone  who plans on staying 
> mostly in one world, meshes probably win hands down (assuming an 
> efficient caching system in the client) .

Prims have their uses, sure -- for example, almost all pysics 
simulations use proxy shapes (similar to prims, if I understand prims 
right), rather than the actual mesh.

However, I would argue that 95% of all 3D content in the world (at large 
-- not just user generated content in a consumer-facing virtual world) 
is in the form of mesh data. All current 3D representation research is 
on how to generate meshes more effectively (from pictures, video, LIDAR 
data, etc), and how to code/transmit them more effectively. The only 
other format that comes close is good-old elevation data ("raster" or 
"heightmap" depending on where you're coming from).

 From what I understand, it's also reasonably easy to generate meshes 
from prim descriptions -- Second Life already does it, for display on 
the screen. Meanwhile, taking mesh data that exists and automatically 
generating prims out of that is intractable, so requiring that every 
interactive 3D system in the world do that is pretty much a non-starter.

For an example, something as simple as an arched doorway is fairly 
common in regular meshes, yet can't be simply described ingeneral convex 
prims (of course you could create an arbitrary set of prims, like 
"teapot," for arbitrary special cases, but that still loses the 
generality of meshes).

Or, to formulate it in a more direct way: Either the Second Life 
platforms have to add a way to display and transmit meshes (if it's not 
already there), OR the rest of the world has to add a way to 
automatically generate prims from existing meshes. One of those problems 
is a lot easier to solve than the other. I think requiring 
implementation of a generally unsolved research problems in an 
interoperability standard is unwise.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Sat, 21 Feb 2009 16:30:56 -0800 (PST)

I disagree. There is no reason for this to be either or. We certainly can make an interop spec that contemplates "prims", "meshes" or other geometric notions. 

As I see this situation evolving, there will be a number fields in negotiating capabilities between a client and a server in teleporting from one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other physics engines are another. Scripting engines are a third.

There will be a number of "world specific" capabilities that need to be negotiated between the client and the server the client is attempting to connect that will need capabilities fields.

Charles Krinke
OpenSim Core Developer
http://opensimulator.org
OSGrid Director
http://osgrid.org

To: [email-masked]
Sent: Saturday, February 21, 2009 4:19:05 PM

Lawson English wrote:
> My understanding is that prims save bandwidth, while meshes can be tailored to more efficiently use client-side resources. For a globe-trotting avatar that is constantly downloading new scenery, prims might be more efficient. For someone  who plans on staying mostly in one world, meshes probably win hands down (assuming an efficient caching system in the client) .

Prims have their uses, sure -- for example, almost all pysics simulations use proxy shapes (similar to prims, if I understand prims right), rather than the actual mesh.

However, I would argue that 95% of all 3D content in the world (at large -- not just user generated content in a consumer-facing virtual world) is in the form of mesh data. All current 3D representation research is on how to generate meshes more effectively (from pictures, video, LIDAR data, etc), and how to code/transmit them more effectively. The only other format that comes close is good-old elevation data ("raster" or "heightmap" depending on where you're coming from).

>From what I understand, it's also reasonably easy to generate meshes from prim descriptions -- Second Life already does it, for display on the screen. Meanwhile, taking mesh data that exists and automatically generating prims out of that is intractable, so requiring that every interactive 3D system in the world do that is pretty much a non-starter.

For an example, something as simple as an arched doorway is fairly common in regular meshes, yet can't be simply described ingeneral convex prims (of course you could create an arbitrary set of prims, like "teapot," for arbitrary special cases, but that still loses the generality of meshes).

Or, to formulate it in a more direct way: Either the Second Life platforms have to add a way to display and transmit meshes (if it's not already there), OR the rest of the world has to add a way to automatically generate prims from existing meshes. One of those problems is a lot easier to solve than the other. I think requiring implementation of a generally unsolved research problems in an interoperability standard is unwise.

Sincerely,

jw

---

From: Kajikawa Jeremy <[email-masked]>
Date: Sun, 22 Feb 2009 10:47:12 +0900

Apologies in advance but this is a partial "brain dump" message...
 so please read as much as you can and not reply immediately

so any "object" inside a "scene" for a "3D environment" will need
 to have interactive handling of some kind.

Do we expand beyond Identity and "presence" where each system
 can provide a "default AV" for "temporary" presence on that system
 into having material transferable between systems to map onto a given
 systems 3D model data ?

in which case any interchange agreement is also going to include usage
 of a "translator" for any "modified defaults" to be transferable to the
new
 "default mesh" to account for the modelling differences of the AV
object?

or are we all getting into transfer of objects before the sytems have a
  transfer of "presence" where one or more systems have a common
"presence"?

Messaging and other comminucations functions I see as being mapped using
 the existing Instant-Messenger/Relay-Chat/Mail systems...

From a personal perspective of using Guild Wars and SecondLife,
  with access to some others for evaluation purposes...

Most of the Messaging subsystem is dependent on presence alone...

Human runs Client opening "online world",
 and contacts are listed by two types "location" and "contactlist",
 "location" being presence on the same server(or map area),
 "contactlist" being a list of people recorded like a cellphone
directory.

I submit the use of an existing open Instant-Messenger for providing,
 "communications presence" extending "login presence"...

where I am defining "login presence" as being the state of "actively
logged into a VW"
 and "communications presence" as permitting others to make contact
through
 either "location" or "contactlist" mechanisms (with permit/deny for
"contactlist")

this will result in Identity on any given VW requiring 2 parts,
  a "vw local" account(temporary if visitor?),
  a "composite" account (primary point of login).

this would allow "fine-grain" sign-on to various services using existing
schema

I come online,  I sign into my VW of choice,  I set
"communication:status=available",

there is also the "Empathy" messenger written in python using service
modules,
  (telepathy stack) for Instant Messenger and Voice over IP functions.

I am personally avoiding transfer of in-world items and more considering
another
 means where a person can "transfer" an item by "transfer"
translators...

Im also wanting to sort out discussing *active* content,  as not all VWs
use the
 same engine,  (SL uses LSL, Croquet uses ???,  what else?) and
 not all VWs are going to even support scripting...

I ask that we start with presence on 1 or more concurrent systems by
some means
  and actively be able to talk on them both before being able to
transfer an item or
  how it appears to others (which comes into the not everyone uses the
same client...)

Has anyone else on this list engaged in a discussion over IRC where two
or
 more people were trying to explain how to do something based on
everyone
 had the same display on screen and were getting mad when the third
person
 was saying about menu items or gadgets not where they were supposed to
be?

I also have the impression this list is apparently trying to work around
exactly
  that kind of problem... everyones client is different and what is the
core "same"??

I look forward to hearing back about this...
  Jeremy

---

From: Morgaine <[email-masked]>
Date: Sun, 22 Feb 2009 02:30:31 +0000

On Sun, Feb 22, 2009 at 12:30 AM, Charles Krinke <[email-masked]> wrote:

> I disagree. There is no reason for this to be either or. We certainly can
> make an interop spec that contemplates "prims", "meshes" or other geometric
> notions.
>

Indeed, either/or is unnecessarily proscriptive..

I believe that we should focus on defining an extensible core protocol that
allows payloads of all of these types, and others, to be carried.  That's
part of our general "mechanism, not policy" guideline.

Morgaine.

On Sun, Feb 22, 2009 at 12:30 AM, Charles Krinke <[email-masked]> wrote:

> I disagree. There is no reason for this to be either or. We certainly can
> make an interop spec that contemplates "prims", "meshes" or other geometric
> notions.
>
> As I see this situation evolving, there will be a number fields in
> negotiating capabilities between a client and a server in teleporting from
> one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other
> physics engines are another. Scripting engines are a third.
>
> There will be a number of "world specific" capabilities that need to be
> negotiated between the client and the server the client is attempting to
> connect that will need capabilities fields.
>
> Charles Krinke
> OpenSim Core Developer
> http://opensimulator.org
> OSGrid Director
> http://osgrid.org
>
>
> ------------------------------
> *To:* [email-masked]
> *Sent:* Saturday, February 21, 2009 4:19:05 PM
> *Subject:* Re: [mmox] Learning from the past; focusing on the future
>
> Lawson English wrote:
> tailored to more efficiently use client-side resources. For a globe-trotting
> avatar that is constantly downloading new scenery, prims might be more
> efficient. For someone  who plans on staying mostly in one world, meshes
> probably win hands down (assuming an efficient caching system in the client)
> .
>
> Prims have their uses, sure -- for example, almost all pysics simulations
> use proxy shapes (similar to prims, if I understand prims right), rather
> than the actual mesh.
>
> However, I would argue that 95% of all 3D content in the world (at large --
> not just user generated content in a consumer-facing virtual world) is in
> the form of mesh data. All current 3D representation research is on how to
> generate meshes more effectively (from pictures, video, LIDAR data, etc),
> and how to code/transmit them more effectively. The only other format that
> comes close is good-old elevation data ("raster" or "heightmap" depending on
> where you're coming from).
>
> From what I understand, it's also reasonably easy to generate meshes from
> prim descriptions -- Second Life already does it, for display on the screen.
> Meanwhile, taking mesh data that exists and automatically generating prims
> out of that is intractable, so requiring that every interactive 3D system in
> the world do that is pretty much a non-starter.
>
> For an example, something as simple as an arched doorway is fairly common
> in regular meshes, yet can't be simply described ingeneral convex prims (of
> course you could create an arbitrary set of prims, like "teapot," for
> arbitrary special cases, but that still loses the generality of meshes).
>
> Or, to formulate it in a more direct way: Either the Second Life platforms
> have to add a way to display and transmit meshes (if it's not already
> there), OR the rest of the world has to add a way to automatically generate
> prims from existing meshes. One of those problems is a lot easier to solve
> than the other. I think requiring implementation of a generally unsolved
> research problems in an interoperability standard is unwise.
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 10:39:37 -0800

Charles Krinke wrote:
> I disagree. There is no reason for this to be either or. We certainly 
> can make an interop spec that contemplates "prims", "meshes" or other 
> geometric notions.
>
> negotiating capabilities between a client and a server in teleporting 
> from one virtual world to another. Prims vs meshes are one. 
> Havoc/ODE/Other physics engines are another. Scripting engines are a 
> third.
>
> There will be a number of "world specific" capabilities that need to 
> be negotiated between the client and the server the client is 
> attempting to connect that will need capabilities fields.

Why would a client connect to an unknown server? What actual benefit do 
you get from that?
What would you do about user interface when connecting to a different 
system?
How would you know to control an avatar at a different system from a 
client written for another system?
How would you interoperate between two different systems that don't use 
the same basic object or simulation representation?

I believe that a "universal client" does not actually solve any useful 
problems (it doesn't add any capability different from what you get by 
just installing multiple clients). It also is a lot of engineering, and 
locks system implementation into a restrictive/prescriptive model.

If what you want to do is make sure that "second life" client can 
connect to "open sim" servers, and vice versa, then your proposal makes 
sense, but I don't believe that's a useful model of interoperability for 
the world at large. I think that level of interoperability should be 
specified in a forum specific for second life-derived technologies (such 
as the AWG, perhaps?)

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 10:48:52 -0800

>   transfer of "presence" where one or more systems have a common

What is an "object"? To me, the object is the platonic ideal of that 
object, typically as embodied in running code on a "server" somewhere 
(for p2p systems, that "server" is also a "peer"). There is one, 
authoritative master version of that object.
Then, there is "object presentation," which includes things like meshes, 
animation, playing sound, location in 3D, available UI 
commands/interactions, etc. Part of "object presentation" is also how 
the object affects other objects around it; specifically things like 
collision meshes (collision meshes present the object to a physics 
system; render meshes presents the object to a display system, etc).
My proposal is that we provide a way to standardize "object 
presentation," so that any system can present an object that's operating 
on another system. This means that the user sees a large amount of 
interoperability, no matter what the specific implementation details are 
of the system the user is interoperating with. It also means that 
objects operating on different systems can interact with each other 
(collide, for example), without needing to "transport" the actual 
object, only the presentation affects of the object.

>  the existing Instant-Messenger/Relay-Chat/Mail systems...

Unfortunately, existing messaging protocols (like OSCAR or IRC or 
Jabber) and voice communication protocols (like SIP or H.320) do not 
provide for 3D localization of data, or tieing the data to specific 3D 
world entities. I believe this capability is actually quite important to 
the 3D world experience, and it would be a shame if that was lost 
through standardization.

Perhaps something like SIP can be extended to provide the necessary 
cross reference, though -- we should definitely consider that!

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Sun, 22 Feb 2009 10:50:48 -0800 (PST)

Well, actually, OpenSim and others are moving forward regardless of what we say here.

Last night, in r8569, a new set of logic was committed to OpenSim for MXP, that is the MetaverseXchangeProtocol. 

So, adding ModRex & MXP with others working on adding things like VastPark is already deploying multiple clients connecting to a single sim server.

I think from our viewpoint here, moving to get our group charter with a "rough consensus" and then agreeing on a protocol will help us participate rather then be spectators.

Charles

________________________________
From: Jon Watte <[email-masked]>
To: Charles Krinke <[email-masked]>
Cc: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Sunday, February 22, 2009 10:39:37 AM
Subject: Re: [mmox] Learning from the past; focusing on the future

> There will be a number of "world specific" capabilities that need to be negotiated between the client and the server the client is attempting to connect that will need capabilities fields.

Why would a client connect to an unknown server? What actual benefit do you get from that?
What would you do about user interface when connecting to a different system?
How would you know to control an avatar at a different system from a client written for another system?
How would you interoperate between two different systems that don't use the same basic object or simulation representation?

I believe that a "universal client" does not actually solve any useful problems (it doesn't add any capability different from what you get by just installing multiple clients). It also is a lot of engineering, and locks system implementation into a restrictive/prescriptive model.

If what you want to do is make sure that "second life" client can connect to "open sim" servers, and vice versa, then your proposal makes sense, but I don't believe that's a useful model of interoperability for the world at large. I think that level of interoperability should be specified in a forum specific for second life-derived technologies (such as the AWG, perhaps?)

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 10:52:52 -0800

Morgaine wrote:
>
> I believe that we should focus on defining an extensible core protocol 
> that allows payloads of all of these types, and others, to be 
> carried.  That's part of our general "mechanism, not policy" guideline.

I am explicitly requesting that we define enough policy that we can 
guarantee interoperability between two systems if both systems claim to 
implement the protocol in question. I think that any kind of 
interoperability less than that would not be of sufficient value to be 
called an open standard. Adding the capability of negotiating 
richer/better/newer formats on top of the defined base is a good thing, 
but there needs to be a defined base.

Some examples:
"If you support displayable geometry, you must support COLLADA."
"If you support voice chat, you must support GSM-11."
"If you support distributed authentication, you must support OpenID."
"If you support moving entities, you must support position, orientation, 
linear velocity and angular velocity with dead reckoning."

Thus, someone could add COLLADA, GSM and OpenID capabilities to their 
system, and they would be guaranteed to have a useful level of 
interoperability.

Otherwise, the interoperability standard is "interoperable" only in name.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 19:15:12 +0000

Just to nitpick, meshes and LCCs do work well together, just provide
different LODs :)

On Sat, Feb 21, 2009 at 8:18 PM, Morgaine
<[email-masked]> wrote:
> we call Limited Capability Clients (LCCs), which are typically gadget-type

---

From: Lawson English <[email-masked]>
Date: Sun, 22 Feb 2009 14:12:14 -0700

> Just to nitpick, meshes and LCCs do work well together, just provide

Well, the ideal thing is to be able to turn off graphical stuff 
completely. Text-based chat via a smartphone
needs no graphical stuff, though navigating via the map system might be 
worth implementing.

L

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 21:33:45 +0000

Of course, I was suggesting multiple LODs only when you actually
request them, not as something mandatory.

On Sun, Feb 22, 2009 at 9:12 PM, Lawson English <[email-masked]> wrote:
> Well, the ideal thing is to be able to turn off graphical stuff completely.
> Text-based chat via a smartphone

---

From: Dan Olivares <[email-masked]>
Date: Sun, 22 Feb 2009 18:21:58 -0500

Since one of the topics we're discussing here is the inclusion of a
universal object description for interoperability as a potential
deliverable and the prim vs mesh debate was brought up, I wanted to
bring up that there is a New BSD Licensed (MIT) library developed in
C# for receiving LLPrim type object descriptions and converting them
to a full mesh (with UV definitions) mostly developed by Tom Hoff.
The current project location is:
http://forge.opensimulator.org/gf/project/primmesher/ .

This is relevant because it is a completely free, open, and tested
code implementation of generating the mesh components of LLPrim.

This letter is NOT to suggest that we SHOULD use LLPrim specifically
in the standard.  It does, however, demonstrate that there is code
that anyone can refer to or use in working with the LLPrim parametric
geometry type.  LLPrim also has a specification for using a
heightfield type graphic with several different mappings (that can be
compressed) for producing a mesh that contains a maximum of 1024
verticies(32x32 heightfield) called the 'sculpted prim'.  For more
information on the sculpted prim, see:
http://wiki.secondlife.com/wiki/Sculpted_Prims:_Technical_Explanation
or refer to the implementation in PrimMesher.

Best Regards

Daniel Olivares

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 23:36:27 +0000

Does primmesher support multiple LODs?
Last I checked it was fairly simplistic in the way it created meshes
and had a few anomalies in the final product.
Bear in mind that I last played with this about 5 or 6 months ago.

---

From: Dan Olivares <[email-masked]>
Date: Sun, 22 Feb 2009 18:44:38 -0500

"Does primmesher support multiple LODs?",
Yes, by defining the number of revolutions during the extrude and
initial face verticies, it's possible to generate meshes at multiple
levels of detail.

"had a few anomalies in the final product"
As far as I could tell (and, I've had experience with two different
applications that use it OpenSimulator and IdealistViewer), the mesh
is quite accurate.   Last I checked, there was one shape where the
extruded hollow had a UV anomoly.

Best Regards

Daniel Olivares

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 16:59:26 -0800

> code implementation of generating the mesh components of LLPrim.

The problem is that 95% of the world's 3D content is in mesh form. I'm 
thinking things like AutoCAD models for public buildings and offices, 
ESRI data for land, GIS data, and even the Google Warehouse. I hope 
you're not seriously suggesting that all of the world's CAD and 3D 
content be re-developed using Prims to be able to be imported into a 
virtual world?

I agree that it's a solved problem to turn prims into meshes. However, 
it is not a solved problem to turn meshes into prims. Thus, meshes are 
the lowest common denominator, and anyone who wants to interoperate 
ought to be capable of understanding and generating meshes, because it's 
not reasonable to require that everyone can /generate/ prims.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 01:02:13 +0000

Ironically (given LL's heavy involvement) this means SL is in for
major changes in order to join in if meshes are to become a mandatory
part of the standard.

Of course, SL could just keep prims and add meshes as an extra, but by
that point you might as well drop prims completely at the protocol
level (the UI of course can maintain prims still).

On Mon, Feb 23, 2009 at 12:59 AM, Jon Watte <[email-masked]> wrote:
> thinking things like AutoCAD models for public buildings and offices, ESRI
> data for land, GIS data, and even the Google Warehouse. I hope you're not
> seriously suggesting that all of the world's CAD and 3D content be
> re-developed using Prims to be able to be imported into a virtual world?
>
> I agree that it's a solved problem to turn prims into meshes. However, it is
> not a solved problem to turn meshes into prims. Thus, meshes are the lowest
> common denominator, and anyone who wants to interoperate ought to be capable
> of understanding and generating meshes, because it's not reasonable to
> require that everyone can /generate/ prims.
>
> Sincerely,
>
> jw
>

---

From: [email-masked]
Date: Sun, 22 Feb 2009 18:12:25 -0800 (PST)

Then again it could be argued that prims offer Linden Lab a way for it's users to easily create and share objects without first learning more traditional modeling methods. I suspect that prims may also reduce storage costs for these shared objects as well as reduce over the wire bandwidth requirements

It seems though that LL would need to add a traditional mesh display capability to any viewer they chose to use for interoperating with other worlds, but they may not necessarily need to add it to their current service.

--Tom

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 02:39:38 +0000

They could of course prevent users from creating mesh objects locally,
but that seems like a rather arbitary limitation.
Can we have a linden speak to this?

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 20:06:53 -0800

> major changes in order to join in if meshes are to become a mandatory

It seems unavoidable that SL and derived technologies would get meshes 
at some level, yes. I don't think users would be particularly mad, 
though ;-)

> level (the UI of course can maintain prims still).

I fully expect prims to remain within the SL system as a first class 
citizen. Their claim is that sending an object based on a prim recipe 
uses less bandwidth than sending the prim recipe "cooked" as a mesh, and 
I see no reason to doubt that claim. (Whether a custom-built mesh would 
be more or less compact is a different question, the answer to which is 
"it depends.") In fact, for the case where SL talks to OpenSim, or some 
other SL derived technology, I would expect them to negotiate to 
exchange only prims and not meshes.

Meanwhile, some subset of prims may very well make for a suitable 
physics proxy representation even for objects that are complex meshes at 
their core. It is quite common for mesh-based systems to only actually 
use concave physics meshes for static geometry, and use proxy shapes 
(like boxes, spheres, capsules and convex hulls) for physics.

Anyway, that's the background that makes me believe that one fundament 
of object interoperability is that everyone must understand meshes at 
some level, and then you can add as much negotiated fancy on top as you 
want.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 07:52:16 +0000

We were discussing the prims vs meshes issue in the chatroom earlier,
and I noted that we have no hard numbers on which takes up more bytes:
prims or meshes.
To clarify, it's possible an optimised mesh could be more efficient
than the same build described in terms of prims.

What I proposed there was to treat the prims like source code, and the
mesh like object code. But the source code also include other "block
types". Basically, when placing a prim you just deform a standard mesh
and use it as one of your blocks, then for sending over the wire you
send the "baked" mesh. This may be more inefficient for some
scenarios, but it's much more compatible for systems that might not
render prims the same way or even support them.

On Mon, Feb 23, 2009 at 4:06 AM, Jon Watte <[email-masked]> wrote:
> It seems unavoidable that SL and derived technologies would get meshes at
> some level, yes. I don't think users would be particularly mad, though ;-)
>
> citizen. Their claim is that sending an object based on a prim recipe uses
> less bandwidth than sending the prim recipe "cooked" as a mesh, and I see no
> reason to doubt that claim. (Whether a custom-built mesh would be more or
> less compact is a different question, the answer to which is "it depends.")
> In fact, for the case where SL talks to OpenSim, or some other SL derived
> technology, I would expect them to negotiate to exchange only prims and not
> meshes.
>
> Meanwhile, some subset of prims may very well make for a suitable physics
> proxy representation even for objects that are complex meshes at their core.
> It is quite common for mesh-based systems to only actually use concave
> physics meshes for static geometry, and use proxy shapes (like boxes,
> spheres, capsules and convex hulls) for physics.
>
> Anyway, that's the background that makes me believe that one fundament of
> object interoperability is that everyone must understand meshes at some
> level, and then you can add as much negotiated fancy on top as you want.
>
> Sincerely,
>
> jw
>
>

---

From: [email-masked]
Date: Sun, 22 Feb 2009 23:58:29 -0800 (PST)

I can't speak for the SecondLife (SL) implementation as it's a black box to me, but from my collision tests, I am inclined to believe that since SL implemented the Havok 4 physics engine on their servers, that they are using fairly high level of detail mesh representations of their prims for proxies.

In OpenSim, if the Open Dynamics (ODE) physics engine is configured, and if the "Meshmerizer" option is chosen, then the prim proxies are meshed by the PrimMesher library at a fairly high level of detail which approaches the highest level of detail in the second life viewer. This configuration has been somewhat optimized over the last several months to yield quite reasonable performance for collisions and memory usage. There are some cases where internal ODE representations of proxies are still used: when prims are simple boxes or spheres.

"Sculpties", or sculpted prims, are a newer feature in SL which can display simple mesh objects. SL uses simple proxies for sculpties, and many content creators simply mark them as "Phantom" and then use regular prims inside the sculptie to make a user defined proxy.

OpenSim has added an experimental feature where a low level of detail sculptie mesh can also be used as a proxy. This seems to work well in many cases, however users are becoming more clever at making increasingly complex sculpties, and due to the limited level of detail, the resulting mesh collision proxy can often differ significantly in shape.

--Tom

----- Original Message ----
From: Jon Watte <[email-masked]>
To: Gareth Nelson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Sunday, February 22, 2009 8:06:53 PM
Subject: Re: [mmox] Learning from the past; focusing on the future

> major changes in order to join in if meshes are to become a mandatory

It seems unavoidable that SL and derived technologies would get meshes at some level, yes. I don't think users would be particularly mad, though ;-)

> level (the UI of course can maintain prims still).

I fully expect prims to remain within the SL system as a first class citizen. Their claim is that sending an object based on a prim recipe uses less bandwidth than sending the prim recipe "cooked" as a mesh, and I see no reason to doubt that claim. (Whether a custom-built mesh would be more or less compact is a different question, the answer to which is "it depends.") In fact, for the case where SL talks to OpenSim, or some other SL derived technology, I would expect them to negotiate to exchange only prims and not meshes.

Meanwhile, some subset of prims may very well make for a suitable physics proxy representation even for objects that are complex meshes at their core. It is quite common for mesh-based systems to only actually use concave physics meshes for static geometry, and use proxy shapes (like boxes, spheres, capsules and convex hulls) for physics.

Anyway, that's the background that makes me believe that one fundament of object interoperability is that everyone must understand meshes at some level, and then you can add as much negotiated fancy on top as you want.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 08:08:03 +0000

"many content creators simply mark them as "Phantom" and then use
regular prims inside the sculptie to make a user defined proxy."
I never knew the physics proxy was so badly out of sync in sculpties,
what is the actual ratio in LOD between the rendered graphic and the
physics proxy?

---

From: [email-masked]
Date: Mon, 23 Feb 2009 00:20:27 -0800 (PST)

The difference in Secondlife? I'm not really sure what they use for a proxy.. could be a sphere or a torus?

In OpenSim, the level of detail is a configuration option, it defaults to a 16x16 maximum. Counting vertices in wireframe mode in the SL viewer shows sculptie LOD to be 32x32 at the highest level.

---

From: Dan Olivares <[email-masked]>
Date: Mon, 23 Feb 2009 03:20:55 -0500

In SecondLife, it's represented by a torus or sphere (which is often
VERY different from the appearence).   They make no attempt to
actually represent physically, the way it appears.

In PrimMesher(And OpenSimulator), the physics proxy is very similar to
the visible mesh and LOD is configurable, however, I tend to limit it
to a total of 1024 vertices for static meshes and 256 vertices for
'physically active simulated' meshes to limit the load on the
processor.

And, now back to your regularly scheduled discussion on architecting
for extensibility...

Best Regards

Dan