[Opensim-dev] SOG/SOP

[Michael Wright]

Yeah I'm not completely against the single object idea. I think each method has its own problems. 

I actually think this is most likely one place where we should use branches so different ideas can be tried out/prototyped without effecting trunk. I know there will be the problems with merging the changes back into trunk. But I think here that is most likely the lesser of the evils. As its a very complex and large task to do such changes in trunk. Also I think we would need a least some prototypes of ideas before we got everyones agreement on any approach.

Melanie <melanie at t-data.com> wrote: I'm against the SOG, personally. I think a clean SceneObject can 
have group methods and object methods. SOG is one reason the 
link/unlink code is such a hack!

SOG is also a showstopper for a clean hierarchical linking 
implementation. The need to handle root objects differently from 
child objects is a real bother and causes lots of issues with 
referential integrity.

An architecture using only one class would be much cleaner, and 
present a cleaner interface.

SOG is also at the root of such issues as incorrect object updating 
to the viewer, loss of child prim inventory, and, actually, every 
issue related to child prims vs. root prims.

Considering that a group can be deleted, translated, rotated and 
scaled,and not much else, those methods would not create too much 
overhaed on a SceneObject, as it would delegate them to it's parent.

That is only a small handful of if/then, since, for most operations, 
all prims are created equal.

We could still limit the Entities list to root objects, to keep it 
tolerably small.

Melanie


Michael Wright wrote:
> Yeah, at the time we wrote the SOG/SOP, I was quite unsure about having the SOG rather than just linked SOP. But even though the current system has big problems and does need changes. I'm now of the mind that something like the SOG is most likely a good idea. As stefan said the problem with a set of linked SOP's is that there would be so many if/else in there, 
> 
> The idea of the SOG, is that if you want to deal with the whole link set (or root) then you could use the SOG, but if you want to deal with one of the separate prims in that group, then you can get its SOP.  Now we all know that things haven't worked out that well. But I'm not sure that is a problem with the actual idea. Just a issue with the implementation and new bits being added over time.
> 
> Stefan Andersson  wrote:    .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma }  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 Andersson
> Tribal 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
> 
> 
>  Send instant messages to your online friends http://uk.messenger.yahoo.com 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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


 Send instant messages to your online friends http://uk.messenger.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080829/968974b4/attachment-0001.html>