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

[Dahlia Trimble]

Would this proposal allow linksets to be children of other linksets?
(assuming we would ever want that)

On Mon, Nov 10, 2008 at 8:08 AM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> 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/6765fc39/attachment-0001.html>