[Opensim-dev] SOG/SOP

[Melanie]

I believe we should have precisely one internal object representing 
precisely one scene object. I am against keeping SOG, and it's 
horrible "RootPart == null" checks the code is peppered with. I 
believe every object should have a children list, that would be 
correct for hierarchical linking, and a parent. Root objects have a 
zero parent.
The data of the object should be in a separate object, inheriting 
from a common base or implementing a common interface, so that each 
of those "NewPrims" can represent a prim, or a mesh, or whatever 
else we would add.
Translating into protocol elements should be the responsibility of 
the ClientView used, since only it knows how to do so.

We have by now collected enough information on the actual properties 
an object needs to have to make the simulation work. Now we could 
design an abstract wrapper that has all the "must have" properties, 
but in a protocol-independent form.

Steps to achieve that could be, unless we branch for it:
Refactor the existing SPG into SOP. Make SOP have a child list. That 
is something I was planning anyway, to get hierarchical linking.

Then, sort this SOP's porperties by protocol independent and 
protocol dependent ones. and finally move the protocol dependent 
ones (e.g. those defining a prim as LL sees it) into a prim class.

So, instead if Scene->SOG->SOP ... we'd have Scene -> SOP -> 
ObjectData<Prim> ...

I really should do this up graphically, but I lack the time.

Once that is achieved, implementing things like "ObjectData<Mesh>" 
would be easy.

Melanie


Stefan Andersson wrote:
> I believe it's time to take that old discussion up again.
>  
> The mess called SOG/SOP that we have get to know and love came out of a simple question:
>  
> * How would we, as application providers, like our object model?
>  
> Now, 'we' at that time was mostly me and Darren, so empirical data and peer input was rather scarce.
> Anyway, at that time, I was still an LSL coder, and one of the things I really hated with LSL was the object model - the notion that an object could change 'role' and thus, you always had to if-then around cases like, 'is this a single object', 'is it a linkset?', 'is it the root object', 'is it attached?' in your code - adn where stuff like 'position' always changed meaning depending on the context. That's what I call 'if-then' coding. And it's bad.
>  
> So, when reviewing how scene content was organized, we thought 
>  
> "we really should have a hierarchihcal model internally, where objects do NOT change behaviour and property meaning. And that model should be rendered into protocol-specific representations at the endpoint, ie, in the clientview."
>  
> I still think that having an object that represents the object in scene, as opposed to having ten scene objects magically linked on 'root' id is a good idea - especially when considering stuff like mesh-enabled objects, where 'child prims' simply does not apply.
>  
> But this time, maybe we should get more discussion. I bid you all ventilate your ideas. And references to other 3D models, and suggestions incorporating how grid, region, scene, avatars, attachments, mesh objects and linksets can work togehter in a single, simple API paradigm are extra welcome. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev