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

[Justin Clark-Casey]

Toni Alatalo wrote:
> Paul Fishwick kirjoitti:
>> Could OAR be generalized to include scene graphs with meshes? That would
>> be really nice as it would create two things not currently supported: 
>> hierarchical scene graphs and triangular mesh. If an importer is written to opensim,
>>   
> 
> It is possible. A simple hack would putting a reference to a mesh asset 
> to the place where <shape> entry with the geom data is used for prims. 
> As OAR is a serialization of the internal SOG/SOP data structure, and 
> ModRex extends those to have the mesh references in the scene, it in a 
> way already does that. Like Mikko Pallari commented to this discussion 
> on rex-dev yesterday, we could easily add another serializer in ModRex 
> that would do that: save OARs where 'prims' are not prims but scene 
> nodes with mesh references, and have ogre mesh assets in the assets dir 
> of the oar.
> 
> That would already be useful for what OARs are for: saving scenes from 
> OpenSim and loading them back, in that case just with also the Rex 
> (Ogre) data. But it might not be helpful at all for exchanging scenes 
> between Opensim and other applications, which is what I'm looking into now.
> 
>> then it is a matter of coaxing the viewer to render these.. In your list of 
>> options, you might also consider the indexedfaceset of X3D for the mesh (X3D also supports 
>> a true scene graph).
>>   
> 
> Yes, it is a possible format also.
> 
> I've now been leaning against writing OAR support elsewhere exactly 
> 'cause it is the internal structure and perhaps awkward for what need 
> now. For example there is no single file with the scene as positions of 
> all objects, but a separate file for every object which has both the 
> scene pos and in case of prims the shape. And if SOG/SOP refactoring 
> happens within OpenSim, it easily changes the OAR 'format' as well, and 
> would break reading archives written using some custom thing that would 
> write the files as they are now .. right?

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 
(which would be a bad thing).

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.

> 
> DotScene is somewhat attractive 'cause it's simple and there are working 
> exporters for Blender, Max, Maya and for some editors written using Ogre 
> itself. There's a C# loader we've used in our company before when using 
> MOgre, http://www.ogre3d.org/wiki/index.php/MOGRE_dotSceneLoader . 
> Downsides of DotScene are that it's Ogre specific, and contains *only* 
> the scene, leaving textures and meshes etc. out .. which may be ok 
> though, 'cause textures are just images and there is separate code for 
> mesh export so getting those over too is just a matter of packaging 
> files for transport (perhaps in a .oar like container).
> 
> Collada and X3D would be engine independent standards that would 
> probably easily cover all I need now, so probably must give them another 
> look before starting to port that encouraginly simple dotSceneLoader (a 
> single simple 600 lines c# file) to OpenSim.. so will be googling for 
> .net libs for Collada and X3D next I guess (there's exports to both from 
> Blender, am not sure if the X3D one does scenes though .. and am a bit 
> afraid of how complex and big collada stuff may be, but hopefully that 
> fear is in vain).
> 
> Thanks for input!
> 
>> -p
>>   
> 
> ~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
> 


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