<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Incidentally, that was the aim of the SOG, to push object changes to its parts, but it just didn't pan out.<BR>
<BR>
Also, it should be noted that, at the time we were thinking of OpenSim as an 'API', not a "Server" - I don't know if people today are even subclassing and specializing SOPs for themselves today - seems everyone is taking the "attaching behaviours to generic objects" route.<BR>
<BR>
So maybe a lot of our initial presuppositions on how OpenSim would be used has been turned moot. I have no problem with that. :-D<BR>
<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR>Join the 3d web revolution : <A href="http://tribalnet.se/" target=_blank>http://tribalnet.se/</A><BR> <BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Fri, 29 Aug 2008 10:39:55 -0400<BR>> From: sdague@gmail.com<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] SOG/SOP<BR>> <BR>> Michael Wright wrote:<BR>> > Well where it gets complicated is when all the children need to have references to their parents. So that the proper positions etc can be set.<BR>> > <BR>> > That was another task of the SOG, to keep track of the children and make sure the correct position etc were resolved for the children. <BR>> > <BR>> > What we had before the current SOG/SOP was a SceneObject that could have child SceneObjects. But it got very complicated. But again its likely that was due as much to the implementation, as to the idea. <BR>> > <BR>> > But its actually been a while since I've had a really good look at the current SOG/SOP so I guess I should do that and see exactly what is happening where, before I comment too much.<BR>> > <BR>> > I think one thing we all agree on is that the current setup has problems and there has to be a better way of doing it.<BR>> <BR>> The rel/absolute bits (pos, vel, acc, rot, ang vel) seem to be the crux<BR>> of why that back reference is needed. And the crux of why we need to do<BR>> it that way today is that we determine absolute position on read of an<BR>> attribute.<BR>> <BR>> If we change the problem around and calculate them on write of a parent<BR>> attribute (i.e. obj.Position triggers a cascade of changes to set it's<BR>> children's AbsolutePosition), I think we can get rid of the back<BR>> reference. It also has the added benefit of making the read case just<BR>> reading existing attributes, and take the cost of the reference frame<BR>> change on the write case, which seems a more logical place to impose<BR>> that tax.<BR>> <BR>> -Sean<BR>> <BR>> -- <BR>> Sean Dague / Neas Bade<BR>> sdague@gmail.com<BR>> http://dague.net<BR>> <BR>> <BR><BR></body>
</html>