[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Sat Dec 19 08:36:29 UTC 2009

On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <adam at deepthink.com.au>wrote:

> ·         Enable full inheritance & linking (ie, hierarchical linking)
>

This is terrific news, Adam!

There's a bunch of us who have been "hierarchical object activists" in SL
for some years, regularly trying to get the benefits of hierarchical objects
across to Linden developers at their Office Hours.  We have a wiki page on Prim
and Object Hierarchy<https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy>,
and a number of Jiras also address the issue, including
MISC-428 <http://jira.secondlife.com/browse/MISC-428>,
MISC-1434<http://jira.secondlife.com/browse/MISC-1434>,
and MISC-2237 <http://jira.secondlife.com/browse/MISC-2237>.

We've been successful *on the principle* (several LL devs now support it
wholeheartedly) but not in practice, because the development process within
the Labs appears to be quite logjammed and stifled so that individual
developer opinion has no effect.  As noted on the wiki page above though,
Lindens *know*  that they made a mistake in not supporting object
hierarchy.  They just can't do anything about it now.

Hierarchical objects provide many different types of benefit, so you'll hear
different people advocate different aspects about them, but they're all
complementary.  My angle stems from the needs of pure engineering, in that
hierarchical object composition is the basis of all engineered products in
RL.  Almost everything in modern life is manufactured by putting
together *complex
components*, not from raw materials, and that's how you ride on the
shoulders of giants.  You can't do that in SL.

It's wonderful to see hierarchical objects finally gaining in profile in
Opensim.  Is there a design for this?

We've been examining the pro's and con's of various approaches, including
evolutionary ones that extend the current very poor linkset paradigm, as
well as new designs that either encapsulate linksets transparently or else
create a completely new and separate hierarchical object system in parallel
with the current non-hierarchical one.  Each approach has its own advantages
and disadvantages.

More info on your current thinking would be very welcome.  Designs tend to
stick around for longer than planned, and getting it partially right from
the start would be a good idea.

Morgaine.

==============================

On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <adam at deepthink.com.au>wrote:

>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20091219/c8462272/attachment-0001.html>