Well where it gets complicated is when all the children need to have references to their parents. So that the proper positions etc can be set.<br><br>That was another task of the SOG, to keep track of the children and make sure the correct position etc were resolved for the children. <br><br>What we had before the current SOG/SOP was a SceneObject that could have child SceneObjects. But it got very complicated. But again its likely that was due as much to the implementation, as to the idea. <br><br>But its actually been a while since I've had a really good look at the current SOG/SOP so I guess I should do that and see exactly what is happening where, before I comment too much.<br><br>I think one thing we all agree on is that the current setup has problems and there has to be a better way of doing it. <br><br><b><i>Sean Dague <sdague@gmail.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px;
padding-left: 5px;"> Michael Wright wrote:<br>> 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, <br>> <br>> 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.<br><br>I'm not sure how this is incompatible with having recursively defined<br>SOP (which I think simplifies both cases), or even better just<br>SceneObject
(lets get rid of this group / part nomenclature).<br><br>As long as SceneObject has recursive ability to have children you could<br>get any level of linking in the prim case, and in the non prim case,<br>you'd have no children. Though in reality I think that mesh integration<br>will still probably want to link messes together to make composite objects.<br><br>Is there something I'm missing that's actually special about SOG that<br>couldn't be done in this way?<br><br> -Sean<br><br>--<br>Sean Dague / Neas Bade<br>sdague@gmail.com<br>http://dague.net<br><br><br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote><br><p> Send instant messages to your online friends http://uk.messenger.yahoo.com