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

Fri Aug 14 06:49:45 UTC 2009

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
>> 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
>   