Re: [mmox] Creating walled gardens considered harmful

[Jon Watte <[e-mail]>]

Larry Masinter wrote:
>> http://tools.ietf.org/html/draft-jwatte-mmox-use-cases-00
>>     
>
> "  The point is
>    that interoperability does not require the source and the destination
>    to be from the same technology family, use the same simulation
>    technology, or even that the clients must understand protocols other
>    than those native to the respective simulation system."
>
> I don't understand how most of those use cases can be managed if
> the source & destination have different simulation models, skeleton
> structions, scripting languages, physics models, rendering engines,
> etc.
>
>   

It's being done all the time in the DIS simulation model, and has been 
since the 1980s. You simply send the presentation information about the 
object. For an avatar, you present a mesh in some known format (COLLADA, 
X3D, etc), one or more textures in some known format (DDS, JPEG, etc), 
and one or more animations that are targeted to the mesh (again, 
COLLADA, X3D, BHV, etc). When that avatar moves, the "playing animation" 
property changes, and the observers can run the walk cycle animation if 
they care. The "velocity" and "position" properties will also change, 
and the observers can update the position of the entity, typically using 
dead reckoning.

All the physics, simulation, skeleton etc gets operated on in the host 
system, so the fact that they are heterogenous doesn't matter. All a 
remote peer needs to understand is how to load and present assets in 
some common format.

The key here is that the property names "current animation," "position" 
and "velocity" are well-known. In traditional simulation interop 
protocols (DIS, HLA, TENA etc), those map to numeric fields at some 
offset in some PDU. In order to make the system scale across different 
clients (cell phones, conference phones, full-immersion CAVEs, etc), 
separating the properties you're interested in, and identifying them by 
name, seems like a good idea -- look at the LESS protocol for an 
illustration of how this can be done.

>>   The benefit is that users of different virtual worlds can invite and
>>  communicate with each other using the virtual world metaphore,
>>   regardless of the particular virtual world technology used for their
>>   "home base" virtual world.
>>     
>
> I think this is "if you can do A, then you can do A". Why would anyone
>  want to do that, and how would it help them?
>
>   

Very simple: When I meet you, I can still use my inventory objects, and 
you can still use your inventory objects. Depending on the degree of 
interaction translation in the host systems, I may even be able to use 
your inventory objects, and vice versa. (Simple things like "activate" 
or "view heritage" or whatever are almost gimmies; harder things like 
"riding shotgun" may or may not be supported by any particular platform)

> In section 2.2.1, the integration of a "plant" and a "city" requires
> so many seams to be knit, I wonder how feasible it really is. Even
> between virtual worlds with the same underlying infrastructure, welding
> a "building" into a city requires a lot of work aligning, wouldn't it?
>
> Just wondering how practical these use cases are.
>   

We are already doing these things using proprietary protocols, and using 
open, but military-centric protocols. I would be very happy if there was 
an extensible, adopted open standard protocol that we could do all this 
over, because then we wouldn't have to code up a new point solution for 
each new system that we encounter. (Of course, if those other systems 
didn't adopt the protocol, then that wouldn't help much)
I predict that integration between virtual worlds will be very important 
a few years from now, so if there's already a well-known language for 
them to speak, that work will be easy. If there isn't, it won't :-)

Sincerely,

jw