Re: [mmox] Making the best of content display variability
Kajikawa Jeremy <belxjander@gmail.com> Tue, 24 February 2009 06:35 UTC
Return-Path: <belxjander@gmail.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 3C58C3A6765 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 22:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 CaA7dM7Yi9ee for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 22:35:35 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 377F43A6905 for <mmox@ietf.org>; Mon, 23 Feb 2009 22:35:35 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so2178449rvb.49 for <mmox@ietf.org>; Mon, 23 Feb 2009 22:35:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=n+gJccr2j6g7wSsoAT+93XVKpfOwCMSgQPnBy3ERjzI=; b=qoPCQDWJ5FAyquW61R0+uLXuyZDcCWLOT679JMKDWuRcuBkBbZEKhanL7uVqVFqOhc QeG5NmxgfoUxquNxrUROCMk3OLkM6q56wa1MI95STLu1dQXf69BcnYFJ9pjjUeVEDdbs DsHn/VfTEBNS7duaSr42nri7A/x3m7fLyKH9c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=CtQPpehq8t7bJ+rX+Yh6tGtMUN99CNxrs7xOMvbrz19jbV+WLpWOcjbkkYPZW9rZfB 7F/9MuAyu1xr7yIubkks/z9puA1D4KEM9mOBJcLDk+9dhhLMyoMBcWqWx46MGpo0h/Ib sPxgkR7sxox7scZ+pOA1sgAL5+kGCLEj9ws5U=
Received: by 10.141.177.2 with SMTP id e2mr2425889rvp.71.1235457352805; Mon, 23 Feb 2009 22:35:52 -0800 (PST)
Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g22sm7157860rvb.0.2009.02.23.22.35.50 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 22:35:52 -0800 (PST)
From: Kajikawa Jeremy <belxjander@gmail.com>
To: eh2th-mmox@yahoo.com
In-Reply-To: <83286.20348.qm@web65715.mail.ac4.yahoo.com>
References: <83286.20348.qm@web65715.mail.ac4.yahoo.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-t4+0GaPNchXbZf/SumBw"
Date: Tue, 24 Feb 2009 06:30:28 +0000
Message-Id: <1235457028.6608.139.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Cc: MMOX <mmox@ietf.org>
Subject: Re: [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 06:35:36 -0000
I agree with the multiple versions option... thats why I proposed the HTML-alike serialization I have written about on this list already... to head towards something usable and extensible without become too "fixed" on what the virtual world implimentations are... allow for creativity to shine... to allow for one or more mesh/prim/<attribute> values to be present as part of any content created and implemented in an extensible manner. I don't expect the format itself to be used but the concept of arranging the data so that there is some kind of error checking and component connectivity so that a different VW render can use the correct resources inside the content object Maybe having resources for SL, maybe having resource references for WoW, maybe having resources for Solipsis or another VW... as long as the object is defined or expandable to be usable within the confines set by the content creator and agreed by the end-user/customer. Jeremy On Mon, 2009-02-23 at 20:05 -0800, eh2th-mmox@yahoo.com wrote: > 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 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox
- [mmox] Making the best of content display variabi… eh2th-mmox
- Re: [mmox] Making the best of content display var… Kajikawa Jeremy