[Opensim-dev] scene import/export to another app: oar? dotscene? collada?
Justin Clark-Casey
jjustincc at googlemail.com
Thu Sep 17 18:13:41 UTC 2009
Thanks for the link Shack, it looks pretty cool - hopefully I'll get the
opportunity to take a look soon myself and maybe make some comments.
Shack Dougall wrote:
> 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
>
--
justincc
Justin Clark-Casey
http://justincc.org
More information about the Opensim-dev
mailing list