[Opensim-dev] Should SOG and SOP be combined into a single object in a linked hierarchy?

[Stefan Andersson]

I guess what we need is something like the composite pattern, perhaps? (not that this I'm toying with here is the kosher GoF 'composite')
 
One thing we stated a long time ago was that we wanted all scene nodes to register all objects, so that stuff like "delete(id)" could be done efficiently and directly. But at the time, we thought it better to iterate over the node tree as that was considered the "safe" way.
 
Basically, what I'm thinking is that maybe the leafs (prims) and the composites (linksets) could co-exist as peers; the linksets being more of 'helpers' - something that is used to orchestrate linkset-wide operations like linking and delinking. The composites should subscribe to leaf operations via events, so as be able to function independently. (for example, if something deletes an object from the 'flat' scene )
 
I guess the same would go for 'avatars' - the avatar would be a helper to manage attachment operations, but do so by delegating and triggering leaf operations. (composite is also a leaf, remember)
 
interface IWorldLeaf
{
   AbsolutePosition (In world coordinates, could be recursively calculated from RelativePosition + Parent AbsolutePosition)
   RelativePosition (Relative to Parent, which would be the region for a root, or the attachment point for an attachment)
 
   Ungroup()
   Group( IWorldComposite )
}
 
interface IWorldComposite : IWorldLeaf
{
   Add( IWorldLeaf )
   Remove( IWorldLeaf )
 
   Children;
}
 
class LLPrim : IWorldLeaf
{
   IWorldComposite m_parent;
 
   event OnDeletion;
 
   public LLPrim( )
   {
 
   }
 
   public Create()
   {
       
   }
}
 
class LLLinkSet : IWorldComposite
{
  LLPrim m_rootObject;
 
  Add(IWorldLeaf leaf)
 {
    leaf.OnDeletion += LeafDeleted;
 }
 
  Remove(IWorldLeaf leaf)
  {
    leaf.OnDeletion -= LeafDeleted;
   }
 
   private LeafDeleted( IWorldLeaf );
}
 
class LLAvatar : IWorldComposite
{
    LLAttachmentCollection m_attachments;
 
   bool TryAddAttachment( int position, IWorldLeaf )
   {
   }
}
I'm starting to think maybe a small proof-of-concept application just implementing a couple of simple operations on a model level would be a good thing, so we can toy around with code.
Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ > Date: Mon, 10 Nov 2008 16:08:15 +0000> From: jjustincc at googlemail.com> To: opensim-dev at lists.berlios.de> Subject: [Opensim-dev] Should SOG and SOP be combined into a single object in a linked hierarchy?> > Somewhat separately from Adam's other post, I'd like to raise this issue on the mailing list since it keeps popping up. > I'll confess that I'm not 100% convinced yet that SOG and SOP should simply be combined, though I do accept that the > code does need some architectural changes. Unfortunately, I'm not quite up to drawing diagrams yet.> > This discussion may also have come up on the mailing list in some way before so references are welcome, as are > clarifications to the statements below.> > Melanie's proposal, as I understand it, is to combine the current SOG and SOP into a single object (let's call it > LLEntity). LLEntity's would be linked into a tree, so there can be something like> > > LLEntity> / | \> / | \> / | \> / | \> LLEntity LLEntity LLEntity> |> |> LLEntity> > > > Here are some of the pros and cons as I see them. Adam has already talked about some of these in his blog post.> > Pros> > 1. At the moment we can only have one level of prim linking (as effectively dictated by the LL Second Life client). > Linking into a tree would allow multiple levels of linking (though with the assumption of single parents).> > 2. It makes manipulation of prims much easier. Instead of having to reference SOPs in and out of SOG, everything is > done on a single class. Some properties can be set on a SOP reference without having to worry about whether they are a > root SOP or not (see below).> > 3. The Second Life client protocol wants to manipulate SOPs directly in many situations (e.g. individual prim selection > of a group, the fact that local ids are passed around that reference prims rather than linksets).> > 4. Get rid of the root part checks on object deletion. However, a lot of these come from the fact that we null out > m_rootPart after object deletion when there may be no need to - I'm anticipating that extraneous info sent to a viewer > about a deleted object will be simply ignored. This is a change we should try soon now that we're at the start of a > release process.> > > Cons> > 1. LLEntity becomes very large and potentially complex. SOG and SOP are already large and complex. It may be possible > to improve this by further refactoring.> > 2. Every setting and getting of a property in LLEntity has to delegate up to its root LLEntity unless it is the root. > Therefore, code such as> > public virtual Vector3 Velocity> {> get { return m_velocity; }> set { m_velocity = value; }> }> > becomes something like> > public virtual Vector3 Velocity> {> get> {> if (ParentEntity != null)> return ParentEntity.Velocity;> else> return m_velocity;> }> > set> {> if (ParentEntity != null)> ParentEntity.Velocity = value;> else> m_velocity = value;> }> }> > One also needs to be careful to set the publicly available property so that delegation happens if required, rather than > the private field to avoid state such as 'attached' becoming inconsistent (this is a potential source of bugs).> > 3. It leads to an increase in property duplication at the database and serialization levels. Every LLEntity will have > a set of fields, even though some of those conceptually only apply to a linkset/SceneObjectGroup. This probably isn't > serious but I think that it will make things harder to work with at those levels.> > > This isn't a full set of pros and cons, just the ones that occur to me right now. I'm sorry this is a long post but I > feel that we need to a get a long form view of this as change here will stay with us for a considerable time into the > future. If there isn't any major discussion then this may go ahead anyway (since Melanie, for one, is quite keen and I > may be the only person really bothered about this).> > At the moment I'm actually leaning towards the single LLEntity suggestion, though I'm a little concerned about the > duplication that ends up at the database/serialization level. But I'd really like to hear what other people think.> > -- > justincc> Justin Clark-Casey> http://justincc.wordpress.com> _______________________________________________> 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/20081110/4360e828/attachment-0001.html>