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

[Shack Dougall]

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
>
>