[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensim-dev
Subject:    [Opensim-dev] [Proposal] Separate SceneObjectGroup/Part into separate classes/interfaces
From:       adam () deepthink ! com ! au (Frisby, Adam)
Date:       2009-07-19 9:33:32
Message-ID: 63FAD4F222230A4EA79DE9E8BE66473520959F3E () winxbeus19 ! exchange ! xchg
[Download RAW message or body]

Look at MRM.IObject - seriously.

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Saturday, 18 July 2009 11:27 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] [Proposal] Separate SceneObjectGroup/Part
> into separate classes/interfaces
> 
> A clear and loud +1 on getting started on removing this SOG/SOP
> hierarchy thing.
> The basic "node" could be stripped down to position, rotation,
> scale, parent, children and a few more things, with the prim stuff
> being in it's own class like Inventory was already moved out.
> 
> Accessors for the common, and frequently used, things like inventory
> would keep things moving at a manageable speed, so I'm also all for
> that.
> 
> I don't now about the interface registry, I'd rather see this
> "minimal" class be a base class from which more specific classes
> inherit and that handles the connections to Scene and the linking
> stuff. Seems more sensible to make this most used entity be fast,
> specific subclasses rather than registered interfaces. But... a
> subclass could offer that registration method if it needs to be that
> extensible......
> 
> Melanie
> 
> MW wrote:
> > Both SceneObjectGroup and Part are growing beyond manageable sizes
> (with both of them over 3000 lines long), and are not very easy to
> change when trying to make custom classes bassed on them (as I think
> Sean found out recently during his attempts).
> >
> > Ideally I think we would all like to see the separate Group and Part
> architecture replaced with a architecture that was more like a Node
> based scenegraph , and had a hierarchy of SceneObjects. But I think we
> all know of the problems in doing that, and how much work is involved.
> >
> > So as a small step in (hopefully) that direction, I propose to start
> splitting those two classes up, and having something similar to the
> interface registry we use in various of parts of the architecture.
> (RegisterInterface<type> , RequestInterface<type>() ).
> >
> > So things like the methods for editing prims would move out into a
> separate class; for example ISceneObjectGroupEditing. And then when the
> scenegraph wants to call a editing method on a Group, it can call :
> >
> > Group.RequestInterface<ISceneObjectGroupEditing>();
> >
> >
> > I believe that this will at least make the code more manageable and
> make those classes easier to customise. I also hope that it will make
> it easier to head towards a new combined architecture for prim
> handling.
> >
> > The draw back could be performance, as we will have the overhead of
> calling those methods to request the correct interfaces. Although we
> could do the same as we do in scene and have properties that can access
> the common interfaces. (eg. SceneObjectGroup.Editor)
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > 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


[prev in list] [next in list] [prev in thread] [next in thread]