[Opensim-dev] Object Representation

Stefan Andersson stefan at tribalmedia.se
Tue Feb 12 18:45:09 UTC 2008


Yes, either closures, or 'state objects'. Or, if there is actually some method to this madness so it can be normalized and described with a clever set of classes.
 
I was tossing around the notion of a 'link set position' so that there was a global position, and that every part, including what would be the 'root' had an offset from that.
 
It definitively has its merits (you get one place to get/set absolute position, and another to set offset) but the backside is that you need quite a few re-calculations of prim positions and rotations when rendering to packets. Also, I'm a bit unsure as of how that would translate into attachment coords.
 
I don't know, anybody has any strong feelings on that issue? Would you like to have 'peer prims' or a 'root prim'?
 
/Stefan
 



Date: Tue, 12 Feb 2008 08:56:43 -0800From: diva at metaverseink.comTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] Object Representation
In general, and talking without knowing the specifics here (so, ignore me), this situation sounds like a good candidate for closures. I.e. associate a function to each object, which governs what can and can't be done with the object in each point in time. The associations between objects and these functions can be determined by some sort of deterministic event-driven state machine, I'm guessing. "linkset attached to avatar" ==> all objects in linkset moved to state "attached", whose associated function says "no sitting here".What this gives you is a way of changing the object semantics dynamically without sprinkling the code with conditionals -- just change its function. Semantically equivalent to changing the class at run-time.But that's just me talking without having read any of the previous discussions.Stefan Andersson wrote: 



Sean, ace of you to take this up. I'm starting to think that we need to come up with a process to figure this out, rather than just figure it out, because everytime we start thinking of it, you start walking in circles. I know from experience, and Darren and I just had one of those tangly discussions where we tried to make heads and tails of the whole object graph, where objects change their properties and the semantics of their properties due to how they are used. (ie, scenes have linksets, that have objects, that have child objects,  that have avatars sitting on them, that have attachment points, that have attachements, that are linksets, that has root objects, that has child objects... you can't sit on an attachment, can you? Please, dear god?) Combine this with our needs a) to be SL conformantb) to have as sleek an API as possible andc) to have efficient storage and exchange of content and we have an alphabet soup to transform into a sonnet. Could we set up a wiki page where we could all pour our knowledge into it, with suggestions and experiences? /Stefan

> Date: Fri, 8 Feb 2008 08:02:53 -0500> From: sean at dague.net> To: opensim-dev at lists.berlios.de> Subject: [Opensim-dev] Object Representation> > Per request, lets run with the thread here. The question at hand is> database refactoring, which well all agree needs to be done. The reason> it hasn't been done so far is because it turns out we end up with> objects at least 4 different formats, needed for different things.> > Object on the Wire - this definition comes from libsecondlife> Object in the code - SceneObjectPart / SceneObjectGroup> Object at rest - Database tables (which actually vary between db> backends)> Object in XML - we have 2? versions of this already.> > One of the challenges in getting to a grand unified scheme is that> all those representations are in some ways equal. Today they are> divergent enough that a lot of work is required at times to chunk them> into one form or another.> > So, here is your chance to be a hero in the OpenSim world. :) Ideas on> how to reasonably pull all this together to give us a much more> consistent serialization approach are very welcomed. Please pile on.> > I think that solving this is probably our next big battle. I'm excited> to see the NHibernate work getting very close, as I think that's a huge> step forward in this regard. This probably also means we need to bring> up the SOP/SOG discussion that Stephan wanted to kick off as well.> > -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.> __________________________________________________________________
_______________________________________________
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/20080212/b27bb93b/attachment-0001.html>


More information about the Opensim-dev mailing list