[mmox] Avatar diversity

Morgaine <morgaine.dinova@googlemail.com> Fri, 06 March 2009 09:06 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC6B3A69C7 for <mmox@core3.amsl.com>; Fri, 6 Mar 2009 01:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhRoeJppl+Mi for <mmox@core3.amsl.com>; Fri, 6 Mar 2009 01:06:02 -0800 (PST)
Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 574C33A68A4 for <mmox@ietf.org>; Fri, 6 Mar 2009 01:06:02 -0800 (PST)
Received: by ewy25 with SMTP id 25so153688ewy.37 for <mmox@ietf.org>; Fri, 06 Mar 2009 01:06:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=AD6C/c+/fmMguolnOMXY1iNK+ycymQtd/Z5R4MtwQPs=; b=JuN3pLPKjyxRfScSHhMtD+tni5LZhQ+pWFwqgZBdda9NZcF2kUJHCsf+2IPDxrfFMR xuarlwK+ug/l4+NQgqpgaT0bUNBVvyMeTIP+TPBrwYl6DZxajoxsngh7PPEmj/iRVazN x2QLAxK/DXuhieX4jiKYncpHCfNzbwGLtM7L8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dNBelX2m4Nzi4yeHbLD9Is60NrkOInzbs8Wke1JNbyP29Ibh26wm/8UbpMfwcczJxZ CZCkXoirXH+ywXau6IAxsVR4yazJqztN+3PHmuVjaqOmJCBYOw17Sf5GUHWvZLKsgwNs vH3k9WasSgNRHde4bPBK/qVyW65Busm7uxb2I=
MIME-Version: 1.0
Received: by 10.216.36.209 with SMTP id w59mr1164524wea.67.1236330391876; Fri, 06 Mar 2009 01:06:31 -0800 (PST)
Date: Fri, 06 Mar 2009 09:06:31 +0000
Message-ID: <e0b04bba0903060106p58143666q55a494ad17f5be54@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: mmox@ietf.org
Content-Type: multipart/alternative; boundary="0016364c76f5d5341b04646f993d"
Subject: [mmox] Avatar diversity
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2009 09:06:03 -0000

A number of threads have touched upon the topic of how avatars might be
handled across interop.  I'd like to make a couple of simple observations
about *diversity* in visual representation that impact on what our protocol
will be required to do, or not to do:


   - Many interoperating virtual worlds are likely to have strong
   constraints on the visual nature of participants in their world, for reasons
   including aesthetics, immersion, morality, legality, role-playing and many
   others, all valid, all different, and all for them to decide and nobody
   else.
   - Many interoperating virtual worlds are likely to luxuriate in the
   eye-opening splendors of worldwide artistry and embrace the widest possible
   diversity in avatar visuals.  That would be for them to decide, and nobody
   else.


My view on this is the following:  such choices are a matter of policy, and
we're not here to make policy.

Instead, we're here to provide mechanisms that can support a broad range of
policies, and this must therefore include the transport of specific visual
information for avatars and their corresponding metadata for those who
desire it.

To not do so would be to deny the opportunity for avatar diversity, and
hence it would create only an interoperating federation of walled gardens,
internally all alike.  It would not allow the metaverse to become a
mesmerizing carnival for those who want it, as well as a controlled
environment for those who do not.

Therefore I would argue strongly against any protocol that seeks not to
transport detailed visual information for avatars.


Morgaine.








On Fri, Mar 6, 2009 at 12:54 AM, Jon Watte <jwatte@gmail.com> wrote:

> Heiner Wolf wrote:
>
>> I totally agree. The simulator seems to be the central component for
>> our discussion. I get the impression, that we should enable the
>> simulators of different vendors to instantiate and simulate foreign
>> avatars (and items), but that we should not define how the simulator
>> feeds the scene description to the renderer.
>>
>>
>
> If you read the LESS proposal carefully, you don't actually get a copy of
> "the avatar" -- you get a representation of what the avatar is doing in its
> originating simulation, such that your objects can react to it, and you can
> forward it to your clients/users/viewers.
> Trying to instantiate the authoritative, user-driven "master" copy of some
> kind of object from a foreign source isn't really practical, because of the
> extremely tight coupling to an extremely large number of subsystems needed
> (which I call the "execution environment" -- UI, script, physics, messaging,
> etc).
>
> Sincerely,
>
> jw
>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>