[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Tue Dec 15 16:24:37 UTC 2009

Not too too painful. The vast majority should be cut&paste-able.

The big stuff will be people who have code tied to SOG/SOP on any deep level - however again, a lot of it should be transportable; it's going to require a healthy amount of refactoring unfortunately however.

I had a longer reply to this which is still sitting open - I'll get to it once I finish a little accounting work.

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Tuesday, 15 December 2009 8:05 AM
> To: diva at metaverseink.com; opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing
> Components
> 
> Hi,
> 
> in fact, yes. Anyone who has private modules is in for a rather
> painful rewrite. That goes double for SOP/SOG extensions.
> 
> Ommelettes and eggs...
> 
> Melanie
> 
> diva at metaverseink.com wrote:
> > I have a question. How does this impact, if it does, extensions of
> > SceneObjectGroup? For example, I have a traffic simulation where
> > Vehicles extend SOG. How will this be affected? Will I be using
> > components instead?
> >
> > Frisby, Adam wrote:
> >> Bumpity Bump. If I don't hear any comments on this, I'm going to
> assume
> >> the proposal is sound and have carte blanche to break OpenSim at my
> >> whim. ;)
> >>
> >>
> >>
> >> (find the original post for the attachment.)
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Adam
> >>
> >>
> >>
> >> *From:* opensim-dev-bounces at lists.berlios.de
> >> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Frisby,
> Adam
> >> *Sent:* Friday, 11 December 2009 3:48 AM
> >> *To:* opensim-dev at lists.berlios.de
> >> *Subject:* [Opensim-dev] Refactoring SceneObjectGroup - Introducing
> >> Components
> >>
> >>
> >>
> >> Hi Folks,
> >>
> >>
> >>
> >> I've got a fairly complicated proposal to deliver here today - the
> short
> >> of it is; I'd like to go ahead and replace the current Scene Object
> >> representation model - at a fairly comprehensive & complete level.
> Some
> >> of you have had the misfortune of working with
> >> SceneObjectPart/SceneObjectGroup and should understand what I am
> talking
> >> about.
> >>
> >>
> >>
> >> There are several stages to this proposal - but I would like to talk
> >> about today the first big one (and a small outline of the larger
> project
> >> - the reason for this being some of the later details require a
> little
> >> more nutting out before I have a complete proposal for them).
> >>
> >>
> >>
> >> So - the larger proposal in a nutshell; I would like to:
> >>
> >> *         Merge SceneObjectGroup & SceneObjectPart
> >>
> >> *         Enable full inheritance & linking (ie, hierarchical
> linking)
> >>
> >> *         Make programming with SceneObjects possible & reasonable
> from
> >> the outside (ie have a clean API).
> >>
> >> *         Provide the ability to extend SceneObjects with
> "components"
> >> to introduce new properties and behaviours.
> >>
> >>
> >>
> >> The item I'd like to talk about today would be implementing
> Components.
> >> Components are small C# classes that may be attached to any
> SceneObject
> >> arbitrarily.
> >>
> >>
> >>
> >> A component is any class inheriting from IComponent - IComponent
> carries
> >> only two properties; a serialisation property (returns the current
> >> 'state' for serialisation purposes), and a type property (which
> >> recognises the 'type' of component that it is) - components allow
> you to
> >> attach arbitrary data to an object for the purposes of interacting
> with
> >> a region module. For instance, a "Mesh" module (which is my current
> best
> >> example) would have a MeshComponent that included all the extra data
> to
> >> tag an object with related to meshes - which would get serialised
> and
> >> passed around with the main object. When deserialized - a "Factory"
> >> handles making sure the MeshComponent is deserialized with the main
> object.
> >>
> >>
> >>
> >> I've attached a document which is my current state of the whole
> proposal
> >> which includes some examples & more detail. Please note that Phase 2
> is
> >> not finalised yet - and some decisions were discussed about changing
> two
> >> facets in particular.
> >>
> >> *         Enabling inheritance of components+sceneobject to make
> >> speedy-classes for common use cases (eg PrimObject inherits
> >> PrimComponent and SceneObject)
> >>
> >> *         Allowing more than one factory potentially; for
> manufacturing
> >> said speedy-classes.
> >>
> >> *         Note that these shorthand classes would still use the
> standard
> >> .Has / .Get methods; they would just return 'this' where the
> particular
> >> component type is concerned.
> >>
> >>
> >>
> >> To begin with - I would like to implement components as an extra
> >> non-serialised property of the SceneObjectPart; this will occur very
> >> shortly after 0.7 is tagged; which I would like to do once ROBUST
> covers
> >> all the main services (I heard something about late-december/early-
> jan);
> >> this first stage should not break anything in particular - however
> once
> >> that Is complete, I would like to migrate properties into components
> in
> >> order to modularised the codebase better.
> >>
> >>
> >>
> >> An example of this would be PrimData - primdata is unique to the
> Second
> >> Life use case, and irrelevant to others; in this case, we'll move
> >> PrimData into a commonly accessed component (eg
> >> "SceneObject.Get<PrimData>.Hollow = 0.9f;") - once the move to
> >> components is complete for the common data; then creating the final
> >> SceneObject class which merges SceneObjectGroup+Part should be a
> fairly
> >> painless process.
> >>
> >>
> >>
> >> Please take a read of the document attached for more information -
> and I
> >> am very keen to hear anyones thoughts as to use cases that this
> model
> >> will make more difficult; or could not support. The goal with this
> >> project is to make OpenSim support more with less - allowing third
> party
> >> modules to really take OpenSim as a framework to the next level; and
> >> make a more modular server for other clients & platforms.
> >>
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> Adam
> >>
> >>
> >> --------------------------------------------------------------------
> ----
> >>
> >> _______________________________________________
> >> 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
> >
> >
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev