[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Sat Dec 19 18:08:56 UTC 2009

It's in the PDF attached to the original post - basically we merge SceneObjectGroup+Part together; then make it possible to chain them directly.

IE:
SceneObject.Parent
SceneObject.Children[]

Then you can represent hierarchies by making a group a parent of another group.

Adam

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Morgaine
Sent: Saturday, 19 December 2009 12:36 AM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <adam at deepthink.com.au<mailto: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<mailto: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<mailto: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/f58650eb/attachment-0001.html>