[Opensim-dev] SOG/SOP

[Diva Canto]

As a data point, I am subclassing SOG. It works great, except for a few 
minor glitches in SOG which could be fixed, including in the XML parts. 
I'm also doing my own IClientAPI classes.

As context, I'm developing several simulation visualization modules, 
e.g. traffic and scientific simulations. I'll put them in UCI's regions 
in OSGrid within the next couple of weeks, if anyone is interested.

I'm coming to the conclusion that inworld scripting is cute but 
ultimately limited by design -- even if the scripting engine was already 
solid and on steroids. Plugging things in the server is infinitely more 
powerful. So I am extremely interested in how this discussion about 
SOG/SOP will  pan out.

I'm looking at OpenSim both as an API *and* as a server, and would like 
to continue to do so. The API mode is for developing interesting 
behaviors; the server mode is for rich user interaction.

Diva / Crista

Stefan Andersson wrote:
> Incidentally, that was the aim of the SOG, to push object changes to 
> its parts, but it just didn't pan out.
>  
> 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.
>  
> 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
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>  
> Join the 3d web revolution : http://tribalnet.se/
>  
>
>
>
> ------------------------------------------------------------------------
>
> > Date: Fri, 29 Aug 2008 10:39:55 -0400
> > From: sdague at gmail.com
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] SOG/SOP
> >
> > Michael Wright wrote:
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> >
> > The rel/absolute bits (pos, vel, acc, rot, ang vel) seem to be the crux
> > of why that back reference is needed. And the crux of why we need to do
> > it that way today is that we determine absolute position on read of an
> > attribute.
> >
> > If we change the problem around and calculate them on write of a parent
> > attribute (i.e. obj.Position triggers a cascade of changes to set it's
> > children's AbsolutePosition), I think we can get rid of the back
> > reference. It also has the added benefit of making the read case just
> > reading existing attributes, and take the cost of the reference frame
> > change on the write case, which seems a more logical place to impose
> > that tax.
> >
> > -Sean
> >
> > --
> > Sean Dague / Neas Bade
> > sdague at gmail.com
> > http://dague.net
> >
> >
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20080829/13c9a735/attachment-0001.html>