[Opensim-dev] Towards 0.5, what's left?
Impalah
impalah at gmail.com
Thu Dec 13 19:06:08 UTC 2007
Hi everyone,
I don't know OS enough "internally" to tell you how to do it but , from the
point of view of a "Utility developer" I think the 3rd point of Sean's list
is the most interesting. Yeah, maybe is a egoist point of view but just ask
you if you want a really Open (and not only open source) server.
Actually I am developing a xml format for my Henshin project (CAD/3D to SL).
It's not perfect, and maybe it is much "Second Life dependant" but maybe
could serve you as a start point. I have developed a DOM .NET object to have
easy access to the data I want.
Ah, and remember, OS can use it's own xml format, the translation to Collada
is made with a single XSLT. The only thing we need is to have the
information accesible (for example, string paths for textures, xml
attributes or elements for modifiers... please, don't use byte arrays and
similars...).
Here is the first version of the DTD I am using... Forget the layer
information, it's only for Autocad compatibility and add a LINK list with
every object.
<?xml encoding="UTF-8"?>
<!ELEMENT slxml (primdef, layers)>
<!ELEMENT primdef (primitive+)>
<!ELEMENT primitive (dimensions+, modifiers*)>
<!ATTLIST primitive
name ID #REQUIRED
type (BOX|CYLINDER|PRISM|SPHERE|TORUS|TUBE|RING|SCULPT) #REQUIRED
>
<!ELEMENT dimensions (size,rotation)>
<!ELEMENT size (#PCDATA)>
<!ELEMENT rotation (#PCDATA)>
<!ATTLIST rotation
spec (VECTOR|QUATERNION) #REQUIRED
>
<!ELEMENT modifiers (modifier*)>
<!ELEMENT modifier EMPTY>
<!ATTLIST modifier
name
(CUT|HOLLOW|TWIST|TAPER|TOPSHEAR|DIMPLE|HOLESIZE|PROFILECUT|REVOLUTIONS|RADIUSOFFSET|SKEW|SCULPTEXTURE|SCULPTSHAPE|OBJECTNAME)
#REQUIRED
value CDATA #REQUIRED
>
<!ELEMENT layers (layer+)>
<!ELEMENT layer (textures*,objects*)>
<!ATTLIST layer
name ID #REQUIRED
visible (YES|NO) #REQUIRED
>
<!ELEMENT textures (texture+)>
<!ELEMENT texture EMPTY>
<!ATTLIST texture
side (ALL|0|1|2|3|4|5|6) #REQUIRED
key CDATA #REQUIRED
name CDATA #REQUIRED
transparency CDATA #IMPLIED
fullbright (YES|NO) #IMPLIED
mapping (DEFAULT|PLANAR) #IMPLIED
shininess (NONE|LOW|MEDIUM|HIGH) #IMPLIED
bumpiness
(NONE|BRIGHTNESS|DARKNESS|WOODGRAN|BARK|BRICKS|CHECKER) #IMPLIED
rotation CDATA #IMPLIED
repeats CDATA #IMPLIED
offset CDATA #IMPLIED
>
<!ELEMENT objects (object+)>
<!ELEMENT object EMPTY>
<!ATTLIST object
name ID #REQUIRED
type IDREF #REQUIRED
position CDATA #REQUIRED
size CDATA #REQUIRED
rotation_vector CDATA #IMPLIED
rotation_quaternion CDATA #IMPLIED
>
2007/12/13, Sean Dague <sean at dague.net>:
>
> On Thu, Dec 13, 2007 at 03:43:04PM +0000, Justin Clark-Casey wrote:
> > So to take up the webpage analogy, the serialization you're talking
> > about is just the pure 'html'? The various bits of binary data which
> > make up the page/prim (e.g. pngs and gifs for webpages, textures,
> > scripts and sounds for second life), are represented by uris/asset ids
> > in the exported xml.
> >
> > Just as in a 'full' webpage format, a full sl export would also export
> > those resources in a separate 'package'/'region'/'directory' to which
> > the asset ids could resolve.
> >
> > Was actual texture data exported in byte[] format before the libsl
> > change? I apologise for my ignorance on this point.
>
> Well, two issues. First off, yes the Texture field is coming out as a
> byte[]. But that is just the texturing description. The asset
> representing actually used textures is in asset land, and isn't
> exported.
>
> My recent thoughts on the save/load model is the following.
>
> 1. It should be a seperate program, OpenSimDump.exe (or something), so
> that you can run it while OpenSim is running, or when OpenSim isn't
> running, and have no fear that OpenSim might alter the data in some
> way while it is coming up.
>
> 2. It should read OpenSim.ini for the data sources for assets and
> primstorage. This would let you use 2 different OpenSim.ini files
> to dump from sqlite and move everything to mysql (for instance).
>
> 3. It should create what it does in an on disk directory, that would
> look something like:
>
> dump/
> prims.xml
> assets.xml
> UUID-UUID-UUID.jp2
> UUID-UUID-UUID.xyz
>
> Basically, appropriate metadata would end up in xml files. When
> dealing with binary data we translate back to appropriate binary
> files named by UUID.
>
> 4. It should support a mode that dumps ALL assets, or one that dumps
> only assets referenced by prims.
>
> For right now, there will be no guaruntee of compatibility between
> OpenSim revisions. I think it will take a couple of iterations before
> we get an at rest definition that makes sense. I really doubt collada
> is that right at rest definition, as it seems pretty heavy for what we
> need (though supporting a collada import in the future would be
> definitely interesting).
>
> I'm going to start hacking on this tomorrow, though it likely won't
> finish prior to me heading away for vacation. I'll check in stuff daily
> if not more frequently so other folks can look and help if they are
> interested.
>
> -Sean
>
> --
> __________________________________________________________________
>
> Sean Dague Mid-Hudson Valley
> sean at dague dot net Linux Users Group
> http://dague.net http://mhvlug.org
>
> There is no silver bullet. Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHYXtlSamXem9TdyYRAo6eAKCvkydQjGNPNIXipeh58rCempPgSwCgoZxv
> E3tStYFPqvw1jxVGeHGFn8I=
> =3Xqj
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071213/049f950e/attachment-0001.html>
More information about the Opensim-dev
mailing list