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? 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? 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. 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. 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 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 >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ > 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
