[mmox] Making the best of content display variability

eh2th-mmox@yahoo.com Tue, 24 February 2009 04:05 UTC

Return-Path: <eh2th-mmox@yahoo.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 96F1D3A6936 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 20:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599]
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 sMw5p83lryCZ for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 20:05:21 -0800 (PST)
Received: from web65715.mail.ac4.yahoo.com (web65715.mail.ac4.yahoo.com [76.13.9.107]) by core3.amsl.com (Postfix) with SMTP id A74923A6782 for <mmox@ietf.org>; Mon, 23 Feb 2009 20:05:21 -0800 (PST)
Received: (qmail 21726 invoked by uid 60001); 24 Feb 2009 04:05:40 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=temrSSY+tVdGRuIj+LffD7oj+8lH3RYuil7ASt1UlIgBv0H9sWXBiMlxiocC+ggN1JWNYQ9nn9uGEZwib7sXbAoXx7yPChg0JBhx/AYAsKQCuWC8SCbs3TLblo/3dvWtJ7PXT6I3lReCoUTdsob0aIfp+R4SKOurUKl5vdUdtiM=;
X-YMail-OSG: pVZb0UYVM1ms8pQ1vudC3_K9AOqbPHT4OvQwRE9b7yzKj2sVGNR9O6_aR7zzjMU7wayp7CMLlkVsq0daTAVPElV3wp9oQwgC8.4xkRCRSCm680T9fZ.5ysb88rIHnCPa0oi3mcG6DwNykYDXnDwfGt5skgIMSoEqnjqcJcp3aKTd2h3pioh5jot4ndg-
Received: from [72.220.236.152] by web65715.mail.ac4.yahoo.com via HTTP; Mon, 23 Feb 2009 20:05:39 PST
X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1
Date: Mon, 23 Feb 2009 20:05:39 -0800
From: eh2th-mmox@yahoo.com
To: MMOX <mmox@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <83286.20348.qm@web65715.mail.ac4.yahoo.com>
Subject: [mmox] Making the best of content display variability
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: Tue, 24 Feb 2009 04:05:22 -0000

As a content creator, I am often experimenting with various display characteristics of the "world" or system where my content may be displayed. For example, in Second Life, I may create a scripted prim object which behaves in a manner to achieve some unique animation, or I may exploit the "alpha sorting problem", or perhaps the inverted normals of specially twisted sphere prims, and use this to create an uncommon visual effect. Such an effect would be unique to the Second Life viewer, and may even be dependant on a particular version of a simulator or viewer. If none of these dependancies are available, the desired effect may fail and the results could be much different than intended.

If this content were confined to the Second Life environment, I should be able to implement some form of control over this content where I could update it and send new copies to my prior customers to maintain the desired effect as the display environment evolves, or I could script it in such a way that it self modifies as instructed by a server object. Now consider the possibility that Linden Lab opens the doors to their grid to interoperability. Suddenly there are several possible scenarios where my content could be rendered in addition to the environment for where it was designed and this could have a detrimental effect on the displayed results. I may not have access to any feedback about how my content performs in these new display environments, and if the results were objectionable, this could affect my reputation as a developer of quality content.

As such I would be interested in ways I could collect statistics on the different display scenarios for my content, perhaps similar to a viewer version string passed from the user's web browser back to the server. Of course I understand such feedback mechanisms as they exist if the 2D web are not known for accuracy, but they do exist and could serve as a crude concept model.

Another option along the same lines would be to allow multiple versions of content, where high detail content could be tailored to each display scenario and the controlling server could choose which asset to display to each type of viewer. Along the same lines, a high definition specially tailored version could be used in the world which has contracted with the content creator to enable display of the finest results, and a lower quality compromised version could be passed to other "grids" and foreign viewers, reducing the risk of illicit use of the premium content while allowing for a functional shared experience.

I'm not certain how this fits into the discussion of the various protocols, but I suspect such an interoperating scenario would impact the designs; hence I feel these concepts to be somewhat applicable and on topic for this forum.

Best regards,
--Tom Hoff