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

[Shack Dougall]

Thanks, Stefan!

No, I hadn't read that.  The first link is very promising where it says:

"Since there is three distinct flavours ("SL GUI values", "LSL 
PrimitiveParams values" and "Protocol values") of defining prims, we 
should accomodate for this, quite possibly by having separate tags, so 
the parser can use that to parse differently."

But I would argue that the SL GUI values are by far the most general and 
abstract.  Better suited to an archive or interchange format.

If you look carefully at the second link, you can see one of the quirks 
that you encounter with the "Protocol" representation (which I have been 
calling server-centric).  The shape of primitive "HaiAsl" is 
Face:Circle, Extrusion:Straight.  This is a cylinder.  But cylinders can 
also be Face:Circle, Extrusion:Flex.  So, if I want to test for all 
cylinders, then I will have to do a complex test for multiple 
conditions.  It just seems more complicated than it needs to be.

The LSL representation doesn't have this problem, but it still would 
have the legacy hack that causes taper to be defined differently for 
different prim types.

Stefan Andersson wrote:
> 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.
>>
>>