<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Impalah,<BR>
<BR>
I know too little about your project to be able to make any comment, but you (and others) might be interested to know that the 'public' prim/shape definition offered by LL thru the build gui and LSL llGetPrimitiveParams() are very different from the 'internal' prim/shape definition that is communicated thru the packets.<BR>
<BR>
Simply put, LL converts the values to and from LSL, and then back again when they show them to the user.<BR>
<BR>
I have done quite a lot of work with this - you need to convert almost all parameters, and not just in scale, but in type as well. (for example, there IS no BOX or CYLINDER, those types are just combinations of other parameters)<BR>
<BR>
Actually, OpenSim can probably produce shapes that is not possible to create thru the GUI or SetParams, just because we use this 'deeper' shape definitions based on 'profile and extrusion'.<BR>
<BR>
/Stefan<BR><BR><BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Thu, 13 Dec 2007 20:06:08 +0100<BR>From: impalah@gmail.com<BR>To: opensim-dev@lists.berlios.de<BR>Subject: Re: [Opensim-dev] Towards 0.5, what's left?<BR><BR>Hi everyone,<BR><BR>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. <BR><BR>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. <BR><BR>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...). <BR><BR>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.<BR><BR><BR><?xml encoding="UTF-8"?><BR><!ELEMENT slxml (primdef, layers)><BR><BR> <!ELEMENT primdef (primitive+)><BR> <!ELEMENT primitive (dimensions+, modifiers*)><BR> <!ATTLIST primitive<BR> name ID #REQUIRED<BR> type (BOX|CYLINDER|PRISM|SPHERE|TORUS|TUBE|RING|SCULPT) #REQUIRED <BR> ><BR> <!ELEMENT dimensions (size,rotation)><BR> <!ELEMENT size (#PCDATA)><BR> <!ELEMENT rotation (#PCDATA)><BR> <!ATTLIST rotation<BR> spec (VECTOR|QUATERNION) #REQUIRED <BR> ><BR> <!ELEMENT modifiers (modifier*)><BR> <!ELEMENT modifier EMPTY><BR> <!ATTLIST modifier<BR> name (CUT|HOLLOW|TWIST|TAPER|TOPSHEAR|DIMPLE|HOLESIZE|PROFILECUT|REVOLUTIONS|RADIUSOFFSET|SKEW|SCULPTEXTURE|SCULPTSHAPE|OBJECTNAME) #REQUIRED <BR> value CDATA #REQUIRED<BR> ><BR><BR><BR> <!ELEMENT layers (layer+)><BR> <!ELEMENT layer (textures*,objects*)><BR> <!ATTLIST layer<BR> name ID #REQUIRED<BR> visible (YES|NO) #REQUIRED<BR> ><BR> <!ELEMENT textures (texture+)><BR> <!ELEMENT texture EMPTY><BR> <!ATTLIST texture<BR> side (ALL|0|1|2|3|4|5|6) #REQUIRED <BR> key CDATA #REQUIRED<BR> name CDATA #REQUIRED<BR> transparency CDATA #IMPLIED<BR> fullbright (YES|NO) #IMPLIED<BR> mapping (DEFAULT|PLANAR) #IMPLIED <BR> shininess (NONE|LOW|MEDIUM|HIGH) #IMPLIED<BR> bumpiness (NONE|BRIGHTNESS|DARKNESS|WOODGRAN|BARK|BRICKS|CHECKER) #IMPLIED<BR> rotation CDATA #IMPLIED<BR> repeats CDATA #IMPLIED <BR> offset CDATA #IMPLIED<BR> ><BR><BR><BR> <!ELEMENT objects (object+)><BR> <!ELEMENT object EMPTY><BR> <!ATTLIST object<BR> name ID #REQUIRED <BR> type IDREF #REQUIRED<BR> position CDATA #REQUIRED<BR> size CDATA #REQUIRED<BR> rotation_vector CDATA #IMPLIED<BR> rotation_quaternion CDATA #IMPLIED <BR> ><BR><BR><BR><BR><BR><BR>
<DIV><SPAN class=EC_gmail_quote>2007/12/13, Sean Dague <<A href="mailto:sean@dague.net">sean@dague.net</A>>:</SPAN>
<BLOCKQUOTE class=EC_gmail_quote style="PADDING-LEFT: 1ex">On Thu, Dec 13, 2007 at 03:43:04PM +0000, Justin Clark-Casey wrote:<BR>> So to take up the webpage analogy, the serialization you're talking<BR>> about is just the pure 'html'? The various bits of binary data which <BR>> make up the page/prim (e.g. pngs and gifs for webpages, textures,<BR>> scripts and sounds for second life), are represented by uris/asset ids<BR>> in the exported xml.<BR>><BR>> Just as in a 'full' webpage format, a full sl export would also export <BR>> those resources in a separate 'package'/'region'/'directory' to which<BR>> the asset ids could resolve.<BR>><BR>> Was actual texture data exported in byte[] format before the libsl <BR>> change? I apologise for my ignorance on this point.<BR><BR>Well, two issues. First off, yes the Texture field is coming out as a<BR>byte[]. But that is just the texturing description. The asset<BR>representing actually used textures is in asset land, and isn't <BR>exported.<BR><BR>My recent thoughts on the save/load model is the following.<BR><BR>1. It should be a seperate program, OpenSimDump.exe (or something), so<BR> that you can run it while OpenSim is running, or when OpenSim isn't <BR> running, and have no fear that OpenSim might alter the data in some<BR> way while it is coming up.<BR><BR>2. It should read OpenSim.ini for the data sources for assets and<BR> primstorage. This would let you use 2 different OpenSim.ini files<BR> to dump from sqlite and move everything to mysql (for instance).<BR><BR>3. It should create what it does in an on disk directory, that would<BR> look something like:<BR><BR> dump/<BR> prims.xml<BR> assets.xml<BR> UUID-UUID-UUID.jp2<BR> UUID-UUID-UUID.xyz<BR><BR> Basically, appropriate metadata would end up in xml files. When<BR> dealing with binary data we translate back to appropriate binary <BR> files named by UUID.<BR><BR>4. It should support a mode that dumps ALL assets, or one that dumps<BR> only assets referenced by prims.<BR><BR>For right now, there will be no guaruntee of compatibility between<BR>OpenSim revisions. I think it will take a couple of iterations before<BR>we get an at rest definition that makes sense. I really doubt collada<BR>is that right at rest definition, as it seems pretty heavy for what we<BR>need (though supporting a collada import in the future would be<BR>definitely interesting).<BR><BR>I'm going to start hacking on this tomorrow, though it likely won't<BR>finish prior to me heading away for vacation. I'll check in stuff daily <BR>if not more frequently so other folks can look and help if they are<BR>interested.<BR><BR> -Sean<BR><BR>--<BR>__________________________________________________________________<BR><BR>Sean Dague Mid-Hudson Valley <BR>sean at dague dot net Linux Users Group<BR><A href="http://dague.net/" target=_blank>http://dague.net</A> <A href="http://mhvlug.org/" target=_blank>http://mhvlug.org</A><BR><BR>There is no silver bullet. Plus, werewolves make better neighbors <BR>than zombies, and they tend to keep the vampire population down.<BR>__________________________________________________________________<BR><BR>-----BEGIN PGP SIGNATURE-----<BR>Version: GnuPG v1.4.6 (GNU/Linux)<BR><BR>iD8DBQFHYXtlSamXem9TdyYRAo6eAKCvkydQjGNPNIXipeh58rCempPgSwCgoZxv <BR>E3tStYFPqvw1jxVGeHGFn8I=<BR>=3Xqj<BR>-----END PGP SIGNATURE-----<BR><BR>_______________________________________________<BR>Opensim-dev mailing list<BR><A href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de </A><BR><A href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target=_blank>https://lists.berlios.de/mailman/listinfo/opensim-dev</A><BR><BR></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></body>
</html>