[Opensim-dev] scene import/export to another app: oar? dotscene? collada?

Thu Sep 17 19:14:14 UTC 2009

Shack,

Have you read 
http://opensimulator.org/wiki/OpenSim:Xml_Serialization
page?

Also, Adam F authored (?) an orphaned page
http://opensimulator.org/wiki/Xml_Objects_Format
that I'm wondering what it's about?

/Stefan

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Shack Dougall
> Sent: den 17 september 2009 17:28
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] scene import/export to another app: oar?
> dotscene? collada?
> 
> I'm excited to see this discussion and would just like to mention the
> HPA format (Hierarchical Prim Archive) which is what Prim Composer for
> 3ds Max uses to store its scenes.
> 
> https://liferain.com/projects/hpa/
> 
> When I started Prim Composer, I looked at the existing formats such as
> OAR and rejected them because they were too closely tied to the server
> implementation.  For example, one of the many problems with the
> server-centric encoding is that it is much harder than it needs to be
> to
> determine the type of a prim.  There isn't a single field that says,
> "This is a box".  Also, some prim fields such as taper have different
> definitions depending on what type of prim it is being applied to.
> 
> HPA is the alternative XML format that I came up with.  It stores the
> data using the client-side values that are presented to the user and
> allows a hierarchical scene graph.
> 
> It's not complete (e.g., it doesn't describe task inventory yet) and
> I'm
> not claiming that it is perfect, but it *is* very well documented.  It
> might be useful as a starting point and I'm more than willing to make
> changes to it and update the documention accordingly.
> 
> It uses the file extensions .hpa for the XML data files and .hpz for
> the
> zipped archive.  I haven't implemented the zipped archive in Prim
> Composer yet, but it is the logical extension of the current
> specification and would give you something similar to an OAR file that
> could be passed around easily.
> 
> Toni Alatalo wrote:
> > Justin Clark-Casey kirjoitti:
> >
> >>> I've now been leaning against writing OAR support elsewhere exactly
> >>> 'cause it is the internal structure and perhaps awkward for what
> need
> >>>
> >>>
> >> That's theoretically true, but I should think that the old format
> will still be
> >> loadable in some way since changes here would break everybody's
> existing content
> >>
> >>
> >
> > Yah was thinking about the same - I guess there are ways to deal with
> > that .. perhaps kind of loosing the initial comfort of automatic
> > serialization though, needing manual processing for backwards compat.
> >
> >
> >> Separate files for objects and assetes were used in order to
> potentially allow
> >> regions to be more easily composed out of world from separate
> components.
> >> Whether this is a good thing or whether there are more advantages to
> a single
> >> monolithic file is, I'm sure, something that could be debated.
> >>
> >>
> >
> > Agreed - I think assets in separate files easily make sense, and for
> > SL/Opensim like prims too 'cause there is no distinction of the
> specific
> > geom and it's instance(s) in the scene. That said the single file
> > Collada .dae files that am working with now seem sensible too.
> >
> >
> >>> Collada and X3D would be engine independent standards that would
> >>>
> >>>
> >
> > I built something called 'ColladaDotNet', using the Collada Document
> > class from the Collada for XNA project, and have succesfully tested
> > using that to read reference Collada scene files, and my own exports
> > from Blender.
> >
> > Am planning to test importing scene info to Opensim / ModRex using
> that
> > .. first just object positions. May test in the Naali viewer (first)
> too
> > .. reading collada files there for local preview (may use with the
> > pycollada lib there, have the same test as for ColladaDotNet working
> now
> > with that too).
> >
> > ~Toni
> >
> >
> >>>> Toni Alatalo wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I started looking into implementing scene exchange between
> Opensim and
> >>>>> Blender yesterday, and am planning to continue later today. Was
> reading
> >>>>> OARs and the code in
> OpenSim.Region.Framework.Scenes.Serialization ..
> >>>>> where SceneObjectPart #region XML Schema seems to be the fields
> that are
> >>>>> autoserialized by some .net writer, right?
> >>>>>
> >>>>> It seems well possible to read and write OAR elsewhere, but I'm
> not sure
> >>>>> if it makes sense, or whether it's more the internal
> representation in
> >>>>> Opensim. Are there any alternatives? With Ogre we've sometimes
> used the
> >>>>> simple DotScene (.scene) made for it, and basically that would
> cover the
> >>>>> info I'm interested in now (positions of meshes in a scene, not
> prim
> >>>>> geom 'cause am not having prims in Blender at least right now
> anyway).
> >>>>> There is an existing DotScene exporter for Blender, would it make
> sense
> >>>>> to write an importer to OpenSim? Or a Collada scene importer
> perhaps? I
> >>>>> haven't looked (yet) what the scene format there looks like. For
> the
> >>>>> Ogre format there is a 15 line complete scene example at
> >>>>> http://www.ogre3d.org/wiki/index.php/DotScene
> >>>>>
> >>>>> In one way the question is: does OAR loading work with 'partial'
> data,
> >>>>> or would I have to make the exporter write all the fields? Am now
> >>>>> looking into exchanging this data first:
> >>>>>
> <GroupPosition><X>123</X><Y>129.55</Y><Z>29.340004</Z></GroupPosition>
> >>>>> <OffsetPosition><X>0</X><Y>0</Y><Z>0</Z></OffsetPosition>
> >>>>> <RotationOffset><X>0</X><Y>0</Y><Z>0</Z><W>1</W></RotationOffset>
> >>>>> <Scale><X>17.7774</X><Y>22.8028</Y><Z>69.2987</Z></Scale>
> >>>>>
> >>>>> and things like velocity would not apply .. also, are valid
> region
> >>>>> handles, creator-id etc. required, and should I generate GUIDs at
> export?
> >>>>>
> >>>>> I'll experiment what happens at loads of partial data etc., and
> of
> >>>>> course can just make the exporter write all those fields, but
> hints are
> >>>>> welcome so would not be banging my head against the most
> irrelevant walls.
> >>>>>
> >>>>> ~Toni
> >>>>> _______________________________________________
> >>>>> Opensim-dev mailing list
> >>>>> Opensim-dev at lists.berlios.de
> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Opensim-dev mailing list
> >>>> Opensim-dev at lists.berlios.de
> >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Opensim-dev mailing list
> >>> Opensim-dev at lists.berlios.de
> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev