[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

[diva at metaverseink.com]

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