Re: [vwrap] Conditioners and refineries

[Morgaine <[e-mail]>]

We've maintained throughout that our protocols would be extensible with
regard to data formats, allowing worlds and user expectations to evolve
without requiring protocol redefinition.

In the area of meshes, it is very much to be expected that COLLADA will
figure strongly among the graphic formats used (particularly since it was
chosen for the iED initiative), but it's not of any special interest to the
VWRAP protocols other than as a potential content type.  All we have to do
is to make sure that we label each transfer with its appropriate type, and
possibly also include other metadata that may be needed.

We're certainly not standardizing what graphics are used in virtual worlds,
beyond assigning types where they might not yet exist.  Hardwiring them
would be a recipe not for extensibility but for stagnation.  Other bodies
may be standardizing which graphics formats are used, whereas we're trying
to define useful deployment architectures and standardizing the protocols
through which they are accessed.


Morgaine.




===================

On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol <[e-mail]> wrote:

> 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
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>