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

[Justin Clark-Casey]

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?

Yep

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

I used the internal representation because it was the most expedient thing at 
the time and was already used by load/save xml[2].  That does make it less than 
perfect.  I did plan to make the first step away from this by initially manually 
[de]serializing the same format instead but I haven't had time to complete the 
code.  I previously posted the partial patch a month or so back on this mailing 
list.

However, it should be possible to use an alternative object representation 
(maybe Ogre) within the oar since OAR is really just a package format.  Some 
more metadata might need to be added to the oar, though maybe the format could 
be automatically detected instead which could be the cleaner solution (esp if 
there's any situation where some objects might be the traditional format and 
some Ogre). .

I guess an alternative would be to extend the default format to allow 'extended' 
arbitrary values for formats which require this data.

I would certainly welcome any patches to make OARs more generic as long as the 
mechanisms are documented and maintainable.  The serialization code in 
OpenSim.Region.Framework.Scenes.Serialization should also really be in a module 
itself.

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

In principle, I believe partial data should work since the .net automatic 
deserialization will just use the class defaults for the missing values.  But I 
haven't tried this.

You will need to supply valid guids (as you say, these can be generated 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
> 


-- 
justincc
Justin Clark-Casey
http://justincc.org