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:* [email protected] > [mailto:[email protected]] *On Behalf Of *Frisby, Adam > *Sent:* Friday, 11 December 2009 3:48 AM > *To:* [email protected] > *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 > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
