[Resending since previous bounced without membership of realxtend-dev] Toni Alatalo wrote: > Melanie wrote on 18th July 2009: > > (am cc'ing rex-dev to inform the devs here who follow that but not > opensim-dev, we talked about this in RL here yesterday, but propose that > the discussion will be continued on opensim-dev) > >> 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. >> > > Has this been worked on already?
No code has been writing, afaik, just discussions. > > We have now had a short two week research period at Realxtend, now that > everyone returned from holidays, and next week we'll plan the work for > coming autumn and the rest of the year. > > One issue we have is the Opensim scene object data model. For the viewer > side, we designed and implemented an Entity-Component model in spring - > this part of the design doc (written in February and implemented in > Naali later) is > http://wiki.realxtend.org/index.php/NG_Design_Document/Viewer_Architecture/Framework#Component_based_World_Object_design > > Instead of a base scenenode class, that model uses aggregation: an > Entity is just an identity, which can refer to any components it wishes > to use. One example is what you say above: position, rotation and scale > -- those are currently implemented in Naali as the Placeable component. > So any entity which wants to have those props can have that component, > currently that is avatars and prims. But also e.g. the terrain and the > water skybox are entities. > > Prim data we haven't splitted into many different components, but now > there is a single component for that data: > http://www.realxtend.org/doxygen/viewer/class_rex_logic_1_1_e_c___open_sim_prim.html > > The idea is that with that Entity-Component model we can have all kinds > of data, like the Ogre material properties or whatever physics settings. > Even that an application can define own custom components, which the > uniform system could then store and transfer, and the application code > could handle how it wants. These components are just passive data, no code. > > The question for Opensim developers is: would this kind of design be a > good target in the SOG/SOP etc. refactoring? On the surface this sounds like a good approach - keep a minimum structure in the objects and bring everything else in via composition. Out of interest, have you thought about a Model-View-Controller approach to this problem? > > In coming Realxtend work there is increasing pressure for being able to > easily extend the data there is about the objects in worlds. This is not > for any specific application only, but specifically to allow all kinds > of applications. In that sense it would seem to fit the Opensim goal > well, being a generic platform for many apps and not only a SL impl. But > for us it would also support the immediate specifics in Rex, like Ogre > animation data etc. > > There is basically two places where we'd need the server to support > arbitary data: 1. in networking and 2. for storing. Also of course it > would have to be within the Opensim internals so that scenes with the > data like that would still function, the actual running of the > simulation like movements and physics etc. Personally, I think that we should support arbitrary data directly but I know other core developers have concerns about this (such as performance ones). This is probably a topic for debate. > > One option is that we make a module that implements an additional > network connection to the client with another protocol that communicates > the scene object data, with basics like movements remaining in SLUPD as > they are. In this case the module could also use some own storage system > for storing the data too. But in this case similar(?) basic information > about objects would be in two places .. dunno if/how bad that would be, > we'll have to examine this more I think. Intuitively, having two sets of data stored in different places feels nasty - really something to be avoided I should think. > > But if we could refactor the core Opensim scene to this design, and > implement the core storage mechanism so that it'd support additional > data (or even arbitary custom app specific data?), it would be just a > matter of different ClientViews .. SL view communicating just the prim > data as it currently does, and Rex view communicating Ogre and/or > arbitary data in the E-C style, possibly using some other protocol like > MXP and/or Google protocol buffers, or an own solution. > > We still have enough tasks to keep us busy easily for the next month or > so without this, but need to get this ball rolling at some point -- > possibly later in the autumn. This is basically just a heads-up to > inform opensim devs about what we have in the client now, and what would > need from the server, to get initial reactions and ideas about how it > might be good to start with this. If there is a feasible roadmap towards > this within Opensim, I imagine we would do the bulk of the work, of > course appreciating all the help that could get. I'm a bit afraid of the > SOG/SOP monster having heard about the difficulties in changing it, but > I guess we'll have to see that as an argument *for* a refactor and not > against it. At least Realxtend can not be stuck with the SL scene model > forever. I think it would be fantastic if Realxtend could help lead the way on a SOG/SOP refactor in partnership with the other interested devs. The best thing would be to develop a roadmap in co-operation rather than wait for one to happen. The topic of SOG/SOP refactoring has been kicked around before in this mailing list - not just this time - but no-one has had the resources to go forward with it. > >> 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...... >> > > So in our design the base Entity is so minimal that it doesn't have any > data, just an identity with pointers to mostly minimal data components > like Placeable for pos&rot&scale, and larger data like Prim. No > interfaces are used, but the extensibility is achieved by aggregation. > >> Melanie >> > > ~Toni > >> 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@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- justincc Justin Clark-Casey http://justincc.wordpress.com -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
