[Opensim-dev] Should SOG and SOP be combined into a single object in a linked hierarchy?
Justin Clark-Casey
jjustincc at googlemail.com
Tue Nov 11 14:50:41 UTC 2008
Stefan Andersson wrote:
> 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 )
Melanie is proposing a hierarchy of a single object - a degenerate Composite. I'm not sure how much a separate
'linkset' object implementing the same interface would add. I suspect that the implementation of stuff like linking and
delinking could be done recursively with a fair degree of elegance.
>
> 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)
>
>
> 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.
I suspect this is going to be done directly in trunk. If there are any concerns with this then they need to be raised
imminently.
>
> Best regards,
> Stefan Andersson
> Tribal 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-dev
mailing list