[vwrap] Conditioners and refineries

Dzonatas Sol <dzonatas@gmail.com> Thu, 31 March 2011 02:32 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477803A6BF4 for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 19:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.527
X-Spam-Level:
X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 XyxWvt-ezoFj for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 19:32:40 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1E6F23A6BF1 for <vwrap@ietf.org>; Wed, 30 Mar 2011 19:32:40 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2166736iwn.31 for <vwrap@ietf.org>; Wed, 30 Mar 2011 19:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=v2mxqHJHAK69IxPnm1yhmbQ6wg93gahvUqhpYBtbqgA=; b=nsat6hx3fQER23dEy7C5zCR1U00y7WmzY//ENi4Dl10hLg5GwoYsXT2VI/GKoljMBs qi1bZ3UqVpMpual21YmmGSH4xdyFN0XJZU9ANoJPqJzlNQJhvwoOiu6EFCBkxrX/nVlH TucGvh3Sc1HLdI4TTR+JAvVnTh5B2zJh8oCrE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=pRC2S7ACahLw7Wdklj4wML5GXTqR8rO3M6mmAStiskUhjtq9I1rrb68ItlUDP1kz8y zZshXg2ZFWjN/igox+gtR6WXURkketqzajWHSUFgenhrzpx+55CYcoYVy03CK09mkm4k yrNt/551ESI3Y3Vxhl0z8vL/I4m28qxhjZNVs=
Received: by 10.231.187.229 with SMTP id cx37mr2068822ibb.99.1301538858455; Wed, 30 Mar 2011 19:34:18 -0700 (PDT)
Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm409137ibb.39.2011.03.30.19.34.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 19:34:17 -0700 (PDT)
Message-ID: <4D93E82C.7060503@gmail.com>
Date: Wed, 30 Mar 2011 19:34:20 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: "vwrap@ietf.org" <vwrap@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [vwrap] Conditioners and refineries
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 02:32:41 -0000

If we say the conditioner basically authenticates or re-signs an asset 
from grid X to grid Y, and the refinery would make sure the physics of 
the object described by the asset is translated from the topology of 
grid X to the topology of grid Y, then this is basically what COLLADA 
expects in exchange. This exchange is this different from the usual 
import/export process. It doesn't have to be this exact process, as this 
is only an example to us be more familiar.

It seems a complete waste to not realize that LL has implemented the 
import process and physics refinery into their browser, and this very 
feature, though not fully automated as such, could be used to help move 
assets in-between grids/v-worlds. Since the import is from local basis, 
the authentication is not implemented. What's to stop to basically 
export to DAE format on the local storage, from one world, and continue 
to import that DAE into another grid.

Note that the refineries may be proprietary. They may produce 
non-COLLADA formats (from DAE files) that are for optimal render/display 
capability of the software "client" (i.e. that the end-user has to view 
graphics).

As with Google Earth and Sony HOME, they already have their assets 
conditioned and refined for those virtual worlds such that they can 
optimally display them. The key note is not the optimal display, as it 
is about being able to exchange and use in other virtual worlds.

The DAE format does have extensive abilities, yet the goal of COLLADA is 
still to define the basic material, scripts, model, etc in the most 
portable format. The DAE may contain hybrid or specific formats that is 
stored in the extensions, so that custom objects are retained/transferred.

If virtual worlds start to not agree upon how they store objects, I see 
COLLADA as the default format for digital asset exchange.

https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F

(Yes, we can put all inventory items in DAE format through the user-data 
and asset extensions, despite the format mainly being for 3D... just sayin')

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant