<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Sure thing, that example was just pouring out of my fingers, the vector syntax came from X3D and I don't like it either.<BR>
<BR>
I would like some really standard albeit compact way of representing vectors/quaternions; surely, there must be something like MathML that does that? I'm thinking the pragmatics of html while still retaining extensibility of xml.<BR>
<BR>
Also, by creating some 'model' group/part/shape classes that's more occupied with transformation of data than transformation of state, these classes could provide PrimitiveBaseShapes for the protocol, as well as more API-and-Xml-friendly property accessors.<BR>
<BR>
I can start working on a suggestion sometime next week, if you all don't just race me to it.<BR>
<BR>
Best,<BR>
/Stefan<BR><BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Tue, 22 Jan 2008 15:56:49 -0500<BR>> From: sean@dague.net<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] SceneObjectGroup vs SceneObjectPart<BR>> <BR>> On Tue, Jan 22, 2008 at 08:35:42PM +0100, Stefan Andersson wrote:<BR>> > > It would be good to see a proposal on how to change those objects into> something better. None of us are in love with them, but better> approaches haven't popped up yet.<BR>> > Probably because nobody has made any attempt at discussing and proposing changes; this mail was an attempt to get that ball rolling.<BR>> > <BR>> > There was some energy poured into analyzing how attachments were communicated; that would be a good start, if we could get a wiki page up just detailing what we know about scene entities.<BR>> > > > * Related, we need to revise the xml serialization scheme and the db> > * schemes. The xml scheme should be user-friendly to the point where> > * you should be confident to create and edit objects in notepad,> > * basically. This is not the case at the moment. Massive duplication,> > * weird bit values and non-intuitive value ranges are king at the> > * moment.> > Given the amount of data in a prim, editing in notepad always is going> to be a bad idea. :) I think we've got something like 40 fields that> have to be sensible for the prim to work.<BR>> > >From working extensibly with shapes and serialization, I know that this is not the case.<BR>> > <BR>> > For example, consider something like<BR>> > <BR>> > <Object position="128.0 128.0 23.0"><BR>> > <Rectangle extrusion="straight" scale="1.0 2.0 5.0" offset="root"/><BR>> > <Circle extrusion="sphere" scale="1 1 1" offset="0 0 1"/><BR>> > </Object><BR>> > <BR>> > that doesn't look like a bad idea at all to me.<BR>> <BR>> That would be pretty sucky to parse though. We should really be<BR>> breaking out the position bits into seperate data so they can be<BR>> accessed directly, and so there is no ambiguity of X Y Z or Z Y X for<BR>> values.<BR>> <BR>> I do like the approach of having sane zero values for things so they can<BR>> be left out if they are defaults. I think that will make life a bit<BR>> easier for making future portability here.<BR>> <BR>> -Sean<BR>> <BR>> -- <BR>> __________________________________________________________________<BR>> <BR>> Sean Dague Mid-Hudson Valley<BR>> sean at dague dot net Linux Users Group<BR>> http://dague.net http://mhvlug.org<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></body>
</html>