Subject: [mmox] Making the best of content display variability

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

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

---

From: Kajikawa Jeremy <[email-masked]>
Date: Tue, 24 Feb 2009 06:30:28 +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, [email-masked] wrote: 
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox