[Opensim-dev] [Fwd: Re: custom scene data (Re: [Proposal] Separate SceneObjectGroup/Part into separate classes/interfaces)]

[Justin Clark-Casey]

[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 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
>>   
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at 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